=== ubuntulog [i=ubuntulo@trider-g7.fabbione.net] has joined #ubuntu-kernel === Topic for #ubuntu-kernel: Ubuntu kernel development discussion ONLY | Kernel Wiki: https://wiki.ubuntu.com/KernelTeam | Latest kernel upload: 2.6.22-8.18 | Latest news: -rt and -xen kernels re-added | New Kernel Team machine: http://kernel.ubuntu.com/ === Topic (#ubuntu-kernel): set by BenC at Mon Jul 16 14:59:07 2007 [04:47] (ScottK/#ubuntu-kernel) That's my guess. [04:52] ok, that's done. i also subscribed the kernel team to my bug, i dunno if that's frowned upon or not. anything else i need to do? [04:58] Actually, IIRC the kernel team prefers to be assigned, not subscribed. [05:05] yeah, i figured that. oops. [05:11] thanks for the help === ThrobbingBrain [n=bradley@CPE-24-208-44-208.new.res.rr.com] has joined #ubuntu-kernel === crimsun [n=crimsun@dargo.trilug.org] has joined #ubuntu-kernel === abogani [n=alessio@adsl203-157-083.mclink.it] has joined #ubuntu-kernel === cjwatson [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk] has joined #ubuntu-kernel === cjwatson_ [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk] has joined #ubuntu-kernel === ivoks [n=ivoks@83-131-78-222.adsl.net.t-com.hr] has joined #ubuntu-kernel [09:23] moin === amitk [n=amit@a81-197-135-210.elisa-laajakaista.fi] has joined #ubuntu-kernel === ivoks [n=ivoks@83-131-78-222.adsl.net.t-com.hr] has joined #ubuntu-kernel === sdrik [n=sdrik@ip-93-4.dsl.newel.net] has joined #ubuntu-kernel === sdrik` [n=sdrik@ip-93-4.dsl.newel.net] has joined #ubuntu-kernel === sdrik`` [n=sdrik@ip-93-4.dsl.newel.net] has joined #ubuntu-kernel === sdrik``` [n=sdrik@ip-93-4.dsl.newel.net] has joined #ubuntu-kernel === ivoks [n=ivoks@83-131-78-222.adsl.net.t-com.hr] has joined #ubuntu-kernel === amitk [n=amit@a81-197-131-161.elisa-laajakaista.fi] has joined #ubuntu-kernel === amitk_ [n=amit@a81-197-131-161.elisa-laajakaista.fi] has joined #ubuntu-kernel === ivoks [n=ivoks@83-131-78-222.adsl.net.t-com.hr] has joined #ubuntu-kernel === ScottK [n=ScottK@ubuntu/member/scottk] has joined #ubuntu-kernel [01:35] please see bug 116648; did we have problems building madwifi in feisty and/or gutsy? === Kano [n=kano@91.64.67.21] has joined #ubuntu-kernel [02:28] BenC: added a new fetch script: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.22/+bug/128297 === gnomefreak [n=gnomefre@ubuntu/member/gnomefreak] has joined #ubuntu-kernel === IntuitiveNipple [n=TJ@alexandros.tjworld.net] has joined #ubuntu-kernel === ScottK [n=ScottK@ubuntu/member/scottk] has joined #ubuntu-kernel === zul__ [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel === infinity1 [n=adconrad@cerberus.0c3.net] has joined #ubuntu-kernel === gicmo [n=gicmo@p5491F4D9.dip.t-dialin.net] has joined #ubuntu-kernel === mikepj [n=mike@66.103.242.89] has joined #ubuntu-kernel [04:05] I have a kernel update question. Recently I came across a blog entry noting a data corruption problem on machines with over 4Gb of memory. This was due to a kernel bug. I was wondering if the patch for this has been merged into the 6.06 LTS version of Ubuntu. The blog entry is here: http://blogs.smugmug.com/don/2007/07/25/silent-data-corruption-on-amd-servers/ === zul_ [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel === ThrobbingBrain_ [n=bradley@CPE-24-208-44-208.new.res.rr.com] has joined #ubuntu-kernel === gnomefreak [n=gnomefre@ubuntu/member/gnomefreak] has joined #ubuntu-kernel === tuxmaniac [n=tuxmania@unaffiliated/tuxmaniac] has joined #ubuntu-kernel === ivoks [n=ivoks@backup.grad.hr] has joined #ubuntu-kernel === Sunny_Shin [n=sunny@76.24.1.152] has joined #ubuntu-kernel [06:28] mikepj: one thing you could do is look for a launchpad bug linked to the kernel.org bug [06:31] mikepj: I think it is safe to say it has not been merged [06:35] BenC: are you familiar with that at all? it is commit cf6387daf8858bdcb3e123034ca422e8979d73f1 I think. === JanC [n=janc@lugwv/member/JanC] has joined #ubuntu-kernel [06:36] bdmurray: looks to be in our gutsy tree [06:37] Right I was thinking about dapper === pmjdebruijn [n=pmjdebru@ds9.pcode.nl] has joined #ubuntu-kernel [06:37] Sounds pretty serious, probably mark it for dapper-6.06.2 milestone and we can look at it in the next week [06:38] really simple patch too, so definitely should be easy :) [06:38] I don't think there is an lp bug yet though. Is there a preferred way to make a new for this? [06:38] BenC: do you guys need any help for 6.06.2 from the "community" side? [06:38] zul: basically going to need a lot of testing from anyone with the target hardware [06:39] if you check the dapper-6.06.2 milestone tagged bugs, you can get a glimpse at what we're hoping to fix/support [06:39] ah ok im running gutsy now [06:39] url? [06:41] https://launchpad.net/ubuntu/+milestone/ubuntu-6.06.2 [06:42] htanks === EtienneG [n=etienne@ubuntu/member/EtienneG] has joined #ubuntu-kernel === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-kernel === bronson [n=bronson@66.237.74.66.ptr.us.xo.net] has joined #ubuntu-kernel [09:08] sorry, I was away. Thanks for the info. Glad to hear the patch might make it into 6.06.2. [09:12] mikepj: I submitted a bug about it but seem to have misplaced it. It should be listed in the milestoned bugs though. [09:12] Yeah, I found it here: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/128568 [09:13] I thought it was effecting all AMD processors though. Must have missed something in one of the other bug reports === ivoks [n=ivoks@0-142.dsl.iskon.hr] has joined #ubuntu-kernel [09:37] I saw a related bug in launchpad earlier searching for "iommu=soft" (2 bugs; only 1 is using >=4GB RAM) but got side-tracked checking for patches to 6.06, and there is a debian bug #404148 with fix for 2.6.18. [10:41] BenC: Could you look at bug 47768? === infinity1 [n=adconrad@cerberus.0c3.net] has joined #ubuntu-kernel [10:46] bdmurray: the original report appears to be an ordering problem [10:47] bdmurray: do you know if we used UUID in dapper? I can't seem to recall, and don't have a dapper system handy [10:51] are kyle and lamont on vacation? [10:51] doko: kyle was hung up returning from UbuntuLive [10:52] kees's UsingUUID page says since Edgy [10:52] I wonder if we should backport UUID stuff to 6.06.2 [10:53] BenC: I have a dapper system. Checking [10:53] BenC: No UUIDs in /etc/fstab. [10:54] It sounds invasive/risky/dangerous to backport to me. [10:55] That's what I would think too - quite the "surprise" [10:56] actually it's not dangerous at all [10:56] we've been upgrading people to UUID since edgy [10:56] the main purpose of 6.06.2 is for people that can't install 6.06{,.1} anyway [10:57] Yes, but dapper-updates will get it all too, right? [10:57] right, but then anyone running dapper right now will eventually be pushed to UUID no matter what [10:57] unless they want to stay with dapper forever [10:57] Well just 5 years. [10:57] then they'll be pushed into the UUID upgrade then [10:58] Yep. [10:58] Exactly. [10:58] either way, not putting it into 6.06.2 is just deferring it, not making it any less dangerous [10:58] At the end of a stable series, not in the middle. [10:58] so that argument is pointless [10:58] I'd put it the other way around. [10:59] ok, so we'll just leave people with no sure way to install a system because of a feature that we've tested over a year now isn't going to be backported :) [10:59] Deferring the upgrade puts the change where it would be expected, not where it would be unexpected (~ 20% of the way into a stable LTS baseline's life). [10:59] same could be said for some of the things we're already doing for 6.06.2 [11:00] UUID usage is stable, it's the non-use of it that is unstable [11:00] especially with SATA and SCSI drives [11:01] It seems like a significant design change to me. If you did it and broke my LTS server, I'd be pretty annoyed. [11:01] I mean, the upgrade is a single shell script [11:01] and it's very well written to avoid breakage...any problems, and it leaves the fstab/menu.lst alone === ScottK recalls helping people survive the transition during Edgy and perhaps that colors my perception. === ScottK got burned personally, but was able to recover. [11:02] i wouldn't do that in LTS :/ [11:02] guess we'll just have people installing and not being able to boot then :/ [11:02] Why? [11:03] read bug #47768 [11:03] and maybe you'll have some context === ScottK looks [11:03] people are unable to install cause of missing drivers :) [11:03] ivoks: this is a case of people being able to install, and then not being able to boot it afterwards [11:04] i heard about that problem [11:04] ScottK: so the alternate installer loads the drivers in a different order than the installed system (which is ok, because driver load order shouldn't matter and can't be enforced) [11:04] right [11:04] i2o and stuff [11:04] as such, they install and on boot, sda becomes sdb, and sdb becomes sda [11:04] blammo [11:04] no, nothing to do with i2o [11:04] this could be onboard SATA == sda, scsi controller == sdb [11:05] load the drivers in different order, and you no longer have a bootable system [11:05] yes, that happend to me once [11:05] i upgraded to feisty then :D [11:05] hehe [11:06] ok, you got my vote, since this will personaly help me in some cases [11:06] (not that it matters :) [11:07] are there plans for new version of e1000, 3w-9xxx and some IDE controlers for 6.06.2? [11:07] e1000 I believe so, I'd have to check 3w-9xxx, but there's a good chance of it [11:07] Hmmm, UUID install-and-not-boot occurs for kernel upgrades even for Feisty/Gutsy, when you've got one boot partition and 2+ root partitions on the boot disk (multiple distro's) the menu.lst UUIDs are always set to the last root partition UUID, regardless of what they were set to already. Should I post it as a bug? [11:08] What about using UUID for new installs and not "upgrading" something that's already working. [11:08] Personally, I've had a lot more trouble with the UUID transition than I've had with not having UUID. [11:08] IntuitiveNipple: sounds like an update-grub issue [11:09] IntuitiveNipple: not a kernel issue [11:09] ScottK: that's possible too [11:09] then go with that... only for new installs [11:09] ScottK: I can't see how anyone could not be using UUIDs to be honest [11:09] That would not place existing working installs at risk and so would be a lot more consistent with the LTS guarantee in my book. [11:09] things were so broken before that [11:09] BenC: I'll do some digging, if necessary post a bug against update-grub then [11:10] Well I'm typing this on a Dapper desktop that's never had troubles and has no UUID. [11:10] IntuitiveNipple: just 'grub', the script is part of that package [11:10] ScottK: and has one disk, right? :) [11:10] Ah. [11:10] ScottK: i had scsi and sata controller [11:10] BenC: ok :) [11:10] It has two, but they're RAIDed. [11:10] depending on moon and sun, once scsi was sda, and in other cases sata was sda [11:11] yeah, if the OS only sees one disk, you'd never have to concern yourself [11:11] Right. [11:11] but think if you have a SATA, and boot with a USB disk plugged in [11:11] SATA or SCSI [11:11] Yeah. [11:11] it might not be a problem, but it could [11:11] ScottK: I think you're right about the UUID upgrade part [11:12] just leaving it for new installs is a safe bet, since it targets the people we're concerned about [11:12] That sounds quite sane to me. [11:12] You might also have it so someone that wanted to could run the upgrade script manually, just don't do it automagically. [11:12] If that's feasible. [11:13] additional complication and my guess is that no one would do that on working system [11:14] Yeah, but someone who has been having trouble would do that over a re-install. [11:14] don't fix if it isn't broken [11:14] That's the least important part. [11:14] Absolutely not. [11:15] well, i would love to see uuid on new installs, but i wouldn't touch running servers [11:15] i'm just happy cause of e1000 and probably 3w-9xxx :) [11:17] what about support for ICH8 IDE? [11:55] hm, someone I know complains that grub sees his internal hard disk as hd 2 and sometimes as hd 0, depending on whether his USB disk is connected... [11:56] AFAIK grub doesn't understand GUIDs ?