=== lamont` is now known as lamont
=== asac_ is now known as asac
[14:32] <CarlFK> smb_tp:  noacpitimer no help. i posted dmesg to bug 254668 - anything else while I have some time right now?
[14:36] <smb_tp> CarlFK, unfortunately nothing that can be done just by options. What is really strange is: even with the udelay version. There is a relatively long period of time with exactly the same timestamp. Which is just not what should happen.
[14:38] <smb_tp> CarlFK, From the evidence it feels like the problem lies somewhere in timing: either that timer is broken in general or that maybe one core doesn't get updated. Just nothing I can simply point to. :(
[14:45] <CarlFK> oh well - once booted the box seems to be ok, so hard to call this critical 
[14:45] <mjg59> CarlFK: You mean noapictimer, right?
[14:45] <mjg59> noacpitimer does nothing
[14:46] <mdz> BenC: thanks for the fix on 262539
[14:46] <mdz> BenC:  do you have any guess why it didn't happen for me until I upgraded?
[14:46] <CarlFK> mjg59: opps... let me try with that :)
[14:49] <BenC> mdz: no idea t all
[14:49] <smb_tp> mjg59, Hm, might be a copy-copy paste error. Got it from another thread that claimed it helped and spelled it like this. But I probably should have cross-checked with the code.
[14:50] <mjg59> Oh, if this started with .26, it's a known bug
[14:50] <mjg59> Some AMD systems stop the local apic timer in C1E
[14:50] <mjg59> So no timer interrupts = no progress in nohz
[14:51] <mjg59> There's a patch submitted to -stable to fix it, not sure if .27 is also hit
[14:51] <smb_tp> mjg59, It did. And the symptoms are exactly like that
[14:51] <mjg59> It appears when ACPI's enabled because up until that point you don't enter any C states
[14:53] <smb_tp> mjg59, And in this case it hangs in acpi scan because the poll uses a delay with 2.6.26++. 
[14:53] <mjg59> It's a one-line or so fix
[14:53] <mjg59> Hang on, let me find it
[14:53] <smb_tp> mjg59, Thanks a lot for the hint
[14:53]  * mjg59 does a cvs up over GPRS...
[14:57] <mjg59> wErgh. Can't find it no.
[14:58] <smb_tp> mjg59, I try to look trough the 2.6.26.y tree. But it is good to have the hint to it
[14:59] <smb_tp> mjg59, I already suspected timers but did not find the known bug to it
[15:06] <CarlFK> smb_tp: noapictimer, still hangs, dmesg posted
[15:12] <smb_tp> CarlFK, There is also this line "AMD C1E detected late. 	Force timer broadcast." which is probably what mjg59 was referring to
[15:14] <mjg59> Mm. Yeah, if that's appearing then this probably isn't that issue
[15:16] <CarlFK> smb_tp: btw - I see I never posted the results of m .27 tests.  did you see my logs in bug 262437
[15:17] <CarlFK> I would like to say .27 doesn't have this problem, but it has so many other pauses it is hard to say this problem is really fixed right 
[15:17] <smb_tp> mjg59, The delay loop still prints "calibrating delay using timer specific routine.." when using noapictimer. Not sure this is relevant, yet. But having exactly the same timestamp during several udelay calls is just too weird.
[15:18] <smb_tp> CarlFK, I did not look to deeply yet. But I remember there have been several hangs. Can you try noapictimer without too much effort on a 2.6.27?
[15:57] <CarlFK> where does "Running /scripts/init-bottom ... \nDone." get logged to?
[16:18] <CarlFK> smb_tp: so I was trying to note all the places .27 pauses, and i ran out of battery 
[16:18] <CarlFK> plugged in, booted, and it seems like it is still pausing, but continuing on its own without me hitting any keys
[16:19] <smb_tp> CarlFK, was that with special options?
[16:19] <CarlFK> as the battery charges, does that generate some sort of event, similar to hitting the power button? 
[16:19] <CarlFK> yes
[16:22] <smb_tp> CarlFK, I can't say for sure. I won't think so on charge. Which options did you use? noapictimer?
[16:22] <CarlFK> yes
[16:22] <smb_tp> CarlFK, Ok
[16:28] <smb_tp> CarlFK, Unfortunately the battery didn't last. I am not quite sure how well this can be matched to places where it hang to why it does. It still might be something timer related.
[19:48] <newz2000> hi, I have a prob with 2.6.27 and filed bug #264096. I just wondered if someone could let me know if further details are needed or if it looks good.
[19:59] <smb_tp> newz2000, so far it looks good
[20:00] <newz2000> ok, thanks a bunch. Ping me if you need more info.
=== emgent`NL is now known as emgent`nl
[21:38] <doko> BenC, rtg: please could you have a look at bug #200589 ? both hardy and intrepid. or let me know, if I should test and upload myself
[21:43] <rtg> doko: huh, I just fixed a similar bug in the fritz pile.
[21:47] <doko> rtg: so this should be already fixed?
[21:48] <rtg> doko: nope, I'm just doing it. it'll be uploaded in a little bit.
[21:48] <doko> ahh, ok
[21:48] <doko> let me know, and I'll tst
[22:03] <rtg> doko: uploaded linux-restricted-modules-2.6.24_2.6.24.14-21.49
[22:05] <rtg> I guess Hardy is the end of the line for Fritz, huh?
[22:06] <rtg> I'm outta here.
[22:51] <nullack> Hi - is there an ETA for RC5 of .27 into Intrepid please?