login
Search
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 Networking Subject : Network card not usable - sky2 References : http://bugzilla.kernel.org/show_bug.cgi?id=8539 Submitter : Ruben <nahoo82@terra.es> Status : Unknown PCI Subject : Oops on 2.6.22-rc2 when unloading the cciss driver References : http://lkml.org/lkml/2007/5/24/172 Submitter : Mike Miller (OS Dev) <mikem@beardog.cca.cpqcorp.net> Status : Unknown PCMCIA Subject : libata and legacy ide pcmcia failure References : http://lkml.org/lkml/2007/5/17/305 Submitter : Robert de Rooy <robert.de.rooy@gmail.com> Status : Unknown SATA/PATA Subject : 22-rc3 broke the CDROM in Dell notebook References : http://lkml.org/lkml/2007/5/27/63 Submitter : Gregor Jasny <gjasny@googlemail.com> Handled-By : Tejun Heo <htejun@gmail.com> Jeff Garzik <jeff@garzik.org> Caused-By : Tejun Heo <htejun@gmail.com> commit d4b2bab4f26345ea1803feb23ea92fbe3f6b77bc Status : problem is being debugged Sparc64 Subject : 2.6.22-rc broke X on Ultra5 References : http://lkml.org/lkml/2007/5/22/78 Submitter : Mikael Pettersson <mikpe@it.uu.se> Status : Unknown Regards, Michal -- "Najbardziej brakowało mi twojego milczenia." -- Andrzej Sapkowski "Coś więcej" -
On Tue, 29 May 2007 14:56:20 +0200 Not a regression. Read the bug report: Most recent kernel where this bug did *NOT* occur: It's been happening for a long time (I'd say always). There is a regression since 2.6.22-rc1 where the b44 driver has receive performance/interrupt lockup issues. -- Stephen Hemminger <shemminger@linux-foundation.org> -
I thought this one should be fixed by commit e9ca75b53. Not so? Mike? Linus -
I apologize for the slow response. I also apologize that I don't know enough about git to figure out what commit e9ca75b53 does. I submitted a fix that was blessed by Eric B. that fixed that Oops. mikem -
Even without git, you can use the kernel.org gitweb install: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e9ca75b53 (where the "h=...." is the magic part - pick any commit SHA1 you want, including short-hand ones like the one I gave). With git, you just do git show e9ca75b53 Ok, I don't think I have anything like that. The one I pointed to is the one by Gerald Britton, acked by you .. But I now realize that that commit was already in -rc2. In fact, it's just before the -rc2 release. So while it claims to fix one oops on shutdown, it may be the _cause_ of the oops on mudule unload. Linus -
Linus,
The fix from Gerald was a different Oops and is not related to this problem.
This is the patch I submitted for the rmmod Oops:
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index e01380b..6632150 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -558,12 +558,12 @@ static int msi_free_irqs(struct pci_dev* dev)
list_for_each_entry_safe(entry, tmp, &dev->msi_list, list) {
if (entry->msi_attrib.type == PCI_CAP_ID_MSIX) {
- if (list_is_last(&entry->list, &dev->msi_list))
- iounmap(entry->mask_base);
-
writel(1, entry->mask_base + entry->msi_attrib.entry_nr
* PCI_MSIX_ENTRY_SIZE
+ PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET);
+
+ if (list_is_last(&entry->list, &dev->msi_list))
+ iounmap(entry->mask_base);
}
list_del(&entry->list);
kfree(entry);
Reference:
http://groups.google.com/group/linux.kernel/browse_frm/thread/ed0949e9d42cfdef/5953daa...
I'm not sure what the status is right now.
Thanks,
mikem
-
On Thu, 31 May 2007 17:39:08 -0500 The status is "sitting in my queue for 2.6.22". I'll be sending it up today or tomorrow. Was hoping to get an ack from Greg &/| Andi on it, but those are not easy to come by. -
Well, it looks "Obviously Correct(tm)", since clearly the iounmap() should be done _after_ the last use. So I don't think it needs any more acking. But tomorrow is fine.. Linus -
What about the changes to fix the order that MSI-X irqs are returned in (iirc, list_add had to be changed to list_add_tail in a couple of places). Without that change, multiple MSI-X interrupts seem to be broken: the kernel programs the MSI-X table in the opposite order that it gives the irq numbers to the driver. The net effect is that if I request, say, 3 MSI-X interrupts for a device, then when the device generates the first interrupt, the driver thinks it generated the third interrupt, and things go fairly haywire. - R. -
On Thu, 31 May 2007 16:17:00 -0700 That's msi-fix-the-ordering-of-msix-irqs.patch, which is also queued for the next batch. "next batch" == around 40 patches atm. Some of these need maintainer acks so they will be further delayed, or more likely just merged without the appropriate ack. From: "Eric W. Biederman" <ebiederm@xmission.com> "Mike Miller (OS Dev)" <mikem@beardog.cca.cpqcorp.net> writes: Found what seems the problem with our vectors being listed backward. In drivers/pci/msi.c we should be using list_add_tail rather than list_add to preserve the ordering across various kernels. Please consider this for inclusion. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Screwed-up-by: Michael Ellerman <michael@ellerman.id.au> Cc: "Mike Miller (OS Dev)" <mikem@beardog.cca.cpqcorp.net> Cc: Andi Kleen <ak@suse.de> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> --- drivers/pci/msi.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff -puN drivers/pci/msi.c~msi-fix-the-ordering-of-msix-irqs drivers/pci/msi.c --- a/drivers/pci/msi.c~msi-fix-the-ordering-of-msix-irqs +++ a/drivers/pci/msi.c @@ -333,7 +333,7 @@ static int msi_capability_init(struct pc msi_mask_bits_reg(pos, is_64bit_address(control)), maskbits); } - list_add(&entry->list, &dev->msi_list); + list_add_tail(&entry->list, &dev->msi_list); /* Configure MSI capability structure */ ret = arch_setup_msi_irqs(dev, 1, PCI_CAP_ID_MSI); @@ -404,7 +404,7 @@ static int msix_capability_init(struct p entry->dev = dev; entry->mask_base = base; - list_add(&entry->list, &dev->msi_list); + list_add_tail(&entry->list, &dev->msi_list); } ret = arch_setup_msi_irqs(dev, nvec, PCI_CAP_ID_MSIX); _ -