[00:23] <CarlFK> hmm, debug output overflowed the dmesg buffer - is there a kernel parameter to increase it?
[02:24] <emma> How many herbs and spices are there again?
[02:31] <mjg59> Eight.
[08:45] <risman> i want compile gcc 2.95.3 but i cant compile on ubuntu 6.10
[09:52] <mdz> how should regressions in 2.6.27 be marked in Launchpad?
[11:12] <ogasawara> mdz: I'd been tagging them 'regression-2.6.27'
[11:23] <mdz> ogasawara: eek, what are you doing awake?
[11:33] <rihs_> anyone here who knows about framebuffers and virtualterminal resolution?
[12:46] <smb_tp> cking, Good catch fixing the paravirt stuff! :)
[12:46] <cking> smb_tp: thanks - it wasn't the most obvious bug to corner :-)
[12:47] <smb_tp> cking, No, hat irq_disable in poke_early seemed to be the least intruding part. I'd rather suspected sync_cores... 
[12:48] <cking> I suspected some weird caching problem on the text segment too. the fix seems stable - I was able to build intrepid inside a virtual box running 2.6.27
[12:51] <smb_tp> cking, something odd in any case. But the code for those paravirt replacements isn't obvious either
[12:52] <cking> smb_tp: the whole paravirt code is really a black art - it's very indirect - fortunately I found a paragraph in a pdf that helped me figure out what was going at the lower-level 
[12:53]  * cking needs a coffee
[14:53] <CarlFK> smb - g'morning 
[14:54] <CarlFK> you see my note about dmesg buffer overflow
[15:12]  * Ng curious if anyone else is seeing bug 262600
[15:13] <smb_tp> CarlFK, Hi, yes. But it is good to have that point where it stops. It is scanning the ACPI namespace when it gets interrupted by the EC GPE. That is some information
[15:14] <CarlFK> i was hoping for that 
[15:15] <smb_tp> CarlFK, One Idea, probably it works when you press ALT+print+t at that moment. But then better take the previous version of the debug kernel. That prints less noise around.
[15:17] <CarlFK> smb_tp:  did you want me to boot linux-image-2.6.26-5-generic_2.6.26-5.13ecdbg_i386.deb ?
[15:18] <smb_tp> CarlFK, Yes correct. 
[15:19] <smb_tp> CarlFK, As sysrq+t prints all task, this is already noisy enough. Better get that alone in the dmesg.
[15:20] <cjwatson> linux-restricted-modules 2.6.27-2 accepted, FYI
[15:20] <cjwatson> BenC: ^-
[15:21] <BenC> cjwatson: thanks
[15:21] <cjwatson> I'm upgrading d-i now
[15:41] <BenC> cjwatson: linux-meta uploaded
[15:41] <cjwatson> thanks
[15:45] <CarlFK> smb_tp: any special kernel params?
[15:45] <smb_tp> CarlFK, No, this time just wait for the hang and try the magic key
[15:47] <CarlFK> on this hp laptop:  Fn + sysrq - nothing.  whats the Alt-T thing?  
[15:47] <cjwatson> alt+print == sysrq
[15:47] <smb_tp> CarlFK, Normally a combinaten of alt+print
[15:48] <cjwatson> sysrq won't do anything on its own though; you need the extra letter (t in this case) as well
[15:48] <smb_tp> CarlFK, and while pressing those two add the 't' key (needs a lot of fingers)
[15:49] <CarlFK> print is prtSc, which needs an Fn too 
[15:51] <smb_tp> CarlFK, You might try to get the right combination by trying 's' instead of 't' when the combination is right the console shows something like emergency sync
[16:00] <CarlFK> smb_tp: even with a usb keyboard (so a dedicated PrintScr/SysRq key) nothing 
[16:03] <smb_tp> CarlFK, Sorry if thats a lame question: You hold first alt then (while holding that) press print and while holding both of then press s or t?
[16:04] <CarlFK> smb_tp: yes, and every other permutation I can think of 
[16:04] <CarlFK> numlock does not toggle the light
[16:05] <smb_tp> CarlFK, Hm, probably too early in the boot. :(
[16:08] <smb_tp> CarlFK, So it requires resorting to more debugging. Looking at the code of the function that prints "non-query interrupt..." hard to get blocked. Not sure how or where the scan gets hold up but I will try to put together code that does not print too much...
[16:44] <smb_tp_> ls
[17:17] <Xan3> hi
[17:18] <Xan3> i have a problem with last kernel in intrepid
[17:20] <Xan3> 27-2....  the problem with 27-2 it's already reported?
[17:49] <cjwatson> Xan3: you might need to actually say which problem
[17:50] <Xan3> simply with 27-2 right afterwards grup kernel crash with no error
[17:50] <Xan3> with 27-1 i have no problem
[17:50] <mdz> pgraner,BenC: is there anything more I can add to bug 262539?  I won't have local access to the machine over the weekend
[17:53] <pgraner> mdz: not that I can think of. BenC would know better
[17:55] <BenC> mdz: if removing lrm fixes it would be a good data point
[17:55] <mdz> BenC: linux depends on lrm
[17:56] <mdz> but I will try to do a test before I go
[17:56] <mdz> disabling the init script would presumably be sufficient
[17:59] <mdz> BenC: does the trace mean anything to you?
[18:09] <CarlFK> how is apt-get linux-image-... and /boot/grub/menu.lst  update-grub options like # defoptions=vga=791 spozed to work?  I keep getting:
[18:09] <CarlFK> " A new version of /boot/grub/menu.lst is available, but the version  installed currently has been locally modified." and lots of options
[18:13] <smb_tp_> CarlFK, It seems a bit like pulling in grub itself. But I am not sure. You might want to keep the locally installed version...
[18:13] <CarlFK> install whackes my options, keep keeps it (no update for new kernel), merge errors, show/show/show shows...
[18:14] <CarlFK> glad I am not the only one that isn't sure what to do :)
[18:16] <smb_tp_> CarlFK, Somehow it seems to be new in the latest packages but I am not sure where exactly it gets triggered.
[18:32] <mdz> BenC: updated bug 262539 with analysis; I found the problem
[18:32] <mdz> though there is still some mystery
[18:35] <CarlFK> um, .27-2 blanks my screen, -1 did not.
[18:36] <CarlFK> oh wait... never mind.  different vga option 
[19:05] <smb> CarlFK, I put up another debug kernel for you to my peoples page, I you could give that a try and add the output to the report...
[19:07] <BenC> mdz: that's enough to fix it...not sure I want to figure out why it didn't fail before...thanks
[19:08] <thekorn> hi, I've got a question about bug 261098
[19:09] <thekorn> ogasawara asked me to test the latest kernel on intrepid there
[19:09] <lukehasnoname> bug #261098
[19:09] <lukehasnoname> hm
[19:09] <thekorn> the messages described tthere are gone, but replaced by other ones
[19:10] <thekorn> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/261098
[19:10] <fabbione> BenC: ping?
[19:10] <BenC> fabbione: yo
[19:10] <fabbione> BenC: hey man.. did you get my pull request?
[19:10] <fabbione> i prepared a tree for gfs1
[19:10] <fabbione> for .27
[19:11] <BenC> fabbione: right, I'm going to pull it for next upload
[19:11] <thekorn> I would like to know if they are related, or totally different
[19:11] <fabbione> I might have a fix for fs/dlm that is scheduled for .28 but nice to have for .27. Not sure it will make it for .27 bug fixes.
[19:11] <fabbione> BenC: ok cool. what about ports?
[19:11] <fabbione> BenC: you said you were going to do it...
[19:12] <thekorn> http://paste.ubuntu.com/41636/ has the new messages
[19:12] <Ng> ehh, 2.6.27 kills some intel eth firmwares
[19:12] <fabbione> hey Ng 
[19:13] <Ng> theres a thread about it on the linux-kernel ml and its one of the listed regressions on the kernel bugzilla
[19:13] <Ng> hey fabio
[19:14] <fabbione> Ng: are for fw for wireless i guess....
[19:14] <fabbione> or wired stuff too?
[19:14] <Ng> just wired
[19:14] <fabbione> eeekkk
[19:14] <BenC> Ng: I saw that, but we are using e1000e from Intel's sf, not the kernel one
[19:14] <BenC> Ng: unless it affects other than e1000e?
[19:14] <Ng> benc: well it happened to my one with intrepid
[19:15] <Ng> neither .27 or .24 pass the checksum, even ater hard power off
[19:16] <fabbione> oh that bug.. 
[19:16] <BenC> Ng: so it corrupted it on the device?!
[19:16] <Ng> seems that way
[19:17] <fabbione> Ng: i assume a .26 kernel work?
[19:18] <Ng> not tried it, but until i make a dos disk and reflash iy, nothing will work with it afaics
[19:22] <Ng> i think it did work for a bit with .27, but i wasnt paying much attention to NM until after it happened
[19:23] <Ng> s'been fine with .24 for months
[19:30] <CarlFK> smb_tp: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/254668 
[19:31] <smb_tp> CarlFK, Ah ok. Thanks.
[19:32] <smb_tp> CarlFK, Very interesting. Ok, back to the code
[19:33] <CarlFK> smb_tp: there are 2 ways for me to get past it: power button or plugging in power to laptop 
[19:33] <smb_tp> CarlFK, Both seems to generate events from/for the embedded controller.
[19:34] <smb_tp> CarlFK, Interestingly it waits just before returning from that handler...
[19:41] <smb_tp> CarlFK, Ok, I guess I have a trace... But it might need a bit of time
[22:08] <Ng> well that didn't go so well, after getting dos booted and running intel's proboot tool to try and restore the NIC, it's now entirely disappeared from the PCI bus
[22:09] <Ng> so I suspect I won't be able to do much testing ;)
[22:12] <Nafallo> Ng: FAIL!?
[22:13] <Ng> very very fail
[22:13] <Ng> unless some kind of miracle happens, my thinkpad will be heading off for a service next week ;(
[22:36] <Nafallo> Ng: haz spare laptop?
[22:42] <Ng> yep, I'll rob my old X40 off my gf ;)
[22:43] <mjg59> Ng: Yeah, that'll allegedly happen if the eeprom is sufficiently funted
[22:43] <mjg59> Ng: Getting increasingly unimpressed with Intel's networking support
[22:44] <Ng> mjg59: it's pretty worrying their their own stable driver release did this. I get a weird oops which seems to relate to drm, so maybe that's screwing with other things, but even that's their code aiui
[22:45] <Ng> mjg59: so if the thing won't enumerate on the PCI bus, this is a repair job, right? ;)
[22:45] <mjg59> Ng: probably, yeah. Though they'll probably want you to boot Windows.
[22:46] <Ng> ugh, I'd need to buy restore media from them for that. I did mail Jesse Brandeburg and he thinks the NVM is actually part of the main system BIOS and so it may be restorable
[22:46] <Ng> but I did put the latest lenovo bios on this evening, to no avail
[22:47] <Ng> he's also "relatively sure" it's not a driver bug
[23:02] <Ng> yeah all of the publically available bios updates for this are the same size, so I'm not sure they've actually got the full BIOS (which may be up to 4MB, I'm told) and thus the LAN bit
[23:24] <CarlFK> smb_tp: " It would make a little bit more sense if the pause would be one message later."
[23:24] <CarlFK> any chance there is a line buffer?
[23:25] <CarlFK> like the fprintf happens, but no \n, then the hang, then the next fprintf does a \n which flushes the buffer and it is displayed 
[23:25] <smb_tp> CarlFK, Could be
[23:25] <CarlFK> i just booted with both hpet=disable and highres=off - same hang.  want me to post the log?
[23:26] <smb_tp> No, enough to know it doesn't change anything
[23:28] <smb_tp> I really suspect msleep there. I replaced that by udelay and put some messages around it. The kernel currently comiles
[23:30] <CarlFK> k - i'll watch for it
[23:31] <smb_tp> CarlFK, Thanks, shouldn't take too long. Its already packaging but that old workhorse of mine takes a bit... ;-)
[23:48] <smb_tp> CarlFK, Ok, number 4 is there