[12:20] 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] 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] It'd be good to run a debug kernel on that PC, see what else it reveals [12:23] 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] Suse, when I played with it for a week or so didn't show this issue either. [12:24] bradley: How do you normally shutdown the system? [12:25] 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] bradley: without logging out though? It might also be interesting to see what happens if you log out and then shutdown. [12:26] 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] bradley: If you need to install acpidump: "sudo apt-get install acpidump" [12:29] lol its "cowardly refusing to create en empty archive [12:29] 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] bradley: you may need to separate the commands I gave you into separate lines :) [12:30] i tried that as well [12:30] sudo -i and then the commands. [12:30] same error [12:30] sudo can't > things [12:30] acpidump, is it creating a DSDT.aml ? [12:30] fanafallo: i know that much :) [12:30] Nafallo: it can, and did, I tested it here first [12:31] yeah, it created the aml === zul_ [n=chuck@mail.edgewater.ca] has joined #ubuntu-kernel [12:31] when did it learn that? :-) === zul [n=chuck@ubuntu/member/zul] has joined #ubuntu-kernel [12:31] evening [12:31] bradley: ok, use "tar -czvf DSDT.aml.tar.gz DSDT.aml" [12:32] ok, that worked, ill attach it [12:32] (it does help to specify *what* is being put in the tar) lol *slaps self* [12:33] 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] 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] im using the latest gutsy kernel [12:35] against all warnings i know, but it's stable for me [12:36] 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] bradley: ok, that makes it easier for me then, I'll just build a debug-version from the git [12:38] 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] yeah, can i disable the script through sysctlrc...that's not the right name, but its something like that [12:43] the program that allows me to see and edit what's running on which runlevels [12:44] otherwise ill just delete the scripts and remake them [12:47] bradley: You mean update-rc.d ? [12:47] yeah, i think thats what i meant, but im retarded sometimes. ill just comment out the line that removes snd_hda_intel [12:48] that should make things not work again, and its much easier to put back to working [12:48] yeah :) [12:48] alright, i'll give it a go === lamont` notes that suspend/hibernate are broken on his laptop with -8 and -9 [12:49] (compaq nw840) [12:49] (compaq nw8440, even) === bradley [n=bradley@CPE-24-208-44-208.new.res.rr.com] has joined #ubuntu-kernel === doko_ [n=doko@dslb-088-073-126-201.pools.arcor-ip.net] has joined #ubuntu-kernel [12:54] IN: ok, added the kern.log [12:54] bradley: I've just skimmed the DSDT for anything obvious, but nothing that stands out. [12:54] what does that imply? [12:56] There's nothing in the way of obvious ACPI DSDT faults apparent [12:57] 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] sure, brb === bronson [n=bronson@66.237.74.66.ptr.us.xo.net] has joined #ubuntu-kernel === bradley [n=bradley@CPE-24-208-44-208.new.res.rr.com] has joined #ubuntu-kernel [01:13] 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] 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 === zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel [01:16] 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] that makes sense...hmmmm, ok, let me look around some more [01:17] 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] ok [01:18] bradley: hang on a minute.... [01:20] 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] oops! === bradley [n=bradley@CPE-24-208-44-208.new.res.rr.com] has joined #ubuntu-kernel [01:25] ha, you ran off before I could finish what I was saying! [01:26] 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] unless im mistaken [01:27] I had just typed... [01:27] 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] sorry, this bug hunting has me all fired up [01:28] 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] yeah, now that you say it, kern.log IS all startup [01:30] there's all but nothing in any of the logs, except for 'tty exiting' messages [01:33] well thats disappointing [01:34] though i have to think signifcant progress now be made on this bug [01:34] I'm just digging to see if we can make it more talkative [01:42] by all means, i really appreciate you taking time out to help me with this. [01:44] 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] There isn't one [01:45] All kernel output will be logged [01:46] All you can change is whether stuff hits the console or not [01:46] Really? another case of the docs not matching reality! I saw "-c" but that is no good [01:47] Is there a way, without kernel recompiling, to increase the logging during shutdown? [01:47] Any output from the kernel will be logged until klogd is stopped or the filesystem unmounted [01:47] If you want more output, then you need to add more output to the kernel [01:48] I thought there was logging of driver-unloading etc., but there's almost nothing [01:48] We don't unload drivers [01:48] Well, stop them then [01:48] That's after the root filesystem has been unmounted [01:48] ahhh [01:49] small round spherical objects === zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel [01:49] You can edit /etc/default/halt [01:49] And set it to "halt" rather than "poweroff" [01:50] Then if you boot without the quiet option, you'll get any logging onscreen until the machine stops [01:51] 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] anyway, aren't you supposed to be on vacation?! [01:52] Yes [01:52] can't keep away? === ..[topic/#ubuntu-kernel:crimsun] : Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.22-9.21 | Latest news: -rt and -xen kernels re-added | New Kernel Team machine: http://kernel.ubuntu.com/ === cjwatson [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk] has joined #ubuntu-kernel === bradley [n=bradley@CPE-24-208-44-208.new.res.rr.com] has joined #ubuntu-kernel === johanbr [n=j@blk-224-156-151.eastlink.ca] has joined #ubuntu-kernel === blenderhead001 [n=blenderh@adsl-068-209-133-121.sip.jax.bellsouth.net] has joined #ubuntu-kernel === bradley [n=bradley@CPE-24-208-44-208.new.res.rr.com] has joined #ubuntu-kernel === johanbr [n=j@blk-89-207-129.eastlink.ca] has joined #ubuntu-kernel === mdomsch [n=Matt_Dom@cpe-70-124-62-55.austin.res.rr.com] has joined #ubuntu-kernel === infinity_ [n=adconrad@cerberus.0c3.net] has joined #ubuntu-kernel === m0rg0th [n=m0rg0th@220.225.228.97] has joined #ubuntu-kernel === abogani [n=alessio@adsl203-157-083.mclink.it] has joined #ubuntu-kernel === TheMuso [n=luke@ubuntu/member/themuso] has joined #ubuntu-kernel [09:53] BenC: Kernel fix didn't happen, I guess? === cjwatson_ [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk] has joined #ubuntu-kernel === defcon [n=defcon@70-58-248-128.phnx.qwest.net] has joined #ubuntu-kernel === Hobbsee [n=Hobbsee@ubuntu/member/hobbsee] has joined #ubuntu-kernel [10:35] moin [11:00] kraut: did you find a solution to your problem? [11:01] 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] 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] true [11:11] amitk_: do you maintain the ubuntu-kernel? [11:12] kraut: Not really, I am just a member of the kernel team. [11:13] 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] i've also mailed an emploeyee of netapp concerning this, but still waiting on an answer. [11:13] perhaps he could tell me the problem and wich fix is missing in the feisty-kernel. [11:15] 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) === cobman [n=justinas@212.47.107.10] has joined #ubuntu-kernel === bullgard4 [n=detlef@p54BF1D15.dip0.t-ipconnect.de] has joined #ubuntu-kernel [12:08] In kern.log I obtain a line "Back to C!" between 'LATE suspend' and 'EARLY resume'. What stands 'C' for? [12:14] It's a programming language [12:15] It means that the resume code has transitioned back to the C language section, rather than the bit written in x86 assembler [12:16] It really needs a "Phew, we made it!" in there. [12:17] Every time a PC manages to boot past real mode, I think it's a minor miracle. === amitk_ [n=amit@a81-197-157-76.elisa-laajakaista.fi] has joined #ubuntu-kernel [12:24] Ok. Thank you. [12:25] amitk_: not really, i need the new one for an urgent project :/ === ICU [n=me@sechzig.dd.ewetel.de] has joined #ubuntu-kernel === gnomefreak [n=gnomefre@ubuntu/member/gnomefreak] has joined #ubuntu-kernel === gnomefreak [n=gnomefre@ubuntu/member/gnomefreak] has joined #ubuntu-kernel === ivoks [n=ivoks@83-131-13-187.adsl.net.t-com.hr] has joined #ubuntu-kernel [01:41] anyone tried out the gutsy-kernel on a x86_64 system? [01:41] it won't boot without any usefull message before it will scan the scsi-bus. === gnomefreak [n=gnomefre@ubuntu/member/gnomefreak] has joined #ubuntu-kernel [01:53] there is a problem concerning a lsi-logic controller :/ [02:18] is it possible to change the magic key to something else then "print screen"? [02:31] lsi-logic is broken in 2.6.22 :/ [02:52] infinity, doko: 9.22 being uploaded with fix for lpia build [02:52] Good timing, we were just talking about you behind your back. [02:53] BenC: Is your link fast enough to get it up before cron.daily? [02:53] just talking =) [02:53] infinity: it's already done [02:53] Awesome. [02:54] we have a .orig.tar.gz now, so it's just a ~3Meg upload [02:54] Ahh, cool. [02:54] Shows how long it's been since I did a kernel upload. :) === zul__ [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel [03:24] oh goody my wife is up === zul_ [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel === chmj [n=nik0n@vc-196-207-32-232.3g.vodacom.co.za] has joined #ubuntu-kernel === zul_ [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel [03:41] BenC: ping there is a request to sync rt2400 source from debian should we even bother? [03:48] zul: nope [03:48] reject it as Invalid [03:49] BenC: thanks === lamont kicks self, builds -9.21hppa1 to verify that the bad abi file was the only thing wrong === cjwatson_ [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk] has joined #ubuntu-kernel === tuxmaniac [n=tuxmania@unaffiliated/tuxmaniac] has joined #ubuntu-kernel [04:58] Bah, where did Ben go? === mdomsch [n=Matt_Dom@cpe-70-124-62-55.austin.res.rr.com] has joined #ubuntu-kernel === lamont [n=lamont@mix.mmjgroup.com] has joined #ubuntu-kernel [05:14] hrm... and -9.22 is in the archive. sigh [05:14] lamont: Don't worry, there's another upload required ASAP. :P [05:15] lamont: (broken on lpia, which was the whole point for this upload) [05:15] heh [05:15] I expect my change will fix hppa finally (mailed kernel-team ml, etc) [05:15] mind you, testing that will take several hours... [05:16] where several is between 2 and 4 [05:17] closer to 2, it appears.. (abicheck of 2nd-and-final kernel failed at 1:55:23) [05:17] so just including it should be fine. [05:18] (it won't be any _more_ broken than what's in -9.22) :-) === lamont crashes the -9.22 build attempt on hppa [05:19] 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. === lamont even used the right template this time. [05:20] lamont: Not sure how much I can do on that front, short of bribing people with hookers and beer. [05:20] And I'm starting to run out of hookers. [05:20] good bribes [05:20] heh. it's more of a "since you have to turn this for me, pls include lamont's latest. kthxbye" === netjoined: irc.freenode.net -> kubrick.freenode.net === zul_ [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel === blenderhead001 [n=blenderh@adsl-068-209-133-121.sip.jax.bellsouth.net] has joined #ubuntu-kernel [05:23] and afk === pmjdebruijn [n=pmjdebru@ds9.pcode.nl] has joined #ubuntu-kernel === ketrox [n=ketrox@Zd14d.z.pppool.de] has joined #ubuntu-kernel [05:45] infinity: it fails again for the udebs after fixing the linux-libc-dev header [05:47] doko: Ugh. === lamont returns, waves [05:52] doko, i can debootstrap a lpia chroot now? [05:53] doko, how does it fail? [05:53] kylem: yes, see my email to distro [05:53] you just need http://people.ubuntu.com/~doko/tmp/linux-libc-dev_2.6.22-9.22_lpia.deb for now [05:53] for dev things [05:54] make: *** [binary-udebs] Error 1 [05:54] kylem: ^^^ [05:54] dude. [05:54] not terribly helpful, that. === m0rg0th [n=m0rg0th@219.64.120.181] has joined #ubuntu-kernel [06:07] doko: You may have noticed some text on your terminal slightly before that error.. :P [06:07] dilist=$(dh_listpackages -s | grep "\-di$") && \ [06:07] for i in $dilist; do \ [06:07] dh_fixperms -p$i; \ [06:07] dh_gencontrol -p$i; \ [06:07] dh_builddeb -p$i; \ [06:07] done [06:07] dpkg-architecture: warning: Unknown gcc system type i686-linux-gnulp, falling back to default (native compilation) [06:07] [...] repeated 100 times [06:07] make: *** [binary-udebs] Error 1 [06:07] Still running the old dpkg, I see... [06:07] indeed [06:07] kylem: better? looks like no udebs are produced, so just copying the config from i386 would be fine (I assume) [06:07] Though, in this case, it's helpful to point out that dpkg-architecture is being run a crapload of times. :) [06:07] grep "\-di$" looks suspicious, missing architecture [06:07] dh_listpackages limits to the current arch, I assume. [06:07] Yeah. [06:07] That's precisely what it does, in fact. [06:07] doko, yes. d-i is completely absent. [06:07] dilist=$$(dh_listpackages -s | grep "\-di$$") && \ [06:07] [ -z "$dilist" ] || \ [06:07] for i in $$dilist; do \ [06:08] ok, that works. [06:08] kyle: how do I correctly increment the version number? just for producing a correct debdiff [06:09] debian/rules startnewrelease [06:14] 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] 17:06:22 < kylem> doko, yes. d-i is completely absent. [06:15] the correct fix would be to add d-i... [06:16] kylem: that can be done later, we just need linux-libc-dev for now [06:16] 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] er, ok. [06:17] ... it's like a two line addition though... [06:17] (Who knows if we'll ever even build lpia installation media) [06:17] alright. fine. [06:17] Oh, if it's easy and guaranteed to work, just do it, then. [06:17] kylem: as you like it, I can test build it here [06:17] Won't hurt to have 'em, just in case. === natenewz [n=nate@12-216-74-75.client.mchsi.com] has joined #ubuntu-kernel [06:19] infinity: it would be nice to have installer and/or live cd's just to offer something for testing [06:19] i'm hoping there are proper sdvs when these cpus become available... === ivoks [n=ivoks@20-182.dsl.iskon.hr] has joined #ubuntu-kernel === ivoks_ [n=ivoks@20-182.dsl.iskon.hr] has joined #ubuntu-kernel === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-kernel === johanbr [n=j@JBrannlund.MathStat.Dal.Ca] has joined #ubuntu-kernel === dhon__ [n=dhon@60-240-97-109.static.tpgi.com.au] has joined #ubuntu-kernel === dhon__ [n=dhon@60-240-97-109.static.tpgi.com.au] has joined #ubuntu-kernel === lamont reads KernelGitGuide, wonders why the top section doesn't say 'git fetch origin; git rebase origin' under "preserve local changes" [07:47] its in there somewhere :) [07:49] oh i hate cvs === tehk [n=tehk@c-69-249-157-157.hsd1.nj.comcast.net] has joined #ubuntu-kernel === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-kernel [07:50] hey BenC [07:53] 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] What is meant by 'LATE suspend' of my agpgart-intel loadable module's message in kern.log? [08:06] It's the portion of the driver suspend called after interrupts are disabled [08:07] mjg59: btw, remember how putting the gutsy kernel on my laptop made suspend work? well, it doesn't now... [08:07] mjg59: Thank you very much for explaining. [08:07] somewhere between -5 and -8, -9 also b0rked [08:08] mjg59: is there a writeup anywhere that would give me clues on how to troubleshoot that? [08:09] lamont: git bisect is probably the easiest [08:09] lamont, go to www.united.com, book a flight to heathrow, underground to kings cross, national rail to cambridge. [08:09] Except you probably can't, because the kernels are rebased [08:09] Which means the git history bears no resemblance to the release history === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-kernel [08:10] mjg59: any chance you have a compaq mumble8440? [08:10] lamont: Nope [08:10] I've a 6220, but that's previous generation [08:10] yeah [08:11] and smaller. [08:11] Per-generation, the hardware is pretty similar [08:12] mjg59: bisect could still work for me, although it may be fun to get from the eventually-found commit to the actual commit... :-) === lamont wonders if maybe using the SD card reader plays into it.. [08:12] or if there were any bits that needed to be blacklisted/whatever to get it to work [08:12] lamont: If it previously worked, then bisect is probably as good as you're going to get [08:13] ye [08:13] p [08:13] You're just going to have to be handwavy in finding the last "good" kernel [08:13] yeah [08:13] If we didn't rebase the tree, this would be a lot easier [08:13] why do we rebase the tree again? [08:14] 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] Ben finds it easier [08:14] Whereas I find having to pull into a branch and then merge that murder inducing [08:15] lamont, the commit you want pulled is not in your tree. [08:15] hrmpf. [08:15] heh [08:15] pushing [08:18] pushed [08:20] 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] it won't be rebased anymore now that 2.6.22 is out. [08:27] kylem: Not even to 2.6.22.1? [08:27] (Or other parts of the stable branch) [08:28] have we actually pulled in 2.6.22.1? [08:31] in debian yes :) [08:36] nerver mine I answered my own question [08:36] ergh === zul_ [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel [08:39] 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] 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] s/stable/stock/ [08:41] BenC: But we don't ship a stock 2.6.22 [08:41] What users know is "-5 worked, -7 doesn't" [08:41] 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] mjg59: keithp says that one should never use 'git pull', instead one should use 'git fetch' and an appropriate merge [08:42] 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] actually, you can get decent history just looking at the changelog [08:43] keith is just being difficult, pull is just a fetch+merge. [08:43] BenC: creating a 2.6.22-9.23 _branch_ at the time of upload would preserve history for us [08:43] kylem: yeah, but he finds that the merge is seldom the one he really wanted [08:43] 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] lamont: well, it's pointless now since we wont be rebasing anymore [08:43] BenC: for the future, I meant [08:43] lamont: That doesn't actually solve the problem in any case :) [08:43] lamont: good point, we can definitely do that [08:43] we have a branch, since we have a tag. [08:43] lamont: tags wont work? [08:44] mjg59: it renders it more-solvable, I expect [08:44] right, you can do "git-branch Ubuntu-2.6.22-9.23 Ubuntu-2.6.22-9.23" [08:44] would a tag add a reference to the un-rebased commits? [08:44] lamont: The tree refers to a different history to the one in my local repository [08:44] BenC: Tags won't work across a rebase in any meaningful way [08:44] lamont: So it's impossible to pull/fetch/whatever [08:45] hrm. [08:45] 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] Subject: Accepted linux-source-2.6.22 2.6.22-9.24 (source) [08:45] kylem: I never uploaded -9.23 [08:46] BenC: You continue to have issues. It may be an interaction between a new upstream patch and one of ours. [08:46] just so you know :) [08:46] BenC, hence it's still unreleased [08:46] 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 === lamont goes to appointments [08:46] blef. [08:46] mjg59: if v2.6.22 works and HEAD doesn't, you can easily rebase between those two points [08:46] coffee. [08:47] BenC: ? [08:47] mjg59: true, you miss the super rare case where an upstream commit during devel actually interacts bad with one of our patches [08:47] s/rebase/bisect/ [08:48] Well, yes, you can do that [08:48] But it's not actually going to be significantly faster [08:48] it's not going to be slower either :) [08:48] lamont: you might be suffering from bug #129226, perhaps? [08:49] But, as you said, it misses one entire class of problem [08:49] bug# 129226 even [08:49] damn.. i can never quite figure out how to trigger the bot [08:49] mjg59: one extremely rare class, as I've never experienced it before :) [08:49] BenC: I've hit it a couple of times. [08:49] amitk_: it's missing from this channel [08:50] mjg59: either way you do it, it doesn't give you full info [08:50] ACPI is hard. Shopping time. [08:50] BenC: Sure it does. One way actually reflects the history that we've published, and the other doesn't. [08:50] 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] 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] I mean, in addition to it being a nightmare to remember to fetch into a branch and then use that as origin === EtienneG [n=etienne@ubuntu/member/EtienneG] has joined #ubuntu-kernel [08:56] error: no such remote ref refs/heads/origin.old [08:56] Ngh. [08:57] \o/ 2.6.22-9.24 [08:57] infinity: wake up call ;-) [08:57] hopefully it builds on more than one flavour of amd64. ;-) === Nafallo [n=nafallo@ubuntu/member/nafallo] has joined #ubuntu-kernel [09:40] hmm. [09:40] sata_nv busted? [09:40] since like... feisty? [09:46] Nafallo: worked on my one system, even in feisty [09:48] BenC: are you aware if there are any bugs with sata_nv hangs? [09:48] starts with: [ 438.240000] irq 7: nobody cared (try booting with the "irqpoll" option) [09:48] Nafallo: Does /proc/interrupts claim that sata_nv is bound to irq 7? [09:48] ah crap, i'm a muppet. forgot to -mv the abi files to 9.23 [09:49] 7: 9820 264076 XT-PIC-XT libata [09:49] Ok, that's a good start [09:50] So for some reason, sata_nv doesn't believe that the interrupt was its [09:50] I got libata on 5,7,10,11 === Nafallo makes a pastebin with the full errormessage [09:51] http://paste.ubuntu-nl.org/32273/ <-- mjg59 [09:52] I haven't really cared about the statement up until now that my two raptors arrived :-P [09:52] Nafallo: The rest of dmesg would help [09:54] http://home.nafallo.info/bugs/sata_nv.txt === IntuitiveNipple [n=TJ@alexandros.tjworld.net] has joined #ubuntu-kernel [09:56] mjg59: feisty running now. same error on the gutsy tribe-3 server iso [09:56] What's kind of weird is that you don't seem to have anything on the ports connected to irq 7 [09:57] So it's either an irq routing issue (try booting with pci=noacpi) or a sata_nv bug [09:58] amitk_: Why not just fudge the USB autosuspend code so it only triggers on mass storage and HID class devices? [09:58] I think sdf and sdg are on IRQ7, cause those drives died after the error. [09:59] also I'm booting with noapic for a reason :-) [09:59] No, they're on irq 10 [09:59] Why are you booting with noapic? [09:59] It's quite possible that the board irq routing has never been tested with xtpic [10:00] mjg59: to keep in sync with upstream. Oliver Neukum pushed a similar patch to GregKH's tree [10:00] amitk_: But it's likely that there's more devices that are broken [10:00] mjg59: the kernel refuse to start telling me to boot with that option :-) [10:00] And I'm sceptical that autosuspend of most USB devices is actually useful [10:00] Nafallo: Well, attempting to debug that would be helpful [10:01] Right now you're passing an option that has a reasonable chance of breaking things in exactly the way you're seeing [10:01] 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] mjg59: aha. how... evil. [10:02] mjg59: so right now it is boot || sata then? ;-) [10:02] So I suspect there's no problem with sata_nv [10:03] 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] hmm. oki :-) === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-kernel [10:05] amitk_: For reference, the only devices Windows suspends are hid, bluetooth and serial [10:05] (http://www.microsoft.com/whdc/system/bus/USB/USBFAQ_intro.mspx) [10:05] 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] ? === bradley [n=bradley@CPE-24-208-44-208.new.res.rr.com] has joined #ubuntu-kernel [10:06] maybe someone on IRQ7 starts caring then :-P [10:07] Nafallo: Could work, but it would be preferable to actually debug it [10:07] interesting... mjg59, thanks for the link. I will work on a patch and talk to Alan [10:08] mjg59: agreed :-) [10:12] 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] i would agree. I would also suspect that everything out of these classes are not connected to laptops very often [10:15] Well, other than mass storage [10:16] But if that's connected it's probably mounted (and therefore in use) === allee [n=ach@lapex-mcallee.mpe.mpg.de] has joined #ubuntu-kernel === amitk_ [n=amit@a81-197-157-76.elisa-laajakaista.fi] has joined #ubuntu-kernel === makx [n=max@baikonur.stro.at] has joined #ubuntu-kernel === macd [n=d@cl-116.atl-01.us.sixxs.net] has joined #ubuntu-kernel === \sh_away [n=nnsherma@server3.servereyes.de] has joined #ubuntu-kernel [10:18] amitk_: If you could cc me on the patch, that would be great [10:19] mjg59: sure === amitk_ [n=amit@a81-197-157-76.elisa-laajakaista.fi] has joined #ubuntu-kernel === makx [n=max@baikonur.stro.at] has joined #ubuntu-kernel === macd [n=d@cl-116.atl-01.us.sixxs.net] has joined #ubuntu-kernel === \sh_away [n=nnsherma@server3.servereyes.de] has joined #ubuntu-kernel [10:26] 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] amitk_: It could be, but in that case why have a blacklist in-kernel at all? [10:27] I think it would make more sense to have a userspace whitelist rather than a "Break my hardware by default" kernel option [10:27] Given that all we get out of it is a small amount of power saving [10:29] 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] 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 :) === zul_ [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel === maximal [n=user1@82-71-15-70.dsl.in-addr.zen.co.uk] has joined #ubuntu-kernel === tehk [n=tehk@c-69-249-157-157.hsd1.nj.comcast.net] has joined #ubuntu-kernel === zul_ [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel