=== JanC [n=janc@lugwv/member/JanC] has joined #ubuntu-kernel === marcin_ant [n=marcin@194.114.146.126] has joined #ubuntu-kernel === marcin_ant_ [n=marcin@194.114.146.126] has joined #ubuntu-kernel === rrittenhouse [n=tad@unaffiliated/rrittenhouse] has joined #ubuntu-kernel === zul_ [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel === johanbr [n=j@128.189.255.57] has joined #ubuntu-kernel === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-kernel === johanbr [n=j@128.189.255.57] has joined #ubuntu-kernel === jml [n=jml@ppp112-44.static.internode.on.net] has joined #ubuntu-kernel === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-kernel === reitblatt [n=mark@resnet-50-71.dorm.utexas.edu] has joined #ubuntu-kernel === owh [n=onno@optussatellitebintb.22bjipb002.optus.net.au] has joined #ubuntu-kernel [04:22] Greetings. I am trying to determine if the FAT as implemented by the kernel supports the dirty flag. I have conflicting information going back to 1998, but no definitive answer either way. I've looked in include/linux/msdos_fs.h where I would expect the definition. There is a mark_inode_dirty call in fs/fat/file.c, but I cannot see it relating to the boot sector in any way. Can anyone here enlighten me? [04:24] Some background: Initially bugs were being reported where dosfschk was checking clean file systems and changing them, causing all manner of grief. Some of the bugs are/have been fixed, but the check should never have happened in the first place. I wrote a spec to handle the (v)FAT flag for dosfschk but stayed away from kernel comments because I do not know the state. [04:25] The spec was updated to comment about the kernel, but I now need to know for sure if it isn't supported, which is what it's beginning to look like. [04:38] I suspect that once dosfstools implements dirty flags, that can then be used within the kernel, seeing that it doesn't currently appear to be there. [04:42] BenC: - pata_oldpiix: Stable, allows us to disable piix.ko IDE module. [04:42] BenC: Does that mean you've added IDs back to ata_piix that had been taken out previously? [04:42] I'd noticed a couple vanish [04:43] yes [04:43] I had shifted some back to piix because ata_piix was getting some weird errors [04:55] Am I asking too much, in the wrong channel, at the wrong time? === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-kernel [05:14] owh: well, this is the ubuntu-specific kernel channel [05:15] owh: I'm not sure that the folk here know the answers offhand. Though they may. [05:15] BenC: any comment on owh's thing ? === fs [i=fs@213.178.77.100] has joined #ubuntu-kernel [05:16] no idea [05:16] owh: there you go. :) [05:19] lifeless: Any suggestions where to ask? === AnAnt [n=anant@62.114.91.84] has joined #ubuntu-kernel === owh suspects that sending an email to lkml will get burried. [05:25] I've been trying to track this down since January 2, I've sent emails to ubuntu-dev, ubuntu-dev-discuss, the maintainer of dosfstools, #ubuntu-motu, LP and here. I'm getting a whole lot of nada. === owh would think that FAT implementation would be high on the list of importance given it's pervasive nature in the interaction with the rest of the world. [05:27] I'm happy to be patient, realise that people are busy with other things, but the response level I'm seeing is a little disheartening. [05:28] How do I get this issue in front of the appropriate eye balls? === jml [n=jml@ppp112-44.static.internode.on.net] has joined #ubuntu-kernel [06:09] morning guys [06:09] BenC: you still awake? === marcin_ant [n=marcin@194.114.146.126] has joined #ubuntu-kernel [06:22] It has just been suggested that I write the patch to implement FAT dirty flag support for the kernel. If I actually do that, how do I get someone to look at it? [06:23] Do I bring it here and show it like a cat comes into your home with it's catch for the night? === owh apologises for the bastardisation of the English language in that previous contribution. === jml [n=jml@ppp112-44.static.internode.on.net] has joined #ubuntu-kernel [06:28] owh: make a patch first :) then post it to kernel-team@lists.ubuntu.com for review [06:28] if the patch is good it will eventually land in Linus tree [06:29] Excellent, now that's what I call progress. Thanks for that fabbione, that pays for the past four hours of banging my head against the keyboard. [06:30] owh: you are only fighting against different people living in different TimeZones [06:31] you can start complaining only after 48 hours of nobody answering (excluding the weekend ;)) [06:31] :) === jml [n=jml@ppp112-44.static.internode.on.net] has joined #ubuntu-kernel === Lure [n=lure@external-7.hermes.si] has joined #ubuntu-kernel === abogani [n=abogani@adsl203-157-083.mclink.it] has joined #ubuntu-kernel === tumbleweed [n=stefanor@dsl-240-82-161.telkomadsl.co.za] has left #ubuntu-kernel ["done] === cassidy [n=cassidy@host-213-189-171-21.brutele.be] has joined #ubuntu-kernel === varka [n=varkatop@p54a5fa22.dip.t-dialin.net] has joined #ubuntu-kernel === m0rg0th [n=manugarg@220.225.228.97] has joined #ubuntu-kernel === m0rg0th [n=manugarg@220.225.228.97] has joined #ubuntu-kernel === ivoks [n=ivoks@backup.grad.hr] has joined #ubuntu-kernel === giangiva [n=giangiva@adsl203-157-083.mclink.it] has joined #ubuntu-kernel === sky_walkie [n=hrdlo@193.85.244.121] has joined #ubuntu-kernel === giangiva [n=giangiva@adsl203-157-083.mclink.it] has joined #ubuntu-kernel === gicmo [n=gicmo@p5491C47D.dip.t-dialin.net] has joined #ubuntu-kernel === Keybuk [n=scott@quest.netsplit.com] has joined #ubuntu-kernel === gicmo [n=gicmo@p5491C836.dip.t-dialin.net] has joined #ubuntu-kernel === raffytaffy [n=raf@24.215.149.187] has joined #ubuntu-kernel [01:09] i have i915 chipset - ditching all the i810 and ati/amd stuff is safe correct? [01:15] I wouldn't drop the i810 stuff, no [01:27] ok thanks [01:28] for character devices - ( im using nvidia go 6600) i dropped ATI and AMD, seems safe. i kept nvidia nforce/geforce [01:32] im trying to configure my kernel to be minimal. === zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-kernel === zul [n=chuck@ubuntu/member/zul] has joined #ubuntu-kernel === Keybuk [n=scott@quest.netsplit.com] has joined #ubuntu-kernel [03:34] BenC: There's a missing ! in the check for acpidata in ata_acpi_push_id [03:34] Sorry about that [03:35] mjg59: Yes, we caught that :) [03:35] Excellent [03:35] Tim is moving the check for !acpidata to skip_acpi_operation() [03:36] BenC: did you see my question about whether we can include kqemu in feisty? [03:36] BenC: As long as he's arranging the order of checks so that doesn't dereference a null, that's fine [03:36] mjg59: Am I correct that the check for skip_acpi_operation() in do_drive_get_GTF() is bogus (already done from the calling function)? [03:37] BenC: do_drive_get_GTF is exported [03:37] Oh, sorry, no it's not [03:37] I was thinking of GTM [03:37] Yeah, in that case it can probably go [03:39] BenC: i committed the fixes to OCFS2 local mount.. 3 small patches.. no ABI change [03:39] BenC: we need to get those in feisty before relase [03:52] Mithrandir: Yeah, as soon as I get the ata stuff settled down, finish my ps3+powerpc64-smp merge, and do the nvidia 9631 stuff, I'll see if I can get to it :) [03:52] fabbione: We have an ABI bump anyway...thanks for the merges [03:53] BenC: ok, cool. It was more of a "would it make sense" than "please do asap". [03:53] Mithrandir: I'd like to have it in there...the more virt stuff we have the better [03:53] BenC: it seems that the problem with the live cd not working in qemu is limited to amd64; i386 works fine. [03:54] BenC: I can look at the kqemu stuff if you want [03:54] Mithrandir: I heard there's problem with amd64 under vmware too...guess I need to check on that today [03:54] zul: Yes, please [03:54] zul: it should be easy enough; the module builds fine as is, so it's just build-system integration. [03:54] Mithrandir: sure no problem [03:54] BenC: great, thanks. If you want bugs about this, then tell me. [03:56] BenC: I'm still trying to track down the HPA issue [03:56] That's basically a blocker to release [03:56] mjg59: April 4th is kernel freeze...I don't want to have to revert all the libata-pata drivers back to ide counterparts :) [03:57] mjg59, it doesn't work with piix or ahci, does it [03:57] Seems fine with ahci [03:57] Breaks on ata_piix on Apple hardware [03:58] can i get an lspci -vvnn from your MBP? [03:58] Not right this second, but what are you looking for? [03:58] The controller is 8086:27c4 [03:58] And it comes up with an IDE class, not an AHCI one [03:58] right. [03:58] that's fixable though. [03:58] ;-) [03:58] Subdevice code is an Intel one, not an Apple one [03:58] Otherwise it'd be really easy [03:59] So, yeah, one fix would be to bodge it over to ahci [03:59] And hope that we're only going to hit the issue on Apples [03:59] Though I suspect we still need to make udev smarter in initramfs-tools in order to guarantee that ahci binds rather than ata_piix [04:00] gnrrr. [04:00] i was hoping i could just install a pci quirk and check the dmi table for Apple [04:00] That ought to be fine [04:01] But the device ID is still present in ata_piix, so both will be loaded [04:01] And I don't think we have guarantees about which will bind first [04:02] So it's either (a) fix udev so that it doesn't load ata_piix unless the class ID is 0x0101, or fix ata_piix so it refuses to bind if the class id is 0x00601 (or whatever ahci is) [04:02] argh. [04:03] BenC: ok .. [04:04] mjg59, i think my ich8 changes the devid too. [04:04] kylem: Really? Wow. ich6 and ich7 don't. [04:04] 1sec whiel i rboot [04:04] Ok [04:05] 00:1f.2 IDE interface: Intel Corporation Mobile SATA IDE Controller (rev 03) [04:05] turns into blah blah AHCI, and sets the prog-if doodly [04:07] And the device ID? [04:07] well, if the string changed, it's different, i didn't bother to save it [04:08] Which bit of the string changed? Just the "IDE interface" to "AHCI interface"? [04:08] If so, surely that's just because the class ID changed? [04:08] no [04:08] the device id. [04:08] *AND* the class id [04:08] 00:1f.2 SATA controller: Intel Corporation Mobile SATA AHCI Controller (rev 03) [04:09] Ah, got you [04:09] Yeah, in that case it seems to change [04:09] this is what all implementations *should* do. [04:09] That doesn't seem to be the case for ICH7 and ICH6 [04:10] since rarely do we match on classid. [04:10] That's why ahci and ata_piix share a load of device IDs [04:11] have i mentioned how much i hate BIOS writers today? [04:11] Not helped by the fact that ata_piix will deliberately try to reprogram your ahci hardware back to piix mode [04:11] ahci has the class ID in it now [04:12] will to-be-driven-by-piix devices always be 0x0101? [04:12] Should be [04:12] hmm. ok. === Keybuk [n=scott@wing-commander.netsplit.com] has joined #ubuntu-kernel === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-kernel === varka [n=varkatop@p54a5fa22.dip.t-dialin.net] has joined #ubuntu-kernel [04:43] zul: You interested in doing a openvz package like the xen one for feisty universe? [04:43] zul: I can get you in contact with the openvz folks who seem ready to do just about anything to get it done [04:44] BenC: sure [04:44] whats one more [04:44] What's your preferred email? [04:44] gmail account === shawarma [n=sh@atlas.linux2go.dk] has joined #ubuntu-kernel [04:46] zul: Sent [04:46] BenC: thanks [04:46] zul: No, thank you :) [04:46] BenC: no thank you [04:46] I can do this all day [04:46] hehe [04:49] Any idea when the kernel in the ubuntu-server daily images will be updated? [04:49] I'm unable to boot it in qemu and I suspect this bug: https://bugs.beta.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/94637 [04:50] ...which appears to have been fixed on the 23rd, but uname -v on the ubuntu-server daily image from yesterday says "Mar 21". [04:50] Er.. Not unable to boot, but unable to access either emulated hard drive or cd-rom. [04:52] BenC: depending on what happens with liam I can probably get it done this weekend [04:52] zul: sounds good [04:53] BenC: ^^ [04:54] shawarma: what kernel is on that CD? [04:54] 2.6.20-12-generic [04:55] BenC: uname -v says:"Linux (none) 2.6.20-12-generic #2 SMPWed Mar 21 20:55:46 UTC 2007 i686 unknown" [04:56] shawarma: Guess it has to wait on debian-installer being rebuilt with the latest kernel [04:56] BenC: That's it?I think I saw a new d-i on feisty-changes earlier today.. [04:57] BenC: That would put it on the daily image for today? [04:58] either today or tomorrow [04:58] BenC: Apparantly so. The changelog even says:"* No-change rebuild to pick up new components." [04:58] :-) [04:58] I didnt' make the connection for some reason. [04:59] BenC: Great. Thanks for clarifying. [05:01] BenC: http://www.linuxsymposium.org/2007/view_abstract.php?content_key=110 [05:03] zul: whack [05:03] zul: Is that a Xen hypervisor as a module? [05:03] shawarma: i think so I havent read the paper yet [05:03] zul: Interesting. [05:04] zul: Well... if you have the appropriate hardware, that is. :-( === tuxmaniac [n=aanjhan@unaffiliated/tuxmaniac] has joined #ubuntu-kernel === sacater [n=sacater@host86-137-253-194.range86-137.btcentralplus.com] has joined #ubuntu-kernel === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-kernel === pmjdebruijn [n=pmjdebru@pmjdebruijn.xs4all.nl] has joined #ubuntu-kernel === bleinmono [n=toffel@ppp91-76-73-23.pppoe.mtu-net.ru] has joined #ubuntu-kernel === ivoks [n=ivoks@backup.grad.hr] has joined #ubuntu-kernel === Nafallo [n=nafallo@ubuntu/member/nafallo] has joined #ubuntu-kernel === Lure [n=lure@clj46-234.dial-up.arnes.si] has joined #ubuntu-kernel [06:48] BenC: is current kernel in git in flux? it oops-es on boot here in ata code (scsi_error_handler)... [06:52] should be fixed now [06:53] git is always in flux [06:56] BenC: ok, expected [07:19] BenC: could you take a look at 91009 and tell me what you think? [07:21] Mithrandir: well, we're using stock 2.6.20 wireless extensions, so if userspace needs to catch up, then that's what has to happen [07:22] I can't revert the kernel stack back, else we risk breaking dozens of drivers [07:22] gnr, ok. [07:23] oh well, let's go for it then. === zul_ [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel [07:39] Is there any documentation about kernel hdX: command errors? === rrittenhouse [n=tad@unaffiliated/rrittenhouse] has joined #ubuntu-kernel === EtienneG [n=etienne@modemcable178.77-70-69.static.videotron.ca] has joined #ubuntu-kernel === cr3 [n=marc@pdpc/supporter/bronze/cr3] has joined #ubuntu-kernel [08:13] BenC: I seem to be experiencing the same problem as reported in bug #84603, should I log another bug, attach to the existing bug or would you even want me to try anything beforehand? [08:14] cr3: let me check [08:16] cr3: More dmesg might help [08:17] BenC: shall I attach it to the same bug or to another bug? [08:17] same one [08:18] BenC: I'm experiencing the problem on a System76 Z35F which is not exactly the same as the original poster, so I'll make sure to mention that in my comment. [08:18] cr3: Ok, then lspci -vvn output too please [08:18] compare notes === m0rg0th [n=manugarg@219.64.120.181] has joined #ubuntu-kernel [08:28] BenC: done [08:29] cr3: thanks === Lure [n=lure@clj46-234.dial-up.arnes.si] has joined #ubuntu-kernel === doko_ [n=doko@dslb-088-074-019-006.pools.arcor-ip.net] has joined #ubuntu-kernel === Keybuk [n=scott@wing-commander.netsplit.com] has joined #ubuntu-kernel === gnomefreak [n=gnomefre@ubuntu/member/gnomefreak] has joined #ubuntu-kernel === m0rg0th [n=manugarg@219.64.120.181] has joined #ubuntu-kernel === m0rg0th [n=manugarg@219.64.120.181] has joined #ubuntu-kernel === sacater [n=sacater@host86-137-253-194.range86-137.btcentralplus.com] has joined #ubuntu-kernel === ivoks [n=ivoks@17-44.dsl.iskon.hr] has joined #ubuntu-kernel === marcin_ant [n=marcin@194.114.146.126] has joined #ubuntu-kernel