[03:02] <kylem> crimsun, ping
[03:30] <BenC> kylem: Hey
[03:31] <BenC> kylem: You busted acx :)
[03:31] <kylem> eh?
[03:31] <BenC> wait, I misread the diff
[03:32] <BenC> I thought it lost the firmware_ver stuff
[03:32] <kylem> i'm pretty sure it's ok
[03:32] <kylem> i test bilt it
[03:32] <BenC> but loading it would have been the problem
[03:33] <BenC> the firmware_ver stuff was all custom code I added a while back to make it easier to change to a different firmware
[03:33] <kylem> heh, i read through the diff too
[03:33] <kylem> hmm, this alsa-firmware thing is confusing.
[03:33] <BenC> was the firmware_ver merged upstream?
[03:34] <BenC> kylem: FYI, debian/commit-templates/external-driver for new drivers
[03:34] <kylem> no clue, i just read through the patch.
[03:34] <kylem> BenC, eh? that's what i did.
[03:35] <kylem> git commit -a -e -F debian/..
[03:35] <BenC> damn, am I losing it or what
[03:35] <kylem> get some sleep, hehe
[03:35] <BenC> remind me not to review commits on 4 hours of sleep
[03:35] <zul> i hear beer helps
[03:36] <kylem> as long as it isn't a bad bear.
[03:36] <zul> i was thinking kieths
[03:36] <kylem> nm. inside joke.
[03:36] <zul> meh..
[03:36] <kylem> BenC, i thought the only removed firmware stuff was some legacy crap
[03:37] <BenC> kylem: in acx? Yeah, some ancient shit
[03:39] <kylem> hehe
[03:41] <zul> remind me never to read the forums please
[03:49] <BenC> I've managed to stay away from the forums
[03:49] <zul> someone was spreading disinformation..
[03:55] <BenC> misinformation on a public internet forum? Say it ain't so :)
[03:55] <zul> i know!
[03:56] <BenC> Next you'll be telling me Slashdot doesn't have trolls
[03:56] <zul> hehe
[03:59] <ajmitch> but the ubuntu forums are different! they're *official*!
[03:59] <kylem> officially full of muppets.
[04:08] <zul> night folks..
[04:36] <kylem> some of it is actually GPL and provides src.
[04:54] <kylem> BenC, sounds good to me.
[05:06] <BenC> $ file ubuntu/net/atl1/atl1_main.c 
[05:06] <BenC> ubuntu/net/atl1/atl1_main.c: HTML document text
[05:07] <BenC> kylem: You sure you test compiled the HTML in the atl1 driver directory? :)
[05:07] <kylem> uh. oops.
[05:07] <BenC> 4 of them
[05:07] <kylem> yeah, i clearly wget'd the wrong thing. shit.
[05:08] <kylem> BenC, probably forgot to turn the option on.
[05:08] <kylem> sigh. fucking kernel.org gitweb breaking my workflow.
[05:10] <kylem> so, why did 3 of them work... weird
[05:10] <BenC> heh
[05:11] <kylem> christ. fucking kernel.org is so fucked.
[05:12] <BenC> I'm uploading a new lrm tonight, but I'm delaying the kernel upload till after our bug day tomorrow, plus so I can merge some VMI patches
[05:13] <kylem> fixed.
[05:13] <kylem> will push in a second.
[05:54] <lifeless> is the past tense wgot ?
[05:55] <kylem> wifuckedup
[05:59] <crimsun> kylem: pong
[06:00] <kylem> crimsun, what's the deal with these alsa-firmware bits?
[06:01] <kylem> i notice some of them are actually GPL and stuff, but i can't figure out where they're hiding
[06:01] <crimsun> kylem: the ones in the upstream tarball of the same name or the source package on REVU [revu.tauware.de] ?
[06:01] <kylem> the former.
[06:02] <kylem> ah, i see.
[06:03] <kylem> i didn't think to look in revu, thanks.
[01:23] <TheMuso> c
[02:46] <zul> guys, im just going through the linux-meta bugs and assigning them to the right component
[02:47] <CyberSnooP> I'm getting a kernel Oops when booting herd 3 desktop cd. Anyone who can help me making a useful report out of it?
[02:49] <zul> CyberSnooP: if you have a digital camera, open a bug report in launchpad and attach it to the bug report.
[02:49] <CyberSnooP> well. It continues booting after the oops.
[02:50] <CyberSnooP> I'm trying to get the dmesg output transferred to somewhere I can make a bug report from
[02:52] <zul> dmesg > dmesg.txt and copy the dmesg.txt somewhere
[02:53] <CyberSnooP> done so. Are there any hints on searching for previous reported bugs?
[02:55] <CyberSnooP> well. there seem to be only 3 bugs (!!) in feisty. Searching by hand isn't that hard, or I just don't understand launchpad yet
[03:00] <pkl_> BenC: ping
[03:04] <CyberSnooP> ah.. well, if anyone cares: found the relevant bug (#76294), but that tells me to use a newer linux-restricted-modules, which I guess is pretty hard on a CD :(
[03:05] <pkl_> the atheros bug?
[03:07] <CyberSnooP> yep
[03:07] <CyberSnooP> Could it be affecting the installation also? (since the installer also hangs on hardware detection)
[03:08] <pkl_> kernel oopses often do random nasty things to the kernel, and so it could affect the installation yes.
[03:09] <CyberSnooP> Are new 'nightly' desktop CDs up to date? Is it worth burning one of them an trying installation again?
[03:12] <BenC> pkl_: yo
[03:13] <pkl_> BenC: hi, ready for the bug tutorial?
[03:13] <BenC> yeah
[03:13] <BenC> kylem: done coding HTML to help with bugs? :)
[03:14] <kylem> heh
[03:15] <cjwatson> CyberSnooP: don't use /feisty/+bugs or similar
[03:16] <cjwatson> CyberSnooP: that doesn't mean what you think it means :) kernel bugs in feisty are on /ubuntu/+source/linux-source-2.6.20/+bugs
[03:16] <cjwatson> CyberSnooP: hang on hardware detection> try booting with hw-detect/start_pcmcia=false; that was in the Herd 3 release notes
[03:17] <CyberSnooP> cjwatson: sorry for the wrong bug report lookup, but I finally found the right set of bugs an found a exisiting bug report (atheros oops)
[03:17] <BenC> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bugs
[03:17] <BenC> CyberSnooP: atheros oops should be fixed in latest lrm
[03:17] <CyberSnooP> cjwatson: will try with special boot options, thanks for that hint :)
[03:17] <kylem> can we blacklist modules from the kernel cmdline?
[03:17] <BenC> Not in Herd3 though
[03:17] <BenC> kylem: I wish
[03:18] <kylem> shouldnt be hard to add...
[03:18] <CyberSnooP> BenC: Yep, but I'm trying herd 3, so that doesn't really help right now :)
[03:18] <BenC> CyberSnooP: Daily iso's
[03:18] <BenC> 185 bugs in 2.6.20
[03:19] <BenC> is there no sorting!?
[03:20] <BenC> "kernel oops while installing win 2k sp2"
[03:20] <BenC> heh, that looks funny
[03:23] <zul> BenC: which one is that?
[03:23] <pkl_> first things, how do you get a listing of all bugs in 2.6.20?
[03:26] <BenC> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bugs
[03:27] <BenC> We need to start with bugs who's Status is !Unconfirmed
[03:27] <BenC> check if we have any patches we can apply immediately
[03:28] <BenC> 36885 is something we can fix with a dmi match entry
[03:30] <BenC> kylem, pkl_: either of you know how to add dmi match for nolapic forcing, or should I do it real quick?
[03:30] <CyberSnooP> BenC: can't find hw-detect/start_pcmcia=false in Release Notes (http://www.ubuntu.com/testing/herd3) but I wlil try it anyway. Is there anything usefull to report about the hw-detect hang (althought this probably isn't -kernel talk anymore)
[03:30] <kylem> BenC, i can do that.
[03:30] <kylem> i'll try to not write it in htm.
[03:30] <kylem> l
[03:30] <CyberSnooP> (note: I'm installer hang right now)
[03:31] <BenC> kylem: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/36885 assigned to you then
[03:31] <BenC> kylem: hehe
[03:31] <pkl_> 36885 is confirmed...
[03:31] <fabbione> BenC: or add a debian/rules to strip html at build time :)
[03:31] <kylem> i've been doing some thinking, we need to sit down with colin and mdz at some point and think about how we're going to handle dapper.
[03:32] <fabbione> even better.. patch gcc :)
[03:32] <BenC> kylem: Good topic for next summit
[03:32] <BenC> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/64308
[03:32] <kylem> i have a few patches that really should make it into stable, but it's kind of scary to think about, so i'd rather have two kernels, one which might actually propogate to -updates.
[03:32] <BenC> looks like another dmi match entry
[03:32] <BenC> kylem: We can't propagate to updates
[03:33] <kylem> BenC, ? why not?
[03:33] <zul> BenC: im just cleaning up linux-meta as well
[03:33] <BenC> not because I don't want to, but because it's a real ugly issue with -security and -updates syncing
[03:33] <kylem> ah.
[03:33] <kylem> lazy archive admins, gotcha. 8)
[03:33] <BenC> I was warned by adam that doing it would be the same as the ghost busters cross streams
[03:33] <kylem> BenC, mind going through bug targetting in a bit?
[03:33] <BenC> sure
[03:34] <kylem> BenC, hey, don't forget, they crossed the streams to defeat zul...
[03:34] <BenC> lol...so Chuck will die if we upload kernels to -updates
[03:34] <kylem> ;-P
[03:34] <cjwatson> CyberSnooP: the release announcement had it (https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-February/000243.html)
[03:34] <kylem> i do ever so much hate xen...
[03:34] <zul> meh..
[03:35] <zul> kylem: whats wrong now?
[03:35] <kylem> zul, nothing.
[03:35] <kylem> zul, just teasing.
[03:35] <BenC> pkl_: want to try your hand at a dmi match for disabling acpi-video on a particular bit of hw?
[03:36] <mjg59> BenC: What was the reason for that?
[03:36] <CyberSnooP> cjwatson: okay, but that says "5 minutes" and the alternate cd. I'm having a >5 minutes hang on the desktop one
[03:36] <cjwatson> ah, probably not much you can do to avoid it short of grotty expert hacking
[03:36] <pkl_> BenC: I can try, but dmi match means nothing to me...
[03:36] <kylem> pkl_, it's basically like a pci id, but for the acpi bios, i guess.
[03:37] <kylem> pkl_, works more or less like a pci quirk
[03:37] <mjg59> kylem: Eh. Not quite - it's not anything to do with acpi
[03:37] <CyberSnooP> cjwatson: It says it's loading 'aec62xx' and since I can't find a bugreport for that I was wondering if there is anything to report
[03:37] <kylem> mjg59, ah, i just associate dmi with acpi, what's the diff?
[03:37] <mjg59> pkl_: DMI is a spec for putting system information in the BIOS, including vendor and product strings
[03:37] <kylem> oh. DMI is for SMBIOS?
[03:37] <cjwatson> CyberSnooP: you sure that's the desktop CD? I wouldn't expect that level of information to be visible on the desktop CD
[03:37] <cjwatson> CyberSnooP: what does the screen look like? blue with a white box in the middle?
[03:38] <CyberSnooP> cjwatson: nope :) It's ubiquity with the GTK progess bar and a line below
[03:38] <mjg59> pkl_: When all else fails, you can break drivers so they don't do something on machines with a given DMI ID
[03:38] <CyberSnooP> However, I picked the dutch translation
[03:38] <cjwatson> CyberSnooP: oh, I see, OK. same boot option is worth a try then
[03:38] <BenC> pkl_: Basically you create a table of stuff to match a specific machine type based on it's dmidecode output
[03:38] <mjg59> In some cases, it's appropriate - in others, it's arguably better to figure out why the machine is breaking
[03:38] <CyberSnooP> okay, will do. Nothing to catch while it's hanging now?
[03:40] <BenC> pkl_: drivers/acpi/sleep/main.c: Look for acpisleep_dmi_table
[03:40] <pkl_> is this dmi match stuff already done in Ubuntu, and so there's a framework to look at to start from?
[03:40] <pkl_> ah, ok.
[03:40] <BenC> pkl_: Use that same logic to make the drivers/acpi/video.c driver not work for the machine in https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/64308
[03:40] <BenC> There's an attachment with dmidecode output
[03:40] <pkl_> ok.
[03:41] <mjg59> BenC: Uh, in future we're going to be moving to depending on more functionality provided by that driver
[03:42] <mjg59> I'd prefer to spend a bit more time trying to debug it
[03:43] <heno> Am I right in guessing that bug 80892 is a kernel bug or is that a brltty bug? the log says 'kernel: [  138.396000]  usb 3-1: USB disconnect, address 3' right after brltty tries to mount a USB device
[03:44] <mjg59> BenC: Also, I can't actually see ACPI code being executed on modprobe, which leaves me a little concerned about why this is happening
[03:45] <mjg59> Oh, I see
[03:49] <cjwatson> CyberSnooP: well, you could look at 'ps ax' from a terminal to see what it's doing
[03:49] <BenC> mjg59: Do you think it's fixable? I'm happy just disabling for feisty...it's a long standing bug
[03:49] <cjwatson> CyberSnooP: could be unrelated to the pcmcia thing
[03:49] <BenC> for that machine I mean
[03:50] <CyberSnooP> cjwatson: sorry, you just missed it by 1 minute.. rebooting with new kernel option now. Will find out if pcmcia was the problem in about 30 minutes I guess :)
[03:50] <cjwatson> CyberSnooP: *nod*
[03:50] <mjg59> BenC: No idea. I've asked for more information.
[03:50] <mjg59> BenC: The bugs marked as duplicates are entirely unrelated
[03:50] <mjg59> I've de-duped them.
[03:51] <BenC> mjg59: It sounds an aweful lot like a BIOS bug to me, but if you think it might be fixable, then have at it
[03:51] <BenC> pkl_: dequeue that bug for now :)
[03:52] <pkl_> hmm, ok, in the middle of reading the code.
[03:52] <kylem> if there's only one thing this job is good for, it's touching parts of the kernel you would never, ever, otherwise touch.
[03:52] <BenC> pkl_: Feel free to study the dmi match stuff...it's useful for workarounds like this
[03:52] <kylem> like, why the fuck would i ever want to look at mmc... but yesterday...
[03:53] <pkl_> yeah
[03:53] <BenC> kylem: Yeah, like I gave up HTML coding a decade ago, but then yesterday... :)
[03:53] <kylem> BenC, ferfuckssake.
[03:53] <kylem> ;-)
[03:55] <mjg59> BenC: Oh, it's quite possible that it's a BIOS bug
[03:55] <mjg59> But that doesn't mean it's unfixable
[03:57] <BenC> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/67810
[03:57] <BenC> bug 67810
[03:57] <BenC> can we get ubugtu in here?
[03:57] <BenC> who maintains that bot?
[03:57] <zul> seveas i think
[03:58] <BenBugtu> 67810: bad hard disk noise on shutdown
[03:58] <BenC> there, now I get warm fuzzies
[03:59] <BenC> Anyone have any comments on that bug? Seems like upstream is ignoring it
[03:59] <mjg59> I suspect just checking through the libata shutdown code would give a good idea about what's going on
[03:59] <BenC> and the comments on it have digressed a lot
[04:00] <mjg59> Yeah, we're not going to get anything useful out of the bug
[04:00] <kylem> hehe.
[04:00] <kylem> do we have the acpi ata driver in .20, hmm....
[04:00] <BenC> "Does OpenSuse have a net-install..."
[04:01] <kylem> BenC, oh yeah, i got that bug and was like "plonk"
[04:01] <BenC> mjg59: Is there a working libata-acpi.c for 2.6.20?
[04:01] <kylem> the blind, lead by the deaf, lead by the dumb.
[04:01] <BenC> is that from libata-dev git?
[04:01] <kylem> BenC, alan posted it the other day.
[04:01] <BenC> kylem: "I see, said the blind man to the deaf man"
[04:01] <kylem> might be a useful fallback.
[04:02] <kylem> ICUP
[04:02] <BenC> I'm waiting for the bug report that says "If I tap three times on the left side of my box, it works...can you code this workaround into the next kernel"
[04:03] <bubbasucks> BenC: can i bug you real quick? just wondering what your ID search came up with
[04:03] <BenC> "FIxed...included kick-box.ko, just use the tap=left-side, count=3 modparams"
[04:03] <BenC> bubbasucks: I found nothing useful
[04:03] <bubbasucks> so the pci ids were in megaraid_mm ?
[04:03] <BenC> In megaraid_mbox
[04:05] <bubbasucks> ok
[04:05] <mjg59> BenC: Yeah
[04:05] <bubbasucks> i'll try just including megaraid_mbox in initramfs
[04:05] <bubbasucks> and take megaraid out
[04:05] <mjg59> kylem: Nah, that's pata_acpi
[04:05] <kylem> ah.
[04:05] <mjg59> kylem: Which is different - it's actually a full pata driver
[04:05] <mjg59> It just uses acpi to get resource information
[04:06] <mjg59> So it's better than pata_generic
[04:06] <zul> BenC: if you click your heels three times does it work?
[04:06] <BenC> mjg59: Does it supercede libata-acpi?
[04:06] <mjg59> No
[04:06] <mjg59> Entirely different
[04:06] <mjg59> libata-acpi provides acpi glue for libata
[04:06] <BenC> Do we need libata-acpi in feisty?
[04:06] <mjg59> pata_acpi is a driver
[04:06] <mjg59> Yes
[04:10] <BenC> where's it at?
[04:10] <mjg59> lkml right now
[04:11] <mjg59> It's not terribly important
[04:11] <mjg59> Or libata-acpi? There's a branch of libata with it
[04:12] <BenC> Ok
[04:13] <BenC> Moving on to 74059: ata2 timeouts, fails to boot
[04:13] <pkl_> BTW as a total aside, how long do people spend reading lkml?  I've not had time to look at it once this week.
[04:14] <zul> i try to do it everyday
[04:14] <zul> ...but thats just me
[04:14] <CyberSnooP> cjwatson: I guess it's not pcmcia, the kernel boot option didn't help and ubiquity is hanging on "Module 'aec62xx' for 'IDE chipset support' is being loaded...'
[04:14] <BenC> pkl_: I scan subjects...rarely do I read content unless it's interesting
[04:15] <pkl_> yes, I like skimming it.  Pity kernel-traffic disappeared, that was a good way to catch up.
[04:16] <CyberSnooP> pkl_: lwn is somewhat a replacement for kernel updates
[04:17] <pkl_> is the openSuse comments of any relevance?  I notice 'More' didn't respond regarding the driver loaded
[04:19] <pkl_> CyberSnooP: lwn is a sort of replacement, but is mainly complemented kernel-traffic.  Lwn concentrates on one or more selected kernel topics per week in depth, kernel-traffic just summarised all the traffic that week...
[04:19] <BenC> Ok, pulled in libata-dev:acpi
[04:20] <CyberSnooP> pkl_: that's true. Just stay subscribed to kt-distrib@... maybe they'll be back sometime :) 
[04:20] <zul> BenC: #79331 our 2.6.20 supports rt73 now does it?
[04:21] <BenC> zul: I'm a little skeptical...we actually should have always supported it, but now I've switched back to legacy
[04:21] <CyberSnooP> someone here in the mood for determining why hw-detect stops on aec26xx? (I've got a hanging installation from herd 3 right now)
[04:22] <zul> BenC: so ill reject it
[04:22] <BenC> CyberSnooP: I can't even find that driver
[04:22] <CyberSnooP> oh, sorry.. aec62xx
[04:23] <CyberSnooP> at least, that's what is reported as the module name
[04:23] <BenC> That module I can find :)
[04:24] <BenC> CyberSnooP: Are you able to switch to the log console when it freezes, tried SysRq?
[04:24] <CyberSnooP> it doesn't freeze and desktop is still usuable
[04:24] <BenC> CyberSnooP: Maybe before it gets to that point you can delete that module from /lib/modules/...
[04:24] <CyberSnooP> there is just no progress
[04:24] <cjwatson> hang on, is it just the installer that hangs? or the entire system?
[04:25] <CyberSnooP> so: just installer is dead. I do see 4 "modprobe" processes on "ps ax" output in terminal window
[04:25] <cjwatson> modprobing what?
[04:25] <BenC> so modprobe is hanging
[04:26] <BenC> cjwatson: We need to donate some hardware to kernel.org or something
[04:26] <BenC> gitweb is so useless
[04:26] <CyberSnooP> hmm, i see even more modprobing going on. Lot's of modprobe -Q pci:.... and a modprobe -v aec62xx
[04:26] <BenC> CyberSnooP: Can you list all the modules that you see being modprobed in ps?
[04:27] <BenC> Maybe we could rsync all the git trees and provide a mirror
[04:27] <CyberSnooP> BenC, will try.. pity there is no irc-client on the live cd, copy & pasting would have been nice now
[04:27] <cjwatson> there's gaim, though it's not great
[04:27] <BenC> CyberSnooP: telnet :P
[04:27] <cjwatson> or you can just install one on the fly
[04:30] <CyberSnooP> http://bram.vleur.nl/tijdelijk/ps-ax.txt
[04:30] <CyberSnooP> scp does work :)
[04:30] <cjwatson> that D-state modprobe doesn't look happy
[04:32] <CyberSnooP> ah. D = Uninterruptible sleep  (usually IO). (didn't know that)
[04:32] <BenC> kylem, pkl_: On to 75626: spurious 8259 interrupt disabled IRQ
[04:33] <cjwatson> kylem: launchpad.net/bugs/#
[04:34] <kylem> cjwatson, yeah, but i'm used to typing bugs. (for bts.)
[04:35] <CyberSnooP> cjwatson: any other info that might be of any use?
[04:36] <pkl_> isn't problems like that due to wrong DSDT tables?
[04:37] <jwest-> anyone using vmware here? vmware by default installs scsci drives right?
[04:38] <BenC> CyberSnooP: dmesg if you can
[04:38] <jwest-> had an issue and i just booted scsi.s kernel  and bam it worked
[04:39] <CyberSnooP> http://bram.vleur.nl/tijdelijk/dmesg.txt
[04:40] <CyberSnooP> which looks like a dmess to me 
[04:40] <BenC> CyberSnooP: wow, that's an ugly mess
[04:40] <BenC> CyberSnooP: Do you have some whacked partition map or something on there?
[04:41] <CyberSnooP> nope.. hda1 hda2 both ntfs, hda5 ext3 for root, hda 6 for swap
[04:42] <CyberSnooP> fdisk -l /dev/hda output: http://bram.vleur.nl/tijdelijk/fdisk-l.txt
[04:42] <BenC> The system keeps saying it's trying to read beyond the end of the device
[04:43] <CyberSnooP> well, I do see the "does not end on cylinder boundary" warning for the first time (although they may have been here for quite some time)
[04:44] <mjg59> BenC: We still have no HPA support for libata, BTW
[04:44] <mjg59> That's pretty critical
[04:44] <BenC> CyberSnooP: your partition map doesn't match what the kernel sees
[04:44] <BenC> mjg59: Can you point me to where that is?
[04:45] <CyberSnooP> well, I didn't repartition with the installer. I'm reinstalling from an (old) edgy installation on the same harddisk
[04:45] <mjg59> BenC: Unimplemented
[04:45] <CyberSnooP> (i didn't repartition at all in the mean time)
[04:45] <BenC> CyberSnooP: weird...so this is a regression?
[04:46] <mjg59> BenC: See idedisk_check_hpa in drivers/ide/ide-disk.c
[04:46] <CyberSnooP> I would guess so. At least dapper installed cleanly on the same laptop, although I'm not really sure if it was exactly the same partitioning
[04:46] <BenC> mjg59: Isn't this why you were suggesting we didn't switch to pata yet? :)
[04:46] <mjg59> BenC: Probably
[04:47] <BenC> I didn't actually switch that many
[04:47] <mjg59> CyberSnooP: Oh, uh. You might actually be hitting this precise issue.
[04:47] <CyberSnooP> (i did dist-upgrade from dapper to edgy, but since feisty wasn't booting I decided to go for the re-install.. there you have the woll story)
[04:47] <BenC> mjg59: He can't be, he's still using an ide driver
[04:47] <mjg59> Oh, right
[04:47] <mjg59> Yeah, fair enough
[04:48] <BenC> CyberSnooP: Where does feisty stop booting?
[04:48] <CyberSnooP> after dist-upgrade
[04:48] <CyberSnooP> It's a different problem I guess, since it didn't boot X
[04:49] <CyberSnooP> I messed a lot with drivers, mesa and stuff during edgy
[04:49] <BenC> so it booted, just didn't start X?
[04:50] <BenC> cjwatson: Is there a way to drop to shell before livecd gets to starting up too much?
[04:50] <CyberSnooP> yeah, sorry about the confusion. It did boot. although I'm not sure which kernel I last used
[04:50] <CyberSnooP> (might have been 2.6.19)
[04:53] <BenC> pkl_: Want to investigate #76489?
[04:53] <BenC> Maybe there's some update to the r8169 driver...I'm leaning toward thinking it's an locking issue triggered because we have SMP by default
[04:53] <pkl_> just let me have a loot at it...
[04:54] <cjwatson> BenC: break=top? (or premount, or casper-bottom, or ...)
[04:54] <BenC> maybe there's an updated driver somewhere
[04:54] <BenC> CyberSnooP: Can you try booting with cjwatson's suggested cmdline and delete the aec62xx driver, then let the boot continue?
[04:54] <BenC> see if that gets you through this, then we can investigate the problem afterwards
[04:55] <CyberSnooP> suggested: break=top ?
[04:55] <BenC> yeah, try that one
[04:55] <BenC> loading aec62xx on my box doesn't produce a hang or errors
[04:57] <CyberSnooP> well, break=top throuws me in a busybox with "(initramfs)" prompt
[04:58] <maks_> how surprising :)
[04:58] <CyberSnooP> but I'm not quite sure where the aec26xx module should be right now
[04:58] <CyberSnooP> not in /lib/modules/2.6.20-6-generic 
[04:59] <pkl_> BenC: I'll have a look at it.  What was the resolution re: bug no. 75626 (spurious 8259....)?
[05:00] <CyberSnooP> oh  sorry, it is there
[05:00] <bubbasucks> BenC: is the megaraid_mbox.c file online or available because i looked in 2.6.17 megaraid_mbox.c here (http://www.gelato.unsw.edu.au/lxr/source/drivers/scsi/megaraid/megaraid_mbox.c) and didnt see 101e 1960 1028 0511
[05:00] <CyberSnooP> I found /lib/modules/2.6.20-6-generic/kernel/drivers/ide/pci/aec62xx.ko Just remove that file and it shouldn't complain further on?
[05:01] <mjg59> What's loading that file?
[05:01] <mjg59> BenC: I'll open a bug on the HPA issue
[05:03] <BenC> CyberSnooP: that's what I'm hoping :)
[05:04] <BenC> bubbasucks: gitweb on kernel.org, ubuntu-2.6 tree
[05:04] <BenC> if you can get it to answer
[05:04] <CyberSnooP> We'll find out.. (in 30 minutes :( )
[05:07] <cjwatson> BenC: driver-backports ping?
[05:08] <BenC> cjwatson: working on it while I'm doing bugs :)
[05:10] <CyberSnooP> side-note: the new partitioner has gone crazy on me now
[05:10] <BenC> There's something whacked about your partition map
[05:10] <CyberSnooP> yeah, but this is an UI error i think
[05:10] <BenC> Ah, ok, blame cjwatson then :)
[05:11] <CyberSnooP> both the OK and Cancel buttons in the  "Edit partition" dialog stopped responding
[05:11] <CyberSnooP> I'm getting to fast at using it after 6 install attempts
[05:11] <BenC> Give it a second, sometimes there's lag after clicking it
[05:11] <CyberSnooP> I gave it 90 seconds now
[05:13] <CyberSnooP> killed all ubiquity, starting over now.. I'll try to be nice to the buttons
[05:13] <bubbasucks> BenC: k
[05:17] <cjwatson> CyberSnooP: ubiquity --debug and file a bug with /var/log/installer/debug, /var/log/syslog, and /var/log/partman attached please; use a password you don't care about in debug mode
[05:17] <CyberSnooP> cjwatson: will do some other time I guess. It seems like some kind of race when I quickly hit the format checkbox and open the edit dialog
[05:18] <CyberSnooP> cjwatson: besides this error the new partitioner is very nice though! Pretty usuable, quick, and to the point. 
[05:22] <cjwatson> aha, I can fix that
[05:22] <cjwatson> insufficient locking
[05:25] <cjwatson> CyberSnooP: off-topic for this channel, but thanks, fixed for the next release
[05:26] <CyberSnooP> cjwatson: hah... that's what I call "getting things done" :) While we're in this words-of-praise moment: mjg59: nice blog-article on suspend/resume with acpi 
[05:30] <\sh> guys, what about HP P800 SmartArray SAS/SATA controller and 64bit LBA support in our kernel? I just need some practical experience with it, if it's working or not...a nice to have is a statement "yes, it works, even with a MSA 60 attached to it" or "yes/no, support is a bit flaky" or "no, smartarray driver doesn't support 64bit lba, means partitions greater 2TB" ;-)
[05:31] <BenC> \sh: How about "I don't know?" :)
[05:32] <kylem> mjg59, wow. we don't have HPA support yet? fucking hell.
[05:32] <pkl_> what is _HPA_ support?
[05:33] <\sh> BenC: then I say "hmmm..who could know" or "who has such a hardware, and runs it" or "ok, I'll google" ;)
[05:33] <mjg59> Host Protected Area
[05:33] <mjg59> Drives can flag a portion of themselves as unusable
[05:33] <kylem> "utter retarded"
[05:33] <mjg59> And then optionally password that
[05:33] <mjg59> Unless you explicitly request that they disable that, the disk just appears smaller to the OS
[05:33] <mjg59> Usually used for hiding recovery areas at the end of the disk
[05:34] <pkl_> or port :-)
[05:34] <mjg59> The problem is that at some point in 2.2, somebody added HPA support to Linux
[05:34] <pkl_> port -> porn... joke
[05:34] <mjg59> And decided that the sensible default would be to disable it
[05:34] <mjg59> So people install Linux into the HPA-covered area without ever noticing
[05:34] <mjg59> We can now never change that default
[05:34] <mjg59> Except libata doesn't support disabling the HPA
[05:35] <mjg59> Hilarity ensues
[05:35] <kylem> fsvo hilarity...
[05:35] <pkl_> okay, that's how manufacturers get away with supplying machines without Windows reinstall disks....
[05:35] <kylem> right.
[05:35] <mjg59> Yeah, it's basically impossible to fuck with it in Windows or DOS
[05:36] <pkl_> But as Ubuntu does have HPA support, it will happily over-write it on the first instal.
[05:36] <kylem> hmm. kernel could catch the access past the end of device, disable HPA, and restart the xaction...
[05:37] <kylem> pkl_, it's only a problem going from edgy->feisty with pata, iirc.
[05:37] <kylem> since libata for sata disks wouldn't ever have supported it.
[05:37] <mjg59> Right
[05:37] <mjg59> Though it would actually be interesting to test
[05:37] <mjg59> The alternative is that the lack of HPA support somehow magically results in the entire disk being available
[05:37] <kylem> but drivers/ide did, so when you boot a pata-*.ko system with it, you die horribly.
[05:38] <mjg59> Though I'm pretty sure that's not the case
[05:38] <CyberSnooP> aec62xx is still being loaded in hw-detect :'(
[05:38] <kylem> mjg59, how much work is it to disable? restarting the bio shouldn't be too too hard, i would think.
[05:39] <mjg59> kylem: Eh, almost none. 
[05:40] <CyberSnooP> okay, I'm being evil now in the hope to progress somewhat. I've killed the "log-output -t hw-detect modprobe -v aec62xx" process, this however results in alim15x3 being modprobed and ALSO hanging
[05:41] <CyberSnooP> so this seems to be a more general IDE-driver thing than specifically the aec62xx
[05:41] <CyberSnooP> (hanging means: process state = D for the modprobe process)
[05:43] <pkl_> did you check the modprobe -v aec62xx process did die?  It if was in an un-interruptible sleep, then killing it is impossible.
[05:43] <CyberSnooP> pkl_: it didn't die. But the installer doesn't seem to care about that process
[05:44] <pkl_> yeah, but the other modules being modprobed might...
[05:45] <CyberSnooP> it goes on for every ide driver now. I've got 7 state=D modprobes right now
[05:47] <bubbasucks> BenC: its not in there
[05:47] <bubbasucks> http://bugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=395174
[05:47] <bubbasucks> there is a patch to add CERC ATA100 raid i believe
[05:47] <bubbasucks> but it's not listed in your megaraid_mbox.c
[05:54] <cjwatson> BenC,mjg59: what happened to the iSight firmware loader bits from mjg59's patch? The rest of it (uvcvideo driver update) seems to have been applied
[05:54] <BenC> I just took the 0004-isight patch as-is...don't know about anything on top of it
[05:55] <BenC> bubbasucks: Ok, applied that patch, so it will be in the next kernel upload
[05:55] <cjwatson> the Apple Remote patch seems to be still missing
[05:56] <cjwatson> mjg59: any idea of the iSight status? the firmware extractor was really a separate binary so I guess it shouldn't be in the kernel anyway
[05:59] <cjwatson> ah, Apple Remote went into ubuntu/mactel/
[06:00] <bubbasucks> BenC: so i'll need to downgrade my firmware to 6.61
[06:00] <bubbasucks> hope that doesn't blow away my raid config
[06:01] <mjg59> cjwatson: Uh. Which firmware loader bits?
[06:01] <mjg59> I moved the firmware-loading in kernel
[06:02] <cjwatson> mjg59: so you did; I must have an earlier version of the patch
[06:02] <mjg59> Ah, ok
[06:03] <mjg59> It still needs the extractor, yeah
[06:03] <mjg59> I *really should* have an Apple next week
[06:03] <mjg59> It's taking an age to get through Intel
[06:06] <BenC> Anyone know if there's a project for rtl818x and rtl8187 that is newer than 1.5 years?
[06:06] <kylem> BenC, there isn't, afaik.
[06:07] <kylem> BenC, i think it's a dead-end chipset (no new hw)
[06:07] <BenC> not dead to our users :/
[06:07] <bubbasucks> BenC: it appears that CERC raid w/ FW>6.61 is broken in megaraid_mbox, but rolling back to 6.61 breaks disks >128GB
[06:08] <BenC> I'd ask for a user to donate one of them so I can fix the crash, but then we probably wouldn't have any more users with the card :)
[06:08] <BenC> bubbasucks: Do you have a disk > 128GB in there?
[06:08] <bubbasucks> yep
[06:08] <BenC> The patch doesn't say that > 6.61 is broken, just that if you have problems, try downgrading fw
[06:08] <bubbasucks> http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/54a1ca21b839ebf1/4a0cd669217f3c7d?lnk=st&rnum=1#4a0cd669217f3c7d
[06:09] <bubbasucks> http://linuxwarez.us/url/RwU4l9
[06:09] <bubbasucks> ^ short version
[06:09] <BenC> Still seems like fw > 6.61 isn't a sure fire problem, just that it might be
[06:10] <BenC> hopefully it isn't for you :)
[06:11] <bubbasucks> i'll give it a try
[06:12] <bubbasucks> when will the next kernel be out?
[06:18] <bubbasucks> Both Dell and LSI Logic have indicated that they no longer support these 
[06:18] <bubbasucks> models in the 2.6 kernel. As a result, these adapters are not supported 
[06:18] <bubbasucks> in Red Hat Enterprise Linux 4.
[06:18] <bubbasucks> lame
[06:18] <bubbasucks> time to go back to software raid...
[06:22] <BenC> kylem: Can you check the work queue fixes in rtl_ieee80211 to see if they may be the cause of the regression in rtl818x (bug 78255)?
[06:23] <kylem> sure.
[06:24] <CyberSnooP> Just to let you know: Killing the "log-output modprobe"-processes was sufficient to make it to the end of the installer. Rebooting the installed feisty was hell (>300s) but after an update to today (with new restricted modules) it works perfectly
[06:26] <BenC> CyberSnooP: Great, thanks
[06:32] <pkl_> Regarding bug #75626 (Spurious 8259...) there's a bug on the kernel.org bugzilla with a huge number of similar problems with many more HP Pavilion laptops (bugzilla.kernel.org/show_bug.cgi?id=7562).
[06:33] <kylem> brb. lunch.
[06:37] <BenC> pkl_: You should be able to link the bug report on launchpad to that kernel.org bugzilla report
[06:37] <BenC> pkl_: Click on Also affects: "Upstream..."
[06:37] <pkl_> ok.
[06:37] <BenC> and point it towards "linux" as the target and add the URL you gave
[06:38] <BenC> kylem, pkl_: Updated ipw3945 to v1.2.0...might consider it for dapper and edgy
[06:41] <BenC> requires new microcode as well
[06:51] <mjg59> BenC: Any chance you can turn on CONFIG_PM_TRACE?
[06:51] <mjg59> Contrary to what the docs say, the default is no longer to screw up the clock
[06:52] <mjg59> And it's very handy for tracking down suspend/resume problems
[06:56] <BenC> Sure
[06:58] <mjg59> Sweet
[06:58] <mjg59> Thanks
[06:58] <BenC> I don't see that option
[06:58] <mjg59> Might need PM_DEBUG enabled
[06:58] <mjg59> Ah, yes
[06:58] <BenC> ah, right
[07:13] <BenC> mjg59: Want this enabled too?
[07:13] <BenC>     Keep console(s) enabled during suspend/resume (DANGEROUS) (DISABLE_CONSOLE_SUSPEND) [N/y/?]  (NEW) 
[07:26] <mjg59> BenC: Leave that at N, I think
[07:28] <pwnguin> if today's bug day, ive got a pet bug in launchpad; it's got a patch attached and everything, just needs someone to look at it
[07:29] <pwnguin> bug #77026
[07:29] <mjg59> BenC: Uh, yeah. Weren't you supposed to be re-applying that?
[07:37] <BenC> Thought I had that one in there
[07:37] <pwnguin> well, you "fixed" it
[07:38] <pwnguin> but it didnt work
[07:39] <BenC> pwnguin: done
[07:40] <pwnguin> huzzah
[07:40] <pwnguin> i'll definately test it when it gets pushed out and report back :)
[07:47] <BenC> It's pushed to git, but if you're waiting for it to be uploaded, it will probably be available tomorrow some time
[07:47] <pwnguin> hmm
[07:47] <pwnguin> im supposed to be doing some kernel development for my master's project
[07:47] <pwnguin> although i doubt ill have git mastered in before it hits the repo
[07:51] <BenC> https://wiki.ubuntu.com/KernelGitGuide :)
[07:51] <pwnguin> noted, though i have a ton of bioinformatics lab to do today =/
[07:53] <BenC> Why are people still filing bugs on 2.6.19 :/
[07:54] <pwnguin> as in they don't know better, or as in it affects .19 only?
[07:56] <zul> BenC: muppets
[07:59] <pwnguin> ajmitch: but did you file bugs against it?
[07:59] <ajmitch> nah, I just couldn't be bothered rebooting
[07:59] <pwnguin> heh
[08:00] <pwnguin> my video card fan is too loud for that
[08:01] <BenC> pwnguin: As in .19 isn't even in ubuntu anymore
[08:01] <zul> heh...
[08:01] <zul> not for main at least
[08:03] <pwnguin> BenC: well, i meant like, they filed against .19 when they were running .20
[08:03] <pwnguin> for "dont know better"
[08:03] <BenC> no, they just haven't upgraded in 2 months :)
[08:04] <pwnguin> well, those are easy ones to close
[08:04] <pwnguin> "we think its fixed in .20. upgrade and retest"
[08:04] <pwnguin> kthnxbye
[08:08] <BenC> kylem: ping 33950
[08:10] <cberl1> Is there any reason a kernel panic wouldn't leave some kind of log on the system when it appears?  Something strange going on with one of my servers.
[08:10] <BenC> cberl1: Yeah, because it crashes so hard that disk write is either impossible, or dangerous
[08:11] <pwnguin> cberl1: hope you have a serial cable / port
[08:11] <cberl1> Okay, and possible solutions?
[08:11] <BenC> cberl1: That sort of crash needs a screen to see and you can take a digital photo for a bug report
[08:12] <cberl1> Ah, now there's the problem:  recreating the issue while having access to the console.  Can I reroute the console to an SSH session?
[08:12] <BenC> No, else the system would be alive enough to use a shell too :)
[08:13] <BenC> if you can redirect console to a serial (via the BIOS for example), then that would probably be best
[08:13] <BenC> leave a screen'd minicom on it with capture enabled
[08:13] <BenC> I do that frequently for my ultrasparc
[08:13] <cberl1> Okay, minicom on another machine, I assume?
[08:14] <pkl_> the machine with the other end of the serial cable...
[08:15] <cberl1> Okay.  I'll have to dig up such a beast.  Don't have any other PCs available for that at the moment.  Might be able to reclaim one of the "thin clients" temporarily.
[08:15] <cberl1> xconsole wouldn't work, would it?
[08:16] <johanbr> I also think there are patches to do the serial console thing over USB or Ethernet instead. Does the Ubuntu kernel contain any of those patches?
[08:20] <cberl1> xconsole looks like it might do the job for now - just keeping it open on my screen now, watching what's going on.  Quite a bit of traffic when you're the hub for 30 clients, eh?  :)
[08:54] <kylem> BenC, sorry, my irc was gone completely haywire.
[08:55] <BenC> kylem: I was going to insert an HTML coding joke here, but I think you've had enough :)
[08:55] <kylem> heh.
[08:55] <kylem> BenC, hmm. i think i posted a patch for that a while back, will update. need to repost the smapi stuff eventuall...