[00:01] <jdub> anyone working on the kernel freeze (possibly related to wireless) issue with hardy? i have a useful petri dish of varying hardware presenting the symptom.
[00:33] <lifeless> jdub: -19 ?
[00:35] <jdub> yeah
[13:56] <rtg> cking: you around? Can you comment on bug #153702 since you have one of the affected machines?
[13:58] <cking> rtg: will do.
[14:01] <cking> rtg: I did the same workaround ida_generic_ide for #153702 - is this classed as a legitimate fix or is this a call for more investigation for a better solution?
[14:02] <rtg> cking: Amit was curious what the parameter actually does. Is there a downside to it?
[14:02] <cking> rtg: These I don't know - I will investigate and comment.
[14:02] <mjg59> Yes, it means that you're driving it as a generic ATA device
[14:04] <cking> mjg59: which could imply some performance hit?  My experience with this hardware is that it can move data to/from the disc reliably and fairly fast
[14:04] <mjg59> Yes, performance hit and reduced functionality
[14:04] <mjg59> What does lspci -n give you when booted with the bios in ide mode?
[14:05] <rtg> mjg59: my fuzzy notion of what that means is that in IDE mode it does not participate in SATA topology discovery, link state, and other stuff. 
[14:06] <mjg59> It's probably less of an issue with the chipset in IDE mode to begin with
[14:06] <mjg59> Since ata_piix provides a smaller set of features to begin with
[14:06] <mjg59> You're probably limited to the timings set up by the BIOS, though
[14:11] <mjg59> I'd be interested to know which driver is binding to the chipset
[14:12] <rtg> cking: ^^
[14:14] <cking> mjg59: 00:1f.2 IDE interface: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 4 port SATA IDE Controller (rev 02) (prog-if 8f [Master SecP SecO PriP PriO])
[14:15] <mjg59> cking: Can I have lspci -n as well?
[14:16] <cking> mjg59: I mail you 
[14:19] <rtg> cking: I have the same Inspiron 530, but it shows a different controller: 00:1f.2 RAID bus controller: Intel Corporation 82801 SATA RAID Controller (rev 02), 00:1f.2 0104: 8086:2822 (rev 02)
[14:20] <rtg> Perhaps thats why I've not seen this issue.
[14:20] <mjg59> rtg: Yeah, that'll happen if you boot in RAID mode
[14:20] <mjg59> If you flick the switch in the BIOS it should be identical to Colin's
[14:21] <rtg> but the bug report is about _not_ being able to sense the drives in non-RAID mode, but I know this one works both ways.
[14:21] <cking> rtg: I need 5 mins to get a monitor added to the server - it's remotely located at the moment.
[14:22] <cking> rtg: "works" meaning "does not need the all_generic_ide" boot option?
[14:24] <rtg> cking: right. I'm cranking up my laptop cause this session is on the Dell 530 (which will go away when I start messing with BIOS options)
[14:42] <cking> rtg_: IDE mode definitely requires the all_generic_ide option, where as RAID does not
[14:44] <rtg_> cking: switching mine between RAID/IDE seems to have trashed the MBR. Now it can;t find a boot device in either mode. shit, that is my dev box.
[14:44] <cking> as for performance, some quick dd tests show: write: IDE 51.1 MB/s, RAID: 51.4 MB/s,  read: IDE 65.0 MB/s RAID: 64.5 MB/s
[14:45] <cking> rtg_: not good.
[14:45] <cking> rtg_: so there is little difference between RAID and IDE modes - apart from crapping up your system in the process of testing
[14:46] <rtg_> cking: indeed. please add that to the bug report :)
[14:46] <cking> will do
[14:47] <cking> rtg_: hope you get your dev box sorted asap
[14:49] <rtg_> cking: thats just great. all of the ISO's for Hardy on the drives I can't get to. 60 minutes to download...
[14:50] <cking> rtg_: 60 minutes - that's lame speed
[15:09] <rtg> cking: stupid BIOS. some futzing around restored the boot.
[15:10] <cking> rtg: it's kinda worrying that a BIOS can be so flakey
[15:11] <rtg> cking: I could boot if I chose F12 and went through the boot menu. I ended up having to change boot device  priority settings
[15:37] <rtg> smb_tp: are you taking care of adding the HVR950Q driver for LUM ?
[15:38] <smb_tp> rtg: yes
[15:38] <smb_tp> rtg: I opened bug 231628 for tracking
[15:38] <smb_tp> bug 241628
[15:39] <mkrufky> thanks for that :-)
[15:39] <rtg> smb_tp: thanks. I'm just going through the kernel team mailing list requests to make sure I don't forget something.
[15:39] <smb_tp> rtg: Np, I am also on the AC-BAT stuff from Yong
[15:40] <rtg> smb_tp: great, thanks.
[15:40] <mkrufky> there was another driver to be added also -- i sent it to mike frey and asked him if i should also send to kernel-team ... he said he'd just commit it and ask you guys to pull ...  but if you want to take a look, it is at: http://linuxtv.org/~mkrufky/lum/add-sms1xxx-to-lum.patch
[15:41] <rtg> mkrufky: is it of general use to the distro kernel? Or just MID style devioces?
[15:41] <mkrufky> general use
[15:41] <smb_tp> mkrufky: at the moment it would be better to post on the list. just to have a better reminder
[15:41] <mkrufky> ok, no prob
[15:44] <rtg> mkrufky: if these drivers are not already in 2.6.26 you should hassle BenC to put them in the Intrepid package.
[15:44] <smb_tp> rtg: I just pushed the changes for bug241229 but since the nomination seems to be pending I am not sure where to place the progress 
[15:45] <mkrufky> rtg they are not in 2.6.26 ....  the hvr950q driver *is* in 2.6.26, but its missing some usb ids and some performance tweaks
[15:45] <rtg> smb_tp: mark it "Fix committed", subscribe ubuntu-sru, nominate it for Hardy, and write up the SRU justification in a comment.
[15:45] <mkrufky> rtg: when it comes to intrepid, i think it would be easier for me to send in patches against upstream to sync intrepid kernel -- is that cool?
[15:46] <mkrufky> er, came out wrong... ie:  the hvr950q fixes for intrepid would be easier for me if i could just patch the kernel, rather than LUM
[15:46] <rtg> mkrufky: you're too late for that. 2.6.26 is the kernel Intrepid will settle on. right now you'll be pressed to get your drivers into 2.6.27.
[15:46] <mkrufky> ok, no prob
[15:47] <mkrufky> i'll get them into 2.6.27.  and i can probably get the performance tweaks and usb vid:pid updates into 2.6.26.y -stable
[15:47] <rtg> mkrufky: as for patching the kernel, we prefer to keep the kernel as close to upstream as possible. wholesale changes (like new drivers) are going into a different directory. 
[15:47] <BenC> mkrufky: If you are adding drivers to intrepid, we don't want them in the same place as upstream would have them
[15:48] <BenC> mkrufky: we'll have them in the ubuntu/ subdirectory
[15:48] <rtg> mkrufky: for Intrepid, the ubuntu/ subdirectory is the equivalent of Hardy LUM.
[15:50] <mkrufky> to clarify:
[15:51] <mkrufky> in 2.6.26, the au0828 xc5000 and au8522 drivers are already merged
[15:51] <mkrufky> but, the 2.6.26 versions are missing some patches, such as usb id's and some small performance tweaks
[15:52] <mkrufky> so, i will try to get those into 2.6.26.y -stable ... if that doesnt work out, then we'll have to do LUM ....  however, LUM poses a problem in this case, since 2.6.26 has OTHER drivers that also depend on xc5000.ko
[15:52] <mkrufky> we'll have linking problems if we provide a new xc5000.ko
[15:52] <rtg> mkrufky: patching an existing driver is much less of an issue.
[15:52] <mkrufky> ....and ^^ that is what i meant. 
[15:52] <mkrufky> :-)  ok, cool then
[16:01] <mkrufky> sms1xxx patch email sent
[16:04] <BenC> mkrufky: patching an existing driver should be limited though...large amounts of patching would mean instead, putting the patched driver in ubuntu/ and disabling the in-kernel one
[16:05] <mkrufky> BenC: so far the delta is very small
[16:05] <rtg> mkrufky: perf tweaks and PCI ID updates should be OK.
[16:06] <mkrufky> BenC: if it gets larger, we can move the au8522 / au0828 to ubuntu/  but we cant do that to xc5000 in intrepid.  actually, right now the xc5000 sumbitted for LUM is identical to upstream, but I plan to rev it over the weekend with some power management fixes.  
[16:07] <mkrufky> ...and it will probably be about a week or so before I submit those patches -- the power management stuff will need good testing here first before i submit anywhere :-)
[17:06] <BenC> cjwatson: were you able to look at makedumpfile? I need it in main because linux-meta deps on it, and I'll also need it as a build-dep for linux
[17:13] <cjwatson> BenC: I'll have to do a main inclusion review on the spot for it - need to take Benedict over to his dad's now though
[17:15] <BenC> cjwatson: ok, no rush, since this is all post-alpha-1
[17:32] <BenC> yet another time I wish dpkg diversions supported directories
[17:33] <rtg> BenC: would your fix your permissions in /srv/kernel.ubuntu.com/git/ubuntu/ubuntu-dapper.git ?
[17:34] <rtg> the usual BS
[17:45] <BenC> rtg: done
[17:45] <rtg> BenC: thanks. dapper abi's pushed
[17:45] <BenC> rtg: maybe a good idea to copy that pre-receive hook to the rest of our trees
[17:46] <BenC> it's in ubuntu-intrepid.git/hooks/
[17:46] <rtg> BenC: yep 
[17:46] <rtg> BenC: I'll do it as long as I'm messing with the ABI uploads.
[18:01] <lamont> dear linux-meta.  why does ppc not get linux-image-server love?
[18:01] <lamont> :-)
[18:28] <rtg> BenC: and again for /srv/kernel.ubuntu.com/git/ubuntu/ubuntu-gutsy.git
[18:36]  * lamont grumbles at bug 241726
[18:36] <lamont> full dmesg output is at davis:~lamont/dmesg
[18:43] <rtg> lamont: what's a windfarm?
[18:45] <elmo> rtg: the thermal/fan subsystem for Xserves
[18:46] <elmo> at least in the powerpc era - I don't know if the Xeon based ones still use it 
[18:46] <rtg> elmo: yeah, I figured it out as soon as I looked at dmesg
[18:47] <rtg> elmo, lamont: looks like it might be a macintosh specific driver.
[18:47] <elmo> it is
[18:47] <rtg> elmo: which might be incompatible with powerpc64-smp ?
[18:47] <elmo> rtg: nope
[18:48] <elmo> rtg: or, rather, it use to work
[18:48] <elmo> in dapper + edgy
[18:48] <rtg> elmo: I'm checking. I seem to remember some issues with smp-64
[18:51] <mjg59> It's used in the G5s, as well
[18:51] <mjg59> It's certainly meant to be SMP-compatible
[18:54] <rtg> mjg59: right - I'm looking at moduels.dep. It looks like its not loading one of the sensor modules correctly, e.g., PM81, PM91, or PM112.
[18:54] <rtg> which would pull in windfarm_core
[18:55] <rtg> elmo: do you know which of those sensor modules davis is supposed to use?
[18:57] <elmo> therm_pm72
[18:57] <elmo> I guess
[18:57] <elmo> http://paste.ubuntu.com/21645/
[18:57] <elmo> ^-- same machine, running dapper
[18:58] <rtg> elmo: well davis has therm_pm72 as well
[18:58] <elmo> yeah
[18:59] <elmo> I've no idea if the output is a problem or not, it just stood out
[18:59] <rtg> elmo: hmm, there is also no winfoarm module installed on ross.
[19:00] <elmo> hmm
[19:00] <elmo> the temperature sensors also claim the cpu is running at 11 degrees
[19:00] <elmo> which seems unlikely
[19:01] <mjg59> My recollection is that the fans will run full-on without windfarm loaded
[19:01] <elmo> that sounds entirely plausible
[19:01] <elmo> 'cos those xserves are probably the loudest piece of equipment we have
[19:02] <mjg59> And beahve more sanely if it is
[19:04] <elmo> fwiw
[19:04] <elmo> http://paste.ubuntu.com/21648/
[19:05] <elmo> I was able to modprobe those on ross
[19:05] <rtg> elmo, mjg59: here's the deal. therm_pm72 is adding i2c drivers at load time, but none of the i2c drivers seem to depend on windfarm_core (which has the missing symbols wf_register_control, etc);
[19:05] <elmo> whether or not they actually helped with the fans is harder to tell
[19:05] <elmo> the others said 'ha ha no such hardware'
[19:07] <rtg> elmo: can you try 'modprobe -r therm_pm72; modprobe windfarm_core; modprobe therm_pm72'
[19:08] <elmo> on davis?
[19:08] <rtg> elmo: sure
[19:08] <elmo> FATAL: Error inserting windfarm_core (/lib/modules/2.6.24-19-powerpc64-smp/kernel/drivers/macintosh/windfarm_core.ko): No such device
[19:09] <rtg> elmo: but no missing symbols. It just couldn't find the i2c device that it liked.
[19:10] <elmo> rtg: it could on ross though
[19:10] <rtg> elmo: lemme figure out what windfarm_core is bitching about.
[19:12] <elmo> k
[19:12] <elmo> it's not super important btw, I'm pretty sure it's not melting the hw
[19:12] <rtg> elomo: how about this comment in windfarm_core: '/* Don't register on old machines that use therm_pm72 for now */'
[19:12] <elmo> and if it did; I'm definitely not sure if I'd care ;-)
[19:13] <elmo> rtg: hmm, could be I guess
[19:13] <elmo> benh would know for sure
[19:13] <rtg> you mean BenC ?
[19:13] <elmo> no, benh
[19:14] <rtg> don't know him
[19:14] <elmo> Benjamin Herrenschmidt 
[19:14] <rtg> oh, he the author :)
[19:15] <rtg> elmo: so aside from the annoyance in dmesg, it looks like the default is OK since the fans come on full?
[19:15] <elmo> rtg: assuming they are on full yes
[19:15] <elmo> rtg: but I can't easily tell that from here.  but I'll let you know if the machine explodes over the weekend ;-)
[19:16] <rtg> elmo: no problem, then I'm back to what I was doing.
[20:21] <BenC> rtg: You've done this before...how do you upload to a ppa?
[20:22] <rtg> I use dput with a .dput.cf file
[20:22] <BenC> what's the stanza in  your .dupt.cf?
[20:22] <rtg> [my-ppa]
[20:22] <rtg> fqdn = ppa.launchpad.net
[20:22] <rtg> method = ftp
[20:22] <rtg> incoming = ~timg-tpi/ubuntu/
[20:22] <rtg> login = anonymous
[20:22] <rtg> allow_unsigned_uploads = 0
[20:22] <BenC> rtg: thanks
[20:28] <ChickenCutlass> rtg: were you able to find the DVB driver commit in the netbook tree?
[20:29] <rtg> ChickenCutlass: after some pain, yes. I just pushed it to the LUM repo.
[20:29] <ChickenCutlass> rtg: sorry -- did I not do the commit correctly
[20:30] <rtg> ChickenCutlass: who is to say, I'm not really a git expert. Was origin/abi-18 a branch name?
[20:31] <ChickenCutlass> rtg: yes
[20:31] <rtg> ChickenCutlass: I kind of fumbled my way through it.
[20:32] <ChickenCutlass> rtg: I typically create a new branch based on an ubuntu kernel tag then make my changes
[20:32] <rtg> ChickenCutlass: exposing the SHA1 commit ID so I could cherry-pick was the hard part. I couldn't seem to get that syntax right.
[20:32] <ChickenCutlass> rtg: ah ok
[20:34] <rtg> ChickenCutlass: I finally had to create a branch in my local tree with the same name, fetch from the remote, cherry-pick, switch back to master, then rebase against abi-18
[20:34] <ChickenCutlass> rtg: ugly
[20:35] <rtg> ChickenCutlass: it seems that a lot of git stuff is done the ugly way :)
[20:35] <ChickenCutlass> rtg: right -- only the strong survive
[20:37]  * BenC stares in wonder at the ppa
[20:37] <BenC> You guys are gonna love this shit
[20:37]  * BenC implemented a last-good-boot infrastructure so you will always have a safe kernel to boot into
[20:38] <rtg> never again will I boot to a blank screen?
[20:38] <BenC> rtg: well, never again will you upgrade to a new kernel, and not have a known good one to reboot to if that one fails
[20:39] <BenC> e.g. if you have only one kernel installed, and you upgrade to a same ABI kernel...you still have one kernel, and it might not boot
[20:39] <BenC> this mechanism will make sure that doesn't happen
[20:39] <rtg> BenC: does the user have to make a grub choice? 
[20:40] <BenC> I'm not sure it can guarantee that things like same-upgrade nvidia breakage wont keep it broken (e.g. userspace libraries mixed with wrong version of kernel modules)
[20:40] <BenC> rtg: For now, yes...but I'm hoping to add some magic to detect a failed boot, boot to last-good, and pop up something on the desktop saying "Blah blah, you failed last time, you are in a safe mode now"
[20:41] <BenC> but with something better than "safe mode" to call it
[20:41] <rtg> BenC: won't that depend on being able to mount a file system?
[20:42] <BenC> what do you mean?
[20:42] <rtg> I was just thinking about the detection for a failed boot.
[20:42] <BenC> well, it will require at least mucking with a boot record for grub to notice it
[20:43] <BenC> I'm not sure how it will come together, but I'm going on the assumption that I can make it work
[20:43] <rtg> isn't Colin training to be a grub expert?
[20:43] <BenC> for now, just the ability to keep a last booted kernel around is golden
[20:43] <BenC> rtg: yeah, this may be a good task for him
[20:48] <BenC> Anyone want to add: "deb http://ppa.launchpad.net/ben-collins/ubuntu intrepid main" to their apt sources.list, install and let me know if it works for them
[20:48] <BenC> I've only tested on one machine :)
[20:49] <BenC> you will have to do a reboot to get the first last-good-boot setup, but then it should work after that
[20:49] <BenC> unfortunately, grub fails to build on amd64, so it will only work for i386 for now
[21:09] <BenC> pgraner: ping
[21:39] <munckfish> BenC: I'm running the misc/getabis script in the ports source. It's failing. I've updated it so it builds the correct URL (was using 'linux' instead of 'linux-ports')
[21:39] <munckfish> BenC: but now I notice there are no linux-image-* packages in their for the 1.2 upload
[21:39] <munckfish> there are kernel-image-*di*
[21:40] <munckfish> Any idea what's wrong there?
[21:43] <munckfish> BenC: this is my patch for it so far http://paste.ubuntu.com/21667/
[21:43] <munckfish> here's where I'm hoping it'll find em http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux-ports/
[21:44] <BenC> munckfish: are you looking on ports.ubuntu.com?
[21:44] <munckfish> yes
[21:44] <munckfish> see url above
[21:45] <BenC> munckfish: hmm...for some reason, someone put them in universe
[21:45] <BenC> which makes zero sense
[21:46] <BenC> http://ports.ubuntu.com/pool/universe/l/linux-ports/
[21:46] <munckfish> hmmm
[21:46] <munckfish> https://launchpad.net/ubuntu/intrepid/powerpc/linux-image-2.6.25-1-powerpc64-smp/2.6.25-1.2
[21:46] <munckfish> yep it says universe there
[21:46] <munckfish> weird
[21:46] <munckfish> :S
[21:47] <munckfish> oh, or is that a sarcastic way of saying that's deliberate?
[21:48] <trainpic> I have a question about madwifi drivers
[21:49] <trainpic> I was under the impression that they are included in restricted-modules, but someone told me that they aren't included at all
[21:49] <trainpic> I'm fairly sure they are, and I'm sure someone here knows
[21:49] <rtg> trainpic: they are in LRM as of feisty.
[21:49] <trainpic> If they are, when will the latest version be in?
[21:49] <trainpic> OK
[21:50] <munckfish> BenC: so shall I just update the getabis script to look there as well as the other 3 urls it already does? Cause I presume they aren't going to move now.
[21:50] <trainpic> When will the version with support for the AR242x be in?
[21:50] <trainpic> I have to manually compile it for each kernel
[21:51] <rtg> trainpic: have the madwifi folks released a mainstream version that supports it?
[21:51] <trainpic> Yes, that is what I downloaded and compiled.
[21:51] <trainpic> I'm not sure what version it is, and madwifi.org is having problems right now
[21:52] <rtg> if I remember correctly, the last version was 0.9.4
[21:52] <rtg> what have you built?
[21:52] <trainpic> The version in Ubuntu supports the chipset under 32bit, but I run 64bit and need the latest
[21:52] <trainpic> let me check
[21:53] <munckfish> BenC: I've just realised I don't actually know how to specify whether something should go into universe or main. I presume it's about which ftp site the package source is uploaded to.
[21:53] <munckfish> BenC: if so, how can half of the packages from the same source end up in the wrong section
[21:54]  * munckfish is utterly confused :S
[21:54] <rtg> munckfish: each package is defined in debian/control under its own 'Section:'
[21:54] <trainpic> I think it was 0.9.4
[21:54] <trainpic> Whatever it was had AR242x support under 64bit, and was mainstream
[21:55] <trainpic> I would check the website but it isn't responding
[21:55] <munckfish> rtg: yep, says 'devel', or 'base' etc
[21:55] <munckfish> rtg: but not 'main' or 'universe'
[21:55] <rtg> trainpic: 0.9.4 is what is in LRM.
[21:56] <trainpic> Hm... maybe it wasn't mainstream yet then. Again, wish the site was up so I could be sure. I know for a fact that what's in LRM doesn't support the AR242x under 64bit :-(
[21:56] <rtg> munckfish: thats the root of your problem. I'd help, but I'm late already. gotta go.
[21:56] <munckfish> rtg: ok np c ya
[22:00] <pgraner> BenC: pong
[22:03] <munckfish> BenC: patched to look in that location too now (http://paste.ubuntu.com/21674/)
[22:03] <munckfish> I'll send this into the mailing list if you like