[00:01] 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] jdub: -19 ? [00:35] yeah === asac_ is now known as asac [13:56] cking: you around? Can you comment on bug #153702 since you have one of the affected machines? [13:58] rtg: will do. [14:01] 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] cking: Amit was curious what the parameter actually does. Is there a downside to it? [14:02] rtg: These I don't know - I will investigate and comment. [14:02] Yes, it means that you're driving it as a generic ATA device [14:04] 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] Yes, performance hit and reduced functionality [14:04] What does lspci -n give you when booted with the bios in ide mode? [14:05] 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] It's probably less of an issue with the chipset in IDE mode to begin with [14:06] Since ata_piix provides a smaller set of features to begin with [14:06] You're probably limited to the timings set up by the BIOS, though [14:11] I'd be interested to know which driver is binding to the chipset [14:12] cking: ^^ [14:14] 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] cking: Can I have lspci -n as well? [14:16] mjg59: I mail you [14:19] 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] Perhaps thats why I've not seen this issue. [14:20] rtg: Yeah, that'll happen if you boot in RAID mode [14:20] If you flick the switch in the BIOS it should be identical to Colin's [14:21] 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] rtg: I need 5 mins to get a monitor added to the server - it's remotely located at the moment. [14:22] rtg: "works" meaning "does not need the all_generic_ide" boot option? [14:24] 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] rtg_: IDE mode definitely requires the all_generic_ide option, where as RAID does not [14:44] 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] 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] rtg_: not good. [14:45] rtg_: so there is little difference between RAID and IDE modes - apart from crapping up your system in the process of testing [14:46] cking: indeed. please add that to the bug report :) [14:46] will do [14:47] rtg_: hope you get your dev box sorted asap [14:49] 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] rtg_: 60 minutes - that's lame speed [15:09] cking: stupid BIOS. some futzing around restored the boot. [15:10] rtg: it's kinda worrying that a BIOS can be so flakey [15:11] 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] smb_tp: are you taking care of adding the HVR950Q driver for LUM ? [15:38] rtg: yes [15:38] rtg: I opened bug 231628 for tracking [15:38] bug 241628 [15:39] thanks for that :-) [15:39] smb_tp: thanks. I'm just going through the kernel team mailing list requests to make sure I don't forget something. [15:39] rtg: Np, I am also on the AC-BAT stuff from Yong [15:40] smb_tp: great, thanks. [15:40] 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] mkrufky: is it of general use to the distro kernel? Or just MID style devioces? [15:41] general use [15:41] mkrufky: at the moment it would be better to post on the list. just to have a better reminder [15:41] ok, no prob [15:44] mkrufky: if these drivers are not already in 2.6.26 you should hassle BenC to put them in the Intrepid package. [15:44] 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] 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] smb_tp: mark it "Fix committed", subscribe ubuntu-sru, nominate it for Hardy, and write up the SRU justification in a comment. [15:45] 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] 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] 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] ok, no prob [15:47] 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] 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] mkrufky: If you are adding drivers to intrepid, we don't want them in the same place as upstream would have them [15:48] mkrufky: we'll have them in the ubuntu/ subdirectory [15:48] mkrufky: for Intrepid, the ubuntu/ subdirectory is the equivalent of Hardy LUM. [15:50] to clarify: [15:51] in 2.6.26, the au0828 xc5000 and au8522 drivers are already merged [15:51] but, the 2.6.26 versions are missing some patches, such as usb id's and some small performance tweaks [15:52] 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] we'll have linking problems if we provide a new xc5000.ko [15:52] mkrufky: patching an existing driver is much less of an issue. [15:52] ....and ^^ that is what i meant. [15:52] :-) ok, cool then [16:01] sms1xxx patch email sent [16:04] 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] BenC: so far the delta is very small [16:05] mkrufky: perf tweaks and PCI ID updates should be OK. [16:06] 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] ...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] 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] 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] cjwatson: ok, no rush, since this is all post-alpha-1 [17:32] yet another time I wish dpkg diversions supported directories === mkrufky is now known as mkrufky-away [17:33] BenC: would your fix your permissions in /srv/kernel.ubuntu.com/git/ubuntu/ubuntu-dapper.git ? [17:34] the usual BS [17:45] rtg: done [17:45] BenC: thanks. dapper abi's pushed [17:45] rtg: maybe a good idea to copy that pre-receive hook to the rest of our trees [17:46] it's in ubuntu-intrepid.git/hooks/ [17:46] BenC: yep [17:46] BenC: I'll do it as long as I'm messing with the ABI uploads. [18:01] dear linux-meta. why does ppc not get linux-image-server love? [18:01] :-) [18:28] BenC: and again for /srv/kernel.ubuntu.com/git/ubuntu/ubuntu-gutsy.git [18:36] * lamont grumbles at bug 241726 [18:36] full dmesg output is at davis:~lamont/dmesg [18:43] lamont: what's a windfarm? [18:45] rtg: the thermal/fan subsystem for Xserves [18:46] at least in the powerpc era - I don't know if the Xeon based ones still use it [18:46] elmo: yeah, I figured it out as soon as I looked at dmesg [18:47] elmo, lamont: looks like it might be a macintosh specific driver. [18:47] it is [18:47] elmo: which might be incompatible with powerpc64-smp ? [18:47] rtg: nope [18:48] rtg: or, rather, it use to work [18:48] in dapper + edgy [18:48] elmo: I'm checking. I seem to remember some issues with smp-64 [18:51] It's used in the G5s, as well [18:51] It's certainly meant to be SMP-compatible [18:54] 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] which would pull in windfarm_core [18:55] elmo: do you know which of those sensor modules davis is supposed to use? [18:57] therm_pm72 [18:57] I guess [18:57] http://paste.ubuntu.com/21645/ [18:57] ^-- same machine, running dapper [18:58] elmo: well davis has therm_pm72 as well [18:58] yeah [18:59] I've no idea if the output is a problem or not, it just stood out [18:59] elmo: hmm, there is also no winfoarm module installed on ross. [19:00] hmm [19:00] the temperature sensors also claim the cpu is running at 11 degrees [19:00] which seems unlikely [19:01] My recollection is that the fans will run full-on without windfarm loaded [19:01] that sounds entirely plausible [19:01] 'cos those xserves are probably the loudest piece of equipment we have [19:02] And beahve more sanely if it is [19:04] fwiw [19:04] http://paste.ubuntu.com/21648/ [19:05] I was able to modprobe those on ross [19:05] 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] whether or not they actually helped with the fans is harder to tell [19:05] the others said 'ha ha no such hardware' [19:07] elmo: can you try 'modprobe -r therm_pm72; modprobe windfarm_core; modprobe therm_pm72' [19:08] on davis? [19:08] elmo: sure [19:08] FATAL: Error inserting windfarm_core (/lib/modules/2.6.24-19-powerpc64-smp/kernel/drivers/macintosh/windfarm_core.ko): No such device [19:09] elmo: but no missing symbols. It just couldn't find the i2c device that it liked. [19:10] rtg: it could on ross though [19:10] elmo: lemme figure out what windfarm_core is bitching about. [19:12] k [19:12] it's not super important btw, I'm pretty sure it's not melting the hw [19:12] elomo: how about this comment in windfarm_core: '/* Don't register on old machines that use therm_pm72 for now */' [19:12] and if it did; I'm definitely not sure if I'd care ;-) === mkrufky-away is now known as mkrufky [19:13] rtg: hmm, could be I guess [19:13] benh would know for sure [19:13] you mean BenC ? [19:13] no, benh [19:14] don't know him [19:14] Benjamin Herrenschmidt [19:14] oh, he the author :) [19:15] elmo: so aside from the annoyance in dmesg, it looks like the default is OK since the fans come on full? [19:15] rtg: assuming they are on full yes [19:15] 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] elmo: no problem, then I'm back to what I was doing. [20:21] rtg: You've done this before...how do you upload to a ppa? [20:22] I use dput with a .dput.cf file [20:22] what's the stanza in your .dupt.cf? [20:22] [my-ppa] [20:22] fqdn = ppa.launchpad.net [20:22] method = ftp [20:22] incoming = ~timg-tpi/ubuntu/ [20:22] login = anonymous [20:22] allow_unsigned_uploads = 0 [20:22] rtg: thanks [20:28] rtg: were you able to find the DVB driver commit in the netbook tree? [20:29] ChickenCutlass: after some pain, yes. I just pushed it to the LUM repo. [20:29] rtg: sorry -- did I not do the commit correctly [20:30] ChickenCutlass: who is to say, I'm not really a git expert. Was origin/abi-18 a branch name? [20:31] rtg: yes [20:31] ChickenCutlass: I kind of fumbled my way through it. [20:32] rtg: I typically create a new branch based on an ubuntu kernel tag then make my changes [20:32] 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] rtg: ah ok [20:34] 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] rtg: ugly [20:35] ChickenCutlass: it seems that a lot of git stuff is done the ugly way :) [20:35] rtg: right -- only the strong survive [20:37] * BenC stares in wonder at the ppa [20:37] 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] never again will I boot to a blank screen? [20:38] 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] 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] this mechanism will make sure that doesn't happen [20:39] BenC: does the user have to make a grub choice? [20:40] 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] 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] but with something better than "safe mode" to call it [20:41] BenC: won't that depend on being able to mount a file system? [20:42] what do you mean? [20:42] I was just thinking about the detection for a failed boot. [20:42] well, it will require at least mucking with a boot record for grub to notice it [20:43] I'm not sure how it will come together, but I'm going on the assumption that I can make it work [20:43] isn't Colin training to be a grub expert? [20:43] for now, just the ability to keep a last booted kernel around is golden [20:43] rtg: yeah, this may be a good task for him [20:48] 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] I've only tested on one machine :) [20:49] you will have to do a reboot to get the first last-good-boot setup, but then it should work after that [20:49] unfortunately, grub fails to build on amd64, so it will only work for i386 for now [21:09] pgraner: ping [21:39] 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] BenC: but now I notice there are no linux-image-* packages in their for the 1.2 upload [21:39] there are kernel-image-*di* [21:40] Any idea what's wrong there? [21:43] BenC: this is my patch for it so far http://paste.ubuntu.com/21667/ [21:43] here's where I'm hoping it'll find em http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux-ports/ [21:44] munckfish: are you looking on ports.ubuntu.com? [21:44] yes [21:44] see url above [21:45] munckfish: hmm...for some reason, someone put them in universe [21:45] which makes zero sense [21:46] http://ports.ubuntu.com/pool/universe/l/linux-ports/ [21:46] hmmm [21:46] https://launchpad.net/ubuntu/intrepid/powerpc/linux-image-2.6.25-1-powerpc64-smp/2.6.25-1.2 [21:46] yep it says universe there [21:46] weird [21:46] :S [21:47] oh, or is that a sarcastic way of saying that's deliberate? [21:48] I have a question about madwifi drivers [21:49] 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] I'm fairly sure they are, and I'm sure someone here knows [21:49] trainpic: they are in LRM as of feisty. [21:49] If they are, when will the latest version be in? [21:49] OK [21:50] 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] When will the version with support for the AR242x be in? [21:50] I have to manually compile it for each kernel [21:51] trainpic: have the madwifi folks released a mainstream version that supports it? [21:51] Yes, that is what I downloaded and compiled. [21:51] I'm not sure what version it is, and madwifi.org is having problems right now [21:52] if I remember correctly, the last version was 0.9.4 [21:52] what have you built? [21:52] The version in Ubuntu supports the chipset under 32bit, but I run 64bit and need the latest [21:52] let me check [21:53] 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] 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] munckfish: each package is defined in debian/control under its own 'Section:' [21:54] I think it was 0.9.4 [21:54] Whatever it was had AR242x support under 64bit, and was mainstream [21:55] I would check the website but it isn't responding [21:55] rtg: yep, says 'devel', or 'base' etc [21:55] rtg: but not 'main' or 'universe' [21:55] trainpic: 0.9.4 is what is in LRM. [21:56] 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] munckfish: thats the root of your problem. I'd help, but I'm late already. gotta go. [21:56] rtg: ok np c ya [22:00] BenC: pong [22:03] BenC: patched to look in that location too now (http://paste.ubuntu.com/21674/) [22:03] I'll send this into the mailing list if you like