[12:16] <BenC> kylem: works on my pata_amd
[12:16] <kylem> lazka, er, maybe?
[12:16] <lazka> kylem, what should be the dev name?
[12:16] <kylem> mount -t iso9660 /dev/scd0 /mount
[12:16] <trejack> FYI my problem persists with a new install from today's daily build.
[12:17] <Nafallo> /dev/cdrom
[12:17] <BenC> trejack: Try: http://people.ubuntu.com/~kyle/kernels/feisty/linux-image-2.6.20-15-generic_2.6.20-15.27_i386.deb
[12:17] <kylem> trejack, what problem?
[12:17] <BenC> kylem: trejack was also having the pata_amd issue
[12:17] <kylem> ok
[12:17] <lazka> no medium found..
[12:17] <BenC> lazka: do you have a disk in there?
[12:17] <trejack> I can't.  Wiped my working 2.6.20-17 install
[12:18] <lazka> yeah, i will  look for a cleaner one..
[12:18] <trejack> Wait a sec - I can chroot in from my edgy
[12:18] <moodydeath> is it the correct device, laska? ... could be scd1, too, if you got more
[12:18] <trejack> I'll be back
[12:19] <lazka> ok, /dev/cdrom is my dvd-drive
[12:19] <lazka> and its working
[12:20] <lazka> but i cant find the lite-on
[12:21] <lazka> kylem, it makes some noise but doesnt spin up
[12:21] <BenC> [   30.987575]  scsi 1:0:1:0: CD-ROM            PLEXTOR  DVD-ROM PX-116A2 1.00 PQ: 0 ANSI: 5
[12:22] <BenC> that's the only thing I see connected
[12:22] <kylem> it only found one ATAPI device
[12:22] <BenC> There is only /dev/sr0, no /dev/sr1
[12:22] <kylem> and didn't even whine about the rest
[12:22] <kylem> are you sure it's cabled properly?
[12:23] <heno> kylem: are you building an amd64 version for testing as well?
[12:24] <lazka> kylem, should be, i'll check with 20.13 again if it still works there, k?
[12:24] <BenC> heno: I am, I'll upload it when it's done
[12:24] <kylem> ok
[12:24] <heno> ok, cool
[12:27] <lazka> kylem, bad news, works ok with 20.13
[12:28] <BenC> lazka: can you pastebin dmesg from .13?
[12:29] <lazka> http://pastebin.ubuntu-nl.org/15681/
[12:29] <lazka> [   32.828189]  hdc: LITE-ON LTR-52246S, ATAPI CD/DVD-ROM drive
[12:29] <BenC> kylem: amd64 is uploading to my ~/, I'll let you put it next to yours
[12:29] <BenC> hdc?!
[12:30] <kylem> you must have shuffled pci ids?
[12:30] <lazka> umh what?
[12:30] <kylem> brb.
[12:30] <BenC> -13 -> -14 == ata update
[12:30] <BenC> probably moved from amd ide to pata_amd
[12:30] <Nafallo> pata_amd still used hd? in -13 for me aswell
[12:31] <Nafallo> or that :-)
[12:31] <BenC> brb
[12:34] <lazka> it did say that in the bugreport...
[12:45] <BenC> kylem: if the problem we're having is just in pata_amd, maybe switching back to the amd IDE driver is best
[12:45] <BenC> looks like the quick fix didn't take care of all the problems
[12:49] <trejack> No good for me, either.  (Iused the -15.27 kernel).  The dmesg is at http://librarian.launchpad.net/7331329/dmesg2.txt
[12:50] <BenC> still showing exceptions for trejack too
[12:50] <trejack> Don't know if this will help or not, but when I booted into the live cd, it at first couldn't use any of my existing partitions.
[12:51] <trejack> I reformated the sda3 one using gparted, and it completed in seconds, and my sda1 partition was suddenly available, as well
[12:52] <BenC> trejack: doing a new build to revert back to amd74xx driver
[12:52] <BenC> lazka, moodydeath: you guys willing to test another kernel in about 30 minutes?
[12:53] <lazka> BenC: yep
[12:53] <trejack> I'll check back in 30.  Thanks
[12:53] <moodydeath> yep
[12:53] <BenC> thanks, build started, will post here when it's done
[01:09] <moodydeath> is this the new one ?
[01:09] <lazka> moodydeath: no
[01:09] <moodydeath> kk :)
[01:09] <moodydeath> ah ... should read the whole topic ... -_-
[01:10] <lazka> there is so much crap on TV at night :P omg
[01:21] <BenC> builds are done, getting ready to upload
[01:22] <defendguin> hey BenC
[01:22] <defendguin> apparently the mmc card reader fix isn't working
[01:23] <BenC> it was reported to work for many people
[01:23] <defendguin> hmmm
[01:23] <BenC> it doesn't resolve all mmc issues
[01:23] <defendguin> i wish i had a card on me
[01:23] <BenC> it was just one major regression
[01:24] <BenC> 53b205c5fbe264a700454a4f5416d0a8  linux-image-2.6.20-15-generic_2.6.20-15.26_amd64.deb
[01:24] <BenC> 7a5f4a0801be29c9c614b3d1a673edf2  linux-image-2.6.20-15-generic_2.6.20-15.26_i386.deb
[01:24] <BenC> http://people.ubuntu.com/~bcollins/kernels/feisty-release/
[01:24] <moodydeath> dl running :D
[01:25] <BenC> note that kernel changes pata_amd back to amd74xx, so your devices will go to hdX
[01:25] <BenC> moodydeath: it's still being uploaded
[01:25] <moodydeath> hmm
[01:25] <BenC> probably be completed in about 5 minutes
[01:25] <BenC> probably less
[01:25] <MrNOKIA> is it a 32 or a 64 bit version ?
[01:25] <moodydeath> i'll f5 ;)
[01:27] <MrNOKIA> i'm sorry, i must be missing something
[01:27] <MrNOKIA> i'm using linux-image-2.6.20-15-generic_2.6.20-15.27_i386.deb
[01:27] <trex37> what's the file size?
[01:28] <MrNOKIA> the new file is .26 ?
[01:28] <MrNOKIA> 21 Mb
[01:29] <lazka> it's ready
[01:29] <MrNOKIA> yes,but...
[01:29] <MrNOKIA> why is it .26 now ?
[01:30] <MrNOKIA> i.m on .27 for about an hour
[01:31] <moodydeath> .27 was a version from kyle
[01:31] <MrNOKIA> kile ?
[01:31] <MrNOKIA> kyle ?
[01:33] <moodydeath> BenC: kernel boots ... as fast as -12 did
[01:33] <moodydeath> testing drives
[01:34] <MrNOKIA> moodydeath, what is kyle ? should i try the new kernel now ?
[01:34] <moodydeath> scd0 & scd1 working :D
[01:35] <moodydeath>  http://people.ubuntu.com/~kyle/kernels/feisty/ <-- here is the .27 ...  but i think the .26 which was released some minutes ago is the new one
[01:36] <lazka> Ubuntu 2.6.20-15.26-generic
[01:36] <lazka> http://pastebin.ubuntu-nl.org/15700/
[01:36] <lazka> everything back to normal
[01:37] <moodydeath>  http://pastebin.ubuntu-nl.org/15701
[01:37] <moodydeath> me, too :D
[01:38] <lazka> BenC: is it intentional that ivtv isn't working with your builds?
[01:38] <lazka> it worked with kylem's build
[01:39] <trejack> Yay!  That one did it
[01:39] <trejack> what do you need from me?
[01:44] <BenC> lazka: no, I didn't change that
[01:44] <BenC> trejack: dmesg please
[01:44] <lazka> BenC: what do you mean?
[01:44] <BenC> lazka: ivtv
[01:45] <cjwatson_> lazka: from your log earlier it looked like you were just missing the firmware
[01:45] <cjwatson_> iirc
[01:45] <lazka> BenC: your build is 2 MB smaller..
[01:45] <BenC> lazka: could be a left out the firmware
[01:45] <BenC> quirk in the build
[01:46] <lazka> thats what i mean..
[01:46] <BenC> lazka: try copying it from /lib/firmware/linux-image-2.6.20-13-generic/
[01:46] <BenC> it wont happen in the final build
[01:46] <lazka> ok, thanks
[01:46] <BenC> I trimmed some things out of the build to speed things up
[01:46] <BenC> mainly linux-headers, linux-debug, and apparently firmware
[01:47] <lazka> ah, i see, however.. i'm going to bed now, already 2 am here.
[01:47] <BenC> lazka: thanks
[01:47] <lazka> gn8 all
[01:47] <BenC> Mithrandir, cjwatson: The three testers we had that reported the problem have reported success
[01:47] <BenC> the fix was reverting back to amd74xx IDE driver instead of pata_amd
[01:47] <cjwatson> right, do you have the diff or is it in git?
[01:48] <BenC> so it's a relatively safe and isolated fix
[01:48] <BenC> amd74xx was actually being used up until about 5 weeks ago
[01:48] <cjwatson> I'm actually just going to bed, but I am happy to be woken up once it's uploaded
[01:48] <BenC> will be done in about 10 minutes
[01:48] <cjwatson> ok
[01:48] <cjwatson> send me an SMS on my mobile number?
[01:49] <BenC> cjwatson: Ok
[01:49] <BenC> cjwatson: wait, I can't send Intl SMS
[01:50] <BenC> unless you have an email that redirects
[01:51] <BenC> trejack, lazka, moodydeath: thanks for the testing!
[01:51] <moodydeath> np :)
[01:51] <MrNOKIA> np ?
[01:51] <BenC> the past few days, we've been very fortunate to have folks coming around to bear the burden of our test builds
[01:51] <BenC> MrNOKIA: np == no problem
[01:52] <BenC> MrNOKIA: were you having the pata_amd problems?
[01:52] <moodydeath> will there be something like a final version, that will need a test ?
[01:52] <MrNOKIA> sorry
[01:52] <MrNOKIA> i knew that
[01:52] <BenC> moodydeath: by tomorrow there should be something in your update manager :)
[01:52] <MrNOKIA> I guess
[01:52] <BenC> MrNOKIA: could you test the kernel in the topic URL?
[01:53] <BenC> I'm sure it will work for you, if that's in fact the issue you were having
[01:53] <MrNOKIA> I could'nt boot the new kernel untill the .25 version came up
[01:53] <trejack> http://librarian.launchpad.net/7331974/dmesg3.txt
[01:53] <MrNOKIA> i posted info on the dedicated thread
[01:53] <MrNOKIA> hope it helped
[01:54] <MrNOKIA> my nick is pretty much the same as on ubuntuforums :)
[01:54] <BenC> MrNOKIA: ok, thanks
[01:54] <BenC> trejack: excellent, thanks
[01:54] <BenC> cjwatson, Mithrandir: kernel away
[01:54] <trejack> Thank you!
[01:55] <trejack> I must say I was intimidated by all of this at first, but it's been a pleasure...
[01:55] <MrNOKIA> BenC: a new kernel ?
[01:56] <MrNOKIA> i see only the 15 april .26 version 
[02:08] <defendguin> got it all fixed?
[02:23] <BenC> defendguin: looks that way
[02:23] <BenC> MrNOKIA: the one in my dir in the URL is the same as the one I uploaded (sans some firmware)
[04:17] <gnufied> extended attributes are enabled on stock ubuntu dapper kernels?
[04:17] <gnufied> if yes, then how do i find out?
[04:19] <crimsun> grep -i xattr /boot/config-$(uname -r)
[04:19] <gnufied> thanks, so its enabled.
[04:54] <yoasif> i just saw the post on ubuntuforums about the sata_nv issue... how can i help?
[04:54] <mjg59> Should be fixed now
[04:55] <mjg59> See the topic
[04:55] <yoasif> ty
[04:56] <yoasif> hmm, 15-27 is listed on ubuntuforums, should i get that, or the one in the topic?
[04:56] <yoasif> (i am experiencing the PATA issues)
[04:57] <mjg59> 15.27 is the latest, I believe
[04:57] <mjg59> It's worth a go
[04:57] <yoasif> ok
[05:00] <yoasif> mjg59: do you have any ideas what the problem might be if every once in a while, the screen goes all wonky (the screen gets compressed down, and a load of copies of the screen get patterned, and skewed)
[05:00] <yoasif> ssh doesn't work, and i've tried just using vesa
[05:00] <mjg59> No
[05:01] <yoasif> heh... i'm really wondering how i can describe the issue properly. 
[05:18] <keturn> sounds a little like your graphics card aesploded
[05:18] <yoasif> it's onboard 
[05:18] <yoasif> and a pretty new mobo
[06:29] <cjwatson> -15.27 kernel belatedly accepted - builds will start running as soon as I can manage it
[06:30] <kylem> thanks colin
[06:32] <cjwatson> http://librarian.launchpad.net/7331974/dmesg3.txt (from trejack earlier) has some DriveReady SeekComplete Error stuff before the kernel finally gets hda going - is that unrelated?
[06:32] <kylem> unlikely
[06:33] <kylem> oh, yeah
[06:33] <mjg59> Likely that it's unrealted, by the looks of it
[06:33] <kylem> i thought hda was the missing cdrom
[06:33] <mjg59> BadCRC is either complete timing fuckup, or bad cable
[06:33] <kylem> likely a 40pin cable
[06:34] <mjg59> But, hell, drivers/ide has never really worked
[06:34] <cjwatson> hda has a partition table in that dmesg so it's not a cdrom
[06:34] <kylem> right
[06:34] <mjg59> It ends up coming up in pio mode
[06:34] <kylem> works by magic
[06:34] <kylem> sheer force of will
[06:34] <mjg59> Not ideal, but it'll do
[06:34] <cjwatson> ha
[06:34] <kylem> hmm, mark lord lives in the same city as me
[06:35] <kylem> i can walk over and beat him up if you want
[06:35] <kylem> :P
[06:35] <cjwatson> ok, publisher's running, I'm off back to sleep
[06:35] <mjg59> Oh, that system looks shitted anyway
[06:35] <kylem> cjwatson, night
[06:35] <mjg59> [   20.079279]  ..MP-BIOS bug: 8254 timer not connected to IO-APIC
[06:35] <mjg59> [   20.079317]  ...trying to set up timer (IRQ0) through the 8259A ...  failed.
[06:35] <mjg59> [   20.079320]  ...trying to set up timer as Virtual Wire IRQ... failed.
[06:35] <mjg59> [   20.119013]  ...trying to set up timer as ExtINT IRQ... works.
[06:35] <mjg59> Never seen that on an nvidia board before
[06:36] <cjwatson> phone me if it all blows up, and I'll try not to fall straight back to sleep again :-/
[06:36] <cjwatson> Mithrandir has it set up so that the kernel builds on palmer this time
[06:37] <mjg59> cjwatson: The errors there don't look related to any of the HPA/libata stuff
[06:38] <cjwatson> ok, thanks
[07:24] <bdgraue> cjwatson: linux-image-2.6.20-15-generic_2.6.20-15.26_i386.deb  works for me
[08:40] <Nafallo> kylem: my server seems to have kept itself from hanging after I removed irqpoll :-).
[09:17] <crimsun> BenC: I've emailed you a tested and verified patch for #105582. Please consider applying it to avoid a regression from dapper.
[09:19] <Mithrandir> crimsun: too late, but it should go into an SRU
[09:20] <crimsun> Mithrandir: whatever you guys [have]  decide[d] 
[09:21] <Mithrandir> crimsun: sorry. :-/
[09:39] <benh> crimsun: here ? :-)
[09:39] <crimsun> yep.
[09:39] <benh> ok, so it's indeed Version: 2.6.20-15.25
[09:40] <benh> and it blows up when moving the mouse
[09:40] <benh> on a Quad G5
[09:40] <benh> linux-image-2.6.20-15-powerpc64-smp, in console mode, minimum install (no X, no gpm)
[09:40] <benh> I don't have a hardcopy of the crash yet, it crashes at irq time, so no log
[09:40] <benh> backtrace shows that it comes from usb -> input -> evdev
[09:41] <benh> and it might be blowing up in do_gettimeofday() which would be VERY strange
[09:41] <benh> are there some known ubuntu patches in that area ?
[09:43] <benh> crimsun: yup, I think BenC is asleep :-( pung him already on some other channel, didn't help
[09:44] <benh> I'm a bit lost with launchpad, how do I look at the bugs reported for a given package ?
[09:44] <benh> https://launchpad.net/ubuntu/+source/linux-source-2.6.20 seems to indicate that a .27 is out
[09:44] <benh> though it hasn't hit au.archive.ubuntu.com
[09:45] <benh> might be worth for me trying to dig that and check before filing a bug report
[09:45] <crimsun> https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bugs
[09:46] <benh> hrm.. I don't see it
[09:46] <benh> me gets the source and have a look how on earch do_gettimeofday() could crash ...
[09:48] <Mithrandir> -15.27 probably won't hit au.archive for another couple of hours, but you can get it off archive.ubuntu.com or launchpad.
[09:49] <benh> yup, I'll try that too
[09:50] <Mithrandir> https://launchpad.net/+builds/+build/318987/linux-image-2.6.20-15-powerpc64-smp
[09:51] <benh> not on archive's Package file yet, I'll wait and look at hte source in the meantime
[09:51] <benh> ok
[09:51] <benh> that would do too I suppose :-0
[09:51] <Mithrandir> I really can't believe we wouldn't have massive amounts of bug reports about that bug, unless there's something special with your hardware.
[09:52] <benh> nothing special that I can see... just a fairly ordinary quad G5
[09:52] <`sam`> does -25.27 need testing for sata_nv or is it known to work? because i'm installing now...
[09:52] <benh> anyway, have to run, will be back later & investigate
[09:53] <benh> have 2 disks though and using an lvm but heh... that shouldn't matter :-)
[09:53] <bdgraue> 15-26 is running fine with sata_nv
[09:53] <bdgraue> -15.26 i mean
[09:54] <Mithrandir> `sam`: we want as much testing as we can get on the latest kernel (-15.27).  Even if previous ones worked fine, we want to make sure there are no regressions.
[09:54] <Mithrandir> `sam`: so if you have a bit of time to spare, it's much appreciated.
[09:54] <bdgraue> Mithrandir: i'll try the new -15.27 too
[09:55] <`sam`> ok, i've had -15.25 installed but have still been running -14.23... going to reboot now and see
[10:03] <`sam`> well -15.27 boots for me
[10:03] <`sam`> took me a few minutes because i had changed my xorg.conf about 30 minutes ago and had messed it up
[10:04] <Mithrandir> `sam`: good to hear, CD-ROM/DVD-ROM and all works too?
[10:06] <`sam`> yeah i just tested a dvd and it started playing in totem
[10:07] <Mithrandir> great
[10:07] <Mithrandir> please tell us if you have other (kernel-related) regressions?
[10:10] <bdgraue> Mithrandir: where can i get the 15-27?
[10:10] <`sam`> like what? anything specific you want me to check out?
[10:12] <bdgraue> are the 2.6.20-15.27 not available for i386 yet?
[10:13] <`sam`> bdgraue, have you checked in update-manager? i just found it there about 25 minutes ago
[10:14] <bdgraue> `sam`: not here i have archive.ubuntu.com
[10:14] <Mithrandir> bdgraue: are you on i386?  If so, the kernel is not done yet.
[10:15] <bdgraue> ok then
[10:15] <bdgraue> i'll wait :-)
[10:16] <macd> palmer is cooking hot ;)
[10:17] <bdgraue> Status:	Currently building
[10:17] <bdgraue> :-)
[10:17] <`sam`> Mithrandir, was the drive detection the main problem? if there's anything else i could test i've got time... even though i don't know what all i'm looking for :)
[10:21] <Mithrandir> `sam`: yes, the problems were all related to drive detection and also some HPA.
[10:22] <Mithrandir> can you run dmesg | grep hpa in a shell and paste the contents somewhere?
[10:23] <`sam`> it's only 2 lines, can i paste it here?
[10:24] <Mithrandir> sure
[10:24] <`sam`> [   24.478810]  ata1.00: ata_hpa_resize 1: sectors = 312500000, hpa_sectors = 312500000
[10:24] <`sam`> [   24.490762]  ata1.00: ata_hpa_resize 1: sectors = 312500000, hpa_sectors = 312500000
[10:25] <Mithrandir> ok, and no scary errors of any kind in dmesg?
[10:27] <`sam`> i don't think so, but i don't know what this is:
[10:27] <`sam`> [   25.958194]  ATA: abnormal status 0x7F on port 0x0000000000010967
[10:29] <Mithrandir> hm
[10:30] <Mithrandir> not great, but if it all works, I wouldn't worry too much
[10:37] <`sam`> what is the hpa exactly? i'm just finding stuff about thinkpads...
[10:37] <benh> Mithrandir: crash still happens with .27
[10:37] <benh> Mithrandir: will investigate
[10:39] <benh> Mithrandir: do you guys have extra patches on top of mainline like some of the -rt or clock sources stuff ? some of that is known to introduce fancy breakage on ppc
[10:40] <benh> (still d/l the source on my crappy link here)
[10:40] <cjwatson> `sam`: http://en.wikipedia.org/wiki/Host_Protected_Area
[10:40] <Mithrandir> benh: we have lowlatency, but it's not enabled in the default kernels.
[10:40] <benh> k
[10:41] <cjwatson> our kernel's in git if that helps
[10:41] <Mithrandir> benh: I'm not a kernel hacker, so I'm not sure what other patches have been brought in.
[10:41] <benh> ok, because the scary thing is ... there is -no way- such an error could happen in gettimeofday on normal mainline
[10:42] <benh> unless there have been kernel memory corruption :-(
[10:42] <cjwatson> http://git.kernel.org/?p=linux/kernel/git/bcollins/ubuntu-feisty.git;a=summary
[10:43] <benh>  ... or it's passed a crap argument
[10:43] <benh> which is probably the likely cause... need to disasm to see where exactly the crash occurs
[10:43] <cjwatson> Mithrandir: -15.27/i386 is in accepted, if you hadn't already noticed; feel like accepting d-i?
[10:43] <benh> I wounder if stupid mousemu could be causing it
[10:48] <Mithrandir> cjwatson: ah, just got there then, I'll accept it
[10:49] <benh> Mithrandir: ok, if you kill mouseemu, it doesn't crash
[10:49] <Mithrandir> is mouseemu kernel mode?
[10:49] <benh> Mithrandir: at this point, I'm about 99% convinced it's some crap in uinput vs. 32 bits apps on 64 bits kernels
[10:50] <benh> Mithrandir: no, but it uses some whacky kernel interfaces (uinput) which I wouldn't be surprised at all is broken
[10:50] <benh> Mithrandir: there is a long tradition of brokenness in the input layer userland interfaces, especially vs 32/64 bits
[10:50] <Mithrandir> hmkay.
[10:50] <benh> Mithrandir: it's likely that running a 32 bits mouseemu on a 64 bits x86 will crash too
[10:51] <benh> Mithrandir: I'll have to investigate in more details but can't do that tonight, in the meantime, it might be worth (if possible) to disable mouseemu by default on powerpc64
[10:51] <Mithrandir> we don't support 64 bit kernels and 32 bit userland on x86_64, so that's not really that important.
[10:51] <benh> Mithrandir: hehe, fair enough :-)
[10:51] <Mithrandir> "you run this and it breaks?  You get to keep both pieces."
[10:52] <benh> Mithrandir: well, I know powerpc isn't officially supported anymore.. but if you guys want to avoid that problem, the short term band-aid is to disable mouseemu on 64 bits powerpc's
[10:52] <Mithrandir> cjwatson: ^^ ; your code, your call, I'm not sure what's a reasonable direction to go in from here.
[10:52] <benh> Mithrandir: want me to file a launchpad entry ?
[10:52] <Mithrandir> benh: yes, a bug would be good.
[10:52] <benh> Mithrandir: I'll try to debug that properly later, I'll be away for most of next week though
[10:52] <Mithrandir> benh: yes, I'm trying to think of a way to not end up saying "sorry, ppc is SOL".
[10:52] <benh> Mithrandir: :-)
[10:53] <benh> Mithrandir: well... it would hit ps3 
[10:53] <Mithrandir> it would, which is bad.
[10:53] <Mithrandir> I'm wondering if we can do it in an SRU or not..
[10:53] <benh> I'd say just don't install mousemu by default on 64 bits ppc's ... I suppose you install it by default bcs of 1 buttons apple mice...
[10:54] <benh> anyway, I'll file a launchpad entry tonight so it's at least tracked before I go
[10:54] <benh> I'll try to find out what's wrong in the kernel later
[10:56] <cjwatson> Mithrandir: wah, need to do that before d-i goes in
[10:56] <cjwatson> Mithrandir: can you reject it temporarily?
[10:58] <cjwatson> benh: one-button mice> right, the old sysctl approach isn't available on x86 for Intel Macs and I wanted to have the same scheme across architectures
[10:58] <cjwatson> it was working fine for me on 32-bit powerpc :-/
[10:58] <benh> cjwatson: faiir enough
[10:58] <benh> cjwatson: yeah, well, uinput is a pile of poo unfortunately
[10:58] <benh> cjwatson: I'll check if the problem is still in upstream 2.6.21-whatever-git-of-the-day first
[10:58] <cjwatson> Mithrandir: I've rejected debian-installer so that I can squeeze hw-detect in front
[10:59] <cjwatson> benh: the powerpc64 option sounds reasonable
[10:59] <benh> another option might be to build it as a 64 bits binary :-) if the bug is what I think, that might work
[10:59] <cjwatson> can't do that at this point
[10:59] <cjwatson> it's the same binary package on powerpc32 and powerpc64, would involve massive fiddling
[10:59] <cjwatson> also we're right at the wire
[11:00] <cjwatson> literally if this had been half an hour later it would have been too late ;)
[11:00] <benh> heh
[11:00] <benh> I knew it was a good idea to try out fesity on this g5 :-)
[11:01] <cjwatson> meh, this means I have to figure out whether the running system is ppc64
[11:01] <benh> I've been running it on the laptop for some time, had minor issues, but overall good
[11:01] <cjwatson> arch_get_kernel_flavour () {
[11:01] <cjwatson>         CPU=`grep '^cpu[[:space:] ] *:' "$CPUINFO" | head -n1 | cut -d: -f2 | sed 's/^ *//; s/[, ] .*//' | tr A-Z a-z`
[11:01] <cjwatson>         case "$CPU" in
[11:01] <benh> cjwatson: ugly way: check /proc/ppc64 :-)
[11:01] <cjwatson>                 power3|i-star|s-star|power4|power4+|ppc970*|power5|power5+|cell)
[11:01] <cjwatson>                         family=powerpc64
[11:01] <benh> nah
[11:01] <cjwatson> will have to duplicate crap like that I guess
[11:01] <benh> don't test the cpu model
[11:01] <cjwatson> benh: huh, that actually exists?
[11:01] <benh> that's too ugly for words
[11:01] <cjwatson> I know, but it's all we had
[11:01] <benh> cjwatson: it does in 2.6.20 :-0
[11:01] <cjwatson> neat
[11:02] <benh> let me dbl check it does on your kernel...
[11:02] <cjwatson> the code's there, but I'm no expert
[11:03] <benh> it does
[11:03] <benh> either that or you check for uname -a containing powerpc64
[11:03] <benh> I'm sure there are better ways :-)
[11:03] <benh> but you should never have to check for individual cpu models
[11:03] <benh> anyway, anything that works for you...
[11:04] <cjwatson> might change that at some point, cpuinfo testing is useful though because of the automatic test framework there
[11:04] <cjwatson> could probably teach it about uname output if it doesn't know already
[11:04] <cjwatson> anyway, I'll [ ! -d /proc/ppc64 ]  in hw-detect, thanks
[11:06] <benh> yah, it's dir with various crap in it
[11:06] <benh> we can't really remove it because of some stupid stuff relying on it
[11:07] <benh> so it will stay a bit longer...
[11:07] <benh> anyway, use whatever is best for you
[11:07] <benh> btw, I was impressed how good the installer was vs. setting up yaboot
[11:07] <benh> I was installing on sdb, with lvm & all, sda had my debian stuff etc..
[11:07] <benh> and the installer figured it all out, and setup yaboot.conf entries for my sda stuff too, neat !
[11:08] <cjwatson> Mithrandir: could you review hw-detect 1.45ubuntu5 to work around benh's bug?
[11:08] <cjwatson> then binaries of that need to be accepted before re-accepting debian-installer
[11:08] <Mithrandir> not in the queue yet, but yes, will do in two minutes
[11:08] <cjwatson> benh: yeah, the os-prober stuff for detecting other systems is nice
[11:09] <cjwatson> still keep getting the odd report of ofpath glitches
[11:09] <benh> yeah, for some reason, I didn't hit those tho
[11:09] <benh> (I was expecting to :-)
[11:09] <benh> I think it re-used my boot partition on sda which is probably why it worked
[11:10] <cjwatson> we do have a couple of ofpath patches, think I sent them to Debian a while back
[11:10] <cjwatson> not entirely sure they're right on all systems though
[11:11] <benh> I'm filing a launchpad entry for the kernel bug so we can track it
[11:11] <cjwatson> had a report the other day which suggests not, though I haven't seen the /proc/device-tree/ tarball for it yet
[11:12] <cjwatson> thanks. so you reckon it's lack of 64/32-bit thunking in the uinput ioctls?
[11:13] <benh> it's either that or a bug in the thunking... either way, it shouldn't crash the kernel :-)
[11:13] <Mithrandir> are those ioctls available to the user?  If so, we should get this fixed in a security upload.
[11:13] <cjwatson> Mithrandir: yes, mouseemu is userspace
[11:13] <cjwatson> oh to non-root you mean?
[11:13] <Mithrandir> well, non-root user.  "root can crash the kernel" isn't very interesting.
[11:14] <benh> I suspect it might use read/write instead of ioctl's ... but I'll confirm all that when I have time to dig, after I'm back from Perth next week
[11:14] <cjwatson> probably to anyone who can read/write /dev/input/*
[11:14] <benh> depends on the permission on uinput
[11:14] <cjwatson> benh: ioctl to set up the virtual device, read/write to interact with it
[11:14] <benh> uinput is a hack that allows to filter input events from userspace
[11:14] <cjwatson> crw-rw---- 1 root root 10, 223 2007-04-12 10:28 uinput
[11:14] <benh> yeah
[11:14] <cjwatson> at the moment
[11:14] <benh> ok, so it's not -too- bad... still worth fixing at one point
[11:15] <Mithrandir> sure, it's worth fixing, but not getting into (another) panic about.
[11:15] <benh> either a small fix if easy, or just forbid read/write on 32 bits if not a simple fix
[11:15] <benh> sure
[11:15] <benh> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/106723
[11:16] <cjwatson> thanks
[11:17] <benh> the input layer 32/64 its thunking is known to be a total PITA
[11:17] <benh> anyway, I'll dig when I can, not enabling mouseemu by default on powerpc64 is a good enough workaround for now as far as I'm concerned
[11:17] <Mithrandir> hw-detect accepted.
[11:18] <cjwatson> ta
[11:18] <Mithrandir> cjwatson: is d-i going to run with the correct kernel (32/64 bit)?
[11:18] <cjwatson> benh: yeah, the ghastly /etc/sysctl.conf-is-different-on-powerpc hack is still in place so 1-button mice won't break anyway
[11:18] <cjwatson> Mithrandir: yes
[11:18] <Mithrandir> ok
[11:18] <cjwatson> one doesn't work on the other
[11:19] <benh> we used to have G5 support on 32 bits ... along time ago :-) we ditched it at least 2 yrs ago
[11:19] <benh> it was a pain to maintain
[11:19] <cjwatson> very glad I didn't revert /etc/sysctl.conf to stock now ...
[11:23] <benh> btw, out of curiosity, what is the policy for updates vs security ?
[11:23] <benh> like feisty-updates vs. feisty-security repos
[11:24] <benh> or more specifically, in what circumstances are things updated when it's not a security update ?
[11:24] <Mithrandir> when there is "significant breakage".
[11:24] <benh> I would suspect... bugs (things don't work) but what is the threshold for a bug to be actually fixed in a release vs. in the next version ?
[11:24] <benh> ah ok
[11:25] <benh> well, I suppose it's a matter of somebody to decide wether it's significant enough and the fix unintrusive enough then...
[11:25] <benh> fair enough
[11:25] <Mithrandir> it's always a matter of judgement, but it's for high-impact bugs which can be fixed in a localised fashion and we're reasonably sure it won't break anything else.
[11:25] <benh> yup, makes sense
[11:26] <benh> I wonder if mplayer not working on most 32 bits powerpc's will be fixed thn ;-)
[11:26] <Mithrandir> https://wiki.ubuntu.com/StableReleaseUpdates under "When" has the criteria.
[11:26] <benh> (it's apparently compiled with an option for using instructions that don't exist on most 32 bits cpus)
[11:26] <benh> oh well, we'll see
[11:27] <Mithrandir> mplayer is multiverse, so less stringent about updates to it.
[11:27] <benh> yeah
[11:27] <Mithrandir> it's also not a core component; updates to glibc have to be much more serious than updates to, say, bluez-cups
[11:28] <benh> yup
[11:28] <benh> ok, have to go, thanks for the workaround !
[11:28] <Mithrandir> see you
[11:28] <benh> bye
[11:59] <bdgraue> 2.6.20-15.27 work well, no more problems here, i think
[12:06] <bdgraue> if i can do somethink, you have to tell me :-)
[12:53] <cjwatson> bdgraue: great, much appreciatted
[12:53] <cjwatson> -t
[12:54] <bdgraue> :-)
[03:54] <`sam`> what's the deal with 2.6.20.15.14, i think it's the same as 2.6.20-15.27? i'm trying to explain it to somebody in #ubuntu+1 but don't completely understand it myself
[04:22] <gene6482> this is a kernel question but it needs support, so if i'm in the wrong place i'm sorry, basically i have a toshiba laptop with sound issues and after some research have learned that my dsdt is buggy, can anyone help me fix it?
[04:22] <defendguin> i don't suppose michael bienia is in here?
[04:45] <Nafallo> defendguin: try -motu
[04:45] <defendguin> -motu?
[04:45] <Nafallo> #ubuntu-motu
[04:45] <defendguin> ahh
[04:47] <gortiz> ehm.. sorry, but someone will ever upload also the restricted driver for -15.25??
[04:48] <gortiz> ?
[04:50] <gortiz> is there someone?
[04:52] <Nafallo> gortiz: some developers haven't had much sleep the last three or four days. please calm down :-)
[04:52] <gortiz> sorry Nafallo 
[04:52] <gortiz> i didn't want to be arrogant
[04:52] <Nafallo> it's okey. I'm not one of them ;-)
[04:53] <gortiz> ok i ask to forgive me..
[04:53] <gortiz> Nafallo, do you know if they are uploading also the restricted drivers?
[04:53] <gortiz> I can't test it withot them..
[04:53] <Nafallo> gortiz: at some point I'm sure they will :-)
[04:53] <gortiz> lol Nafallo 
[04:53] <gortiz> thanks bye
[04:55] <Nafallo> they even seems to BE uploaded already :-)
[04:55] <Nafallo> gortiz: ^
[04:55] <gortiz> ok so it's my mirror to be outdated..
[04:56] <gortiz> i'll wait the italian mirror to be updated.. :)
[04:56] <gortiz> thanks
[05:00] <gortiz> ehm.. ok i've controlled.. it's the -15.27 not -15.25 the one i need..
[05:00] <gortiz> i'm on -15.25 and i haven't any problem
[05:01] <mjg59> -15.25 and -15.27 use the same l-r-m
[05:02] <Nafallo> -15.20
[05:14] <MrNOKIA> guys, may i ask what's the diference between  linux-headers-2.6.20-13-lowlatency and linux-headers-2.6.20-13-generic 
[05:15] <gortiz> MrNOKIA, ehm the lowlatency?
[05:15] <MrNOKIA> in other words, what is more desirable to have on a dual-core centrino ?
[05:15] <gortiz> generic
[05:15] <MrNOKIA> the genreric or the low-latency kernel ?
[05:16] <MrNOKIA> lowlatency kernels are for slow cpu's ?
[05:16] <MrNOKIA> pardon if i'm mistaking
[05:17] <gortiz> no, lowlatency are for special uses on computers that need a very lowlatency..
[05:17] <MrNOKIA> like editing audio/video ?
[05:17] <gortiz> no
[05:18] <gortiz> MrNOKIA, don't worry i dont think that you need them you can use the generic
[05:18] <gortiz> :)
[05:18] <gortiz> bye
[05:18] <MrNOKIA> thanks
[05:19] <gortiz> :)
[05:19] <MrNOKIA> i just wanna clarify some issues regarding linux in general
[05:19] <MrNOKIA> that's why i asked
[05:20] <mjg59> MrNOKIA: #ubuntu is a better place for support questions
[05:21] <MrNOKIA> thanks mjg59
[06:19] <defendguin> mjg59: you can close that bug 44615 the fix works
[06:28] <defendguin> nevermind i got it
[06:36] <gene6482> this is a kernel question but it needs support, so if i'm in the wrong place i'm sorry, basically i have a toshiba laptop with sound issues and after some research have learned that my dsdt is buggy, can anyone help me fix it?
[09:14] <pokoko> g'day everyone. In Ubuntu (Linux kernel 2.6.17-11), i think there's a bug where a mounted usb device doesn't get recognised after a suspend/resume. Has this been worked out yet or some solution which I am unaware of ?
[10:01] <blueyed> Bug 106028 is still not fixed, although it's a key feature AFAIK. Not even Importance of the bug has been set..
[10:02] <blueyed> Malone bug 106028 in linux-source-2.6.20 "Kvm not installable in feisty" [Undecided,Confirmed]  https://launchpad.net/bugs/106028
[11:24] <cjwatson> blueyed: people set way too much stock in the Importance field, but yes, that should get fixed; I'll try to see to it tomorrow if nobody beats me to it
[11:25] <cjwatson> the number of people complaining about the Importance field there in fact encourages me to leave it unset simply as a demonstration ;-)
[11:26] <blueyed> cjwatson: lol, yeah. But OTOH it would be really bad if this showstopper would make it into the RC or final, wouldn't it?
[11:26] <cjwatson> "but yes, that should get fixed; I'll try to see to it tomorrow if nobody beats me to it"
[11:27] <blueyed> sure. I understand this. But the last time this was brought to IRC the answer was "it will be fixed soonish" (Bug #105263).
[11:28] <cjwatson> I don't know what you think you're going to achieve by further haranguing me given that I've already promised to look at it
[11:29] <cjwatson> looks like the kvm-api-9 provides change was one of the things that was committed to kernel mainline but not to the -15 branches, so best thing is probably to revert kvm's dependency
[11:29] <cjwatson> but, tomorrow
[11:34] <BenC> It's in git
[11:34] <BenC> it's going to be fixed on the first post-release update
[11:35] <cjwatson> BenC: kvm needs to be fixed for release, IMO
[11:35] <MrNOKIA> git ?
[11:35] <cjwatson> i.e. installable
[11:35] <BenC> cjwatson: kvm doesn't even work unless you use universe, so I'd argue it's not that bad?
[11:35] <cjwatson> honestly I think it should do Depends: kvm-api-9 | kvm-modules-2
[11:36] <cjwatson> it's a feature we've highlighted in our release notes
[11:36] <cjwatson> it's kind of an oversight that it's in universe given that IMO, but I do think it needs to work
[11:36] <BenC> cjwatson: do you want me to do another kernel upload to fix it? :)
[11:36] <cjwatson> no, I want kvm's dependencies to DTRT with what we've got
[11:36] <BenC> or wait for post-RC
[11:36] <cjwatson> unless you're saying there is no way a kvm upload can fix it?
[11:37] <BenC> cjwatson: it can't, they are broken because the kernel doesn't provide the right modules to work with kvm-18
[11:37] <cjwatson> can we revert kvm then?
[11:37] <cjwatson> blow it back with an epoch
[11:37] <BenC> we really want kvm-18, but sure, we can downgrade kvm package to kvm-16
[11:37] <cjwatson> I'll look at that tomorrow then
[11:38] <BenC> https://launchpad.net/ubuntu/+source/kvm
[11:38] <BenC> the previous version, 16-1ubuntu1 works with current kernel
[11:38] <cjwatson> I don't think another kernel upload for this is likely to be an option unless there are further critical problems
[11:38] <BenC> cjwatson: I can do it pretty quickly now, and test it
[11:38] <cjwatson> ok, thanks
[11:38] <Nafallo> epoch :-/
[11:39] <cjwatson> Nafallo: people get hung up about epochs, but shouldn't
[11:39] <cjwatson> BenC: ok, that works too, but it's Sunday so ...
[11:39] <Nafallo> well, they are evil :-P
[11:39] <BenC> epochs are a dpkg gift above
[11:39] <cjwatson> Nafallo: no they aren't
[11:39] <Nafallo> so we might not want to sync with Debian at some point then I take it :-)
[11:39] <BenC> cjwatson: good night
[11:40] <Nafallo> night.