| 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:20 |
| IntuitiveNipple | It'd be good to run a debug kernel on that PC, see what else it reveals | 12:21 |
| 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:23 |
| bdmurray | bradley: How do you normally shutdown the system? | 12:24 |
| 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:25 |
| 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:26 |
| IntuitiveNipple | bradley: If you need to install acpidump: "sudo apt-get install acpidump" | 12:27 |
| 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:29 |
| 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:30 |
| bradley | yeah, it created the aml | 12:31 |
| === zul_ [n=chuck@mail.edgewater.ca] has joined #ubuntu-kernel | ||
| Nafallo | when did it learn that? :-) | 12:31 |
| === zul [n=chuck@ubuntu/member/zul] has joined #ubuntu-kernel | ||
| zul | evening | 12:31 |
| IntuitiveNipple | bradley: ok, use "tar -czvf DSDT.aml.tar.gz DSDT.aml" | 12:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| bradley | im using the latest gutsy kernel | 12:35 |
| bradley | against all warnings i know, but it's stable for me | 12:35 |
| 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:36 |
| 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:38 |
| bradley | yeah, can i disable the script through sysctlrc...that's not the right name, but its something like that | 12:41 |
| bradley | the program that allows me to see and edit what's running on which runlevels | 12:43 |
| bradley | otherwise ill just delete the scripts and remake them | 12:44 |
| 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:47 |
| 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:48 |
| === lamont` notes that suspend/hibernate are broken on his laptop with -8 and -9 | ||
| lamont` | (compaq nw840) | 12:49 |
| lamont` | (compaq nw8440, even) | 12:49 |
| === 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 | ||
| 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:54 |
| IntuitiveNipple | There's nothing in the way of obvious ACPI DSDT faults apparent | 12:56 |
| 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? | 12:57 |
| bradley | sure, brb | 01:01 |
| === 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 | ||
| 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:13 |
| 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:15 |
| === zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel | ||
| 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:16 |
| 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:17 |
| bradley | ok | 01:18 |
| IntuitiveNipple | bradley: hang on a minute.... | 01:18 |
| 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:20 |
| === bradley [n=bradley@CPE-24-208-44-208.new.res.rr.com] has joined #ubuntu-kernel | ||
| IntuitiveNipple | ha, you ran off before I could finish what I was saying! | 01:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| bradley | yeah, now that you say it, kern.log IS all startup | 01:29 |
| IntuitiveNipple | there's all but nothing in any of the logs, except for 'tty exiting' messages | 01:30 |
| bradley | well thats disappointing | 01:33 |
| 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:34 |
| bradley | by all means, i really appreciate you taking time out to help me with this. | 01:42 |
| 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:44 |
| mjg59 | There isn't one | 01:45 |
| mjg59 | All kernel output will be logged | 01:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| IntuitiveNipple | small round spherical objects | 01:49 |
| === zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel | ||
| mjg59 | You can edit /etc/default/halt | 01:49 |
| mjg59 | And set it to "halt" rather than "poweroff" | 01:49 |
| mjg59 | Then if you boot without the quiet option, you'll get any logging onscreen until the machine stops | 01:50 |
| 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:51 |
| IntuitiveNipple | anyway, aren't you supposed to be on vacation?! | 01:52 |
| mjg59 | Yes | 01:52 |
| IntuitiveNipple | can't keep away? | 01:52 |
| === ..[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 | ||
| infinity | BenC: Kernel fix didn't happen, I guess? | 09:53 |
| === 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 | ||
| kraut | moin | 10:35 |
| amitk_ | kraut: did you find a solution to your problem? | 11:00 |
| 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:01 |
| kraut | amitk_: do you maintain the ubuntu-kernel? | 11:11 |
| amitk_ | kraut: Not really, I am just a member of the kernel team. | 11:12 |
| 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:13 |
| 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) | 11:15 |
| === cobman [n=justinas@212.47.107.10] has joined #ubuntu-kernel | ||
| === bullgard4 [n=detlef@p54BF1D15.dip0.t-ipconnect.de] has joined #ubuntu-kernel | ||
| bullgard4 | In kern.log I obtain a line "Back to C!" between 'LATE suspend' and 'EARLY resume'. What stands 'C' for? | 12:08 |
| mjg59 | It's a programming language | 12:14 |
| mjg59 | It means that the resume code has transitioned back to the C language section, rather than the bit written in x86 assembler | 12:15 |
| infinity | It really needs a "Phew, we made it!" in there. | 12:16 |
| infinity | Every time a PC manages to boot past real mode, I think it's a minor miracle. | 12:17 |
| === amitk_ [n=amit@a81-197-157-76.elisa-laajakaista.fi] has joined #ubuntu-kernel | ||
| bullgard4 | Ok. Thank you. | 12:24 |
| kraut | amitk_: not really, i need the new one for an urgent project :/ | 12:25 |
| === 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 | ||
| 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:41 |
| === gnomefreak [n=gnomefre@ubuntu/member/gnomefreak] has joined #ubuntu-kernel | ||
| kraut | there is a problem concerning a lsi-logic controller :/ | 01:53 |
| kraut | is it possible to change the magic key to something else then "print screen"? | 02:18 |
| kraut | lsi-logic is broken in 2.6.22 :/ | 02:31 |
| 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:52 |
| 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:53 |
| 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. :) | 02:54 |
| === zul__ [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel | ||
| zul | oh goody my wife is up | 03:24 |
| === 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 | ||
| zul | BenC: ping there is a request to sync rt2400 source from debian should we even bother? | 03:41 |
| BenC | zul: nope | 03:48 |
| BenC | reject it as Invalid | 03:48 |
| zul | BenC: thanks | 03:49 |
| === 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 | ||
| infinity | Bah, where did Ben go? | 04:58 |
| === 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 | ||
| 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:14 |
| 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:15 |
| lamont | where several is between 2 and 4 | 05:16 |
| 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:17 |
| lamont | (it won't be any _more_ broken than what's in -9.22) :-) | 05:18 |
| === lamont crashes the -9.22 build attempt on hppa | ||
| 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:19 |
| === lamont even used the right template this time. | ||
| 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:20 |
| === 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 | ||
| lamont | and afk | 05:23 |
| === pmjdebruijn [n=pmjdebru@ds9.pcode.nl] has joined #ubuntu-kernel | ||
| === ketrox [n=ketrox@Zd14d.z.pppool.de] has joined #ubuntu-kernel | ||
| doko | infinity: it fails again for the udebs after fixing the linux-libc-dev header | 05:45 |
| infinity | doko: Ugh. | 05:47 |
| === lamont returns, waves | ||
| kylem | doko, i can debootstrap a lpia chroot now? | 05:52 |
| 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:53 |
| doko | make: *** [binary-udebs] Error 1 | 05:54 |
| doko | kylem: ^^^ | 05:54 |
| kylem | dude. | 05:54 |
| kylem | not terribly helpful, that. | 05:54 |
| === m0rg0th [n=m0rg0th@219.64.120.181] has joined #ubuntu-kernel | ||
| 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:07 |
| doko | ok, that works. | 06:08 |
| doko | kyle: how do I correctly increment the version number? just for producing a correct debdiff | 06:08 |
| kylem | debian/rules startnewrelease | 06:09 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| === natenewz [n=nate@12-216-74-75.client.mchsi.com] has joined #ubuntu-kernel | ||
| 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... | 06:19 |
| === 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" | ||
| zul | its in there somewhere :) | 07:47 |
| zul | oh i hate cvs | 07:49 |
| === 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 | ||
| zul | hey BenC | 07:50 |
| 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... | 07:53 |
| bullgard4 | What is meant by 'LATE suspend' of my agpgart-intel loadable module's message in kern.log? | 08:05 |
| mjg59 | It's the portion of the driver suspend called after interrupts are disabled | 08:06 |
| 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:07 |
| lamont | mjg59: is there a writeup anywhere that would give me clues on how to troubleshoot that? | 08:08 |
| 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:09 |
| === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-kernel | ||
| 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:10 |
| lamont | and smaller. | 08:11 |
| mjg59 | Per-generation, the hardware is pretty similar | 08:11 |
| 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 wonders if maybe using the SD card reader plays into it.. | ||
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| lamont | pushed | 08:18 |
| 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:20 |
| kylem | it won't be rebased anymore now that 2.6.22 is out. | 08:26 |
| mjg59 | kylem: Not even to 2.6.22.1? | 08:27 |
| mjg59 | (Or other parts of the stable branch) | 08:27 |
| zul | have we actually pulled in 2.6.22.1? | 08:28 |
| makx | in debian yes :) | 08:31 |
| zul | nerver mine I answered my own question | 08:36 |
| zul | ergh | 08:36 |
| === zul_ [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel | ||
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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 |
| === lamont goes to appointments | ||
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| === EtienneG [n=etienne@ubuntu/member/EtienneG] has joined #ubuntu-kernel | ||
| mjg59 | error: no such remote ref refs/heads/origin.old | 08:56 |
| mjg59 | Ngh. | 08:56 |
| 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. ;-) | 08:57 |
| === Nafallo [n=nafallo@ubuntu/member/nafallo] has joined #ubuntu-kernel | ||
| Nafallo | hmm. | 09:40 |
| Nafallo | sata_nv busted? | 09:40 |
| Nafallo | since like... feisty? | 09:40 |
| BenC | Nafallo: worked on my one system, even in feisty | 09:46 |
| 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:48 |
| Nafallo | 7: 9820 264076 XT-PIC-XT libata | 09:49 |
| mjg59 | Ok, that's a good start | 09:49 |
| 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:50 |
| === Nafallo makes a pastebin with the full errormessage | ||
| Nafallo | http://paste.ubuntu-nl.org/32273/ <-- mjg59 | 09:51 |
| 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:52 |
| Nafallo | http://home.nafallo.info/bugs/sata_nv.txt | 09:54 |
| === IntuitiveNipple [n=TJ@alexandros.tjworld.net] has joined #ubuntu-kernel | ||
| 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:56 |
| mjg59 | So it's either an irq routing issue (try booting with pci=noacpi) or a sata_nv bug | 09:57 |
| 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:58 |
| 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 | 09:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-kernel | ||
| 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:05 |
| === bradley [n=bradley@CPE-24-208-44-208.new.res.rr.com] has joined #ubuntu-kernel | ||
| Nafallo | maybe someone on IRQ7 starts caring then :-P | 10:06 |
| 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:07 |
| Nafallo | mjg59: agreed :-) | 10:08 |
| 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:12 |
| amitk_ | i would agree. I would also suspect that everything out of these classes are not connected to laptops very often | 10:13 |
| mjg59 | Well, other than mass storage | 10:15 |
| mjg59 | But if that's connected it's probably mounted (and therefore in use) | 10:16 |
| === 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 | ||
| mjg59 | amitk_: If you could cc me on the patch, that would be great | 10:18 |
| amitk_ | mjg59: sure | 10:19 |
| === 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 | ||
| 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:26 |
| 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:27 |
| 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 :) | 10:29 |
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!