[01:13] Wow, new upstream merged two days before kernel freeze. === NCommander is now known as NC|G1 === NC|G1 is now known as NCommander === dschulz is now known as Broccoli === Broccoli is now known as dschulz === Whoopie_ is now known as Whoopie [04:52] What's the difference between Ubuntu-2.6.31-14.46 and Ubuntu-2.6.31-302.7 ? [04:54] obviously the numbers - I'm just curious what the really high numbers are used for [06:56] does anyone here maintain submit fixes to upstream for the gspca v4l2 modules? [06:57] maintain/submit [06:57] rather :P [06:57] I tried to build a package and when I did "make install" I got this error. I'm wondering what's missing in the kernel to make it work. "include/linux/autoconf.h or include/config/auto.conf are missing." [06:57] just wondering how i go about getting my webcam to work, it hasn't worked throughout the whole 2.6.31 kernel development, and i was hoping by now that it might have been fixed [07:00] do those files exist in your kernel source directory? [07:07] me? [07:07] ya [07:07] they do [07:11] billybigrigger: do you know ho to find out what option compiles the files? [07:11] no [07:11] haven't done any compiling for months [07:11] I'm shooting for a 2.5MB kernel [07:11] since A2 :P [07:11] oh [07:11] hehe [07:46] 12min to dload vbox - hurray crappy internet [08:24] I got the kernel source package to build and boot patched with both the bfs cpu scheduler and the bfq i/o scheduler. [11:56] hi guys, member of bug control here, there is a bug 425756 in the Ubuntu kernel which affects the SB6/700 sata controller with an ata soft lockup, there seems to be a patch at http://kerneltrap.org/mailarchive/git-commits-head/2008/6/14/2122314 does this look any good, and is there any chance we can get it in? :) [11:56] Malone bug 425756 in linux "[Karmic] cd/dvd drive not detected ." [Undecided,New] https://launchpad.net/bugs/425756 === L is now known as L_X_ === L_X_ is now known as L === L is now known as Guest39426 === Guest39426 is now known as L_X_ [11:58] hi there! I have a little trouble installing the backports-modules [11:58] !ubuntu [11:58] Ubuntu is a complete Linux-based operating system, freely available with both community and professional support. It is developed by a large community and we invite you to participate too! - Also see http://www.ubuntu.com [11:58] oops [11:58] L_X_, the place for help and asking questions is #ubuntu this is the kernel teams IRC chatroom :) [11:59] only in launchpad (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/445931) it says to ask the question here... maybe you should clarify... [11:59] Malone bug 445931 in linux "linux-backports-modules-karmic not installable, dependency problem" [Undecided,New] [11:59] * L_X_ is heading to [11:59] * L_X_ is heading to #ubuntu [11:59] cya [12:01] Kernel Team: Sorry to be a pain, but I'd appreciate if you could look at that patch if/when you're not busy bug 425756 with patch :) [12:01] Malone bug 425756 in linux "[Karmic] cd/dvd drive not detected ." [Undecided,New] https://launchpad.net/bugs/425756 [12:01] and thank you [12:40] In hotplugging, a bus probe occurs after which a matching driver probes a device. The driver is chosen based on the device id and the vendor id. [12:40] Is this understanding right ? [12:41] Or does a bus driver probe for every device (without looking at the device id) ? === TheMuso` is now known as TheMus === TheMus is now known as TheMuso [13:09] csurbhi, It is add devid,vendorid based. When a new device appears it will register to a bus and each driver already registered with that bus will get its probe function called with the device id until one driver claims it or no more drivers are present. As there s an add event for the device udev can match that id of the device with alias strings of drivers and load one if one is found which is not already present. New drivers registering ag [13:09] ain get their probe function called with every device on the bus, which is not yet claimed. [13:13] ok [13:14] but is not /lib/modules/modules.alias looked at to modprobe a particular driver? [13:15] right, that file is generated from the information in the modules when you run depmod [13:15] i thought that the bus looks at the vendor id and the product id and then looks at the modules.alias and then appropriately that driver module gets inserted [13:15] the bus (from the kernel) does nothing here. It is udev that loads modules [13:16] if you insert a device, this jsut generates an add event and causes currently loaded drivers to be called [13:17] but what happens if a driver (compiled as a module) for a device is not yet loaded [13:17] if you do a modinfo on a driver you will notice alias strings, these are used to make the modules.alias file and that is used by udev to match an add event on a bus with a driver [13:18] right..so who generates the event on the bus [13:18] what bus? [13:18] because that event should have the device id and the vendor id [13:19] when you add a device an event is generated. on a bus ? so who generates that ? [13:19] I would call it the bus subsystem (not sure this is the correct term) [13:20] when new devices are detected, the subsystem driver creates stub kernel objects for them [13:20] yes.. thats why i said that the bus might look at the device id and the vendor id [13:20] ok.. but i get it [13:20] .. [13:20] the properties of those kernel objects include things like their port id, and any bus-specific information like vendor id, device id, etc. [13:21] driver core creates entries in the /sys filesystem for these [13:21] and it sends a message on a special netlink socket announcing the new device [13:21] it then *also* runs its internal match table against built-in and already loaded modules [13:21] yes.. and then udev gets this message looks at the module.alias and modprobes the device driver [13:21] :) [13:21] and those modules may claim the device (in which case they take over the kernel object and begin added more details, like interfaces and device nodes) [13:22] udev receives this message [13:22] inside this message is a "modalias" string [13:22] this is a single string made up of the important kernel object information [13:22] the format of the string is generally : [13:22] so for example, a PCI subsystem modalias would look like [13:22] pci:v00001180d00000843sv00001028sd00000209bc08sc80i00 [13:22] while a USB subsystem modalias looks like [13:23] usb:v413Cp8126d0367dcE0dsc01dp01icE0isc01ip01 [13:23] as you can probably tell, inside that is the vendor id, device id, etc. [13:23] modules themselves have match tables which are used in the kernel to match against a module [13:23] from these wildcard modalias strings are generated [13:24] ok [13:24] these have the "any of these" bits of the string replaced by * [13:24] and you can see these by running modinfo on a module [13:24] # modinfo ricoh_mmc | grep alias [13:24] alias: pci:v00001180d00000843sv*sd*bc*sc*i* [13:24] two questions 1) at boot time, how is a bus driver claimed ? [13:24] so whenever it receives a netlink message with a modalias in it, udev calls "modprobe $MODALIAS" [13:25] modprobe matches the string against the known module names, and known module aliases [13:25] using wildcard matching [13:25] and thus you end up with a particular driver loaded [13:25] as this driver loads, its _init() function will bind it in-kernel to any kobjects [13:25] and since it's loaded, any new devices it claims will be bound in-kernel too [13:25] that's it ;) [13:26] csurbhi: I have answered that question above [13:26] so by this logic a driver should be invoked only when a device id is registered in it [13:26] yes [13:26] if a device id is not registered it should not be called [13:26] I don't know what you mean by "called" [13:27] called = invoked [13:27] a driver is not bound to a device that it hasn't claimed [13:27] I don't know what you mean by "invoked" [13:27] drivers aren't called or invoked, they claim devices [13:27] the devices become bound to the driver [13:27] but a modalias of a driver will have a device id and a vendor id [13:28] csurbhi: not necessarily [13:28] it's quite valid to have a modalias wildcard match that matches all devices [13:28] pci:* [13:28] that would be a driver that can claim any pci device [13:28] (for example) [13:28] ok [13:28] that'd be bad though, only one driver can claim any one device [13:28] there are drivers that match entire device class or interface classes though [13:28] but then what is the point of this: [13:28] usb-storage for example [13:29] alias: usb:v*p*d*dc*dsc*dp*ic08isc06ip50* [13:29] less 2.6.28-15-generic/modules.alias | grep sdhci [13:29] alias pci:v*d*sv*sd*bc08sc05i* sdhci_pci [13:29] yes.. exactly [13:29] csurbhi: exactly my point [13:29] have a v*d* ? [13:29] why have that ? [13:29] any vendor's device, that has a PCI base class of 08 and subclass of 05 [13:30] could there be a clash ? when another driver for eg: says bc*sc* [13:30] and one driver says v*d* [13:30] had to look that up [13:30] and some eejit has moved pci.ids [13:30] PCI class 08 is "Generic system peripheral" [13:30] subclass 05 is "SD Host controller" [13:31] hmmm...thanks a lot :) [13:31] so you have a case there where there is a generic kernel driver for that entire device class [13:31] that helped me a lot.. :) [13:31] that's actually a Linux tendancy [13:31] now i get it [13:31] if you can do away with a driver-per-device and instead have generic drivers that deal with the special cases through quirks, that's a big WIN! [13:32] yes, you're quite right that if you added another driver that matched the same device (e.g. by vendor/device id) they would clash [13:32] both would be able to claim the device [13:32] in which case there are rules about which one wins [13:32] (look at the modules.order file :p) [13:32] i can see a sdhci-pci driver getting called and failing and then another driver getting called.. and i was wondering why the sdhci-pci was getting called.. i can now see why ! [13:32] a driver is quite permitted to decline a device [13:33] "oh, I don't know about *this* one" [13:33] ok [13:33] in which case, the next driver in line can have a go [13:33] yess [13:33] now i get it :) thanks a lot !! [13:33] one more question [13:33] i also read somewhere [13:33] the Windows developers hate this [13:33] that hotplugging could be scpi intermediated [13:33] :) [13:33] gregkh gave a wonderful presentation at a devcon about Linux driver core [13:33] and the windows people were sitting with dropped jaws [13:34] :D [13:34] they have nothing as simple and elegant as this ;) [13:34] :) [13:34] boy !!! thanks a lot!!!! [13:34] csurbhi: I'm not sure how scpi applies in this question? [13:34] did you mean acpi? [13:34] i not get the whole thing !! i took a great deal of time looking at why ricoh_mmc was getting called after a sdhci-pci driver [13:34] now i get it completely !!! wow ! [13:35] yes.. i meant acpi [13:35] oh wow that was a totally freaky guess [13:35] I picked ricoh_mmc simply because it was the last thing with a pci modalias in my udev log ;) [13:35] heehee [13:35] right [13:35] ACPI is a whole world of pain [13:35] so can u pleaee tell me how this thing works [13:35] when acpi mediates ? [13:36] everything I am about to say is a lie [13:36] i believe u [13:36] :P [13:36] but it's a lie that explains how things work [13:36] ACPI is a system that allows your computer to have software that is executed by the kernel [13:36] when the kernel needs to do something (e.g. enumerate the PCI bus), it actually runs this special software [13:36] this special software is run on a virtual machine that Linux implements [13:37] and produces the results the kernel expects [13:37] this can also deal with interrupt handlers, and so forth [13:37] the side-effects of running this software ideally include programming chips on the board to do the right things [13:37] that way the kernel doesn't need to know how to program the MMC [13:37] or PCI controller [13:37] the motherboard can know that [13:37] so cool [13:37] but the motherboard doesn't need an operating system on it [13:38] so the kernel executes code on the motherboard's behalf [13:38] so on boot, the kernel will begin executing the acpi code [13:38] this will result in the hardware being programmed correctly [13:38] linux arranges (through standard acpi methods) for pci hotplugging to be enabled [13:39] this may require, for example, that when a card is hotplugged that further acpi methods are invoked to communicate with the pci controller and find out what happens [13:39] but this results in Linux's registers being updated [13:39] so it can know what cards were added/removed [13:39] and can arrange for the new card to be initialised [13:39] or resources of the old card to be freed [13:39] etc. [13:39] ok [13:40] so when its not acpi mediated, the pci subsystem gets the interrupt when a device is added [13:40] whereas when it is acpi initiated, acpi gets the interrupt [13:40] no, it's still all done with interrupts the old fashioned way [13:40] the difference is that when not using acpi, Linux has to do the leg work to talk to the pci controller [13:41] and has to know every detail about your pci controller [13:41] whereas with acpi, that is somewhat abstracted [13:41] ok [13:41] and one last question [13:41] the modules.order [13:41] who creates that and based on what ? [13:42] the kernel build system creates that [13:42] based on the order that modules are listed in its Makefiles [13:42] ok [13:42] :) [13:42] this is the same order that the code would be statically linked into the kernel if they were all built-in [13:42] ok [13:42] thanks a lottt [13:43] that was veryy insightful [13:44] hello, is the generic kernel built with PAE enabled ? [13:46] oh, its linux-image-2.6.31-14-generic-pae === bjf-afk is now known as bjf [15:54] amitk, bjf, all new shiney arm kernels of both types are in the archive [15:55] lool, i belive you should find a good linux-libc-dev for armel in the archive now [15:56] [Bug 447791] [15:56] Malone bug 447791 in linux "after update to 2.6.31-13,the virtual Console Huap" [Undecided,New] https://launchpad.net/bugs/447791 [15:57] hi team, could I ask which package should we exactly file bug against for this bug? ^^^ [15:57] apw, thanks, looks like I might have a regression on mvl [15:58] bug 450940 [15:58] Malone bug 450940 in linux-mvl-dove "Regression in linux-mvl-dove 207 and later causes Y0 boards to hang seconds after booting" [High,Confirmed] https://launchpad.net/bugs/450940 [15:58] apw: Thanks [15:58] apw: I did see the build output the package at least [15:59] bjf, hrm, is that your new fix or something in the rebase do we think [15:59] apw, I've not touched dove other than that config issue, possible rebase / stable updates fallout, not sure [16:00] hrm yes it was a simple config change. then again the rebase shouldn't have changed much core it was mostly stable updates and that was pretty limited [16:01] and cirtainy nothing on the mvl-dove boot i'd think [16:07] Too bad we cant bisect it -- exactly what was to be solved by rebasing the tree :-) [16:07] we could cherry pick stable updates on top of the previous mvl tag and see how long it works [16:14] Did you guys know that rolling your own kernel can be heap load if fun and irritation :) [16:25] rtg: got one for you [16:25] ext4 doesn't seem to be syncing data on shutdown or SysRq-S [16:25] an explicit sync() does seem to work [16:26] Keybuk, that seems more like one for Ted [16:27] did I break something? [16:27] well, it's causing me at the moment to fail to boot after upgrading the kernel ;) [16:27] because the initramfs is trunctated [16:28] Keybuk, ick! [16:28] Keybuk, so, we don't normally sync() on shutdown or reboot? it should sync on unmount. [16:28] we don't call sync() no [16:29] the kernel should do that [16:30] Keybuk, does rootfs get unmounted before shutdown? I'd think it couldn't as long as /sbin/init was alive. [16:30] yes [16:30] so that should sync [16:32] of course, now that I look at it, I can't find that sync [16:32] maybe ext4 doesn't sync the filesystem on remount readonly now? [16:33] hell if I know [16:33] its hard to imagine that an issue this systemic would not have been noticed already [16:35] doesn't look like it does now [16:36] Keybuk, drat, lemme wrap up LBM. are you gonna file a bug? this seems like a show stopper. [16:36] the kernel comment for reboot() says you should sync() first [16:37] how can remount readonly _not_ sync first? especially if there are not outstanding I/O errors. [16:38] it just doesn't [16:38] ext3 clearly does [16:38] ext4 clearly does not [16:38] this looks like a change in ext4 relatively close to .31 [16:39] Keybuk, well, we should confirm this with Ted [16:39] I'm going to put the sync() call back into reboot anyway [16:39] it's probably for the best [16:39] Keybuk, do shutdown and reboot go through the same path at some point? [16:39] yes [16:39] app sapce or kernel? [16:40] app space [16:40] kernel is quite different [16:40] I haven't looked at the shutdown path in the kernel since 2.4 days [16:44] let's see if this fixes it [16:45] Keybuk, so how did you notice, ext4 always dirty on reboot? [16:46] that seemed better [16:46] will probably need to do a few of those to be sure [16:46] Keybuk, so how did you notice, ext4 always dirty on reboot? [16:46] apw, I'm wondering if this might have something to do with the KVM folks complaining about fsck on boot === Keybuk_ is now known as Keybuk [16:46] rtg very likely ... [16:46] i am supprised noone noticed before, like you or me [16:46] apw: no, truncated files or empty files after reboot [16:47] Keybuk, I must update kernels several times a day on different machines. [16:47] but there was an article on lwn about truncation of files for ext4 [16:47] yeah, but depends how much gets flushed to disk [16:47] speed of reboot [16:47] etc. [16:47] reboot here is fast, I'm on SSD, but it's *ahem* not production [16:48] Keybuk, i note my main lappy is still ext3, but my 10v is ext4 and i've not seen it there [16:48] it seems that it does a sync only after a timeout and before that if you reboot or shutdown, u can loose data [16:48] but its likely i am idle for ages before reboot often [16:48] http://lwn.net/Articles/322823/ [16:48] apw: I've been doing a lot of "update-initramfs -u ; reboot" in the last 24 hours [16:48] and that's when I've noticed it [16:49] oh is this the cause of your bust initramfs you mentioned ... hrm [16:50] possible [16:50] anyway, comment in the kernel above the definition of reboot() says you must call sync() first [16:50] so I call sync() first :p [16:50] it sure can't hurt [16:58] Keybuk, i wonder what use there is to not sync and hit reboot ... [17:02] apw: speeeeed [17:03] Keybuk, speedily losing my data, yay [17:04] bjf, did you say your y0 was ok on that kernel? [17:04] apw, so far so good [17:04] bjf, so panic 'less' [17:05] apw, because it's Y0 and now Y1 I panic 'less' [17:06] bjf, basically it works on all your h/w ? [17:06] apw, it works on my Y0 and lool's Y1 [17:06] apw, I've not had a chance to test my Y1 [17:07] apw, these are not fat machines to install onto [17:07] no i guess not [17:07] *fat*fast [17:08] * apw didn't even see that [17:08] bjf: so you coulduse yesterday;s image to install and then upgrade to today's kernel? [17:08] lool, yup, doing that [17:11] How can I find out if I have any EFI firmware? [17:14] MTecknology, unless you are running a recent server, then you likely _don't_ have EFI. [17:14] apw, care to have a look at karmic LBM? [17:14] rtg: thanks [17:15] rtg sure [17:39] smb: howdy! is there anything else I should test for the Geode bug? [17:41] Q-FUNK, Hi there. As much I hate to say so, the last days have been busily filled with other work, so I never had much time to get back to that. [17:44] kernel freeze is tomorrow, isn't it? [17:45] smb: understood. please let me know if there's anything else I can do. [17:45] s/if/r/when [17:47] MTecknology, its effectively already frozen. [17:47] jjohansen, you re-run your kernel tests ? [17:48] Q-FUNK, Sure will do. I'll put any updates into the bug [17:48] i do remember that we had some intermittent issues with kernel logs, but nothing since we attached chuck's patch that i was aware of. [17:49] smb: ok. I'm just wondering how we're gonna manage to fix this on time for Karmic's release, though. right now, the whole Geode product line no longer works on Ubuntu, which pretty much kills the investment that Canonical made into LTSP. [17:50] smoser: not yet, and I haven't seen any problems since chucks patch either until yesterday [17:51] bugger [17:51] do you happen to have available to you the region that they failed in ? you might wnant to try ther eagain [17:54] This is why freezes should happen sooner and be more strict :) [17:55] Q-FUNK, It is quite unlikely that this will happen in the Karmic release. The kernel freeze is tomorrow. We will have fix it in later updates. [17:57] Wow. [17:58] smb: sad to hear. [18:00] Q-FUNK, Yes, I know [18:01] smb: espeically considering that support for older geodes already fell down a few kernel releases ago and the bug was not acted upon. [18:01] Is LTSP still usable under hardy? [18:01] smb, have we broken something in the 386 flavour? [18:02] Darxus: yes and no. support for Geode x86 CPU is currently broken, which essentially kills support for the most wide-spread CPU used in thin clients. [18:03] Ah, Geode is a CPU, thanks :) [18:04] I would be more comfortable with this if I felt it was less likely to happen on an LTS release, but I see kernel freeze wasn't any longer for Hardy. [18:05] Darxus: hardy was the release that broke if for older Geode variants, actually. it's never been fixed. [18:05] now, karmic broke it for more recent Geode variants, which affects the OLPC as well. [18:05] Wow. [18:06] rtg, It is a one byte corruption in inodes early on boot, but as far as I can tell only on geode [18:06] The ubuntu release process is weird :) [18:06] all this because upstream kernel developers cannot be bothered with answering bug reports. [18:06] Q-FUNK: Ah, that sucks. [18:06] Q-FUNK: Does it work in upstream? [18:06] meanwhile, smb does his best to pinpoint the source of the regression, but he has so much work on his hands that he's unlikely to figure out the solution on time for Karmic. [18:07] ooh, did someone say OLPC? [18:07] Darxus: as I already said, upstream is the one that broke it. [18:07] Q-FUNK: Ah, okay. I didn't catch that. [18:07] AlanBell: yup. OLPC support broken starting with Karmic, due to upstream regressions in kernel. [18:08] did it ever work? I didn't think the DCON drivers were in the Ubuntu kernel [18:08] (I guess submitting an upstream bug report is sufficient implication that the problem was upstream.) [18:08] AlanBell: yes, they are in the standard kernel [18:09] at the moment mine never unfreezes the display after the open firmware bit [18:09] AlanBell: well, the problem is not DCON support as much as the fact that kernel 2.6.31 flat out won't boot on Geode LX. [18:10] oh, mine flashes the microphone light after 10 seconds or so which I thought was an indication it was doing some stuff [18:10] AlanBell: the kernel dies sometimes during the loading of the initramfs image. [18:11] isn't the viglen mpc-l a geode? [18:11] AlanBell: viglen products use either a geode GX or a geode LX, depending on which one you're talking about. [18:13] quite a few Ubuntu-UK people have the MPC-L. There was a special discount offer via the Ubuntu-uk podcast [18:13] Do you think, for LTS releases, kernel freeze and final freeze should be doubled, to a month? [18:14] AlanBell: *IS* still the offer L( [18:14] :) [18:14] hi Daviey [18:14] \o [18:15] pip pip [18:16] popey has an MPC-L [18:16] or two [18:16] will they boot Karmic is the question [18:17] live CD should prove it one way or the other [18:17] i dont have cd, i can try off a usb stick, if that helps [18:17] or pxe [18:18] popey: is it a geode GX or a geode LX? [18:18] http://popey.com/~alan/viglen/hardware.html says it's a GX2 [18:19] ah, so that might work [18:19] apparently the kernel 2.6.31 flat out won't boot on Geode LX [18:20] Q-FUNK, I just noticed in the latest dmesg, that there is a crashkernel line in the parameters. Has that been always enabled when you booted newer kernels? The original boot with 2.6.30 does not seem to have one. Maybe just desperate but ... [18:20] bug 396286 [18:20] Malone bug 396286 in linux "2.6.31-generic: kernel panic near the end of initramfs" [High,In progress] https://launchpad.net/bugs/396286 [18:21] smb: I installed crashkernel recently. actually, I think that was pulled by recent ubuntu-standard. [18:23] Any objection to me adding "geode" to the title of that bug? [18:24] Hm, then rather not. The bad pointers seem to start right after mounting the root fs. Before much else is done... :/ [18:33] popey, did you try the very latest kernel, there were a couple of allocation off by two bytes style bugs fixed in .46 [18:33] I haven't done any testing at all yet [18:33] mine run hardy, I'm just here in case someone needs something confirmed/tested [18:35] Darxus: I just updated it now [18:37] Q-FUNK, Also, as apw said, it might be at least worth a check with -14.46 [18:38] anything I can do on the OLPC to confirm whether or not this is the bug I am stumped by? [18:38] smb: I check with every new kernel that pops up. if any of them ever fixed anything, I'd report it. :) [18:38] so you checked .46 today [18:39] AlanBell: yes. boot with usplash disabled and snap a picture of what happens when it freezes. [18:39] smb, it would be good to report the addy of the i_default_acl ptr in the debug next time [18:39] so we can see if its one inode its reporting or 10 differnet ones [18:39] Q-FUNK: Thanks. [18:40] as you cannot get the name [18:41] apw: yup.that one crashes too. [18:41] apw, Ok, I update the patch with that [18:42] smb, as it occurs really early in boot, you could consider printing the addy of every inode too as they are added to dcache, with the file [18:42] a [18:42] and see if we get a name that way [18:43] i guess that does assume we ahve some way to collect a long boot output [18:43] apw, I already had the check whenever one was looked up, and that seems to happen rare to never [18:44] smb, i see in the last one there are three bad ones at 83583s in ... so very late in the day [18:45] smb, when you report it, are you releasing the inode then? ie. its guarenteed to be a different one? [18:45] apw, Yes this actually reverses the claim that it only happens early [18:45]