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