[00:09] <pwnguin> mermaidman: thats nice, but from wikipedia: The file system is currently marked as developmental and is titled "ext4dev".[5] It is considered unstable and so is not recommended for use in production environments, since data corruption is possible in this early stage of development."
[00:09] <pwnguin> im kinda thinking anyone interested in ext4 outta learn how to build kernels anyways
[00:10] <mermaidman> pwnguin: Umm you have to add some special test_fs code to ext3 in order to mount ext4 which the ubuntu devs dont understand
[00:12] <pwnguin> mermaidman: when you say "dont understand"
[00:12] <pwnguin> is there specific evidence?
[00:12] <mermaidman> they never respond to all my suggestions
[00:12] <pwnguin> im not sure those are equivilent
[00:13] <pwnguin> where can i read these suggestions?
[00:13] <mermaidman> forums
[00:13] <pwnguin> oh well duh
[00:14] <pwnguin> you'd get more attention from IRC or the mailing list
[00:14] <mermaidman> http://ubuntuforums.org/showthread.php?t=837589
[00:14] <mermaidman> went there to still no answer
[00:14] <pwnguin> on -kernel?
[00:15] <mermaidman> yup
[00:15] <pwnguin> gotta grab dinner
[00:15] <pwnguin> but i'll check the archive
[00:17] <pwnguin> john nelson?
[00:18] <mermaidman> yeah
[00:19] <pwnguin> We need to talk about effective writing 
[00:21] <mermaidman> i was in a rush that day
[00:21] <pwnguin> https://lists.ubuntu.com/archives/kernel-team/2008-July/002793.html
[00:21] <pwnguin> well, then the little time you did spend was wasted =/
[00:22] <mermaidman> Since i have all the time of the night I will write another one right now
[00:22] <pwnguin> if you communicate intelligently, you may find people are more willing to talk with you
[00:24] <pwnguin> but I believe there's also some structural bias
[00:24] <pwnguin> from what ive seen many in the kernel team are paid canonical employees who work 9-5
[00:24] <mermaidman> just sent it its in the moderation queue now
[00:25] <pwnguin> being the weekend, there's probably a bit less attention to go around, if you know what i mean
[00:25] <mermaidman> Yeah
[00:29] <pwnguin> well pizza time
[00:29] <mermaidman> cool
[00:49] <pwnguin> you know what, if ted doesn't think it's ready, i don't think we should bother enabling it
[00:50] <mermaidman> ted Tso?
[00:50] <pwnguin> yes
[00:53] <mermaidman> finally finshed the annoying fsck on ext3
[17:16] <benje> hi there a bug in the se401 driver i get this [ 3335.080589] se401: probe of 3-1:1.0 failed with error -5
[17:16] <benje>  with a kensington webcam Bus 003 Device 004: ID 047d:5001 Kensington 
[17:16] <benje> under hardy 
[17:17] <sn9> benje: you're sure it's not bug 88746?
[17:18] <sn9> !bug 88746
[17:18] <sn9> where's ubottu?
[17:18] <benje> i go to see i just searching there
[17:19] <benje> shure sn9 it's about ehci but it using usb 3-1: new full speed USB device using uhci_hcd and address 4
[17:20] <sn9> any hub involved?
[17:20] <benje> since a long time this webcam not working 
[17:20] <benje> no directly on face pc (dell 1800)
[17:20] <sn9> ok...
[17:20] <benje> it was working a day
[17:21] <benje> do you want full dmesg ?
[17:22] <benje> sn9, http://pastebin.com/m3d7c3f1e
[17:24] <sn9> 404
[17:25] <benje> sn9, :/
[17:25] <benje> this is working for me 
[17:25] <benje> sn9, do you have an other paste 
[17:25] <benje> prefered 
[17:26] <sn9> i probably won't learn anything from it, anyway
[17:26] <benje> yes nothing particular 
[17:26] <benje> detect w"ebcam firware format 
[17:26] <benje> but [ 3335.080563] /build/buildd/linux-2.6.24/drivers/media/video/se401.c: Bayer format not supported!
[17:28] <benje> the light at webcam stay lighting
[17:29] <benje> sn9, what is it need for post bug about this ? i have even post bug 
[17:29] <sn9> have you looked at upstream info about the driver?
[17:29] <benje> but what will be usefull
[17:30] <benje> there a patch for version http://members.chello.nl/~j.vreeken/se401/
[17:31] <benje> but only for epcam
[17:31] <benje> it's now in kernel tree
[17:31] <benje> no sn9 
[17:31] <sn9> do you know whether this works in later kernels?
[17:31] <benje> sn9, here http://cateee.net/lkddb/web-lkddb/USB_SE401.html .
[17:32] <benje> no i don't know 
[17:32] <benje> this was working in dapper and edgy at start
[17:32] <benje> at bigining
[17:32] <benje> begining
[17:33] <benje> but she is in all list as working :/
[17:33] <benje> http://lxr.linux.no/linux/Documentation/video4linux/se401.txt
[17:35] <sn9> so, it's a regression?
[17:35] <benje> yes 
[17:36] <benje> it 's avery old webcam doesn't work in xp 
[17:36] <benje> ;)
[17:37] <benje> no driver but it always working under linux
[17:37] <benje> sn9, where can i find upstream of ubuntu ? 
[17:39] <sn9> if the driver is in the mainline kernel tree, the upstream is often the mainline kernel itself, unless patches are applied
[17:39] <sn9> ubuntu maintains local kernel trees for each version on kernel.org, too
[17:40] <benje> ok
[17:40] <benje> i haven't try with an other distrib 
[17:40] <benje> i try under debian etch 
[17:41] <sn9> under debian, you may need to use module-assistant
[17:41] <benje> same error
[17:42] <benje> :/
[17:43] <benje> not needed ;) 
[17:43] <benje> thanks sn9 
[17:43] <benje> sn9, do you know what is the problem ? 
[17:44] <benje> or seems 
[17:44] <sn9> it sounds like the upstream driver might be broken
[17:46] <benje> ok thanks sn9 i will post bug or do you think it s not necessary 
[17:46] <sn9> search for existing bug reports first
[17:47] <benje> i found nothing about se401 and kensington webcam
[17:48] <sn9> no se401 bugs at all? file it, then
[17:49] <benje> no, oki 
[17:49] <benje> no now i discution with friend but i will ;)
[18:27] <benje> thanks and bye 
[21:07] <DHR> I reported this problem a few days ago.  IOCTL interface to MTRRs appears broken in 8.04.1.  Thoughts?  https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/253204
[21:54] <pwnguin> who moderates mail to ubuntu-kernel?
[21:56] <sn9> it should say at the bottom of the listinfo page for that list
[21:57] <BenC> pwnguin: rtg does
[21:57] <BenC> DHR: looking at it now
[21:58] <pwnguin> ok thanks; a guy came by yesterday asking about ext4 and he said it was waiting moderation approval
[21:58] <pwnguin> probably it'll be taken care of on monday
[21:58] <pwnguin> a bit unfortunate for our weekend hackers
[21:59] <DHR> BenC: thanks!
[22:00] <BenC> DHR: it seems to be specific to the system, so the fact that it works on fedora9 is misleading
[22:01] <DHR> BenC: in what sense is it specific?
[22:01] <BenC> DHR: on my laptop, it prints all of them, but on my 8-way Core2 box, it only prints the first two
[22:02] <BenC> and they are running the exact same kernel
[22:02] <DHR> OK.
[22:03] <BenC> my laptop has 4 registers enabled, and it prints all 4...the workstation has 3 registers and it only prints the first 2
[22:03] <DHR> There seem to be some problems with MTRRs on Intel systems with >4G.  
[22:03] <BenC> Nope
[22:03] <BenC> neither of these has > 4G
[22:03] <DHR> Sorry: not *this* problem, but it is the reason I care about MTRRs.
[22:03] <BenC> Ah
[22:04] <DHR> Some BIOSes set MTRRs with overlapping ranges.  X drivers cannot then change their frame buffer to Write Combining.
[22:04] <DHR> So: I wanted to write a C program to eliminate overlapping ranges.
[22:06] <BenC> isn't that something you can do in your BIOS?
[22:06] <DHR> There is a kernel patch to do this.  I'm trying to understand the code (right now).  I'm not convinced it is great code.
[22:06] <DHR> No, I cannot write a new BIOS easily :-)
[22:06] <BenC> No, I mean you can set it in your BIOS config :P
[22:07] <DHR> no.  Not normally.  The usual work-around is to remove memory!
[22:08] <DHR> You can also hack away with echos to /proc/mtrr.  I thought ioctl interface would be cleaner.  But it is broken, I think.
[22:10] <DHR> kernel patch as discussed on LKML: http://kerneltrap.org/mailarchive/linux-kernel/2008/5/1/1686464
[22:11] <DHR> example of the problems caused by overlapping MTRRs: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/224404
[22:13] <DHR> BenC: since you have observed to problem with the ioctl interface too, could you add to https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/253204
[22:17] <BenC> DHR: ...
[22:17] <BenC>                 /* Hide entries that go above 4GB */
[22:17] <BenC>                 if (gentry.base + size - 1 >= (1UL << (8 * sizeof(gentry.size) - PAGE_SHIFT))
[22:17] <BenC>                     || size >= (1UL << (8 * sizeof(gentry.size) - PAGE_SHIFT)))
[22:17] <BenC>                         gentry.base = gentry.size = gentry.type = 0;
[22:17] <BenC> that's from the MTRRIOC_GET_ENTRY code in the kernel
[22:18] <DHR> interesting!
[22:18] <BenC> So it has nothing to do with > 4G of memory, just mapped to > 4G
[22:18] <DHR> what file is that in?
[22:18] <BenC> and sure enough, but 3rd entry on the workstation is mapped at 4G
[22:18] <BenC> arch/x86/kernel/cpu/mtrr/if.c
[22:19] <BenC> s/but/my/
[22:19] <DHR> Why would that be the correct thing to do?  Especialy on amd64 (which I'm on)?
[22:20] <mjg59> What's the size of the field in the structure that the address gets returned in?
[22:21] <BenC> mjg59: ah, it's unsigned int
[22:21] <DHR> "unsigned int size"
[22:21] <BenC> that's pretty stupid
[22:22] <mjg59> Yeah, so ABI concerns
[22:22] <BenC> well, that still shouldn't be a problem...the base is unsigned long, so it should still be able to print up to 4G size
[22:23] <mjg59> Probably best to add a new ioctl...
[22:23] <mjg59> (nngh ioctls)
[22:23] <BenC> yeah, best to just shove it in /sys somewhere and add something to X to use that
[22:23] <DHR> if you look at /usr/include/asm/mtrr.h, i386 differs from amd64.  So no excuse.
[22:24] <BenC> ioctl's are just ugly anyway, I don't blame them for not fixing it by now
[22:25] <BenC> plus they are working on something better for X to use, so focus is probably there
[22:25] <DHR>  /proc is ugly too: race conditions and all.
[22:27] <mjg59> You probably want to be using PAT on newer systems anyway
[22:28] <BenC> right, PAT is what I was thinking of
[22:29] <DHR> if the IOCTL cannot return the correct value, it ought to return an error.
[22:31] <DHR> EOVERFLOW       Value too large to be stored in data type (POSIX.1) ??
[22:32] <DHR> ERANGE          Result too large (POSIX.1, C99) ??
[22:34] <DHR> is a size >= 4G legal on i386?  It could well be, given PAE.