Skip to contentSkip to conversation

2.6.22-rc6: known regressions v2

PATCH In review Michal Piotrowski 5 participants 9 messages Jun 29, 2007 libata

lore
Share & tools
lore
#0 lore raw

PATCH 1/2 2.6.22-rc6: known regressions v2

Hi all,

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

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

List of Aces

Name Regressions fixed since 21-Jun-2007
Hugh Dickins 2
Andi Kleen 1
Björn Steinbrink 1

Bjorn Helgaas                          1
Jean Delvare                           1
Olaf Hering                            1
Siddha, Suresh B                       1
Trent Piepho                           1

Ville Syrjälä 1

Unclassified

Subject : Kernel hang on CMOS_READ
References : http://lkml.org/lkml/2007/6/3/138
Submitter : Rodrigo Luiz <[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 <[email protected]>

Status : Unknown

FS

Subject : 2.6.22-rc4-git5 reiserfs: null ptr deref.
References : http://lkml.org/lkml/2007/6/13/322
Submitter : Randy Dunlap <[email protected]>

Status : problem is being debugged

IDE

Subject : 2.6.22-rcX: hda: lost interrupt
References : http://lkml.org/lkml/2007/6/29/121
Submitter : David Chinner <[email protected]>
Status : unknown

SATA/PATA

Subject : libata IT821X driver still fails! Hard-freezes system
References : http://lkml.org/lkml/2007/6/14/82
Submitter : Rodney Gordon II <[email protected]>
Status : unknown

Regards,
Michal

--
LOG
http://www.stardust.webpages.pl/log/

#1 lore raw
Quoted 6 lines

SATA/PATA

Subject : libata IT821X driver still fails! Hard-freezes system
References : http://lkml.org/lkml/2007/6/14/82
Submitter : Rodney Gordon II <[email protected]>
Status : unknown

Not a regression as it seems this user's box has always been broken. I've been running heavy testing with 2.6.22rc6 and IT8212 and its working reliably for the "dumb" mode in question.

The hardware mode needs a fix Tejun has queued somewhere (probably in Jeff's vast backlog) and then works too.

I'm not even sure this report is IT8212 related rather than just an IRQ storm

#2 lore raw
Quoted 11 lines · Alan Cox
Quoted 6 lines

SATA/PATA

Subject : libata IT821X driver still fails! Hard-freezes system
References : http://lkml.org/lkml/2007/6/14/82
Submitter : Rodney Gordon II <[email protected]>
Status : unknown

Not a regression as it seems this user's box has always been broken. I've been running heavy testing with 2.6.22rc6 and IT8212 and its working reliably for the "dumb" mode in question.

Quoted 5 lines

The hardware mode needs a fix Tejun has queued somewhere (probably in Jeff's vast backlog) and then works too.

I'm not even sure this report is IT8212 related rather than just an IRQ storm

Why does the driver report "irq 0"?

ata7: PATA max UDMA/133 cmd <blah> ctl <blah> bmdma <blah> irq 0 <====

Above that, the ACPI layer says it assigned IRQ 20

#3 lore raw
Quoted 8 lines
Quoted 2 lines

I'm not even sure this report is IT8212 related rather than just an IRQ storm

Why does the driver report "irq 0"?

ata7: PATA max UDMA/133 cmd <blah> ctl <blah> bmdma <blah> irq 0 <====

Above that, the ACPI layer says it assigned IRQ 20

Because the libata core code in 2.6.22rc6 reports all the ports and IRQ values wrongly ?

Alan

#4 lore raw
Quoted 10 lines · Alan Cox
Quoted 7 lines
Quoted 2 lines

I'm not even sure this report is IT8212 related rather than just an IRQ storm

Why does the driver report "irq 0"?

ata7: PATA max UDMA/133 cmd <blah> ctl <blah> bmdma <blah> irq 0 <====

Above that, the ACPI layer says it assigned IRQ 20

Because the libata core code in 2.6.22rc6 reports all the ports and IRQ values wrongly ?

AFAIK that was fixed, for IRQ. Please point out examples where it remains broken...

Jeff

#5 lore raw
Quoted 7 lines · On Fri, 29 Jun 2007 14:10:49 -0400 Jeff Garzik <[email protected]> wrote:
Quoted 6 lines · Alan Cox
Quoted 6 lines
Quoted 2 lines

I'm not even sure this report is IT8212 related rather than just an IRQ storm

Why does the driver report "irq 0"?

ata7: PATA max UDMA/133 cmd <blah> ctl <blah> bmdma <blah> irq 0 <====

Quoted 7 lines
Quoted 4 lines
Quoted 1 line

Above that, the ACPI layer says it assigned IRQ 20

Because the libata core code in 2.6.22rc6 reports all the ports and IRQ values wrongly ?

AFAIK that was fixed, for IRQ. Please point out examples where it remains broken...

2.6.22-rc6 it is broken, for all the systems I've looked at, as are the port numbers. Tejun posted fixes for the IRQ but they do not seem to have been applied, or if they were it was post -rc6 to a git tree.

Alan

#6 lore raw
Quoted 10 lines · Alan Cox
Quoted 7 lines · On Fri, 29 Jun 2007 14:10:49 -0400 Jeff Garzik <[email protected]> wrote:
Quoted 6 lines · Alan Cox
Quoted 6 lines
Quoted 2 lines

I'm not even sure this report is IT8212 related rather than just an IRQ storm

Why does the driver report "irq 0"?

ata7: PATA max UDMA/133 cmd <blah> ctl <blah> bmdma <blah> irq 0 <====

Quoted 8 lines
Quoted 4 lines
Quoted 3 lines
Quoted 1 line

Above that, the ACPI layer says it assigned IRQ 20

Because the libata core code in 2.6.22rc6 reports all the ports and IRQ values wrongly ?

AFAIK that was fixed, for IRQ. Please point out examples where it remains broken...

2.6.22-rc6 it is broken, for all the systems I've looked at, as are the port numbers. Tejun posted fixes for the IRQ but they do not seem to have been applied, or if they were it was post -rc6 to a git tree.

I've seen the patch that eventually became 22888423b3b1b96573250671afb5b72ea4364902 from Olof Johansson but nothing from Tejun on the subject.

Jeff

#8 lore raw
In reply to Michal Piotrowski

Hello.

Quoted 9 lines · Michal Piotrowski

IDE

Subject : 2.6.22-rcX: hda: lost interrupt
References : http://lkml.org/lkml/2007/6/29/121
Submitter : David Chinner <[email protected]>
Status : unknown

Probing IDE interface ide0...
hda: probing with STATUS(0xa0) instead of ALTSTATUS(0x58)

Ugh, 0xa0 is the device/head register's value, not the status register's!
I'd suppose that I/O space was borken in some funny way, however, it would be hard top expect form x86 which should be prone to endiannes blues...

MBR, Sergei