[00:18] ogasawara: how tyler working out for ya? [00:21] pgraner: good so far, I've started some builds on it already [00:22] ogasawara: yea I noticed all 12 cpus are pegged [00:22] :) [00:22] * maco wonders how much of this channel will show up in #ubuntu-meeting in a half hour to support your comrades [00:22] * maco points at pgraner and manjo [00:23] komrades [00:23] Ooo, is the ubuntu membership meeting happening? [00:24] yes [00:24] in 35 minutes [00:24] * ogasawara will try to be there then [00:31] * bjf done for today [00:38] cnd: the intent is, but I'm afraid we need to work on it more. The current wait is too short. [00:39] cnd: namely there are reports of it being worse with the newer driver snapshots, so it doesn't affect LTS currently. [00:56] pgraner, membership meeting starts in 5mts ? [00:56] manjo: oh so you ARE alive! [00:56] manjo: 4 minutes now :) [00:56] ok [00:56] :) [00:56] maco: yep [00:57] pgraner: if you werent online, i was going to call your house [00:58] maco: why? [01:00] pgraner, you on ubuntu-meeting ? [01:00] manjo: yep [01:00] pgraner: so you wouldnt miss the meeting? [01:12] pgraner: tyler cranks out builds quick! [01:12] ogasawara: sweet... its dead quiet [01:13] ogasawara: once we get emerald redone I might send this one on to you [01:13] pgraner: nice :) [01:13] ogasawara: you need it more than I do [01:14] pgraner, is it like the one you are going to send me or is that yet another? [01:15] ogasawara, pgraner I made it [01:15] manjo: yep, congrats! [01:15] manjo: congrats [01:15] thanks yall [01:16] partah time for manjo! \o/ \o/ woo hoo!!! [01:16] akgraner, thanks for the wiki clean up ... owe you a drink of choice [01:16] akgraner, and the nice reco [01:17] :-) you are most welcome! [01:18] back on later [01:20] pgraner: your wiki page makes me think ive only met half the kernel team. or at least only been introduced to half of them by name [01:20] maco: there are 27 now [01:21] WOW [01:34] ogasawara: your a whimp... tgardner had tyler at 35 load ave. today your at 13.75 [01:39] pgraner: damn. I wonder what he was doing. [01:40] ogasawara: running stress and builds at the same time [01:40] ogasawara: :-) [01:40] pgraner: that's cheating [01:40] ogasawara: if you ain't cheatin' you aint trying [01:40] heh [01:41] ogasawara: and if you get caught you ain't trying hard enough :-) [02:11] ogasawara: awww I'm touched :-) [02:16] pgraner: congrats! /me goes to eat dinner [02:17] ogasawara: thanks :-) [02:40] I figured out why my pc randomly reboots [02:40] it's fvdr [02:40] vdr [02:40] why vdr does that I don't know === kamal is now known as kamal-away [02:43] crimsun: what do you mean by "it doesn't affect LTS"? [02:43] Ubuntu 10.04 LTS? [02:51] Thanks for that Xorg.0.log; nouveau isn't working, but the fallbacks are successfully kicking in, which they didn't do earlier in the Lucid cycle. [07:00] Am I correct in thinking that installing the two header files for the mainline PPA kernels will let you install restricted drivers through jockey? [07:00] stenten: Sometimes. [07:04] i'm trying to troubleshoot someone's kernel problems :(. Should the lts-backport-maverick kernel Tim Gardner posted in kernel-ppa for the LTS Backport Kernel idea work? [07:05] It depends on whether or not the restricted driver's kernel component will build against the new kernel. I know that fglrx doesn't, I'm unsure about nvidia. [07:08] Ah, that makes sense. It's the Broadcom Wireless driver. I'm thinking they just didn't install the header files correctly, so it should be moot. [07:10] Is there anything special in the ubuntu-specific (default) kernels that would affect restricted drivers, or is all that handled by the header files? [07:15] stenten: grab bcmwl-kernel-source from maverick [08:22] * apw aches [08:25] apw, Hey morning. Before I forget this (because I did already many times), I got one interesting case of being unusually hot for an old thinkpad. Those things pretend to have a floppy drive even when not attached. And I noted it running quite hot. After blacklisting floppy its now down to a sensible temp on idle. [08:26] heheh, overheating due to floppy driver hallucinations [08:27] Nearly. :) More to trying to access it over and over agai [08:28] Some part of the basic installation tried to find out what is on the non-existing floppy in the non-existing drive. And seemed not to take a nothing for an answer [08:28] smb, i wonder what the thing was doing [08:29] apw, Not sure it came from userspace (as cd polling used to be) or from the driver to check there is a media present [08:30] First thought its the lack of any frequency scaling (a quite old hw, T21 I think) [08:31] But wanted to get rid of this anyoing "read error on fd0" messages [08:31] and surprise, after blacklisting temp went down from 80 to 50C [08:31] smb, yeah ... [08:32] smb, i am almost supprised if it was that busy that you could remove it at all [08:32] apw, I could not [08:32] blacklisted and rebooted [08:32] cking, \o [08:34] smb, ahhh interesting, i bet waiting for status or something from the interface chipset [08:36] apw, That would be my guess. But thats probably just something that happens not very often. I don't think any reasonably modern TPs will try to fake a floppy drive [08:36] smb, is it faking it for hot plug ? [08:37] morning, (yawn) [08:37] Yes, afaik. You were able to replace the cd drive with a floppy drive (after some magic to disable the ide bus) and on older models you could attach a floppy later [08:38] * smb places a cup of coffee into cking 's hand [08:39] * abogani2 waves [08:39] abogani2, moin [08:39] * smb waves back [08:39] smb, nasty but must be the trigger ... [08:39] cnd, apw: http://kernel.ubuntu.com/git?p=abogani/ubuntu-lowlatency-maverick.git;a=summary lowlatency branch [08:39] cnd, apw: http://kernel.ubuntu.com/git?p=abogani/ubuntu-lowlatency-maverick-meat.git;a=summary lowlatency branch [08:40] cking, morning, its tooo hot here again [08:40] *meta [08:42] apw, cking You actually see this bright thing in the sky? Its magically bright here but enough clouds and only 15°C [08:43] yeah only 13c here so far, but its not going to stay cool for long i can feel it [08:43] smb, and where is your 'degrees' button on your keyboard [08:44] Above the ^ key :-P [08:44] which is left of 1 [08:44] not something i would have expected you to have an actual key for, no such key for me [08:45] smb, so is that also the key which adds a flying circle over the top of vowels ? [08:46] Its not considered that useful to do it [08:46] I bet there is some magic to make it behave like ~ [08:46] But now thats instant [08:47] apw, Probably amitk 's keyboard does that [08:48] no flying circles on the finnish keyboard [08:49] though there is a key for 'A' with the flying circle (used in norwegian, i think) [08:54] * smb wonders whether abogani2 currently plays with his PPA [08:56] smb: No [08:57] man it's sunny today - and it's near a UK holiday [08:57] abogani2, Hrm, I just tried to get the sources for the linux-rt packages from it and the orig.tar.gz appears lost to me [08:57] cking, Its a trap. As soon as you go out there will be water [08:59] smb, I need the rain to water my garden, so it's no big loss ;-) [09:00] cking, Well no, but you don't want it on *you*, do you? [09:00] * smb had his share of cold water from above yesterday [09:00] smb: Mhhhh [09:24] smb: I surely have did a mistake: apologize for this. It is my fault haven't did enough tests. So I have investigated and _seems_ that orig.tar.gz is the same of the previous version (if I don't recall wrong I almost sure to have used "debuild -S -sd"). In any case I'll upload again to an other PPA to be sure. Sorry again. :-( [09:28] abogani2, Ah, ok. In theory the orig.tar.gz would be a clean 2.6.31 linux tree, so I should also be able to use that. But I wanted to be sure. Just let me know when it has been uploaded. No need to wait for the build for me. :) [09:31] smb: Ok thanks. I'm _really_ sorry. [09:31] * abogani2 doesn't like waste time of UKT members... [09:32] abogani2, Bah, compared to the time you had to wait on me thats nothing. [09:55] smb: I have found the files which I used to first upload. I have just re-uploaded and again orig.tar.gz is unavailable :-( [09:55] abogani2, Ok, cool. Some PPA as before, right? [09:55] err [09:56] I should open my eyes this morning [09:56] smb: No because same PPA don't accept to build the same version two times. [09:56] smb: Is it debdiff enough for you? [09:57] abogani2, I would want to try to extract in and look at things. Hm, have you an account on zinc? [09:57] smb: Sure. [09:57] abogani2, Then just dump the files there. :) [09:59] smb: Also orig.tar.gz ? [10:00] abogani2, Is that just a linux-2.6.31.tar.gz? (Like from kernel.org)? In that case probably just add a text file with the md5sum of it and I make one here. [10:00] I just want to be sure to take the same orig.tar.gz when playing with it [10:01] smb: It could be Karmic orig.tar.gz. In any case Zinc seems go fast now so I'm uploading it too, [10:02] abogani2, right, which is in turn just the plain Linus tree. But perfect. Seems you got a good uplink. :) [10:28] smb: I have just uploaded the classic triple (diff, dsc, orig), debdiff (only for safety) and the two files for meta. At the moment the only issue that I know is the section which is settled to "lucid" (I suspect "lucid-updates" should be used instead). [10:28] lucid-proposed probabally [10:28] abogani2, Make that 'lucid-proposed" [10:28] yeah [10:29] after release (at least the packages we do) is uploaded to proposed and then later archive copied to updates [10:30] abogani2, I will have a look next and reply anything I think to your original email [10:30] smb: Ok. Thanks! [10:59] hello [11:00] is there a difference in module loading/features used between normal and recovery mode? [11:01] because I have a server in here who is shutting down itself after 1 minute or so [11:01] but in recovery mode it doesn't do that [11:01] even when I manually go in recovery mode and then start runlevel 2 [11:02] so even when the same applications are running, it doesn't shutdown in recovery mode but does in normal mode [11:02] so I try to pinpoint the problem === smb is now known as smb-afk [11:06] could it be that a kernel module reacts on cpu fans not running (at least 0RPM in sensor data) but in recovery mode ignores that? [11:08] have a look at /boot/grub/grub.conf to see which kernel options differ in your case [11:10] quiet splash in normal, and single without quiet splash in recovery mode [11:11] even when I disable splash and quiet on boot it shutsdown [11:13] and no reason for the shutdown in the logs? is it really a shutdown or rather a crash? [11:14] it could be a crash [11:14] but I think a shutdown [11:14] because I see, when running top, flush and mdadm stopping it's devices [11:15] but I cannot find a shutdown reason in the logs [11:16] the only error I can find, but I really thing that is not the problem, is: svc: failed to register lockdv1 RPC service (errno 97) [11:16] using the nfs kernel server [11:23] can I use some kind of verbose logging? [11:24] more verbose then removing quiet [11:26] try replacing "quiet" with "debug" [11:26] and maybe stuff your logs into some pastebin and paste the link here :-) [11:26] that is, syslog and maybe dmesg [11:26] ok [11:27] udev-worker add_inotify failed couldn't be the cause now could it? [11:30] /var/log/messages, right? [11:33] michiel_e, that was a bug during development on which a shutdown was performed because the fsck from mountall was running on the background, and the script was invoking the *after file system check* reboot when the system was running, that bug is expected to be fixed now, I am just wondering [11:35] joaopinto, lucid-updates is set as repo as well as multiverse and universe [11:35] and fully upgraded via dist-upgrade [11:36] joaopinto, you know how I can confirm that is that bug? [11:36] mv /etc/init/mountall-reboot.conf /etc/init/mountall-reboot.conf.disable [11:36] or have a launchpad link? [11:36] that would make sure the mountall rebook will not be invoked [11:37] but this really a wild guess assuming it's a reboot and not a crash [11:37] is [11:37] yeah well, it looks like a crash, but looking at the processes it just flushes to the disk [11:37] so I actually don't know [11:38] the system doesn't give a shutdown message [11:38] but it seems like the kernel knows it's shutting down [11:40] michiel_e, most fan control is bios level [11:41] the mountall-reboot.conf doesn't get invoked [11:41] so it's not that bug I guess [11:41] apw, but Ubuntu is using the sensor limits, right? [11:41] michiel_e, and one minute seems a bit quick to overheat anyhow [11:42] apw, yeah but it's not even overheating [11:42] michiel_e, you can find out what they are, but most actual control is done in the bios [11:42] i suspect its more likely something else, a panic or something [11:42] if you can see the console, then i would boot without quiet and without splash [11:42] and see if you see anything on the console to aid debug [11:43] the sensor data: http://pastebin.com/3akr24m4 [11:44] I'm worried if the system reacts on the fan RPM's being 0 [11:44] this is the system information: http://pastebin.com/NUTt6T6W [11:44] michiel_e, i don't know of any support there that is not builtin, and therefore would behave the same [11:45] in recovery and normal modes [11:49] I am going to test with recovery mode, going through normal boot process [11:49] in debug mode [11:53] michiel_e, sounds like a sound plan [11:55] michiel_e: 2.6.34-020634-generic is that your own kernel? maybe try to compare if the same thing happens with the lucid kernel? [11:58] kro, thats a mainline 2.6.34 kernel from the archive (i suspect) [11:59] Cool! The ondemand governor freezes an old P4! [11:59] but yes, it would be good to know if the same issue appears with the stock lucid kernels as well [12:00] abogani2, is that in the stock kernel or -rt ? [12:00] apw: Stock kernel. [12:01] apw, Karmic and Lucid. [12:01] abogani2, lovely [12:01] abogani2, so does it freeze when we switch after login ? [12:02] apw: No. Randomly. [12:02] abogani2, not helpful, does it panic or just lock up hard [12:03] apw: Very hard lock up. No Sysreq keys works, Only removing the battery. [12:03] abogani2, woh, well i can only really say i've not heard of that before [12:04] * abogani2 too [12:04] it is likely that freq control is different on P4 so i could imagine it being only broken there and few people even have them to notice now [12:04] * abogani2 agrees [12:04] abogani2, i assume if you leave it in performance everything is fine? other that it being a bad idea [12:04] apw: After a week it still runs. [12:05] No freeze at all. [12:05] No useful log neither through network nor through serial. [12:06] So a sort of magic :-) [12:06] apw: It is P4 _*_Mobile_ *_ [12:08] cooloney: thanks for the sbuild write [12:08] up [12:10] apw, same issue appears with stock kernel as well [12:10] apw, which do you like I debug, 2.3.34-* (which is indeed from ppa archive) or the stock? [12:15] amitk: no problem, man. I think it is a good benchmark for our hardware machine. [12:16] amitk and apw, it still took me 3 hrs to build the whole package. [12:16] my server is not so powerful [12:16] cooloney: 3 hrs is still better than 7 hr on buildd and then fail :) [12:17] amitk: aha, yeah, much better. [12:24] michiel_e, likely matters not if the issue is in both [12:25] abogani2, hrm [12:26] cooloney, yeah and we'll get that put up on emerald once its rebuilt [12:26] amitk, bah he has gone [12:26] apw. I'm about to disable ACPI_CPUFREQ and enable P4 CLOCKMODE instead. [12:26] was going to say, and if its a local build you can 'continue it' by [12:27] removing the build stamps === ayan-afk is now known as ayana === ayana is now known as ayan === smb-afk is now known as smb [13:38] there is in the boot process something running /sbin/poweroff [13:38] that's why it crashes [13:38] saw it with ps aux [13:38] although no parent process so hard to trace currently [13:39] maybe still the mountall bug [13:50] Hm, somehow calling poweroff sounds like some sort of thermal emergency action. Unfortunately I am missing the details but I thought machine check events might be involved. On the other hand I don't see why things should be different in recovery mode (if there are no special options for the kernel in /boot/grub/grub.cfg). And in mine there only seems to be single instead of quiet splash... [13:53] ls -l [13:54] Yeah, that'll work :( [13:56] soren, It better does not. :) [14:03] HI [14:03] hello guys. i am trying to recompile the ubuntu kernel because i need to add support to toshiba laptops. I cant find this option when make menucofig. some help please [14:04] I want to file a bug report about recognition of my laptop keyboard by linux kernel. [14:04] All versions of linux kernel don't recognize my LG E300 built-in laptop keyboard. [14:04] It is a known problem. [14:04] But there is no relevant bug report as far as I know. [14:04] Where should I file a bug report about this? [14:05] /sbin/poweroff -fp [14:05] where the heck does that come from? [14:05] it has no parent process [14:05] bagaimana cara mendapatkan shell ya ? [14:05] yes how do I get a shell ? [14:06] michiel_e, "dpkg -S /sbin/poweroff" says it is included in upstart package. [14:06] Conficker- : Is that english? [14:06] this is my process list http://pastebin.com/neRdDPyi [14:06] ah ok [14:07] jessicaNatalie, what sort of support? [14:07] michiel_e, problem solved? [14:07] Somebody tell me about my problem [14:07] crocket, not yet, I need to find out why it's running poweroff [14:07] michiel_e, What's running it? [14:08] I could not ask for his shell ? [14:08] crocket, I think upstart, but not shure [14:08] JFo i mean, i am runnig toshset and i am receiving this message "required kernel toshiba support not enabled." [14:08] crocket, no parent process [14:08] interesting, where do you see that jessicaNatalie? [14:09] michiel_e, Does it appear no matter how many times you reboot? [14:09] crocket, I'm not sure what you mean by where should you file it/ [14:09] JFo: in console, when executing toshset [14:09] I think of filing a bug in bugzilla.kernel.org [14:09] I don't know which section of bugzilla.kernel.org I should file a bug in. [14:10] JFo the truth is that i am doing this because i am having a very weird behavior in this laptop: when i boot ubuntu, the cooler is always off, unless I put the laptop to sleep and awake it again... [14:11] so the fans aren't working? [14:11] hmmm [14:11] why ? [14:11] jessicaNatalie, do you have a bug I can take a look at? [14:11] woy tahede [14:12] JFo a bug? you can look at all you want, but no idea what you mean... some log file or something? [14:13] crocket, it appears al the time, but not in recovery mode [14:13] crocket, I think upstart is just running /etc/rc0.d/halt or something [14:13] crocket, but not sure though [14:13] nou, I mean have you filed one that I can look at and provide the team to work on? [14:13] jessicaNatalie, ^ [14:13] michiel_e, it doesn't have to be upstart that's running poweroff -fp [14:14] crocket, indeed it doesn't [14:14] crocket, maybe fgrep would give me some info [14:14] JFo mmm no i havent... sorry for my ignorance [14:14] no problem :) [14:15] I just need one before we can start looking at the problem in-depth [14:15] jessicaNatalie, mind filing one? [14:15] JFo I understand. So i will do it [14:15] thanks a lot! [14:16] jessicaNatalie, my pleasure :) [14:17] Conficker, I'm not sure I understand what your questions are? [14:17] do you have a bug i can look at?> [14:19] crocket, I know you probably have already, but did you search against the kernel bugzilla for your laptop model to see if someone has already filed something? [14:20] JFo : I just checked and nobody reported such a bug. [14:20] ok [14:20] What section of bugzilla.kernel.org should I file a bug report in? [14:21] not sure what you mean by section [14:22] There is no section assigned to keyboards. [14:22] ah, right [14:22] I mean [14:22] a category [14:22] There is no category assigned to keyboards. [14:23] I think those are some sort of internal USB keyboard oddity from my conversation with smb [14:24] are you able to run lsinput crocket? [14:24] JFo one last question: do you know where is this toshiba support option when recompiling the kernel???? I am sure I have seen it, but cant find it now... :) [14:25] JFo : Is it a command? [14:25] jessicaNatalie, I don't, unfortunately [14:25] crocket, yes [14:25] JFo : are you a kernel developer? [14:25] crocket, do you have an LP bug open? [14:25] crocket, I'm the bug triager [14:25] What's an LP bug? [14:26] JFo mmm all right... I continue looking for it. thanks a lot! [14:26] launchpad bug [14:26] jessicaNatalie, my pleasure [14:26] JFo : I filed that bug somewhere in launchpad years ago, but nobody cared. [14:26] ah [14:26] Maybe it was a wrong place to file a report. [14:26] no it is, there are just so many that get opened [14:26] I think bugzilla.kernel.org is the right place [14:27] crocket, is the keyboard detected at all? [14:27] or better [14:27] is it misbehaving? [14:27] Let me pastebin for you [14:27] ok [14:27] I already have a USB keyboard plugged in. [14:28] I see [14:28] An external USB keyboard works. [14:28] but the internal doesn't at all? [14:28] JFo, http://pastebin.org/288193 <-- the result of lsinput [14:28] I don't know how to interpret the result. [14:29] There are some USB devices that don't have human-readable names. [14:29] "AT Translated Set 2 keyboard" may be the external USB keyboard. [14:29] * JFo looks [14:30] No that seems to be the internal one [14:30] smb : do you think "AT Translated Set 2 keyboard" is the internal keyboard? [14:30] Its connected to the i8042 controller, which is usually the internal one [14:30] Damn [14:30] It might be that hid device [14:31] # [14:31] /dev/input/event6 [14:31] # [14:31] bustype : BUS_USB [14:31] # [14:31] vendor : 0x566 [14:31] If I add "i8042.nopnp i8042.dumbkbd" in kernel boot parameters of GRUB, the keyboard works, but Num Lock and Caps Lock toggle LEDs don't blink at all, so I can't check the status of Caps Lock and Num Lock. [14:31] # [14:31] product : 0x3002 [14:31] # [14:31] version : 272 [14:31] # [14:31] smb : don't flood man [14:31] name : "HID 0566:3002" [14:31] # [14:31] phys : "usb-0000:00:13.0-2/input0" [14:31] # [14:31] uniq : "" [14:31] # [14:31] bits ev : EV_SYN EV_KEY EV_MSC EV_LED EV_REP [14:31] gah [14:31] hmmm [14:31] my bad [14:31] wonder why it doublespaced [14:32] JFo : How come does it get recognized and not work at all? [14:32] crocket, good question [14:32] well, that points to that that [14:32] I'm not sure [14:32] ha [14:32] the HID device smb? [14:32] The driver might try to communicate with it and fail at some point [14:33] I believe that is the usb keyboard [14:33] i8042.nopnp & i8042.dumbkbd kernel options make it work [14:33] lsusb could verify that [14:33] mus be some device at 00:13.0-2 [14:33] crocket, mind running lsusb for us? [14:34] more for smb than for me :) [14:34] This is the result of sudo lsusb ---> http://pastebin.org/288208 [14:35] Why do I have to specify i8042.nopnp and i8042.dumbkbd? [14:35] I didn't have those options myself. Others found them for me. [14:35] I need to check with those options [14:35] But my guess is [14:35] that the keyboard has some special ps2 protocol extensions variations [14:36] smb : In windows vista, it's recognized as a PS2 keyboard. [14:36] and by telling it to use sumkbd the used commands on the protocol are more generic and simpler [14:36] What driver should I install? [14:36] or put in kernel? [14:37] the driver is in the kernel. i8042, its just that this keybard might need special treatment by it [14:37] dumbkbd: Do not try to control the state leds [14:38] crocket, Have you once tried with only nopnp? [14:38] hi, could somebody add rt3090.bin [14:38] I mean i8042.nopnp [14:38] smb : I tried, but don't remember the result now. [14:38] rt3071.bin is missing too [14:38] http://packages.debian.org/sid/firmware-ralink [14:39] there it is already packaged [14:39] I hate LG laptops. [14:39] From the docs the nopnp does not do any plug and play to detect the keyboard, I assume it brute force looks at the common io ports [14:39] I called LG today, and the engineer there said no LG laptops have 64bit OS. [14:39] The other option will prohibit any commands that control the leds [14:40] The kernel will do that anyway if there's no pnp devices described [14:40] So no blinking, and so on [14:40] no blinking, dumb keyboard [14:40]