/srv/irclogs.ubuntu.com/2007/08/02/#ubuntu-kernel.txt

bradleyIN: 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 education12:20
IntuitiveNippleFrom 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
IntuitiveNippleIt'd be good to run a debug kernel on that PC, see what else it reveals12:21
bradleymaybe 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 problem12:23
bradleySuse, when I played with it for a week or so didn't show this issue either.12:23
bdmurraybradley: How do you normally shutdown the system?12:24
bradleynormally i shut it down graphically....click the icon that brings up log out, restart, shutdown, suspend, hibernate, etc, and then click shut down12:25
bdmurraybradley: without logging out though?  It might also be interesting to see what happens if you log out and then shutdown.12:26
IntuitiveNipplebradley: 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
IntuitiveNipplebradley: If you need to install acpidump: "sudo apt-get install acpidump"12:27
bradleylol its "cowardly refusing to create en empty archive12:29
IntuitiveNipplebradley: 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
IntuitiveNipplebradley: you may need to separate the commands I gave you into separate lines :)12:30
bradleyi tried that as well12:30
Nafallosudo -i and then the commands.12:30
bradleysame error12:30
Nafallosudo can't > things12:30
IntuitiveNippleacpidump, is it creating a DSDT.aml ?12:30
bradleyfanafallo: i know that much :)12:30
IntuitiveNippleNafallo: it can, and did, I tested it here first12:30
bradleyyeah, it created the aml12:31
=== zul_ [n=chuck@mail.edgewater.ca] has joined #ubuntu-kernel
Nafallowhen did it learn that? :-)12:31
=== zul [n=chuck@ubuntu/member/zul] has joined #ubuntu-kernel
zulevening12:31
IntuitiveNipplebradley: ok, use "tar -czvf DSDT.aml.tar.gz DSDT.aml"12:31
bradleyok, that worked, ill attach it12:32
IntuitiveNipple(it does help to specify *what* is being put in the tar) lol *slaps self*12:32
IntuitiveNippleI was doing some suspend/resume hacking of snd_hda_intel a few weeks ago so that module source-code is still fresh in my mind12:33
IntuitiveNipplebradley: 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
bradleyim using the latest gutsy kernel12:35
bradleyagainst all warnings i know, but it's stable for me12:35
bradleybdmurray: before i applied the workaround no shut down worked for me, from desktop, loginscreen or otherwise, after i applied the work around, everything works12:36
IntuitiveNipplebradley: ok, that makes it easier for me then, I'll just build a debug-version from the git12:36
IntuitiveNipplebradley: 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
bradleyyeah, can i disable the script through sysctlrc...that's not the right name, but its something like that12:41
bradleythe program that allows me to see and edit what's running on which runlevels12:43
bradleyotherwise ill just delete the scripts and remake them12:44
IntuitiveNipplebradley: You mean update-rc.d ?12:47
bradleyyeah, i think thats what i meant, but im retarded sometimes.  ill just comment out the line that removes snd_hda_intel12:47
bradleythat should make things not work again, and its much easier to put back to working12:48
IntuitiveNippleyeah :)12:48
bradleyalright, i'll give it a go12: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
bradleyIN: ok, added the kern.log12:54
IntuitiveNipplebradley: I've just skimmed the DSDT for anything obvious, but nothing that stands out.12:54
bradleywhat does that imply?12:54
IntuitiveNippleThere's nothing in the way of obvious ACPI DSDT faults apparent12:56
IntuitiveNippleThis 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
bradleysure, brb01: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
bradleyok, 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 messages01:13
IntuitiveNipplebradley: ahh... maybe some confusion... kern.log is the logfile the system writes to, but when it 'backs-up' it moves it to kern.log.001:15
=== zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel
IntuitiveNippleThe 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.001:16
bradleythat makes sense...hmmmm, ok, let me look around some more01:17
IntuitiveNippleMaybe do another start/shutdown sequence with a freshly cleared kern.log, and then check what you've got in both files when you restart01:17
bradleyok01:18
IntuitiveNipplebradley: hang on a minute....01:18
IntuitiveNippleI 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
IntuitiveNippleoops!01:20
=== bradley [n=bradley@CPE-24-208-44-208.new.res.rr.com] has joined #ubuntu-kernel
IntuitiveNippleha, you ran off before I could finish what I was saying!01:25
bradleyok 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 it01:26
bradleyunless im mistaken01:27
IntuitiveNippleI had just typed...01:27
IntuitiveNippleI 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
bradleysorry, this bug hunting has me all fired up01:27
IntuitiveNipplebut 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 useless01:28
bradleyyeah, now that you say it, kern.log IS all startup01:29
IntuitiveNipplethere's all but nothing in any of the logs, except for 'tty exiting' messages01:30
bradleywell thats disappointing01:33
bradleythough i have to think signifcant progress now be made on this bug01:34
IntuitiveNippleI'm just digging to see if we can make it more talkative01:34
bradleyby all means, i really appreciate you taking time out to help me with this.01:42
IntuitiveNippleAccording 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
mjg59There isn't one01:45
mjg59All kernel output will be logged01:45
mjg59All you can change is whether stuff hits the console or not01:46
IntuitiveNippleReally? another case of the docs not matching reality! I saw "-c" but that is no good01:46
IntuitiveNippleIs there a way, without kernel recompiling, to increase the logging during shutdown?01:47
mjg59Any output from the kernel will be logged until klogd is stopped or the filesystem unmounted01:47
mjg59If you want more output, then you need to add more output to the kernel01:47
IntuitiveNippleI thought there was logging of driver-unloading etc., but there's almost nothing 01:48
mjg59We don't unload drivers01:48
IntuitiveNippleWell, stop them then01:48
mjg59That's after the root filesystem has been unmounted01:48
IntuitiveNippleahhh01:48
IntuitiveNipplesmall round spherical objects01:49
=== zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel
mjg59You can edit /etc/default/halt01:49
mjg59And set it to "halt" rather than "poweroff"01:49
mjg59Then if you boot without the quiet option, you'll get any logging onscreen until the machine stops01:50
IntuitiveNippleThe 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
IntuitiveNippleanyway, aren't you supposed to be on vacation?!01:52
mjg59Yes01:52
IntuitiveNipplecan'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
infinityBenC: 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
krautmoin10:35
amitk_kraut: did you find a solution to your problem?11:00
krautamitk_: not really, i know that it is fixed in 2.6.22. that's why i'll now tryout the gutsy-kernel.11:01
krautamitk_: 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_true11:01
krautamitk_: do you maintain the ubuntu-kernel?11:11
amitk_kraut: Not really, I am just a member of the kernel team.11:12
krautamitk_: 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
krauti've also mailed an emploeyee of netapp concerning this, but still waiting on an answer.11:13
krautperhaps 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
bullgard4In kern.log I obtain a line "Back to C!" between 'LATE suspend' and 'EARLY resume'. What stands 'C' for?12:08
mjg59It's a programming language12:14
mjg59It means that the resume code has transitioned back to the C language section, rather than the bit written in x86 assembler12:15
infinityIt really needs a "Phew, we made it!" in there.12:16
infinityEvery 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
bullgard4Ok. Thank you.12:24
krautamitk_: 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
krautanyone tried out the gutsy-kernel on a x86_64 system?01:41
krautit 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
krautthere is a problem concerning a lsi-logic controller :/01:53
krautis it possible to change the magic key to something else then "print screen"?02:18
krautlsi-logic is broken in 2.6.22 :/02:31
BenCinfinity, doko: 9.22 being uploaded with fix for lpia build02:52
infinityGood timing, we were just talking about you behind your back.02:52
infinityBenC: Is your link fast enough to get it up before cron.daily?02:53
dokojust talking =)02:53
BenCinfinity: it's already done02:53
infinityAwesome.02:53
BenCwe have a .orig.tar.gz now, so it's just a ~3Meg upload02:54
infinityAhh, cool.02:54
infinityShows 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
zuloh goody my wife is up03: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
zulBenC: ping there is a request to sync rt2400 source from debian should we even bother?03:41
BenCzul: nope03:48
BenCreject it as Invalid03:48
zulBenC: thanks03: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
infinityBah, 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
lamonthrm... and -9.22 is in the archive.  sigh05:14
infinitylamont: Don't worry, there's another upload required ASAP. :P05:14
infinitylamont: (broken on lpia, which was the whole point for this upload)05:15
lamontheh05:15
lamontI expect my change will fix hppa finally (mailed kernel-team ml, etc)05:15
lamontmind you, testing that will take several hours...05:15
lamontwhere several is between 2 and 405:16
lamontcloser to 2, it appears.. (abicheck of 2nd-and-final kernel failed at 1:55:23)05:17
lamontso 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
lamontinfinity: 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.
infinitylamont: Not sure how much I can do on that front, short of bribing people with hookers and beer.05:20
infinityAnd I'm starting to run out of hookers.05:20
lamontgood bribes05:20
lamontheh.  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
lamontand afk05:23
=== pmjdebruijn [n=pmjdebru@ds9.pcode.nl] has joined #ubuntu-kernel
=== ketrox [n=ketrox@Zd14d.z.pppool.de] has joined #ubuntu-kernel
dokoinfinity: it fails again for the udebs after fixing the linux-libc-dev header05:45
infinitydoko: Ugh.05:47
=== lamont returns, waves
kylemdoko, i can debootstrap a lpia chroot now?05:52
kylemdoko, how does it fail?05:53
dokokylem: yes, see my email to distro05:53
dokoyou just need http://people.ubuntu.com/~doko/tmp/linux-libc-dev_2.6.22-9.22_lpia.deb for now05:53
dokofor dev things05:53
dokomake: *** [binary-udebs]  Error 105:54
dokokylem: ^^^05:54
kylemdude.05:54
kylemnot terribly helpful, that.05:54
=== m0rg0th [n=m0rg0th@219.64.120.181] has joined #ubuntu-kernel
infinitydoko: You may have noticed some text on your terminal slightly before that error.. :P06:07
dokodilist=$(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        done06:07
dokodpkg-architecture: warning: Unknown gcc system type i686-linux-gnulp, falling back to default (native compilation)06:07
doko[...]  repeated 100 times06:07
dokomake: *** [binary-udebs]  Error 106:07
infinityStill running the old dpkg, I see...06:07
kylemindeed06:07
dokokylem: better? looks like no udebs are produced, so just copying the config from i386 would be fine (I assume)06:07
infinityThough, in this case, it's helpful to point out that dpkg-architecture is being run a crapload of times. :)06:07
dokogrep "\-di$" looks suspicious, missing architecture06:07
infinitydh_listpackages limits to the current arch, I assume.06:07
infinityYeah.06:07
infinityThat's precisely what it does, in fact.06:07
kylemdoko, 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
dokook, that works.06:08
dokokyle: how do I correctly increment the version number? just for producing a correct debdiff06:08
kylemdebian/rules startnewrelease06:09
dokokylem: 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.debdiff06:14
kylem17:06:22 < kylem> doko, yes. d-i is completely absent.06:15
kylemthe correct fix would be to add d-i...06:15
dokokylem: that can be done later, we just need linux-libc-dev for now06:16
infinitykylem: 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
kylemer, 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
kylemalright. fine.06:17
infinityOh, if it's easy and guaranteed to work, just do it, then.06:17
dokokylem: as you like it, I can test build it here06:17
infinityWon't hurt to have 'em, just in case.06:17
=== natenewz [n=nate@12-216-74-75.client.mchsi.com] has joined #ubuntu-kernel
dokoinfinity: it would be nice to have installer and/or live cd's just to offer something for testing06:19
kylemi'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"
zulits in there somewhere :)07:47
zuloh i hate cvs07: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
zulhey BenC 07:50
lamontzul: 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
bullgard4What is meant by 'LATE suspend' of my agpgart-intel loadable module's message in kern.log?08:05
mjg59It's the portion of the driver suspend called after interrupts are disabled08:06
lamontmjg59: btw, remember how putting the gutsy kernel on my laptop made suspend work?  well, it doesn't now...08:07
bullgard4mjg59: Thank you very much for explaining.08:07
lamontsomewhere between -5 and -8, -9 also b0rked08:07
lamontmjg59: is there a writeup anywhere that would give me clues on how to troubleshoot that?08:08
mjg59lamont: git bisect is probably the easiest08:09
kylemlamont, go to www.united.com, book a flight to heathrow, underground to kings cross, national rail to cambridge.08:09
mjg59Except you probably can't, because the kernels are rebased08:09
mjg59Which means the git history bears no resemblance to the release history08:09
=== BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-kernel
lamontmjg59: any chance you have a compaq mumble8440?08:10
mjg59lamont: Nope08:10
mjg59I've a 6220, but that's previous generation08:10
lamontyeah08:10
lamontand smaller.08:11
mjg59Per-generation, the hardware is pretty similar08:11
lamontmjg59: 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..
lamontor if there were any bits that needed to be blacklisted/whatever to get it to work08:12
mjg59lamont: If it previously worked, then bisect is probably as good as you're going to get08:12
lamontye08:13
lamontp08:13
mjg59You're just going to have to be handwavy in finding the last "good" kernel08:13
lamontyeah08:13
mjg59If we didn't rebase the tree, this would be a lot easier08:13
lamontwhy do we rebase the tree again?08:13
lamontI 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
mjg59Ben finds it easier08:14
mjg59Whereas I find having to pull into a branch and then merge that murder inducing08:14
kylemlamont, the commit you want pulled is not in your tree.08:15
lamonthrmpf.08:15
lamontheh08:15
lamontpushing08:15
lamontpushed08:18
mjg59BenC: Could we not rebase the tree repeatedly? It makes it *much* harder to figure out whether regressions are due to our code or to upstream08:20
kylemit won't be rebased anymore now that 2.6.22 is out.08:26
mjg59kylem: Not even to 2.6.22.1?08:27
mjg59(Or other parts of the stable branch)08:27
zulhave we actually pulled in 2.6.22.1?08:28
makxin debian yes :)08:31
zulnerver mine I answered my own question08:36
zulergh08:36
=== zul_ [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel
BenCmjg59: it was pretty easy for me to test that by testing with stock 2.6.22 and with our 2.6.2208:39
BenCmjg59: 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 it08:40
BenCs/stable/stock/08:40
mjg59BenC: But we don't ship a stock 2.6.2208:41
mjg59What users know is "-5 worked, -7 doesn't"08:41
mjg59That's easy to map back to a tree that matches the development history, but very difficult to map to a rebased tree08:41
lamontmjg59: keithp says that one should never use 'git pull', instead one should use 'git fetch' and an appropriate merge08:42
BenCtrue, but even mapping it back to proper history wont help much, considering the amount of upstream kernel changes mixed with our uploads08:42
BenCactually, you can get decent history just looking at the changelog08:42
kylemkeith is just being difficult, pull is just a fetch+merge.08:43
lamontBenC: creating a 2.6.22-9.23 _branch_ at the time of upload would preserve history for us08:43
lamontkylem: yeah, but he finds  that the merge is seldom the one he really wanted08:43
mjg59BenC: Given that the number of bisect jumps you need to do is log2 of the number of commits, it's not really a problem08:43
BenClamont: well, it's pointless now since we wont be rebasing anymore08:43
lamontBenC: for the future, I meant08:43
mjg59lamont: That doesn't actually solve the problem in any case :)08:43
BenClamont: good point, we can definitely do that08:43
kylemwe have a branch, since we have a tag.08:43
BenClamont: tags wont work?08:43
lamontmjg59: it renders it more-solvable, I expect08:44
BenCright, you can do "git-branch Ubuntu-2.6.22-9.23 Ubuntu-2.6.22-9.23"08:44
lamontwould a tag add a reference to the un-rebased commits?08:44
mjg59lamont: The tree refers to a different history to the one in my local repository08:44
mjg59BenC: Tags won't work across a rebase in any meaningful way08:44
mjg59lamont: So it's impossible to pull/fetch/whatever08:44
lamonthrm.08:45
BenCmjg59: 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
kylemSubject: Accepted linux-source-2.6.22 2.6.22-9.24 (source)08:45
BenCkylem: I never uploaded -9.2308:45
mjg59BenC: You continue to have issues. It may be an interaction between a new upstream patch and one of ours. 08:46
BenCjust so you know :)08:46
kylemBenC, hence it's still unreleased08:46
mjg59If 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 easier08:46
=== lamont goes to appointments
kylemblef.08:46
BenCmjg59: if v2.6.22 works and HEAD doesn't, you can easily rebase between those two points08:46
kylemcoffee.08:46
mjg59BenC: ?08:47
BenCmjg59: true, you miss the super rare case where an upstream commit during devel actually interacts bad with one of our patches08:47
BenCs/rebase/bisect/08:47
mjg59Well, yes, you can do that08:48
mjg59But it's not actually going to be significantly faster08:48
BenCit's not going to be slower either :)08:48
amitk_lamont: you might be suffering from bug #129226, perhaps?08:48
mjg59But, as you said, it misses one entire class of problem08:49
amitk_bug# 129226 even08:49
amitk_damn.. i can never quite figure out how to trigger the bot08:49
BenCmjg59: one extremely rare class, as I've never experienced it before :)08:49
mjg59BenC: I've hit it a couple of times.08:49
BenCamitk_: it's missing from this channel08:49
BenCmjg59: either way you do it, it doesn't give you full info08:50
mjg59ACPI is hard. Shopping time.08:50
mjg59BenC: Sure it does. One way actually reflects the history that we've published, and the other doesn't.08:50
BenCmjg59: without rebase, you wont know which patch of ours is interacting badly, and with rebase, you wont know which patch from upstream is the cause08:50
BenCmjg59: you still miss the info to know which patch of ours is interacting with a commit from upstream...unless I'm missing some detail08:51
mjg59I mean, in addition to it being a nightmare to remember to fetch into a branch and then use that as origin08:51
=== EtienneG [n=etienne@ubuntu/member/EtienneG] has joined #ubuntu-kernel
mjg59error: no such remote ref refs/heads/origin.old08:56
mjg59Ngh.08:56
doko\o/ 2.6.22-9.2408:57
dokoinfinity: wake up call ;-)08:57
kylemhopefully it builds on more than one flavour of amd64. ;-)08:57
=== Nafallo [n=nafallo@ubuntu/member/nafallo] has joined #ubuntu-kernel
Nafallohmm.09:40
Nafallosata_nv busted?09:40
Nafallosince like... feisty?09:40
BenCNafallo: worked on my one system, even in feisty09:46
NafalloBenC: are you aware if there are any bugs with sata_nv hangs? 09:48
Nafallostarts with: [  438.240000]  irq 7: nobody cared (try booting with the "irqpoll" option)09:48
mjg59Nafallo: Does /proc/interrupts claim that sata_nv is bound to irq 7?09:48
kylemah crap, i'm a muppet. forgot to -mv the abi files to 9.2309:48
Nafallo  7:       9820     264076    XT-PIC-XT        libata09:49
mjg59Ok, that's a good start09:49
mjg59So for some reason, sata_nv doesn't believe that the interrupt was its09:50
NafalloI got libata on 5,7,10,1109:50
=== Nafallo makes a pastebin with the full errormessage
Nafallohttp://paste.ubuntu-nl.org/32273/ <-- mjg59 09:51
NafalloI haven't really cared about the statement up until now that my two raptors arrived :-P09:52
mjg59Nafallo: The rest of dmesg would help09:52
Nafallohttp://home.nafallo.info/bugs/sata_nv.txt09:54
=== IntuitiveNipple [n=TJ@alexandros.tjworld.net] has joined #ubuntu-kernel
Nafallomjg59: feisty running now. same error on the gutsy tribe-3 server iso09:56
mjg59What's kind of weird is that you don't seem to have anything on the ports connected to irq 709:56
mjg59So it's either an irq routing issue (try booting with pci=noacpi) or a sata_nv bug09:57
mjg59amitk_: Why not just fudge the USB autosuspend code so it only triggers on mass storage and HID class devices?09:58
NafalloI think sdf and sdg are on IRQ7, cause those drives died after the error.09:58
Nafalloalso I'm booting with noapic for a reason :-)09:59
mjg59No, they're on irq 1009:59
mjg59Why are you booting with noapic?09:59
mjg59It's quite possible that the board irq routing has never been tested with xtpic09:59
amitk_mjg59: to keep in sync with upstream. Oliver Neukum pushed a similar patch to GregKH's tree10:00
mjg59amitk_: But it's likely that there's more devices that are broken10:00
Nafallomjg59: the kernel refuse to start telling me to boot with that option :-)10:00
mjg59And I'm sceptical that autosuspend of most USB devices is actually useful10:00
mjg59Nafallo: Well, attempting to debug that would be helpful10:00
mjg59Right now you're passing an option that has a reasonable chance of breaking things in exactly the way you're seeing10:01
Nafallomjg59: 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
Nafallomjg59: aha. how... evil.10:02
Nafallomjg59: so right now it is boot || sata then? ;-)10:02
mjg59So I suspect there's no problem with sata_nv10: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
Nafallohmm. oki :-)10:03
=== BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-kernel
mjg59amitk_: For reference, the only devices Windows suspends are hid, bluetooth and serial10:05
mjg59(http://www.microsoft.com/whdc/system/bus/USB/USBFAQ_intro.mspx)10:05
Nafallomjg59: do you think there would be a difference if I move the cables from ports 1 and 2 to ports 3 and 410:05
Nafallo?10:05
=== bradley [n=bradley@CPE-24-208-44-208.new.res.rr.com] has joined #ubuntu-kernel
Nafallomaybe someone on IRQ7 starts caring then :-P10:06
mjg59Nafallo: Could work, but it would be preferable to actually debug it10:07
amitk_interesting... mjg59, thanks for the link. I will work on a patch and talk to Alan10:07
Nafallomjg59: agreed :-)10:08
mjg59amitk_: 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 often10:13
mjg59Well, other than mass storage10:15
mjg59But 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
mjg59amitk_: If you could cc me on the patch, that would be great10:18
amitk_mjg59: sure10: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
mjg59amitk_: It could be, but in that case why have a blacklist in-kernel at all?10:26
mjg59I think it would make more sense to have a userspace whitelist rather than a "Break my hardware by default" kernel option10:27
mjg59Given that all we get out of it is a small amount of power saving10: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 happy10:29
mjg59amitk_: 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!