2.6.22-rc3: known regressions v2

Hi all,

Here is a list of some known regressions in 2.6.22-rc3.

Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions

Unclassified

Subject : build failed in function `vic_sys_interrupt'
References : http://lkml.org/lkml/2007/5/31/227
Submitter : Toralf Förster <[email protected]>
Status : Unknown

Subject : long freezes on thinkpad t60
References : http://lkml.org/lkml/2007/5/24/100
Submitter : Miklos Szeredi <[email protected]>

Status : problem is being debugged

ACPI

Subject : unable to shutdown on kernel 2.6.22-rc2
References : http://bugzilla.kernel.org/show_bug.cgi?id=8516
Submitter : Thierry Volpiatto <[email protected]>
Status : Unknown

ALSA

Subject : snd-aoa causes badness in lib/kref.c:33
References : http://bugzilla.kernel.org/show_bug.cgi?id=8513
Submitter : Ben Collins <bcollins-GeWIH/[email protected]>
Status : Unknown

Networking

Subject : b44: regression in 2.6.22
References : http://lkml.org/lkml/2007/5/27/108
Submitter : Maximilian Engelhardt <[email protected]>

Status : problem is being debugged

Regards,
Michal

--
"Najbardziej brakowało mi twojego milczenia."
-- Andrzej Sapkowski "Coś więcej"

This isn't a regression strictly speaking, as 2.6.21 is known to be affected, and older kernels might also be.

It's non-fatal and only happens under very special circumstances, so it's definitely not a showstopper.

I don't mind being bugged about this once in a while, this is just for clarification.

Miklos

i have no better ideas that what you already tried - but unfortunately the tracer makes the bug go away and the NMI watchdog crashes your box. Btw., nmi_watchdog=2 might have a higher chance of surviving (it can still lock up a T60 but with a lower likelyhood).

Ingo

Good tip, nmi_watchdog=2 worked. Unlike the previous freezes, after this one it didn't continue after some minutes. Don't know if that's because the NMI oopser changed something, or if this is a slightly different lockup...

No serial port on this laptop, so screenshot done with digicam:

http://www.kernel.org/pub/linux/kernel/people/mszeredi/freeze/nmioops.jpg

Here are the transcribed stack traces:

CPU1
process: strace
_spin_lock
task_rq_lock
wait_task_inactive
ptrace_check_attach
sys_ptrace

CPU0
process: fusexmp_fh (this is one of several similar threads being straced)
_spin_lock_irq
schedule
ptrace_stop
ptrace_notify
syscall_trace
syscall_trace_enter
tracesys

Both these seem to be spinning on rq->lock, but who is holding this lock?

Miklos

Can you please add this ...

Got this only after "recompile". "make clean" will make the warnings go away.

SYSMAP System.map
SYSMAP .tmp_System.map
MODPOST vmlinux
WARNING: arch/i386/kernel/built-in.o(.text+0xa677): Section mismatch:
reference to .init.text: (between 'init_intel_cacheinfo' and 'cache_shared_cpu_map_setup')
WARNING: arch/i386/kernel/built-in.o(.text+0xb8c0): Section mismatch:
reference to .init.text: (between 'mtrr_bp_init' and 'mtrr_ap_init')
WARNING: arch/i386/kernel/built-in.o(.text+0xba79): Section mismatch:
reference to .init.text: (between 'mtrr_bp_init' and 'mtrr_ap_init')
WARNING: arch/i386/kernel/built-in.o(.text+0xba7e): Section mismatch:
reference to .init.text: (between 'mtrr_bp_init' and 'mtrr_ap_init')
WARNING: arch/i386/kernel/built-in.o(.text+0xc4a0): Section mismatch:
reference to .init.text: (between 'get_mtrr_state' and 'mtrr_wrmsr')
WARNING: kernel/built-in.o(.text+0x17437): Section mismatch: reference to .init.text: (between 'kthreadd' and 'init_waitqueue_head')
AS arch/i386/boot/setup.o
LD arch/i386/boot/setup
OBJCOPY arch/i386/boot/compressed/vmlinux.bin

Thanks,
Jeff.

I'm a bit lost looking at those patches and don't know which ones are the appropriate ones I should I apply?

Thanks,
Jeff.

The fix is in -mm and sent to Andi.
So it will likely be merged soon.

I recommemd to ignore the warnings for now.

Sam

Thanks, I'll check when the next rc4 is ready.

Jeff.

Well, it looks like a highres-timers problem or something
like that. So I can't really be handling that, as I have no
clue about this.
I suggest you also add Gary Zambrano <zambrano-dY08KVG/lbpWk0Htik3J/[email protected]> here, as he is actually the maintainer of b44. Not me.
My role was just helping in debugging the issue, as I know
some details of b44.

Greetings Michael.

I probably wouldn't call a randconfig build problem a regression.

James, does Voyager support SMP=n now?

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

No, this is a longstanding bug that I keep meaning to find time to fix.

James

CCs stripped...

I saw the same phenomenon on a totally other machine (therefore it's likely something else):
Long periods (10-100s) of total unresponsiveness, not even SysRq-* working.

In my case it was a HP nx6125, beeing unresponsive for about 5s, also e.g. NUM Led did not work (but was still set after the unresponsive phase ended).
Looks like machine got stuck with irqs disabled?

It came out that the problem was related to cpufreq (the real cause probably came from ACPI subsytem). The freq was limited via processor (_PPC) event and limitation got removed again at the same time, letting the machine switching down and up it hang in powernow-k8. Yes, it's unlikely that it's the same problem, but disabling cpufreq should be worth a test?

Trying a kernel with CONFIG_DETECT_SOFTLOCKUP lockup should tell you at which place the machine hangs?

Thomas