[04:22] <owh> 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] <owh> 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] <owh> 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] <owh> 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] <mjg59> BenC:      - pata_oldpiix: Stable, allows us to disable piix.ko IDE module.
[04:42] <mjg59> BenC: Does that mean you've added IDs back to ata_piix that had been taken out previously?
[04:42] <mjg59> I'd noticed a couple vanish
[04:43] <BenC> yes
[04:43] <BenC> I had shifted some back to piix because ata_piix was getting some weird errors
[04:55] <owh> Am I asking too much, in the wrong channel, at the wrong time?
[05:14] <lifeless> owh: well, this is the ubuntu-specific kernel channel
[05:15] <lifeless> owh: I'm not sure that the folk here know the answers offhand. Though they may.
[05:15] <lifeless> BenC: any comment on owh's thing ?
[05:16] <BenC> no idea
[05:16] <lifeless> owh: there you go. :)
[05:19] <owh> lifeless: Any suggestions where to ask?
[05:25] <owh> 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.
[05:27] <owh> 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] <owh> How do I get this issue in front of the appropriate eye balls?
[06:09] <fabbione> morning guys
[06:09] <fabbione> BenC: you still awake?
[06:22] <owh> 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] <owh> Do I bring it here and show it like a cat comes into your home with it's catch for the night?
[06:28] <fabbione> owh: make a patch first :) then post it to kernel-team@lists.ubuntu.com for review
[06:28] <fabbione> if the patch is good it will eventually land in Linus tree
[06:29] <owh> 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] <fabbione> owh: you are only fighting against different people living in different TimeZones
[06:31] <fabbione> you can start complaining only after 48 hours of nobody answering (excluding the weekend ;))
[06:31] <owh> :)
[01:09] <raffytaffy> i have i915 chipset - ditching all the i810 and ati/amd stuff is safe correct?
[01:15] <Mithrandir> I wouldn't drop the i810 stuff, no
[01:27] <raffytaffy> ok thanks
[01:28] <raffytaffy> for character devices - ( im using nvidia go 6600) i dropped ATI and AMD, seems safe. i kept nvidia nforce/geforce
[01:32] <raffytaffy> im trying to configure my kernel to be minimal.
[03:34] <mjg59> BenC: There's a missing ! in the check for acpidata in ata_acpi_push_id
[03:34] <mjg59> Sorry about that
[03:35] <BenC> mjg59: Yes, we caught that :)
[03:35] <mjg59> Excellent
[03:35] <BenC> Tim is moving the check for !acpidata to skip_acpi_operation()
[03:36] <Mithrandir> BenC: did you see my question about whether we can include kqemu in feisty?
[03:36] <mjg59> BenC: As long as he's arranging the order of checks so that doesn't dereference a null, that's fine
[03:36] <BenC> 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] <mjg59> BenC: do_drive_get_GTF is exported
[03:37] <mjg59> Oh, sorry, no it's not
[03:37] <mjg59> I was thinking of GTM
[03:37] <mjg59> Yeah, in that case it can probably go
[03:39] <fabbione> BenC: i committed the fixes to OCFS2 local mount.. 3 small patches.. no ABI change
[03:39] <fabbione> BenC: we need to get those in feisty before relase
[03:52] <BenC> 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] <BenC> fabbione: We have an ABI bump anyway...thanks for the merges
[03:53] <Mithrandir> BenC: ok, cool.  It was more of a "would it make sense" than "please do asap".
[03:53] <BenC> Mithrandir: I'd like to have it in there...the more virt stuff we have the better
[03:53] <Mithrandir> BenC: it seems that the problem with the live cd not working in qemu is limited to amd64; i386 works fine.
[03:54] <zul> BenC: I can look at the kqemu stuff if you want
[03:54] <BenC> Mithrandir: I heard there's problem with amd64 under vmware too...guess I need to check on that today
[03:54] <BenC> zul: Yes, please
[03:54] <Mithrandir> zul: it should be easy enough; the module builds fine as is, so it's just build-system integration.
[03:54] <zul> Mithrandir: sure no problem
[03:54] <Mithrandir> BenC: great, thanks.  If you want bugs about this, then tell me.
[03:56] <mjg59> BenC: I'm still trying to track down the HPA issue
[03:56] <mjg59> That's basically a blocker to release
[03:56] <BenC> 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] <kylem> mjg59, it doesn't work with piix or ahci, does it
[03:57] <mjg59> Seems fine with ahci
[03:57] <mjg59> Breaks on ata_piix on Apple hardware
[03:58] <kylem> can i get an lspci -vvnn from your MBP?
[03:58] <mjg59> Not right this second, but what are you looking for?
[03:58] <mjg59> The controller is 8086:27c4
[03:58] <mjg59> And it comes up with an IDE class, not an AHCI one
[03:58] <kylem> right.
[03:58] <kylem> that's fixable though.
[03:58] <kylem> ;-)
[03:58] <mjg59> Subdevice code is an Intel one, not an Apple one
[03:58] <mjg59> Otherwise it'd be really easy
[03:59] <mjg59> So, yeah, one fix would be to bodge it over to ahci
[03:59] <mjg59> And hope that we're only going to hit the issue on Apples
[03:59] <mjg59> 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] <kylem> gnrrr.
[04:00] <kylem> i was hoping i could just install a pci quirk and check the dmi table for Apple
[04:00] <mjg59> That ought to be fine
[04:01] <mjg59> But the device ID is still present in ata_piix, so both will be loaded
[04:01] <mjg59> And I don't think we have guarantees about which will bind first
[04:02] <mjg59> 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] <kylem> argh.
[04:03] <fabbione> BenC: ok ..
[04:04] <kylem> mjg59, i think my ich8 changes the devid too.
[04:04] <mjg59> kylem: Really? Wow. ich6 and ich7 don't.
[04:04] <kylem> 1sec whiel i rboot
[04:04] <mjg59> Ok
[04:05] <kylem> 00:1f.2 IDE interface: Intel Corporation Mobile SATA IDE Controller (rev 03)
[04:05] <kylem> turns into blah blah AHCI, and sets the prog-if doodly
[04:07] <mjg59> And the device ID?
[04:07] <kylem> well, if the string changed, it's different, i didn't bother to save it
[04:08] <mjg59> Which bit of the string changed? Just the "IDE interface" to "AHCI interface"?
[04:08] <mjg59> If so, surely that's just because the class ID changed?
[04:08] <kylem> no
[04:08] <kylem> the device id.
[04:08] <kylem> *AND* the class id
[04:08] <kylem> 00:1f.2 SATA controller: Intel Corporation Mobile SATA AHCI Controller (rev 03)
[04:09] <mjg59> Ah, got you
[04:09] <mjg59> Yeah, in that case it seems to change
[04:09] <kylem> this is what all implementations *should* do.
[04:09] <mjg59> That doesn't seem to be the case for ICH7 and ICH6
[04:10] <kylem> since rarely do we match on classid.
[04:10] <mjg59> That's why ahci and ata_piix share a load of device IDs
[04:11] <kylem> have i mentioned how much i hate BIOS writers today?
[04:11] <mjg59> Not helped by the fact that ata_piix will deliberately try to reprogram your ahci hardware back to piix mode
[04:11] <mjg59> ahci has the class ID in it now
[04:12] <kylem> will to-be-driven-by-piix devices always be 0x0101?
[04:12] <mjg59> Should be
[04:12] <kylem> hmm. ok.
[04:43] <BenC> zul: You interested in doing a openvz package like the xen one for feisty universe?
[04:43] <BenC> 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] <zul> BenC: sure
[04:44] <zul> whats one more 
[04:44] <BenC> What's your preferred email?
[04:44] <zul> gmail account
[04:46] <BenC> zul: Sent
[04:46] <zul> BenC: thanks
[04:46] <BenC> zul: No, thank you :)
[04:46] <zul> BenC: no thank you
[04:46] <zul> I can do this all day
[04:46] <BenC> hehe
[04:49] <shawarma> Any idea when the kernel in the ubuntu-server daily images will be updated? 
[04:49] <shawarma> 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] <shawarma> ...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] <shawarma> Er.. Not unable to boot, but unable to access either emulated hard drive or cd-rom.
[04:52] <zul> BenC: depending on what happens with liam I can probably get it done this weekend
[04:52] <BenC> zul: sounds good
[04:53] <shawarma> BenC: ^^
[04:54] <BenC> shawarma: what kernel is on that CD?
[04:54] <shawarma> 2.6.20-12-generic
[04:55] <shawarma> BenC: uname -v says:"Linux (none) 2.6.20-12-generic #2 SMPWed Mar 21 20:55:46 UTC 2007 i686 unknown"
[04:56] <BenC> shawarma: Guess it has to wait on debian-installer being rebuilt with the latest kernel
[04:56] <shawarma> BenC: That's it?I think I saw a new d-i on feisty-changes earlier today..
[04:57] <shawarma> BenC: That would put it on the daily image for today?
[04:58] <BenC> either today or tomorrow
[04:58] <shawarma> BenC: Apparantly so. The changelog even says:"* No-change rebuild to pick up new components."
[04:58] <shawarma> :-)
[04:58] <shawarma> I didnt' make the connection for some reason. 
[04:59] <shawarma> BenC: Great. Thanks for clarifying.
[05:01] <zul> BenC: http://www.linuxsymposium.org/2007/view_abstract.php?content_key=110
[05:03] <BenC> zul: whack
[05:03] <shawarma> zul: Is that a Xen hypervisor as a module?
[05:03] <zul> shawarma: i think so I havent read the paper yet 
[05:03] <shawarma> zul: Interesting. 
[05:04] <shawarma> zul: Well... if you have the appropriate hardware, that is. :-(
[06:48] <Lure> BenC: is current kernel in git in flux? it oops-es on boot here in ata code (scsi_error_handler)...
[06:52] <BenC> should be fixed now
[06:53] <BenC> git is always in flux
[06:56] <Lure> BenC: ok, expected
[07:19] <Mithrandir> BenC: could you take a look at 91009 and tell me what you think?
[07:21] <BenC> 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] <BenC> I can't revert the kernel stack back, else we risk breaking dozens of drivers
[07:22] <Mithrandir> gnr, ok.
[07:23] <Mithrandir> oh well, let's go for it then.
[07:39] <bdmurray> Is there any documentation about kernel hdX: command errors?
[08:13] <cr3> 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] <BenC> cr3: let me check
[08:16] <BenC> cr3: More dmesg might help
[08:17] <cr3> BenC: shall I attach it to the same bug or to another bug?
[08:17] <BenC> same one
[08:18] <cr3> 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] <BenC> cr3: Ok, then lspci -vvn output too please
[08:18] <BenC> compare notes
[08:28] <cr3> BenC: done
[08:29] <BenC> cr3: thanks