[04:34] <maccam-sager> i heard the intel eeprom corruption issue has been fixed, has that been put into synaptic yet?
[09:09] <mdz> what does the "PIIX3...enabling passive release" message mean which comes up in KVM?
[09:23] <soren> mdz: It means that the bios in kvm fails to enable passive release for the piix3 pci bridge, and the kernel fixes this.
[09:24] <soren> I don't think it should be a KERN_ERR thing.
[09:26] <soren> Seems I'm not alone: http://lkml.org/lkml/2008/8/8/198
[09:27] <soren> mdz: Oh, or are you asking what passive release is?
[09:31] <mdz> soren: no, you answered my question, thanks
[09:31] <soren> mdz: Any time.
[11:09] <ivoks> umm... we have a serious regression in intrepid's kernel
[11:10] <ivoks> drbd isn't functional - while the drbd works on linus's kernel, it doesn't on ubuntu's, even tough it's the same patch/module
[11:12] <ivoks> could someone assist me in detecting where is the bug?
[11:17] <laga> i think that's a known issue
[11:17] <laga> check the meeting minutes of the server team
[11:18] <ivoks> thanks
[11:36] <ivoks> laga: can't find anything... do you recall which meeting that was?
[11:41] <laga> doh. it references your nick name...
[11:41] <laga> http://ubuntuserver.wordpress.com/2008/09/30/server-team-20080930-meeting-minutes/
[11:42] <ivoks> eh... :)
[11:43] <ivoks> bottom line: drbd 8.2.7~rc1 works with vanilla kernel and doesn't with ubuntu's latest git
[11:43] <laga> and vanilla kernel is the latest 2.6.27 RC?
[11:43] <ivoks> no, rc7
[11:44] <ivoks> the same one which is base for ubuntu's kernel
[11:44] <laga> ah, okay
[11:44] <laga> my usual answer to such problems is git-bisect, but maybe one of the kernel developers already has an idea what's going on
[11:45] <IntuitiveNipple> ivoks: kernel config differences/
[11:45] <IntuitiveNipple> ?
[11:45] <ivoks> IntuitiveNipple: i used ubuntu servers config for vanilla
[11:46] <ivoks> there are differences, cause vanilla doesn't have all that stuff ubuntu has
[11:49] <IntuitiveNipple> The Kconfig looks pretty straightforward
[11:49] <paran> anybody know (or can guess) when the ubuntu kernel will be rebased against -rc8? I have a machine that needs a fix from there :)
[11:49] <ivoks> IntuitiveNipple: everything looks fine
[11:49] <ivoks> IntuitiveNipple: it just doesn't work - i have a strace output from userland tools
[11:49] <IntuitiveNipple> ivoks: Is the module loading and not working - any log clues?
[11:50] <ivoks> module is loading, but when userspace want's to connect to it, it can't
[11:50] <ivoks> but cn is loaded
[11:51] <ivoks> :q
[11:51] <ivoks> ups :)
[11:54] <ivoks> i could upload strace output if that could help
[11:55] <ivoks> with ubuntu kernel, userspace tool timeouts (strace show that it reads eth0 and never finishes)
[11:56] <ivoks> while on the vanilla kernel, same tool works (strace shows on that same point read(5, "Unconfigured\n", 4096) )
[11:59] <amitk_> paran: it has already been rebased against -rc8. Upload will probably happen on Monday.
[12:00] <ivoks> IntuitiveNipple: is it normal to have something like 'ESPIPE (Illegal seek)'? :)
[12:01] <IntuitiveNipple> ivoks: I've not seen that much so, no, I doubt it.
[12:01] <IntuitiveNipple> ivoks: Is it using a single ethernet port, or the bonding driver?
[12:02] <ivoks> single
[12:02] <paran> amitk_: sounds great, thanks.
[12:03] <ivoks> IntuitiveNipple: if you are interested in problem, i could provide you access to machine (both i386 and amd64) with full setup
[12:07] <IntuitiveNipple> ivoks: I doubt I know enough of the specifics to be of any help
[12:07] <ivoks> IntuitiveNipple: ok, thanks for assisting
[12:08] <IntuitiveNipple> ivoks: Is the *only* difference between the working and non-working configuration, the kernel the system boots with?
[12:09] <ivoks> IntuitiveNipple: yes
[12:11] <ivoks> IntuitiveNipple: i don't think that ESPIPE is problem, since seeking socket isn't possible at all :)
[12:12] <IntuitiveNipple> ivoks: possibly a symptom of the root cause
[12:13] <ivoks> could be...
[12:13] <ivoks> i've asked drbd devs, so i'm waiting for an answer
[13:56] <Wellark^> hi! any change getting the HSO driver to ship with intrepid? http://tinyurl.com/4jynn6
[13:56] <Wellark^> there are many option 3g devices that need this driver
[13:57] <Wellark^> and it's actively developed
[13:59] <Wellark^> I honestly thought it was included in vanilla 2.6.27, but obviously it's not
[13:59] <amitk_> Wellark^: hso is already merged into the mainline kernel in 2.6.26, so we carry it already. Is the pharscape driver a different version?
[13:59] <amitk_> see drivers/net/usb/hso.c
[14:00] <Wellark^> hmm.. didn't spot that in gitweb.. 
[14:01] <amitk_> Wellark^: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=tree;f=drivers/net/usb;h=704c3d6c5ecce21316f65a33d802a1ce54ed6b8a;hb=HEAD
[14:02] <Wellark^> ah, ok. I checked drivers/usb/serial where option.c is :)
[14:03] <Wellark^> hmm.. option forum states that 1.6 is the latest.. intrepid kernel has 1.2..
[14:12] <rtg> BenC: can you think of a good reason _not_ to go with upstream e1000e? I've just pulled the NVM protection patch from Linus, so I'm thinking about dropping the SourceForge version of e1000e.
[14:13] <BenC> rtg: none that I'm aware of...what does Intel say about it?
[14:13] <BenC> do they have any requirements for us to use the sf one?
[14:13] <rtg> BenC: it seems upstream is where all of their development effort has gone lately. I'm wondering why they have a duplicate project in the first place.
[14:14] <rtg> BenC: I'm not aware of any requirements from Intel.
[14:15] <rtg> BenC: I think I'll just swizzle the configs for now and see if anyone squawks. 
[14:16] <BenC> rtg: ok
[14:17] <rtg> BenC: I'm alos gonna upload -rc8 plus that one e1000e patch.
[14:21] <BenC> rtg: ok
[14:23] <rtg> BenC: is there a trick to setting these tags after a rebase so that the next time you 'insertchanges' you don't get all of the UBUNTU history repeated?
[14:25] <amitk_> rtg: debian/scripts/misc/retag
[14:26] <BenC> rtg: ./debian/scripts/misc/retag
[14:26] <rtg> huh
[14:27] <BenC> fairly new script
[14:27] <rtg> I was just gonna ask when that little tidbit appeared :)
[18:07] <CarlFK> ibex  2.6.27-3-generic  clonezilla output "Try to turn on the harddisk "/dev/sda" DMA...  HDIO_GET_DMA failed: Inappropriate ioctl for device"
[18:08] <CarlFK> what command is it probably running?
[18:13] <mjg59> hdparm
[18:24] <CarlFK> # hdparm -d /dev/sda " HDIO_GET_DMA failed: Inappropriate ioctl for device"
[18:24] <CarlFK> is this a problem?
[18:29] <smb_tp> CarlFK, No, just a result from moving to lib(s)ata. IIRC this automatically wants to set the right dma mode
[18:30] <CarlFK> thanks.  I'll pass that on to clonezilla
[18:31] <cobradevil> can someone help me out ?
[18:31] <cobradevil> i have some strange feelings about virtualization
[18:32] <cobradevil> what will ubuntu be supporting with the intro of intrepid?
[18:33] <cobradevil> i'm using xen but i read at a few places intrepid will only support xen domu?
[18:36] <cobradevil> can someone confirm that?
[19:12] <CarlFK> [   10.725634] ata1.00: limited to UDMA/33 due to 40-wire cable
[19:12] <CarlFK> it's an 80
[19:12] <CarlFK> who's problem?
[19:18] <cobradevil> you could try a knoppix cd
[19:18] <cobradevil> see if thats giving the same output?
[19:18] <cobradevil> it could be a hardware problem?
[19:19] <cobradevil> what does the bios say
[19:19] <smb_tp> CarlFK, It's from libata-core, which kernel version?
[19:19] <CarlFK> Linux dhcp91 2.6.27-3-generic #1 SMP Wed Sep 10 16:02:00 UTC 2008 i686 GNU/Linux
[19:20] <CarlFK> I was about to install daily ﻿u-server, so should have -4 in about 30 min 
[19:24] <smb_tp> CarlFK, Doesn't look to me like there was much activity in that area since then...
[19:27] <CarlFK> cobradevil: bios - hardly says anything - I am lucky to see a model number
[19:30] <smb_tp> CarlFK, From cable_is_40wire() in drivers/ata/libata-core.c it looks either the controller thinks it is 40wires or it doesn't know and none of the drives on that controller can tell...
[19:30] <CarlFK> smb_tp: might be older drives - 40 and 80 gig
[19:34] <smb_tp> CarlFK, There is some description to force cable type in Documentation/kernel-parameters libata-force.. Maybe that could help
[19:34] <smb_tp> CarlFK, libata.force= (to be correct)
[19:34] <CarlFK> ill give it a shot and see what happens 
[19:34] <CarlFK> thanks 
[22:16] <CarlFK> where are docs for append ... libata.force=2:1.5g,2.15:3.0g,2.03:noncq,udma4
[22:53] <CarlFK> smb_tp:  2.6.27-4-server works fine: [    4.510417] ata1.00: configured for UDMA/100 [    4.551749] ata1.01: configured for UDMA/66
[23:19] <asac> rtg: http://launchpadlibrarian.net/17919677/syslog (from bug 273633) ... any ideas? what does "disassociating by local choice" means?
[23:20] <asac> rtg: also this guy has a bogus ethernet driver (eth0: driver is 'NULL(info.linux.driver)'. 
[23:21] <asac> this means that hal didnt provide any driver name (i added that NULL (info...) thing as a hack at some point for broadcom wireless)
[23:44] <smb_tp> CarlFK, Hm, since the libata code did change, maybe it was the code for the controller. Well, it works now...