[12:20] <bradley> IN: thanks for all the help on getting this bug rolling.  I guess I also curious for a more in depth explanation of your reasoning purely for education
[12:20] <IntuitiveNipple> From what I've read of the upstream kernel.org bug report, they initially (back in 2006) thought it was ACPI but then narrowed it down to the X server, then got confused as lots of other similar reports were attached to the bug, and finally marked it as "insufficient data"
[12:21] <IntuitiveNipple> It'd be good to run a debug kernel on that PC, see what else it reveals
[12:23] <bradley> maybe this isn't important, but when you said you read a post on Fedora forums..I was playing with fedora7 when it came out and didn't have this problem
[12:23] <bradley> Suse, when I played with it for a week or so didn't show this issue either.
[12:24] <bdmurray> bradley: How do you normally shutdown the system?
[12:25] <bradley> normally i shut it down graphically....click the icon that brings up log out, restart, shutdown, suspend, hibernate, etc, and then click shut down
[12:26] <bdmurray> bradley: without logging out though?  It might also be interesting to see what happens if you log out and then shutdown.
[12:26] <IntuitiveNipple> bradley: Can you add the PC's ACPI DSDT to the bug, just in case, with "sudo acpidump -t DSDT > DSDT.aml; tar -cjvf DSDT.aml.tar.bz2"
[12:27] <IntuitiveNipple> bradley: If you need to install acpidump: "sudo apt-get install acpidump"
[12:29] <bradley> lol its "cowardly refusing to create en empty archive
[12:29] <IntuitiveNipple> bradley: when I can find time I'll build a debug-version of snd-hda-intel you can test. What kernel-version are you using day-to-day ?
[12:30] <IntuitiveNipple> bradley: you may need to separate the commands I gave you into separate lines :)
[12:30] <bradley> i tried that as well
[12:30] <Nafallo> sudo -i and then the commands.
[12:30] <bradley> same error
[12:30] <Nafallo> sudo can't > things
[12:30] <IntuitiveNipple> acpidump, is it creating a DSDT.aml ?
[12:30] <bradley> fanafallo: i know that much :)
[12:30] <IntuitiveNipple> Nafallo: it can, and did, I tested it here first
[12:31] <bradley> yeah, it created the aml
[12:31] <Nafallo> when did it learn that? :-)
[12:31] <zul> evening
[12:31] <IntuitiveNipple> bradley: ok, use "tar -czvf DSDT.aml.tar.gz DSDT.aml"
[12:32] <bradley> ok, that worked, ill attach it
[12:32] <IntuitiveNipple> (it does help to specify *what* is being put in the tar) lol *slaps self*
[12:33] <IntuitiveNipple> I was doing some suspend/resume hacking of snd_hda_intel a few weeks ago so that module source-code is still fresh in my mind
[12:34] <IntuitiveNipple> bradley: when I can find time I'll build a debug-version of snd-hda-intel you can test. What kernel-version are you using day-to-day ?
[12:35] <bradley> im using the latest gutsy kernel
[12:35] <bradley> against all warnings i know, but it's stable for me
[12:36] <bradley> bdmurray: before i applied the workaround no shut down worked for me, from desktop, loginscreen or otherwise, after i applied the work around, everything works
[12:36] <IntuitiveNipple> bradley: ok, that makes it easier for me then, I'll just build a debug-version from the git
[12:38] <IntuitiveNipple> bradley: Do you think you could clear  /var/log/kern.log then do a single startup/shutdown procedure (without the workaround script, so it fails to shutdown), and then attach that kern.log to the bug report?
[12:41] <bradley> yeah, can i disable the script through sysctlrc...that's not the right name, but its something like that
[12:43] <bradley> the program that allows me to see and edit what's running on which runlevels
[12:44] <bradley> otherwise ill just delete the scripts and remake them
[12:47] <IntuitiveNipple> bradley: You mean update-rc.d ?
[12:47] <bradley> yeah, i think thats what i meant, but im retarded sometimes.  ill just comment out the line that removes snd_hda_intel
[12:48] <bradley> that should make things not work again, and its much easier to put back to working
[12:48] <IntuitiveNipple> yeah :)
[12:48] <bradley> alright, i'll give it a go
[12:49] <lamont`> (compaq nw840)
[12:49] <lamont`> (compaq nw8440, even)
[12:54] <bradley> IN: ok, added the kern.log
[12:54] <IntuitiveNipple> bradley: I've just skimmed the DSDT for anything obvious, but nothing that stands out.
[12:54] <bradley> what does that imply?
[12:56] <IntuitiveNipple> There's nothing in the way of obvious ACPI DSDT faults apparent
[12:57] <IntuitiveNipple> This kern.log, it only has a boot-up sequence in it. I think the file we need is kern.log.0 - can you check?
[01:01] <bradley> sure, brb
[01:13] <bradley> ok, the kern.log.0 isn't cooperating with me.  i cleared it out and did a reboot etc, but now it's not filling wiht messages
[01:15] <IntuitiveNipple> bradley: ahh... maybe some confusion... kern.log is the logfile the system writes to, but when it 'backs-up' it moves it to kern.log.0
[01:16] <IntuitiveNipple> The kern.log you uploaded appears to have been generated during the start *after* the failed shutdown, so I guessed the log we wanted would be kern.log.0
[01:17] <bradley> that makes sense...hmmmm, ok, let me look around some more
[01:17] <IntuitiveNipple> Maybe do another start/shutdown sequence with a freshly cleared kern.log, and then check what you've got in both files when you restart
[01:18] <bradley> ok
[01:18] <IntuitiveNipple> bradley: hang on a minute....
[01:20] <IntuitiveNipple> I think I might be telling you the wrong log, I'm just looking at a notebook I use for ACPI testing and it looks like kern.log only gets updated during a suspend/resume, not a shutdown!
[01:20] <IntuitiveNipple> oops!
[01:25] <IntuitiveNipple> ha, you ran off before I could finish what I was saying!
[01:26] <bradley> ok a did a clean, shutdown, start, shutdown, start sequence.  kern.log.0 is still empty. kern.log _seems_ to have start, shutdown and start in it
[01:27] <bradley> unless im mistaken
[01:27] <IntuitiveNipple> I had just typed...
[01:27] <IntuitiveNipple> I think I might be telling you the wrong log, I'm just looking at a notebook I use for ACPI testing and it looks like kern.log only gets updated during a suspend/resume, not a shutdown!
[01:27] <bradley> sorry, this bug hunting has me all fired up
[01:28] <IntuitiveNipple> but you went! I'm used to loads of output for suspend/resume - I just assumed shutdown was as prolific! The only shutdown logging I can find is in syslog and its brief to the point of useless
[01:29] <bradley> yeah, now that you say it, kern.log IS all startup
[01:30] <IntuitiveNipple> there's all but nothing in any of the logs, except for 'tty exiting' messages
[01:33] <bradley> well thats disappointing
[01:34] <bradley> though i have to think signifcant progress now be made on this bug
[01:34] <IntuitiveNipple> I'm just digging to see if we can make it more talkative
[01:42] <bradley> by all means, i really appreciate you taking time out to help me with this.
[01:44] <IntuitiveNipple> According to the (convoluted) documentation, we use "sudo sysctl -w variable=value" to control the log-level of klogd, but when I do "sysctl -a" to report all the possible names I can't find a variable that sets the log-level!
[01:45] <mjg59> There isn't one
[01:45] <mjg59> All kernel output will be logged
[01:46] <mjg59> All you can change is whether stuff hits the console or not
[01:46] <IntuitiveNipple> Really? another case of the docs not matching reality! I saw "-c" but that is no good
[01:47] <IntuitiveNipple> Is there a way, without kernel recompiling, to increase the logging during shutdown?
[01:47] <mjg59> Any output from the kernel will be logged until klogd is stopped or the filesystem unmounted
[01:47] <mjg59> If you want more output, then you need to add more output to the kernel
[01:48] <IntuitiveNipple> I thought there was logging of driver-unloading etc., but there's almost nothing 
[01:48] <mjg59> We don't unload drivers
[01:48] <IntuitiveNipple> Well, stop them then
[01:48] <mjg59> That's after the root filesystem has been unmounted
[01:48] <IntuitiveNipple> ahhh
[01:49] <IntuitiveNipple> small round spherical objects
[01:49] <mjg59> You can edit /etc/default/halt
[01:49] <mjg59> And set it to "halt" rather than "poweroff"
[01:50] <mjg59> Then if you boot without the quiet option, you'll get any logging onscreen until the machine stops
[01:51] <IntuitiveNipple> The issue was to look for any messages during shutdown for bradley's Toshiba, which needs snd_hda_intel unloaded in order to shutdown cleanly, and it seems to be an X issue, since shutdown is fine if gdm is stopped first.
[01:52] <IntuitiveNipple> anyway, aren't you supposed to be on vacation?!
[01:52] <mjg59> Yes
[01:52] <IntuitiveNipple> can't keep away?
[09:53] <infinity> BenC: Kernel fix didn't happen, I guess?
[10:35] <kraut> moin
[11:00] <amitk_> kraut: did you find a solution to your problem?
[11:01] <kraut> amitk_: not really, i know that it is fixed in 2.6.22. that's why i'll now tryout the gutsy-kernel.
[11:01] <kraut> amitk_: i didn't found the exactly problem, because there were many changes in nfs-client between 2.6.20 and 2.6.22 :/
[11:01] <amitk_> true
[11:11] <kraut> amitk_: do you maintain the ubuntu-kernel?
[11:12] <amitk_> kraut: Not really, I am just a member of the kernel team.
[11:13] <kraut> amitk_: the question is, how long does it take. when i fill in a bug-report, until it is fixed in the feisty-kernel.
[11:13] <kraut> i've also mailed an emploeyee of netapp concerning this, but still waiting on an answer.
[11:13] <kraut> perhaps he could tell me the problem and wich fix is missing in the feisty-kernel.
[11:15] <amitk_> kraut: possibly. So I take it that it's not possible for you to migrate to the Gutsy kernel (in a few weeks after it stabiliizes)
[12:08] <bullgard4> In kern.log I obtain a line "Back to C!" between 'LATE suspend' and 'EARLY resume'. What stands 'C' for?
[12:14] <mjg59> It's a programming language
[12:15] <mjg59> It means that the resume code has transitioned back to the C language section, rather than the bit written in x86 assembler
[12:16] <infinity> It really needs a "Phew, we made it!" in there.
[12:17] <infinity> Every time a PC manages to boot past real mode, I think it's a minor miracle.
[12:24] <bullgard4> Ok. Thank you.
[12:25] <kraut> amitk_: not really, i need the new one for an urgent project :/
[01:41] <kraut> anyone tried out the gutsy-kernel on a x86_64 system?
[01:41] <kraut> it won't boot without any usefull message before it will scan the scsi-bus.
[01:53] <kraut> there is a problem concerning a lsi-logic controller :/
[02:18] <kraut> is it possible to change the magic key to something else then "print screen"?
[02:31] <kraut> lsi-logic is broken in 2.6.22 :/
[02:52] <BenC> infinity, doko: 9.22 being uploaded with fix for lpia build
[02:52] <infinity> Good timing, we were just talking about you behind your back.
[02:53] <infinity> BenC: Is your link fast enough to get it up before cron.daily?
[02:53] <doko> just talking =)
[02:53] <BenC> infinity: it's already done
[02:53] <infinity> Awesome.
[02:54] <BenC> we have a .orig.tar.gz now, so it's just a ~3Meg upload
[02:54] <infinity> Ahh, cool.
[02:54] <infinity> Shows how long it's been since I did a kernel upload. :)
[03:24] <zul> oh goody my wife is up
[03:41] <zul> BenC: ping there is a request to sync rt2400 source from debian should we even bother?
[03:48] <BenC> zul: nope
[03:48] <BenC> reject it as Invalid
[03:49] <zul> BenC: thanks
[04:58] <infinity> Bah, where did Ben go?
[05:14] <lamont> hrm... and -9.22 is in the archive.  sigh
[05:14] <infinity> lamont: Don't worry, there's another upload required ASAP. :P
[05:15] <infinity> lamont: (broken on lpia, which was the whole point for this upload)
[05:15] <lamont> heh
[05:15] <lamont> I expect my change will fix hppa finally (mailed kernel-team ml, etc)
[05:15] <lamont> mind you, testing that will take several hours...
[05:16] <lamont> where several is between 2 and 4
[05:17] <lamont> closer to 2, it appears.. (abicheck of 2nd-and-final kernel failed at 1:55:23)
[05:17] <lamont> so just including it should be fine.
[05:18] <lamont> (it won't be any _more_ broken than what's in -9.22) :-)
[05:19] <lamont> infinity: at any rate, I'll be afk for a bit, feel free to help my patch get from my git tree into the real one.
[05:20] <infinity> lamont: Not sure how much I can do on that front, short of bribing people with hookers and beer.
[05:20] <infinity> And I'm starting to run out of hookers.
[05:20] <lamont> good bribes
[05:20] <lamont> heh.  it's more of a "since you have to turn this for me, pls include lamont's latest. kthxbye"
[05:23] <lamont> and afk
[05:45] <doko> infinity: it fails again for the udebs after fixing the linux-libc-dev header
[05:47] <infinity> doko: Ugh.
[05:52] <kylem> doko, i can debootstrap a lpia chroot now?
[05:53] <kylem> doko, how does it fail?
[05:53] <doko> kylem: yes, see my email to distro
[05:53] <doko> you just need http://people.ubuntu.com/~doko/tmp/linux-libc-dev_2.6.22-9.22_lpia.deb for now
[05:53] <doko> for dev things
[05:54] <doko> make: *** [binary-udebs]  Error 1
[05:54] <doko> kylem: ^^^
[05:54] <kylem> dude.
[05:54] <kylem> not terribly helpful, that.
[06:07] <infinity> doko: You may have noticed some text on your terminal slightly before that error.. :P
[06:07] <doko> dilist=$(dh_listpackages -s | grep "\-di$") && \
[06:07] <doko>         for i in $dilist; do \
[06:07] <doko>           dh_fixperms -p$i; \
[06:07] <doko>           dh_gencontrol -p$i; \
[06:07] <doko>           dh_builddeb -p$i; \
[06:07] <doko>         done
[06:07] <doko> dpkg-architecture: warning: Unknown gcc system type i686-linux-gnulp, falling back to default (native compilation)
[06:07] <doko> [...]  repeated 100 times
[06:07] <doko> make: *** [binary-udebs]  Error 1
[06:07] <infinity> Still running the old dpkg, I see...
[06:07] <kylem> indeed
[06:07] <doko> kylem: better? looks like no udebs are produced, so just copying the config from i386 would be fine (I assume)
[06:07] <infinity> Though, in this case, it's helpful to point out that dpkg-architecture is being run a crapload of times. :)
[06:07] <doko> grep "\-di$" looks suspicious, missing architecture
[06:07] <infinity> dh_listpackages limits to the current arch, I assume.
[06:07] <infinity> Yeah.
[06:07] <infinity> That's precisely what it does, in fact.
[06:07] <kylem> doko, yes. d-i is completely absent.
[06:07] <doko>         dilist=$$(dh_listpackages -s | grep "\-di$$") && \
[06:07] <doko>         [ -z "$dilist" ]  || \
[06:07] <doko>         for i in $$dilist; do \
[06:08] <doko> ok, that works.
[06:08] <doko> kyle: how do I correctly increment the version number? just for producing a correct debdiff
[06:09] <kylem> debian/rules startnewrelease
[06:14] <doko> kylem: if you can commit this, and maybe prepare a new upload, tested that it works on lpia  http://people.ubuntu.com/~doko/tmp/linux-source-2.6.22.debdiff
[06:15] <kylem> 17:06:22 < kylem> doko, yes. d-i is completely absent.
[06:15] <kylem> the correct fix would be to add d-i...
[06:16] <doko> kylem: that can be done later, we just need linux-libc-dev for now
[06:16] <infinity> kylem: Yeah, the lack of d-i was intentional at this point.  BenC asked if I wanted udebs, I said "maybe later, don't care for now".
[06:16] <kylem> er, ok.
[06:17] <kylem> ... it's like a two line addition though...
[06:17] <infinity> (Who knows if we'll ever even build lpia installation media)
[06:17] <kylem> alright. fine.
[06:17] <infinity> Oh, if it's easy and guaranteed to work, just do it, then.
[06:17] <doko> kylem: as you like it, I can test build it here
[06:17] <infinity> Won't hurt to have 'em, just in case.
[06:19] <doko> infinity: it would be nice to have installer and/or live cd's just to offer something for testing
[06:19] <kylem> i'm hoping there are proper sdvs when these cpus become available...
[07:47] <zul> its in there somewhere :)
[07:49] <zul> oh i hate cvs
[07:50] <zul> hey BenC 
[07:53] <lamont> zul: the rebase option is at the bottom under 'if you have access to kernel.u.c', not up at the top for others...
[08:05] <bullgard4> What is meant by 'LATE suspend' of my agpgart-intel loadable module's message in kern.log?
[08:06] <mjg59> It's the portion of the driver suspend called after interrupts are disabled
[08:07] <lamont> mjg59: btw, remember how putting the gutsy kernel on my laptop made suspend work?  well, it doesn't now...
[08:07] <bullgard4> mjg59: Thank you very much for explaining.
[08:07] <lamont> somewhere between -5 and -8, -9 also b0rked
[08:08] <lamont> mjg59: is there a writeup anywhere that would give me clues on how to troubleshoot that?
[08:09] <mjg59> lamont: git bisect is probably the easiest
[08:09] <kylem> lamont, go to www.united.com, book a flight to heathrow, underground to kings cross, national rail to cambridge.
[08:09] <mjg59> Except you probably can't, because the kernels are rebased
[08:09] <mjg59> Which means the git history bears no resemblance to the release history
[08:10] <lamont> mjg59: any chance you have a compaq mumble8440?
[08:10] <mjg59> lamont: Nope
[08:10] <mjg59> I've a 6220, but that's previous generation
[08:10] <lamont> yeah
[08:11] <lamont> and smaller.
[08:11] <mjg59> Per-generation, the hardware is pretty similar
[08:12] <lamont> mjg59: bisect could still work for me, although it may be fun to get from the eventually-found commit to the actual commit... :-)
[08:12] <lamont> or if there were any bits that needed to be blacklisted/whatever to get it to work
[08:12] <mjg59> lamont: If it previously worked, then bisect is probably as good as you're going to get
[08:13] <lamont> ye
[08:13] <lamont> p
[08:13] <mjg59> You're just going to have to be handwavy in finding the last "good" kernel
[08:13] <lamont> yeah
[08:13] <mjg59> If we didn't rebase the tree, this would be a lot easier
[08:13] <lamont> why do we rebase the tree again?
[08:14] <lamont> I could see starting a new branch off upstream each time we release, and then merging all our stuff onto that new branch, that'd give us all kinds of good history...
[08:14] <mjg59> Ben finds it easier
[08:14] <mjg59> Whereas I find having to pull into a branch and then merge that murder inducing
[08:15] <kylem> lamont, the commit you want pulled is not in your tree.
[08:15] <lamont> hrmpf.
[08:15] <lamont> heh
[08:15] <lamont> pushing
[08:18] <lamont> pushed
[08:20] <mjg59> BenC: Could we not rebase the tree repeatedly? It makes it *much* harder to figure out whether regressions are due to our code or to upstream
[08:26] <kylem> it won't be rebased anymore now that 2.6.22 is out.
[08:27] <mjg59> kylem: Not even to 2.6.22.1?
[08:27] <mjg59> (Or other parts of the stable branch)
[08:28] <zul> have we actually pulled in 2.6.22.1?
[08:31] <makx> in debian yes :)
[08:36] <zul> nerver mine I answered my own question
[08:36] <zul> ergh
[08:39] <BenC> mjg59: it was pretty easy for me to test that by testing with stock 2.6.22 and with our 2.6.22
[08:40] <BenC> mjg59: in fact, I would argue that it's easier to see if it's us or upstream, considering we are rebased on top of stable 2.6.22 instead of intermixed with it
[08:40] <BenC> s/stable/stock/
[08:41] <mjg59> BenC: But we don't ship a stock 2.6.22
[08:41] <mjg59> What users know is "-5 worked, -7 doesn't"
[08:41] <mjg59> That's easy to map back to a tree that matches the development history, but very difficult to map to a rebased tree
[08:42] <lamont> mjg59: keithp says that one should never use 'git pull', instead one should use 'git fetch' and an appropriate merge
[08:42] <BenC> true, but even mapping it back to proper history wont help much, considering the amount of upstream kernel changes mixed with our uploads
[08:42] <BenC> actually, you can get decent history just looking at the changelog
[08:43] <kylem> keith is just being difficult, pull is just a fetch+merge.
[08:43] <lamont> BenC: creating a 2.6.22-9.23 _branch_ at the time of upload would preserve history for us
[08:43] <lamont> kylem: yeah, but he finds  that the merge is seldom the one he really wanted
[08:43] <mjg59> BenC: Given that the number of bisect jumps you need to do is log2 of the number of commits, it's not really a problem
[08:43] <BenC> lamont: well, it's pointless now since we wont be rebasing anymore
[08:43] <lamont> BenC: for the future, I meant
[08:43] <mjg59> lamont: That doesn't actually solve the problem in any case :)
[08:43] <BenC> lamont: good point, we can definitely do that
[08:43] <kylem> we have a branch, since we have a tag.
[08:43] <BenC> lamont: tags wont work?
[08:44] <lamont> mjg59: it renders it more-solvable, I expect
[08:44] <BenC> right, you can do "git-branch Ubuntu-2.6.22-9.23 Ubuntu-2.6.22-9.23"
[08:44] <lamont> would a tag add a reference to the un-rebased commits?
[08:44] <mjg59> lamont: The tree refers to a different history to the one in my local repository
[08:44] <mjg59> BenC: Tags won't work across a rebase in any meaningful way
[08:44] <mjg59> lamont: So it's impossible to pull/fetch/whatever
[08:45] <lamont> hrm.
[08:45] <BenC> mjg59: but if you're bisecting, then you are building kernels for the user or yourself and you can easily testing stock 2.6.22 vs ubuntu-2.6.22 :)
[08:45] <kylem> Subject: Accepted linux-source-2.6.22 2.6.22-9.24 (source)
[08:45] <BenC> kylem: I never uploaded -9.23
[08:46] <mjg59> BenC: You continue to have issues. It may be an interaction between a new upstream patch and one of ours. 
[08:46] <BenC> just so you know :)
[08:46] <kylem> BenC, hence it's still unreleased
[08:46] <mjg59> If a user has a good and a bad commit already (by virtue of knowing which package versions worked), that's going to make the bisect much easier
[08:46] <kylem> blef.
[08:46] <BenC> mjg59: if v2.6.22 works and HEAD doesn't, you can easily rebase between those two points
[08:46] <kylem> coffee.
[08:47] <mjg59> BenC: ?
[08:47] <BenC> mjg59: true, you miss the super rare case where an upstream commit during devel actually interacts bad with one of our patches
[08:47] <BenC> s/rebase/bisect/
[08:48] <mjg59> Well, yes, you can do that
[08:48] <mjg59> But it's not actually going to be significantly faster
[08:48] <BenC> it's not going to be slower either :)
[08:48] <amitk_> lamont: you might be suffering from bug #129226, perhaps?
[08:49] <mjg59> But, as you said, it misses one entire class of problem
[08:49] <amitk_> bug# 129226 even
[08:49] <amitk_> damn.. i can never quite figure out how to trigger the bot
[08:49] <BenC> mjg59: one extremely rare class, as I've never experienced it before :)
[08:49] <mjg59> BenC: I've hit it a couple of times.
[08:49] <BenC> amitk_: it's missing from this channel
[08:50] <BenC> mjg59: either way you do it, it doesn't give you full info
[08:50] <mjg59> ACPI is hard. Shopping time.
[08:50] <mjg59> BenC: Sure it does. One way actually reflects the history that we've published, and the other doesn't.
[08:50] <BenC> mjg59: without rebase, you wont know which patch of ours is interacting badly, and with rebase, you wont know which patch from upstream is the cause
[08:51] <BenC> mjg59: you still miss the info to know which patch of ours is interacting with a commit from upstream...unless I'm missing some detail
[08:51] <mjg59> I mean, in addition to it being a nightmare to remember to fetch into a branch and then use that as origin
[08:56] <mjg59> error: no such remote ref refs/heads/origin.old
[08:56] <mjg59> Ngh.
[08:57] <doko> \o/ 2.6.22-9.24
[08:57] <doko> infinity: wake up call ;-)
[08:57] <kylem> hopefully it builds on more than one flavour of amd64. ;-)
[09:40] <Nafallo> hmm.
[09:40] <Nafallo> sata_nv busted?
[09:40] <Nafallo> since like... feisty?
[09:46] <BenC> Nafallo: worked on my one system, even in feisty
[09:48] <Nafallo> BenC: are you aware if there are any bugs with sata_nv hangs? 
[09:48] <Nafallo> starts with: [  438.240000]  irq 7: nobody cared (try booting with the "irqpoll" option)
[09:48] <mjg59> Nafallo: Does /proc/interrupts claim that sata_nv is bound to irq 7?
[09:48] <kylem> ah crap, i'm a muppet. forgot to -mv the abi files to 9.23
[09:49] <Nafallo>   7:       9820     264076    XT-PIC-XT        libata
[09:49] <mjg59> Ok, that's a good start
[09:50] <mjg59> So for some reason, sata_nv doesn't believe that the interrupt was its
[09:50] <Nafallo> I got libata on 5,7,10,11
[09:51] <Nafallo> http://paste.ubuntu-nl.org/32273/ <-- mjg59 
[09:52] <Nafallo> I haven't really cared about the statement up until now that my two raptors arrived :-P
[09:52] <mjg59> Nafallo: The rest of dmesg would help
[09:54] <Nafallo> http://home.nafallo.info/bugs/sata_nv.txt
[09:56] <Nafallo> mjg59: feisty running now. same error on the gutsy tribe-3 server iso
[09:56] <mjg59> What's kind of weird is that you don't seem to have anything on the ports connected to irq 7
[09:57] <mjg59> So it's either an irq routing issue (try booting with pci=noacpi) or a sata_nv bug
[09:58] <mjg59> amitk_: Why not just fudge the USB autosuspend code so it only triggers on mass storage and HID class devices?
[09:58] <Nafallo> I think sdf and sdg are on IRQ7, cause those drives died after the error.
[09:59] <Nafallo> also I'm booting with noapic for a reason :-)
[09:59] <mjg59> No, they're on irq 10
[09:59] <mjg59> Why are you booting with noapic?
[09:59] <mjg59> It's quite possible that the board irq routing has never been tested with xtpic
[10:00] <amitk_> mjg59: to keep in sync with upstream. Oliver Neukum pushed a similar patch to GregKH's tree
[10:00] <mjg59> amitk_: But it's likely that there's more devices that are broken
[10:00] <Nafallo> mjg59: the kernel refuse to start telling me to boot with that option :-)
[10:00] <mjg59> And I'm sceptical that autosuspend of most USB devices is actually useful
[10:00] <mjg59> Nafallo: Well, attempting to debug that would be helpful
[10:01] <mjg59> Right now you're passing an option that has a reasonable chance of breaking things in exactly the way you're seeing
[10:01] <Nafallo> mjg59: I'll boot with the debug command next time I restart then. will need to keep the server up until the weekend now though :-)
[10:02] <Nafallo> mjg59: aha. how... evil.
[10:02] <Nafallo> mjg59: so right now it is boot || sata then? ;-)
[10:02] <mjg59> So I suspect there's no problem with sata_nv
[10:03] <amitk_> mjg59: I agree. It's more than likely there are more devices. But how can we be sure that this affects only scanner-type devices?
[10:03] <Nafallo> hmm. oki :-)
[10:05] <mjg59> amitk_: For reference, the only devices Windows suspends are hid, bluetooth and serial
[10:05] <mjg59> (http://www.microsoft.com/whdc/system/bus/USB/USBFAQ_intro.mspx)
[10:05] <Nafallo> mjg59: do you think there would be a difference if I move the cables from ports 1 and 2 to ports 3 and 4
[10:05] <Nafallo> ?
[10:06] <Nafallo> maybe someone on IRQ7 starts caring then :-P
[10:07] <mjg59> Nafallo: Could work, but it would be preferable to actually debug it
[10:07] <amitk_> interesting... mjg59, thanks for the link. I will work on a patch and talk to Alan
[10:08] <Nafallo> mjg59: agreed :-)
[10:12] <mjg59> amitk_: So I strongly suspect that pretty much everything outside those classes has never been tested with autosuspend, and if it works it's more by accident than by luck :)
[10:13] <amitk_> i would agree. I would also suspect that everything out of these classes are not connected to laptops very often
[10:15] <mjg59> Well, other than mass storage
[10:16] <mjg59> But if that's connected it's probably mounted (and therefore in use)
[10:18] <mjg59> amitk_: If you could cc me on the patch, that would be great
[10:19] <amitk_> mjg59: sure
[10:26] <amitk_> mjg59: Just had a thought: would disabling autosuspend be something that should be relegated to userspace? After all there is a sysfs entry to do so.
[10:26] <mjg59> amitk_: It could be, but in that case why have a blacklist in-kernel at all?
[10:27] <mjg59> I think it would make more sense to have a userspace whitelist rather than a "Break my hardware by default" kernel option
[10:27] <mjg59> Given that all we get out of it is a small amount of power saving
[10:29] <amitk_> mjg59: I haven't followed usb-devel, but I would suspect this blacklist is a knee-jerk reaction to solve immediate problems and keep users happy
[10:29] <mjg59> amitk_: I suspect we'll keep users somewhat happier if they don't have to keep sending patches to upstream (either kernel or hal) to make their hardware work :)