| === 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 | ||
| (ScottK/#ubuntu-kernel) That's my guess. | 04:47 | |
| ThrobbingBrain66 | 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:52 |
|---|---|---|
| ScottK | Actually, IIRC the kernel team prefers to be assigned, not subscribed. | 04:58 |
| ThrobbingBrain66 | yeah, i figured that. oops. | 05:05 |
| ThrobbingBrain66 | thanks for the help | 05:11 |
| === 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 | ||
| kraut | moin | 09:23 |
| === 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 | ||
| doko | please see bug 116648; did we have problems building madwifi in feisty and/or gutsy? | 01:35 |
| === Kano [n=kano@91.64.67.21] has joined #ubuntu-kernel | ||
| Kano | BenC: added a new fetch script: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.22/+bug/128297 | 02:28 |
| === 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 | ||
| mikepj | 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/ | 04:05 |
| === 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 | ||
| bdmurray | mikepj: one thing you could do is look for a launchpad bug linked to the kernel.org bug | 06:28 |
| bdmurray | mikepj: I think it is safe to say it has not been merged | 06:31 |
| bdmurray | BenC: are you familiar with that at all? it is commit cf6387daf8858bdcb3e123034ca422e8979d73f1 I think. | 06:35 |
| === JanC [n=janc@lugwv/member/JanC] has joined #ubuntu-kernel | ||
| BenC | bdmurray: looks to be in our gutsy tree | 06:36 |
| bdmurray | Right I was thinking about dapper | 06:37 |
| === pmjdebruijn [n=pmjdebru@ds9.pcode.nl] has joined #ubuntu-kernel | ||
| BenC | Sounds pretty serious, probably mark it for dapper-6.06.2 milestone and we can look at it in the next week | 06:37 |
| BenC | really simple patch too, so definitely should be easy :) | 06:38 |
| bdmurray | I don't think there is an lp bug yet though. Is there a preferred way to make a new for this? | 06:38 |
| zul | BenC: do you guys need any help for 6.06.2 from the "community" side? | 06:38 |
| BenC | zul: basically going to need a lot of testing from anyone with the target hardware | 06:38 |
| BenC | 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 |
| zul | ah ok im running gutsy now | 06:39 |
| zul | url? | 06:39 |
| bdmurray | https://launchpad.net/ubuntu/+milestone/ubuntu-6.06.2 | 06:41 |
| zul | htanks | 06:42 |
| === 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 | ||
| mikepj | sorry, I was away. Thanks for the info. Glad to hear the patch might make it into 6.06.2. | 09:08 |
| bdmurray | mikepj: I submitted a bug about it but seem to have misplaced it. It should be listed in the milestoned bugs though. | 09:12 |
| mikepj | Yeah, I found it here: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/128568 | 09:12 |
| mikepj | I thought it was effecting all AMD processors though. Must have missed something in one of the other bug reports | 09:13 |
| === ivoks [n=ivoks@0-142.dsl.iskon.hr] has joined #ubuntu-kernel | ||
| IntuitiveNipple | 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. | 09:37 |
| bdmurray | BenC: Could you look at bug 47768? | 10:41 |
| === infinity1 [n=adconrad@cerberus.0c3.net] has joined #ubuntu-kernel | ||
| BenC | bdmurray: the original report appears to be an ordering problem | 10:46 |
| BenC | 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:47 |
| doko | are kyle and lamont on vacation? | 10:51 |
| BenC | doko: kyle was hung up returning from UbuntuLive | 10:51 |
| bdmurray | kees's UsingUUID page says since Edgy | 10:52 |
| BenC | I wonder if we should backport UUID stuff to 6.06.2 | 10:52 |
| ScottK | BenC: I have a dapper system. Checking | 10:53 |
| ScottK | BenC: No UUIDs in /etc/fstab. | 10:53 |
| ScottK | It sounds invasive/risky/dangerous to backport to me. | 10:54 |
| bdmurray | That's what I would think too - quite the "surprise" | 10:55 |
| BenC | actually it's not dangerous at all | 10:56 |
| BenC | we've been upgrading people to UUID since edgy | 10:56 |
| BenC | the main purpose of 6.06.2 is for people that can't install 6.06{,.1} anyway | 10:56 |
| ScottK | Yes, but dapper-updates will get it all too, right? | 10:57 |
| BenC | right, but then anyone running dapper right now will eventually be pushed to UUID no matter what | 10:57 |
| BenC | unless they want to stay with dapper forever | 10:57 |
| ScottK | Well just 5 years. | 10:57 |
| BenC | then they'll be pushed into the UUID upgrade then | 10:57 |
| ScottK | Yep. | 10:58 |
| ScottK | Exactly. | 10:58 |
| BenC | either way, not putting it into 6.06.2 is just deferring it, not making it any less dangerous | 10:58 |
| ScottK | At the end of a stable series, not in the middle. | 10:58 |
| BenC | so that argument is pointless | 10:58 |
| ScottK | I'd put it the other way around. | 10:58 |
| BenC | 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 |
| ScottK | 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 |
| BenC | same could be said for some of the things we're already doing for 6.06.2 | 10:59 |
| BenC | UUID usage is stable, it's the non-use of it that is unstable | 11:00 |
| BenC | especially with SATA and SCSI drives | 11:00 |
| ScottK | 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 |
| BenC | I mean, the upgrade is a single shell script | 11:01 |
| BenC | and it's very well written to avoid breakage...any problems, and it leaves the fstab/menu.lst alone | 11:01 |
| === ScottK recalls helping people survive the transition during Edgy and perhaps that colors my perception. | ||
| === ScottK got burned personally, but was able to recover. | ||
| ivoks | i wouldn't do that in LTS :/ | 11:02 |
| BenC | guess we'll just have people installing and not being able to boot then :/ | 11:02 |
| ScottK | Why? | 11:02 |
| BenC | read bug #47768 | 11:03 |
| BenC | and maybe you'll have some context | 11:03 |
| === ScottK looks | ||
| ivoks | people are unable to install cause of missing drivers :) | 11:03 |
| BenC | ivoks: this is a case of people being able to install, and then not being able to boot it afterwards | 11:03 |
| ivoks | i heard about that problem | 11:04 |
| BenC | 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 |
| ivoks | right | 11:04 |
| ivoks | i2o and stuff | 11:04 |
| BenC | as such, they install and on boot, sda becomes sdb, and sdb becomes sda | 11:04 |
| BenC | blammo | 11:04 |
| BenC | no, nothing to do with i2o | 11:04 |
| BenC | this could be onboard SATA == sda, scsi controller == sdb | 11:04 |
| BenC | load the drivers in different order, and you no longer have a bootable system | 11:05 |
| ivoks | yes, that happend to me once | 11:05 |
| ivoks | i upgraded to feisty then :D | 11:05 |
| BenC | hehe | 11:05 |
| ivoks | ok, you got my vote, since this will personaly help me in some cases | 11:06 |
| ivoks | (not that it matters :) | 11:06 |
| ivoks | are there plans for new version of e1000, 3w-9xxx and some IDE controlers for 6.06.2? | 11:07 |
| BenC | e1000 I believe so, I'd have to check 3w-9xxx, but there's a good chance of it | 11:07 |
| IntuitiveNipple | 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:07 |
| ScottK | What about using UUID for new installs and not "upgrading" something that's already working. | 11:08 |
| ScottK | Personally, I've had a lot more trouble with the UUID transition than I've had with not having UUID. | 11:08 |
| BenC | IntuitiveNipple: sounds like an update-grub issue | 11:08 |
| BenC | IntuitiveNipple: not a kernel issue | 11:09 |
| BenC | ScottK: that's possible too | 11:09 |
| ivoks | then go with that... only for new installs | 11:09 |
| BenC | ScottK: I can't see how anyone could not be using UUIDs to be honest | 11:09 |
| ScottK | 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 |
| BenC | things were so broken before that | 11:09 |
| IntuitiveNipple | BenC: I'll do some digging, if necessary post a bug against update-grub then | 11:09 |
| ScottK | Well I'm typing this on a Dapper desktop that's never had troubles and has no UUID. | 11:10 |
| BenC | IntuitiveNipple: just 'grub', the script is part of that package | 11:10 |
| BenC | ScottK: and has one disk, right? :) | 11:10 |
| ScottK | Ah. | 11:10 |
| ivoks | ScottK: i had scsi and sata controller | 11:10 |
| IntuitiveNipple | BenC: ok :) | 11:10 |
| ScottK | It has two, but they're RAIDed. | 11:10 |
| ivoks | depending on moon and sun, once scsi was sda, and in other cases sata was sda | 11:10 |
| BenC | yeah, if the OS only sees one disk, you'd never have to concern yourself | 11:11 |
| ScottK | Right. | 11:11 |
| BenC | but think if you have a SATA, and boot with a USB disk plugged in | 11:11 |
| BenC | SATA or SCSI | 11:11 |
| ScottK | Yeah. | 11:11 |
| BenC | it might not be a problem, but it could | 11:11 |
| BenC | ScottK: I think you're right about the UUID upgrade part | 11:11 |
| BenC | just leaving it for new installs is a safe bet, since it targets the people we're concerned about | 11:12 |
| ScottK | That sounds quite sane to me. | 11:12 |
| ScottK | You might also have it so someone that wanted to could run the upgrade script manually, just don't do it automagically. | 11:12 |
| ScottK | If that's feasible. | 11:12 |
| ivoks | additional complication and my guess is that no one would do that on working system | 11:13 |
| ScottK | Yeah, but someone who has been having trouble would do that over a re-install. | 11:14 |
| ivoks | don't fix if it isn't broken | 11:14 |
| ScottK | That's the least important part. | 11:14 |
| ScottK | Absolutely not. | 11:14 |
| ivoks | well, i would love to see uuid on new installs, but i wouldn't touch running servers | 11:15 |
| ivoks | i'm just happy cause of e1000 and probably 3w-9xxx :) | 11:15 |
| ivoks | what about support for ICH8 IDE? | 11:17 |
| JanC | 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:55 |
| JanC | AFAIK grub doesn't understand GUIDs ? | 11:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!