2.6.21 known regressions (v2) (for -stable team)

Hi all,

Here is a list of known regressions reported after 2.6.21 release.

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

Subject : kernel crash at boot with maxcpus=1 on quad core
kernel BUG at drivers/cpufreq/cpufreq.c:1023
References : http://lkml.org/lkml/2007/4/27/460
Submitter : Brandeburg, Jesse <[email protected]>
Status : Unknow

Subject : Soft lockup on CPU0 when resuming from suspension to ram, related to acpi processor module
References : http://bugzilla.kernel.org/show_bug.cgi?id=8391
Submitter : Giorgio Lando <[email protected]>
Status : Unknow

Subject : Bad interaction between dynticks and amarok?
References : http://lkml.org/lkml/2007/4/26/307
Submitter : Thomas Meyer <[email protected]>
Status : Unknow

Subject : Long pause initializating usb-storage
References : http://bugzilla.kernel.org/show_bug.cgi?id=8380
Submitter : Vincent Frentzel <[email protected]>
Status : Unknow

Subject : Multpiple problem when thermal is loaded with kernel 2.6.21
References : http://bugzilla.kernel.org/show_bug.cgi?id=8385
Submitter : François Valenduc <[email protected]>
Status : Unknow

Subject : 2.6.21: sky2 "hw csum failure" problem
References : http://lkml.org/lkml/2007/4/28/105
Submitter : Håkan Lindqvist <[email protected]>
Status : unknown

Subject : sky2 regression in 2.6.21: Asus P5B-E Plus ethernet adapter no more supported
References : http://lkml.org/lkml/2007/4/26/599
Submitter : Francois SIMOND <[email protected]>

Status : unknown

Subject : 2.6.21 - BUG: at arch/i386/kernel/smp.c:177 send_IPI_mask_bitmask()
References : http://lkml.org/lkml/2007/4/27/621
Submitter : Jeff Chua <[email protected]>
Status : unknown

Subject : 2.6.21 don't boot, it stops after ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 9 10 11 12 14 15).
References : http://lkml.org/lkml/2007/4/27/400
Submitter : Riccardo Ricci < [email protected] >

Status : unknown

Subject : ACPI interpreter errors
References : http://lkml.org/lkml/2007/4/27/206
Submitter : Udo A. Steinberg < [email protected] >

Status : unknown

Subject : reiserfs -- circular locking
References : http://lkml.org/lkml/2007/4/26/648
Submitter : David Brownell < [email protected] >

Patch : http://lkml.org/lkml/2007/4/27/332
Status : patch available

Regards,
Michal

Michal K. K. Piotrowski
Kernel Monkeys
(http://kernel.wikidot.com/start)
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

I went here, but without a login the page is immutable

Therefore I'll add it here

Subject :proprietary belkin upsd turns into cpu hog
Submitter :[email protected]
Reference :something changed in how /dev/ttyUSB's handle 1 and 2 byte messages
from pl2303 usb<->serial adaptors. Also, assignation of ttyUSB#'s is volatile depending on phase of the moon when booted.

Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Love is a grave mental disease.
		-- Plato

Hi Gene,

I'm not sure if I understand correctly. Is it a proprietary driver? If so, it's not a task for -stable team.

Regards,
Michal

Michal K. K. Piotrowski
Kernel Monkeys
(http://kernel.wikidot.com/start)

I'm not sure if my use of that should be dismissed out of hand because its proprietary, the point being that the pl2303 driver seems to have deteriorated over the last month or so to the point that now neither of my pl2303 cables is working, while the FTDI adaptor I put in the heyu path a month ago is working just fine. I do have another FTDI cable too, but I need to get an extension for it, 10" overall just won't reach the ups so its not yet tested.

Up until this boot to 2.6.21-cfs-v7, I could usually make that proprietary upsd driver daemon work if I killed it, reconfigured it to use whatever port it got at this bootup, kill it, restart it etc and eventually it would settle down to 0.0% cpu, and work fine. Today I had to swap ports in both its config and in heyu's after the reboot. heyu is fine now, but the pl2303 is totally, can't even cat the 1 or 2 bytes a second worth of data that should be coming from it, dead.

Hence, I'm pointing my personal finger of blame at the pl2303 driver, which I've noted has been touched a couple of times recently.

In this case, no other change in the kernel config, just swapped the sd046 patch for the cfs-v7 patch, installed and rebooted.

I started having trouble with this in the middle (roughly) of the 2.6.21-rc series.

Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Universe, n.:
	The problem.

Last time this came up, I asked you to enable debugging in the driver to see the data flow through it and find out if it really is the driver at fault here.

Did you do this? Did anything happen that was "odd"?

Can you do a 'git bisect' of Linus's tree to try to track down the issue?

That's always been the case, ever since the 2.2 kernel releases. Please use udev if you want persistent device names for your tty USB devices.

thanks,

greg k-h

I don't know how udev (or anything) could help here. AFAIK the converters have no serial numbers and no other means to differentiate.

Krzysztof Halasa

Some do have serial numbers, and others do not. You can also use hints on which port they are plugged into, which is usually the best way to name these types of things persistently.

thanks,

greg k-h

Michal, thanks for stepping up !

Len,

clockevents_notify() is called with the power verify information for an offline CPU. I can handle this in the clockevents code, but I think acpi is the correct place.

Thanks,

tglx

So the CONFIG_GENERIC_CLOCKEVENTS=y case is broken, but the CONFIG_GENERIC_CLOCKEVENTS=n below is okay? Not immediately clear why both cases can't fail.

Maybe Venki can explain.

-Len

static void acpi_propagate_timer_broadcast(struct acpi_processor *pr) {

#ifdef CONFIG_GENERIC_CLOCKEVENTS
        unsigned long reason;

        reason = pr->power.timer_broadcast_on_state < INT_MAX ?
                CLOCK_EVT_NOTIFY_BROADCAST_ON : CLOCK_EVT_NOTIFY_BROADCAST_OFF;

        clockevents_notify(reason, &pr->id);
#else
        cpumask_t mask = cpumask_of_cpu(pr->id);

        if (pr->power.timer_broadcast_on_state < INT_MAX)
                on_each_cpu(switch_APIC_timer_to_ipi, &mask, 1, 1);
        else
                on_each_cpu(switch_ipi_to_APIC_timer, &mask, 1, 1);

#endif
}

True, that's strange. Even more strange is that 2.6.21-rc7 does not have the problem, but 2.6.21 has. We did not change anything in those code pathes between rc7 and final.

Jeff, can you please verify which -rcX was the last which did not have this problem.

Thanks,

tglx

Michal,

I don't think this is a regression. What Thomas wanted to point out is, that the amarok / sound device is making the positive effect of dynticks moot, as it starts to trigger useless interrupts.

Thomas, is my interpretation correct ? Did you check, which interrupt was increasing - i.e. was it the soundcard one ?

tglx

No, it wasn't the soundcard one. but i had this effect with amarok and audacious... so, i guessed... which was wrong.

It's the timer interrupt (+50-70 timer interrupts). But i'm not sure what both applications are doing, while they are "idle"...

with kind regards
thomas

Ok, so amarok is one of those applications which arm timers for no obvious reason. If you enable CONFIG_TIMER_STATS in the kernel, you can analyse the timer offenders via the /proc/timer_stats interface.

tglx

Please remove this from the regression list. This seems to be an userspace only problem and is not related to any kernel driver:
amarok and/or audacious seems to repeatedly read/write to the X socket:

tail of the strace of audacious:
gettimeofday({1177782978, 24491}, NULL) = 0 clock_gettime(CLOCK_MONOTONIC, {224, 581502867}) = 0 clock_gettime(CLOCK_MONOTONIC, {224, 581614815}) = 0
select(4, [3], [3], NULL, NULL) = 1 (out [3])
writev(3, [{"\221\3\n\0\3\0\200\2#\0\200\2\0\6@\0\240\4\20\0L\0\20\0"..., 40}], 1) = 40
read(3, 0x80da6c8, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
gettimeofday({1177782978, 25286}, NULL) = 0
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, 9) = 0 gettimeofday({1177782978, 33242}, NULL) = 0
read(3, 0x80da6c8, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
gettimeofday({1177782978, 33475}, NULL) = 0
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, 1) = 0 gettimeofday({1177782978, 36548}, NULL) = 0 clock_gettime(CLOCK_MONOTONIC, {224, 593554129}) = 0
read(3, 0x80da6c8, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
gettimeofday({1177782978, 36921}, NULL) = 0
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, 9) = 0 gettimeofday({1177782978, 46572}, NULL) = 0 clock_gettime(CLOCK_MONOTONIC, {224, 603578038}) = 0 clock_gettime(CLOCK_MONOTONIC, {224, 603689148}) = 0
select(4, [3], [3], NULL, NULL) = 1 (out [3])
writev(3, [{"\221\3\n\0\3\0\200\2#\0\200\2\0\6@\0\0\4 \0L\0\20\0\23"..., 40}], 1) = 40
read(3, 0x80da6c8, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
gettimeofday({1177782978, 47341}, NULL) = 0
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, 9) = 0 gettimeofday({1177782978, 56566}, NULL) = 0
read(3, 0x80da6c8, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
gettimeofday({1177782978, 56799}, NULL) = 0
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, 0) = 0 clock_gettime(CLOCK_MONOTONIC, {224, 613921380}) = 0
read(3, 0x80da6c8, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
gettimeofday({1177782978, 57282}, NULL) = 0
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, 9) = 0 gettimeofday({1177782978, 67696}, NULL) = 0 clock_gettime(CLOCK_MONOTONIC, {224, 624704202}) = 0 clock_gettime(CLOCK_MONOTONIC, {224, 624817966}) = 0
select(4, [3], [3], NULL, NULL) = 1 (out [3])
writev(3, [{"\221\3\n\0\3\0\200\2#\0\200\2\0\6@\0P\4 \0L\0\20\0\23\0"..., 40}], 1) = 40
read(3, 0x80da6c8, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
gettimeofday({1177782978, 68476}, NULL) = 0
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, 9) = 0 gettimeofday({1177782978, 76564}, NULL) = 0
read(3, 0x80da6c8, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
gettimeofday({1177782978, 76796}, NULL) = 0
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, 0) = 0 clock_gettime(CLOCK_MONOTONIC, {224, 633919963}) = 0
read(3, 0x80da6c8, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
gettimeofday({1177782978, 77280}, NULL) = 0
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}], 2, 9) = 0 gettimeofday({1177782978, 86898}, NULL) = 0 clock_gettime(CLOCK_MONOTONIC, {224, 643911329}) = 0 clock_gettime(CLOCK_MONOTONIC, {224, 644025581}) = 0
select(4, [3], [3], NULL, NULL) = 1 (out [3])
writev(3, [{"\221\3\n\0\3\0\200\2#\0\200\2\0\6@\0\240\4 \0L\0\20\0\23"..., 40}], 1) = 40
read(3, 0x80da6c8, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
gettimeofday({1177782978, 87702}, NULL) = 0
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN, revents=POLLIN}], 2,
9) = 1
read(3, "\n\3P\v\4\0\200\2\0\0\0\0\210v\274\277r\300\10\10x\35!"..., 4096) = 96
read(3, 0x80da6c8, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
read(3, 0x80da6c8, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
read(3, 0x80da6c8, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
gettimeofday({1177782978, 90108}, NULL) = 0 gettimeofday({1177782978, 90163}, NULL) = 0

But i didn't have a look at what is going on here. But running amarok and/or audacious (without playing a song!) adds 50-70 more interrupts to the timer interrupt.

with kind regards
thomas

OK - I added it just to be sure that there wasn't any dynticks regression, it's gone now.
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

This is not a "regression" it is a bug, that has shown up for some users for quite a while, see:
http://bugzilla.kernel.org/show_bug.cgi?id=7579

Stephen Hemminger <[email protected]>

It's not a regression in 2.6.21, but it is a regression as there is an earlier kernel version where the sky2 driver works properly with this card.

To me it doesn't really matter which way the problem is classified. I'm just hoping that there will be a chance of moving past 2.6.16 on this machine at some point.

Regards,
Håkan Lindqvist