[12:25] <BenC> victory747: it's not a problem, it's just a change (albeit, one that shouldn't have happened)
[12:25] <victory747> BenC: thanks.  But I'm afraid of average-joe not being able to proceed if they should upgrade the kernel
[12:25] <BenC> victory747: unless you hard coded usage of /dev/sdaX in /etc/fstab, it shouldn't cause you any problems
[12:26] <BenC> victory747: unless they did that, it also should not affect them
[12:26] <victory747> BenC: right - all the non-hard-coded stuff works as well as LVM
[12:26] <BenC> on a normal install, fstab and similar things should use UUID instead of hardcoded hdX/sdX devices
[12:26] <victory747> but it seems odd to change something like that after release
[12:26] <BenC> as I said, it wasn't intentional
[12:27] <victory747> so will it be reverted?
[12:27] <BenC> if people experience the issue and have to fix something, then changing it back is pointless
[12:28] <BenC> either they fixed it right, and they wont even notice us switching it back, or they fixed it wrong (changed hard coding) and we'll be forcing them to change it again
[12:28] <BenC> 90% of people wont even know it happened
[12:28] <BenC> the other 10% had to create the situation that caused it, and would know how to resolve it
[12:28] <victory747> hmm.  I'm an old unix guy, so never really knew about UUID
[12:29] <victory747> yeah, like me
[12:29] <BenC> actually I would put it more like 98/2
[12:29] <victory747> ok, well if you are aware of it, then I'm ok with it
[12:29] <BenC> so it's not something that would crop up for a real green user who wouldn't know how to resolve it
[12:29] <victory747> may I ask why IDE was /dev/sdX in the first place?
[12:30] <he1ix> yep, that seems interesting to me too :)
[12:30] <BenC> everyone is hooked on this old idiom that says sdX is scsi
[12:30] <he1ix> was just about to ask that...
[12:30] <BenC> libata uses the scsi layer as it's backend
[12:30] <victory747> I'm not worried about me, but I am very concerned about people I support and people I turn onto Ubuntu.
[12:31] <BenC> libata has a lot of drivers for SATA/PATA, and we are moving to that core since it is more hotplug capable, and also handles errors a lot better
[12:31] <victory747> ok, that's what I figured - it made sense to me - but this reversion makes things a real mess
[12:31] <victory747> in my humble opinion
[12:31] <victory747> because I work with semi-technical people moving over from windows
[12:31] <BenC> yeah, the reasoning behind it was that ata_piix was causing some problems that the IDE piix driver didn't have
[12:31] <victory747> changes like this mid-stream are very frustrating to them
[12:32] <victory747> ok
[12:32] <BenC> late in feisty release we moved a few PCI ids back to piix, and somehow a larger portion of the move got left in for feisty post release upload
[12:32] <BenC> and it shouldn't have. I thought it had gotten reverted
[12:33] <BenC> that's a mistake we usually don't make, and it's definitely at the top of my "don't let it happen again" list
[12:33] <victory747> yeah, but what now?
[12:33] <victory747> we are back to /dev/hdX for IDE?
[12:33] <BenC> for stability reasons, yes
[12:33] <victory747> ok
[12:34] <BenC> I actually don't mind that it happened, because I wanted to do it during beta freeze, but it was considered too extensive of a change
[12:34] <victory747> may I ask the proper way of finding a partition UUID?
[12:34] <BenC> sudo vol_id /dev/hga1
[12:34] <he1ix> victory747: have a look into /dev/disk/by-uuid/
[12:34] <BenC> *hda1 
[12:34] <victory747> ok
[12:35] <victory747> so in feisty+1 will we go back to libata?
[12:35] <BenC> right, the links in by-uuid are a good starting point, but udev, which mounts things and creates those links uses vol_id
[12:35] <BenC> victory747: very likely
[12:35] <BenC> ata_piix PATA support seems to be much more stable now, and all the issues that were noticed for feisty are gone
[12:35] <he1ix> BenC: ok, sounds reasonable :)
[12:35] <victory747> ok
[12:36] <victory747> thanks for your time.  i appreciate your response and I'm glad you are aware of the issues.  that was my biggest concern
[12:36] <BenC> thanks for taking the time to report it
[12:36] <BenC> hope my answers were satisfactory
[12:36] <he1ix> the links provide a nice overview, thats why i like them...
[12:37] <victory747> no, i understand now the issues, your answers were great.  thanks.
[12:38] <he1ix> (other topic) i was looking around for this for quite a while, but wasn't able to find anything:
[12:38] <he1ix> the timestamps that precede every kernel-message... where do they come from?
[12:39] <he1ix> this seems to be a ubuntu-speciality, afaics
[12:39] <BenC> he1ix: no, it's a kernel config option that enables them
[12:40] <he1ix> BenC: vanilla-default? haven't found that...
[12:40] <BenC> we enable them because it helps us to understand dmesg output when debugging problems
[12:40] <BenC> he1ix: debian/config/i386/config:CONFIG_PRINTK_TIME=y
[12:40] <sits> Is there an acknowledged problem with Intel SATA in the latest Feisty kernel update?
[12:40] <BenC> sits: not that I know of...what's the issue?
[12:41] <sits> Bug #116996
[12:41] <sits> https://launchpad.net/bugs/116996
[12:41] <he1ix> BenC: ah, i see. thanks...
[12:42] <BenC> sits: the change to hdX from sdX was intentional but it's not really a bug unless something stopped working
[12:42] <pkl_> AFAIK Dapper has problems in that many system files didn't use the UUID.
[12:43] <sits> BenC: hang on
[12:43] <sits> BenC: Isn't it going the wrong way?
[12:43] <sits> e.g. from hda -> sda
[12:43] <BenC> pkl_: but the upgrade from dapper to edgy would convert fstab and grub's menu.lst to UUID
[12:44] <sits> BenC: and what about these IRQ timeouts that are occuring?
[12:44] <BenC> sits: it doesn't matter which way it goes...if your disk is in IDE compatibility mode, it looks like an IDE disk to the kernel
[12:44] <sits> ok
[12:44] <BenC> sits: would be nice if I could see them :)
[12:44] <sits> heh
[12:44] <BenC> do you have a digital camera?
[12:44] <sits> I didn't have time to test things out on a work machine today
[12:45] <pkl_> BenC: in the Feisty pre-release kernels when the libata work was in flux, there were numerous issues related to systems upgraded from Dapper -> Edgy -> Feisty.  So it is clear in some case the upgrades didn't work correctly, or a number of cases, people had heavily customised grub loaders.
[12:45] <sits> BenC: so if I understand you correctly
[12:45] <sits> BenC: the change is simply to make disks set in PATA mode actually appear as PATA disks?
[12:46] <sits> s/PATA mode/PATA emulation mode
[12:46] <BenC> sits: the hdX/sdX thing should be a non-issue
[12:46] <BenC> sits: but your IRQ timeouts concern me, and I'm hoping you can work with us to resolve that
[12:47] <sits> BenC: well as I said I'll try reproducing it on the dells at work tomorrow
[12:47] <BenC> does reverting to AHCI or native mode work for you?
[12:47] <sits> (this isn't my bug it just turns up in my "list of bugs I watch")
[12:47] <sits> BenC: what about the reports of broken CD drives etc?
[12:48] <sits> (because they no longer appear as sda devices)
[12:48] <sits> s/sda/sd
[12:48] <BenC> CD drives being broken with ata_piix (libata) are the reason things were switched back to piix (IDE)
[12:48] <pkl_> sits: the fstab entries for CD drives don't use UUID entries.
[12:48] <sits> pkl_: indeed
[12:48] <BenC> those should point to /dev/cdrom instead
[12:48] <sits> pkl_: Would it be even possible for them too given they are removable?
[12:48] <BenC> which is a symlink to whatever cdrom is detected first (scd0 or hdc)
[12:49] <BenC> sits: the fstab entry is noauto,user so it's hotplug for when media is inserted
[12:49] <sits> hmm that isn't the case on my system which is a "Fresh" feisty install
[12:49] <sits> (this is my home system which is not intel)
[12:49] <sits> /dev/hdc        /media/cdrom0   udf,iso9660 user,noauto     0       0
[12:50] <sits> That was created by the Ubuntu installer
[12:51] <pkl_> In my Feisty install, the fstab entry is also /dev/hdb.
[12:51] <stiv2k> hey
[12:51] <sits> pkl_: that's not going to be robust against a change like this
[12:51] <stiv2k> if im on the amd64 arch, and i have the ia32 libs installed and whatnot, how do i go about downloading the 32bit setiathome app?
[12:51] <sits> stiv2k: this is probably the wrong channel to ask that
[12:52] <sits> stiv2k: I'd recommend a 32 bit chroot myself...
[12:52] <stiv2k> ok something for the right channel
[12:52] <stiv2k> how come i can't load the module powernow-k8 for the life of me
[12:52] <stiv2k> heres what happens
[12:52] <stiv2k> (trying to get cpu freq. scaling to work)
[12:52] <sits> stiv2k: it doesn't support/knokw your hardware?
[12:53] <stiv2k> sits: it works fine in windows xp
[12:53] <stiv2k> FATAL: Error inserting powernow_k8 (/lib/modules/2.6.20-16-generic/kernel/arch/x86_64/kernel/cpufreq/powernow-k8.ko): No such device
[12:53] <sits> stiv2k: ah that's not quite what I meant
[12:53] <stiv2k> [  222.884968]  powernow-k8: Found 2 AMD Turion(tm) 64 X2 Mobile Technology TL-52 processors (version 2.00.00)
[12:53] <stiv2k> [  222.884942]  powernow-k8: MP systems not supported by PSB BIOS structure
[12:53] <sits> stiv2k: I mean the module itself is unaware of how to support your hardware
[12:53] <stiv2k> [  222.886287]  powernow-k8: MP systems not supported by PSB BIOS structure
[12:53] <stiv2k> sits: *shrug* it should work, i remember it worked back in edgy
[12:53] <sits> stiv2k: check whether you can get an updated BIOS I guess
[12:54] <stiv2k> its a AMD turion 64x2
[12:54] <sits> pkl_: I guess I'm wondering if some sort of post cleanup is going to be needed to handle that case
[12:55] <sits> stiv2k: hmm. OK if it used to work and no longer does then that's different. I guess in that case I would guess it was a regression (assuming it was running in the same 32/64 bit mode in edgy)
[12:56] <stiv2k> well back in the day
[12:56] <stiv2k> i had the x86 arch installed
[12:56] <stiv2k> in edgy, and it worked for a while
[12:56] <stiv2k> then i think it updated the kernel
[12:56] <stiv2k> and it stopped working
[12:56] <stiv2k> i forget which version exactly
[12:57] <sits> BenC: ok lets assume that I manage to reproduce this problem on an Intel machine tomorrow and I wind up using irqpoll to try and workaround it? What's the next step?
[12:58] <stiv2k> sits: i think it might have something to do with this.... http://bugzilla.kernel.org/show_bug.cgi?id=8075
[12:59] <pkl_> sits: yeah, it would be a good idea.  I guess the issue is the belief that if the files are installer generated/ugrader generated, there shouldn't be an issue as they should use UUID.  If you've edited your files, you're on your own etc.  But, as you've seen, for some reason the installer/ugrader seems to be making mistakes, not upgrading to UUIDs, or not using /dev/cdrom.  I don't know enough about the installer to know if this is a genu
[12:59] <pkl_> ine bug, or what can be done about it unfortunately.
[01:00] <sits> pkl_: ah I see
[01:01] <sits> pkl_: I was unaware the installer _should_ have been using /dev/cdrom
[01:01] <sits> pkl_: the uuid problems are just unfortunate
[01:01] <sits> stiv2k: looks like you answered your own question : )
[01:01] <sits> pkl_: and yes, if you hand edit you're on your own
[01:02] <sits> pkl_: that suggests we may need a ubiquity bug to be opened on this too..
[01:02] <sits> pkl_: what about rumours of uuids changing when switching drivers though?
[01:02] <stiv2k> sits: right but it doesnt appear like they fixed it yet :(
[01:02] <sits> and what about SATA CD drives? Will those really work?
[01:04] <sits> There's a machine at work that has such a drive and it was utterly unable to boot SUSE 10.1 disks because of a lack of SATA drivers...
[01:04] <pkl_> sits: that's a weird issue, I can't explain it.  The obvious solution is the filesystem has been reformatted in addition to the driver change, even if the user isn't aware of it.
[01:04] <sits> pkl_: ok I'll chalk that up as a quirk until I see it myself
[01:04] <sits> pkl_: an fsck wouldn't cause such a change though would it?
[01:05] <pkl_> sits: no, a new filesystem has to be written AFAIK.
[01:05] <sits> pkl_: how do uuids differ from FS labels?
[01:06] <sits> (sorry for the barrage of questions, just trying to build a picture)
[01:06] <pkl_> sits: my suggestion would be to use disktype (or another user-space program) that prints UUIDs.  Both using both drivers, and see if the user-space program reports a different UUID.
[01:07] <sits> pkl_: Ah good suggestion
[01:08] <sits> pkl_/BenC: you may want to say that the change of driver was intentional in one of those bugs (however I predict that will only stir up a barrage of criticism)
[01:09] <sits> the only other thing that springs to mind is won't this change from SATA to PATA dramatically cut throughput?
[01:10] <pkl_> sits: the patches were put into the Feisty kernel, I released the security update with the patches in the kernel.  I _thought_ it was intended to have these changes in the security update, but I'm not so sure now :)
[01:10] <sits> heh
[01:11] <pkl_> If they were not meant to be there, then it is probably my fault :(
[01:11] <sits> hey accidents happen
[01:13] <sits> I'm just working out whether to get the users at work to upgrade now or wait for another kernel release
[01:14] <sits> pkl_: you might want to steer clear of the forums for a little bit if it does turn out to be accident though ;)
[01:16] <pkl_> sits: it depends if they're going to experience some of the issues the kernel fixes, tifm driver (Texas Instruments MMC card), and mouse problems on SiS chipsets are the major changes affecting most people beyond the security fixes (and the dev/sdX - /dev/hdX stuff).
[01:17] <sits> mouse problems on SiS chipsets? Sigh.
[01:17] <sits> SiS chipsets cause me enough grief given that the framebuffer puts out strange modelines at 1280x1024...
[01:17] <pkl_> sits: yeah, I'm mainly lurking watching all the complaints. 
[01:18] <sits> pkl_: ok understood
[01:19] <pkl_> anyway, it's gone midnight here, and so I'm off....
[01:20] <sits> ditto
[01:20] <sits> night
[01:21] <pkl_> Ok, night.
[02:25] <NrbelexUbuntu> Are extremely slow boot times and launch times known to be an issue with the most recent kernel?
[02:26] <NrbelexUbuntu> My laptop has a 2.2GHz P4-M but its running at a ridiculously slow speed...
[02:38] <n2diy> NrbelexUbuntu: everybody signed off at 1917 hours Eastern US time.
[02:38] <NrbelexUbuntu> ... why, n2diy?
[02:51] <n2diy> NrbelexUbuntu: it was after midnight where they live.
[02:52] <pkl_> n2diy: there are kernel guys in the states working for Ubuntu... In fact most do :)
[02:53] <n2diy> pkl_: roger that, did you see NrbelexUbuntu message at 2023?
[02:54] <pkl_> 2023 in what timezone?
[02:54] <kylem> iz dinner time.
[02:54] <kylem> "it's slow" isn't exactly debugging information.
[02:54] <pkl_> iz two hours past midnight for me...
[02:54] <n2diy> pkl_: Eastern US, about half an hour ago.
[02:56] <pkl_> kylem: you shock me, not having a clue isn't an excuse :)
[02:56] <n2diy> pkl_: ok, take a look at this, he rolled back to his previous kernel, and the system returned to normal, note line 114:http://pastebin.ca/520522
[02:57] <pkl_> kylem: I've been in that postion for 4 months, and look at all the damage I've caused  :)
[02:58] <kylem> n2diy, system being slow isn't really a symptom of bad irq routing.
[02:59] <n2diy> pkl_: ok, take a look at this, he rolled back to his previous kernel, and the system returned to normal, note line 114:   http://pastebin.ca/520522
[03:02] <pkl_> kylem: this is probably a result of the libata reversion patches?  I'm not aware of anything else that went into the kernel to cause this...
[03:03] <kylem> yes. i'd believe that.
[03:03] <kylem> NrbelexUbuntu, could you pastebin the output of hdparm -c -d -k /dev/hda?
[03:13] <n2diy> kylem: roger that, it is the only thing I saw that raised a flag to me. He quit anyway, so it is a moot point now, thanks anyway.
[06:19] <purpzey> I've heard from some people in #ubuntu that they've had problems with the new kernel update...Is this and update I should avoid until the quirks are worked through? 
[06:22] <crimsun> not the appropriate channel, but you should inspect your fstab(5) post-update [but pre-reboot] , revert it if necessary and regenerate the initramfs.
[09:36] <kraut> hi
[09:36] <kraut> is there a problem with the feisty-kernel and the usage of UUIDs as root-device in grub?
[09:36] <kraut> when i use UUIDs, it can't map the root-volume.
[10:12] <maks_> kraut ask on #ubuntu, that's the support channel
[10:15] <kraut> maks_: i did it hundreds of times and i got never an answer.
[10:15] <kraut> and i need this information for my own kernel-maintenance.
[10:37] <maks_> kraut: your question is so general that one would need a crystal ball to start debugging your question ;)
[10:37] <maks_> what does "i can't map" mean?
[10:37] <kraut> hmm, thought it would consist of enough details..
[10:38] <kraut> maks_: it doesn't found / and runs into a timeout and i'll get the busybox.
[10:38] <maks_> and did you check which devices or uuid are around?
[10:39] <maks_> (rootdelay=5 or lower comes handy for such boots)
[10:39] <kraut> hmm, there is a path under /dev where i find those UUID pathes.
[10:39] <kraut> ah, thanks for the tip
[10:39] <kraut> the crazy thing is, that i can't find any UUID pathes in the busybox.
[10:40] <JanC> use 'vol_id'
[10:40] <kraut> and i must say, that i compiled the feisty-sources in a dapper-chroot, because i am backporting them.
[10:40] <kraut> JanC: i try it later and give you more details.
[10:58] <cmvo> Hi! After upgrading the kernel to -11 in edgy I get the strange phenomenon of sticking mouse keys.
[11:01] <crimsun> is this 11.37 or 11.38?
[11:01] <cmvo> crimsun: 11.38
[11:01] <crimsun> I'm still running 11.37 on an older Dell Dimension XPS, so I don't know offhand if I'll be able to trigger said symptoms
[11:03] <cmvo> Here it is a P965+Core2Duo and a PS/2 trackball, also kubuntu.
[11:04] <crimsun> yeah, yours is _considerably_ newer (to the tune of a half-decade)
[11:07] <cmvo> Its rather strange, it most often happens when clicking and dragging between windows. I release the key of the destination and the dragged object is droppen.
[11:08] <cmvo> Afterwards it seems the other keys not used during the drap are down.
[11:08] <cmvo> s/drap/drag/
[11:11] <cmvo> I was about to blame it on X/KDE, but since booting back to -10.34 the effect is gone.
[11:24] <crimsun> hmm
[11:24] <crimsun> I wonder if it's the i8042 changes.
[11:38] <cmvo> crimsun: where there any between 10.34 and 11.38?
[11:53] <crimsun> cmvo: no, I was looking at the wrong git tree.  Sorry.
[11:53] <crimsun> (pulled on -feisty, not -edgy)
[11:57] <cmvo> crimsun: yeah, this system needs an upgrade...
[12:14] <cmvo> crimsun: I'll try the other -11s on the next reboot.
[01:38] <maks_> is there already first field experience of nouveau ?
[01:39] <maks_> latest powertop wants this hpet patch did you add it?
[01:42] <maks_> hmm not seen in fedora
[01:43] <maks_> but they have an 2.6.21 patch to disable hpet on some dell notebooks
[01:44] <maks_> not yet merged http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/devel/linux-2.6-x86-dell-hpet.patch?view=markup
[08:29] <apt_get> I need some help with ifb kernel module
[10:30] <bdmurray> hello?
[10:33] <crimsun> hi
[10:36] <bdmurray> hey crimsun I was looking a probable kernel bug but the original reporter replaced the hardware so I'm not sure if there is enough info in the bug
[10:36] <bdmurray> it is bug 115647
[10:38] <crimsun> erm, yeah, there's not much that can be done if the hardware itself is gone...
[10:40] <crimsun> (-> 6.12)
[10:42] <apt_get> Hi
[10:42] <apt_get> i need some help with ifb....  
[11:19] <fxc> just a curiosity: did latest kernel (2.6.20-16) disable libata?
[11:20] <fxc> My ide disk was sda beofre. Since update it's hda