Happy New Year (and v2.6.20-rc3 released)

Quoted 3 lines · Linus Torvalds

Alexey Dobriyan (2):
V4L/DVB (5012): Usbvision fix: It was using "&&" instead "&"
fuse: fix typo

Second is from Thomas Hisch <[email protected]>, actually.

Cyrill V. Gorcnov

2007-01-01 07:24 UTC #3 lore raw

In reply to Cyrill V. Gorcnov

On Monday 01 January 2007 04:19, you wrote:

|  
|  In order to not get in trouble with MADR ("Mothers Against Drunk 
|  Releases") I decided to cut the 2.6.20-rc3 release early rather than wait 
|  for midnight, because it's bound to be new years _somewhere_ out there. So 
|  here's to a happy 2007 for everybody.
|

I've tried to clone linux git repo and got:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
fatal: unexpected EOF
fetch-pack from 'git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git' failed.

What's wrong?

Happy New Year ;)

Signature · 1 line

	- Cyrill

A message that is not in the archive (sent off-list or not yet received): [email protected]

Cyrill V. Gorcnov

2007-01-01 09:42 UTC #5 lore raw

On Monday 01 January 2007 10:45, you wrote:

|  Cyrill V. Gorcnov wrote:
|  > On Monday 01 January 2007 04:19, you wrote:
|  > |  
|  > |  In order to not get in trouble with MADR ("Mothers Against Drunk 
|  > |  Releases") I decided to cut the 2.6.20-rc3 release early rather than wait 
|  > |  for midnight, because it's bound to be new years _somewhere_ out there. So 
|  > |  here's to a happy 2007 for everybody.
|  > |  
|  > 
|  > I've tried to clone linux git repo and got:
|  > 
|  > 	git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
|  > 	fatal: unexpected EOF
|  > 	fetch-pack from 'git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git' failed.
|  > 
|  > What's wrong?
|  
|  I think that git does not like year rollover.  I've tried it after Linus 
|  sent message out, and it was not giving me anything new (cca from 5PM 
|  PST when Linus sent change to 8PM).  Then it gave out random changes 
|  (8PM to 9PM).  After that it was dead, as you've noticed.  But after 
|  that I was able to get 2.6.20-rc3 out - compiling now.   So perhaps just 
|  try it again...
|  								Petr
|  
|  P.S.: Happy New Year.  Here in California we still have 15 minutes of 
|  year 2006 to go.
|  
|  
|

Yea, I've got linux git clone later. I think that was some files activity on git server so that is why I was noticed with "fatal: unexpected EOF" git message.

Signature · 1 line

	- Cyrill

H. Peter Anvin

2007-01-02 02:19 UTC #6 lore raw

Quoted 6 lines · Cyrill V. Gorcnov

On Monday 01 January 2007 04:19, you wrote:

|  |  In order to not get in trouble with MADR ("Mothers Against Drunk |  Releases") I decided to cut the 2.6.20-rc3 release early rather than wait |  for midnight, because it's bound to be new years _somewhere_ out there. So |  here's to a happy 2007 for everybody.
|

I've tried to clone linux git repo and got:

Quoted 8 lines

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
fatal: unexpected EOF
fetch-pack from 'git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git' failed.
What's wrong?
Happy New Year ;)

Look at http://www.kernel.org/. Currently, the git daemon stops serving new clients at loadavg 200.

-hpa

Arkadiusz Miskiewicz

2007-01-01 11:29 UTC #7 lore raw

Quoted 4 lines · Linus Torvalds

In order to not get in trouble with MADR ("Mothers Against Drunk Releases") I decided to cut the 2.6.20-rc3 release early rather than wait for midnight, because it's bound to be new years _somewhere_ out there. So here's to a happy 2007 for everybody.

I hope that upcoming gcc 4.2 will be considered as supported compiler before final 2.6.20 release and patch which broke build is reverted or the thing fixed :)

MODPOST 1371 modules
WARNING: "_proxy_pda" [fs/fuse/fuse.ko] undefined! make[1]: *** [__modpost] Błąd 1

+ some other modules which I didn't enable this time

Signature · 2 lines

Arkadiusz Miśkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/

Alessandro Suardi

2007-01-01 13:28 UTC #8 lore raw

Quoted 14 lines · Linus Torvalds

In order to not get in trouble with MADR ("Mothers Against Drunk Releases") I decided to cut the 2.6.20-rc3 release early rather than wait for midnight, because it's bound to be new years _somewhere_ out there. So here's to a happy 2007 for everybody.
The big thing at least for me personally is that nasty shared mmap corruption fix, but there's a number of other changes in here, many of them just documentation (and some media and network drivers). Shortlog and diffstat appended..
The git trees have been updated, and the tar-tree and patches seem to have finisged crawling out my poor DSL connection too.

Quoted 8 lines

As usual, mirroring might take a while, although the delay has not been all that horrible lately, so it's probably going to be up-to-date by the time the hangovers are mostly gone.
At which point the first thing on any self-respecting geek's mind should obviously be: "is there a new kernel release for me to try?"
Right?

Right ! And this one is still broken in -rc3:

Subject : kernel panics on boot (libata-sff)
References : http://lkml.org/lkml/2006/12/3/99

           http://lkml.org/lkml/2006/12/14/153
           http://lkml.org/lkml/2006/12/24/33

Submitter : Alessandro Suardi <[email protected]>

Caused-By Alan Cox <[email protected]>

           commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f

Handled-By Alan Cox <[email protected]>

Status : people are working on a fix

Happy 2007 everyone,

--alessandro

"...when I get it, I _get_ it"

(Lara Eidemiller)

Linus Torvalds

author

2007-01-01 20:13 UTC #9 lore raw

Jeff,
what was the resolution to this one? Just revert the offending commit, or
what?

We're about five weeks into the 2.6.20-rc series. I was hoping for a two-month release rather than the usual dragged-out three months, so I'd like to get these regressions to be actively fixed. By forcible reverts if that is what it takes.

Linus

Quoted 21 lines · Alessandro Suardi

Right ! And this one is still broken in -rc3:
Subject : kernel panics on boot (libata-sff)
References : http://lkml.org/lkml/2006/12/3/99
           http://lkml.org/lkml/2006/12/14/153
           http://lkml.org/lkml/2006/12/24/33
Submitter : Alessandro Suardi <[email protected]>
Caused-By Alan Cox <[email protected]>
           commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f
Handled-By Alan Cox <[email protected]>
Status : people are working on a fix
Happy 2007 everyone,
--alessandro
"...when I get it, I _get_ it"
(Lara Eidemiller)

Jeff Garzik

2007-01-01 20:50 UTC #10 lore raw

Quoted 5 lines · Linus Torvalds

Jeff,
what was the resolution to this one? Just revert the offending commit, or
what?
We're about five weeks into the 2.6.20-rc series. I was hoping for a two-month release rather than the usual dragged-out three months, so I'd like to get these regressions to be actively fixed. By forcible reverts if that is what it takes.

Data points:

* I was unable to argue against Alan's logic behind 368c73d4f689dae0807d0a2aa74c61fd2b9b075f but I just don't like it. Regardless of whether or not this truly reflects how the PCI device is wired, it makes pci_request_regions() and similar resource handling code behave differently.

* Alan's 368c73d4f689dae0807d0a2aa74c61fd2b9b075f change was IMO incomplete, because he obviously did not fix all the breakage it caused

* Alan proposed a libata fix patch. I noted two key breakages in his fix patch, one of which Alan agreed was a problem.

* Outside of the two bugfix pushes, I've been actively avoiding computers during the holidays. It's a shocking concept I'm trying with the new wife :) Don't expect anything useful from me until Jan 4th or so.

* This affects a lot of Intel ICH platforms in legacy/combined mode, so it's definitely high on my post-holiday priority list. If the patch is not reverted, then I'll definitely fix it sooner rather than later.

* For 2.6.21, I proposed to yank out all the ugly combined mode hacks (grep for '____request_resource'), which should make Alan's change a bit easier... but nonetheless stirs the IDE quirks code again.

* I am lazy and would rather not touch the fragile ata_pci_init_one() code now /and/ in 2.6.21.

So I vote for revert, for 2.6.20, but I know Alan will squawk loudly. Also NOTE thoughfb0f2b40faff41f03acaa2ee6e6231fc96ca497c which fixes fallout from Alan's change, too.

Jeff

Alan

2007-01-01 21:22 UTC #11 lore raw

Quoted 5 lines

* I was unable to argue against Alan's logic behind 368c73d4f689dae0807d0a2aa74c61fd2b9b075f but I just don't like it. Regardless of whether or not this truly reflects how the PCI device is wired, it makes pci_request_regions() and similar resource handling code behave differently.

Correctly: The resource tree is no longer corrupt for example and pci_* resource functions actually now do the right thing. The old code works by chance due to link order, not because anything was "broken" by the corrections.

Quoted 2 lines

* Alan proposed a libata fix patch. I noted two key breakages in his fix patch, one of which Alan agreed was a problem.

Not a "2.6.20 stopping problem" and trivial to fix further.

Quoted 3 lines

So I vote for revert, for 2.6.20, but I know Alan will squawk loudly. Also NOTE thoughfb0f2b40faff41f03acaa2ee6e6231fc96ca497c which fixes fallout from Alan's change, too.

I'm very concerned about what that will break that depends upon it - eg all the work done for suspend/resume PCI handling has not been tested without the patch. Thus I'd rather fix it given the fix is trivial.

Want a fix Linus given Jeff is away ?

Alan

Linus Torvalds

author

2007-01-01 23:35 UTC #12 lore raw

Quoted 2 lines · Alan

Want a fix Linus given Jeff is away ?

Send it over, and please cc Alessandro and others that can test it. Things obviously aren't broken on _my_ machines ;)

And if we end up having more problems related to this in -rc4, I'll just revert both your fix and the original one. No hair lost over this one, I think.

Linus

Theodore Tso

2007-01-02 02:33 UTC #13 lore raw

Quoted 8 lines · Linus Torvalds

Quoted 2 lines · Alan
Want a fix Linus given Jeff is away ?
Send it over, and please cc Alessandro and others that can test it. Things obviously aren't broken on _my_ machines ;)

Can I get a copy of the fix for testing as well? I can confirm that Alan's 368c73d4f689dae0807d0a2aa74c61fd2b9b075f breaks for me on my T60 thinkpad. Unfortunately I missed the earlier discussion on this, and I didn't have time to test -rc1 and -rc2, so I spent a few hours doing the git bisection in order to determine that it was Alan's 2b9b075f patch which was breaking -rc3 for me.

My current plan for testing -rc3 was to back out Alan's patch (attached below for others' convenience), but I'm happy to test an alternative fix.

- Ted

Revert "PCI: quirks: fix the festering mess that claims to handle IDE quirks"

This reverts commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f.

This is needed to fix booting on a Thinkpad T60. Without this patch, we see the following error messages, and the SATA drive in the laptop isn't detected, with the following messages printed during the boot sequence:

ata_piix 0000:00:1f.2: MAP [ P0 P2 IDE IDE ]
ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 16 (level, low) -> IRQ 16
PCI: Unable to reserve I/O Region #1:8@1f0 for device 0000:00:1f.2
ata_piix: probe of 0000:00:1f.2 failed with error -16

Signed-off-by "Theodore Ts'o" <[email protected]>

---
 arch/i386/pci/fixup.c |   46 ++++++++++++++++++++++++++++++++++++++
 drivers/pci/probe.c   |   27 ----------------------
 drivers/pci/quirks.c  |   59 ++++++++++++++++++++++++++++++++++++++++++++++--
 3 files changed, 102 insertions(+), 30 deletions(-)

arch/i386/pci/fixup.c +46 -0

index 8053b17..422483e 100644
@@ -74,6 +74,52 @@ static void __devinit  pci_fixup_ncr53c810(struct pci_dev *d)
 }
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NCR, PCI_DEVICE_ID_NCR_53C810, pci_fixup_ncr53c810);
 
+static void __devinit pci_fixup_ide_bases(struct pci_dev *d)
+{
+	int i;
+
+	/*
+	 * PCI IDE controllers use non-standard I/O port decoding, respect it.
+	 */
+	if ((d->class >> 8) != PCI_CLASS_STORAGE_IDE)
+		return;
+	DBG("PCI: IDE base address fixup for %s\n", pci_name(d));
+	for(i=0; i<4; i++) {
+		struct resource *r = &d->resource[i];
+		if ((r->start & ~0x80) == 0x374) {
+			r->start |= 2;
+			r->end = r->start;
+		}
+	}
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, pci_fixup_ide_bases);
+
+static void __devinit  pci_fixup_ide_trash(struct pci_dev *d)
+{
+	int i;
+
+	/*
+	 * Runs the fixup only for the first IDE controller
+	 * (Shai Fultheim - [email protected])
+	 */
+	static int called = 0;
+	if (called)
+		return;
+	called = 1;
+
+	/*
+	 * There exist PCI IDE controllers which have utter garbage
+	 * in first four base registers. Ignore that.
+	 */
+	DBG("PCI: IDE base address trash cleared for %s\n", pci_name(d));
+	for(i=0; i<4; i++)
+		d->resource[i].start = d->resource[i].end = d->resource[i].flags = 0;
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_5513, pci_fixup_ide_trash);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801CA_10, pci_fixup_ide_trash);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801CA_11, pci_fixup_ide_trash);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82801DB_9, pci_fixup_ide_trash);
+
 static void __devinit  pci_fixup_latency(struct pci_dev *d)
 {
 	/*

drivers/pci/probe.c +0 ~~-27~~

index 0e0401d..8e077b1 100644
@@ -681,33 +681,6 @@ static int pci_setup_device(struct pci_dev * dev)
 		pci_read_bases(dev, 6, PCI_ROM_ADDRESS);
 		pci_read_config_word(dev, PCI_SUBSYSTEM_VENDOR_ID, &dev->subsystem_vendor);
 		pci_read_config_word(dev, PCI_SUBSYSTEM_ID, &dev->subsystem_device);
-
-		/*
-		 *	Do the ugly legacy mode stuff here rather than broken chip
-		 *	quirk code. Legacy mode ATA controllers have fixed
-		 *	addresses. These are not always echoed in BAR0-3, and
-		 *	BAR0-3 in a few cases contain junk!
-		 */
-		if (class == PCI_CLASS_STORAGE_IDE) {
-			u8 progif;
-			pci_read_config_byte(dev, PCI_CLASS_PROG, &progif);
-			if ((progif & 1) == 0) {
-				dev->resource[0].start = 0x1F0;
-				dev->resource[0].end = 0x1F7;
-				dev->resource[0].flags = LEGACY_IO_RESOURCE;
-				dev->resource[1].start = 0x3F6;
-				dev->resource[1].end = 0x3F6;
-				dev->resource[1].flags = LEGACY_IO_RESOURCE;
-			}
-			if ((progif & 4) == 0) {
-				dev->resource[2].start = 0x170;
-				dev->resource[2].end = 0x177;
-				dev->resource[2].flags = LEGACY_IO_RESOURCE;
-				dev->resource[3].start = 0x376;
-				dev->resource[3].end = 0x376;
-				dev->resource[3].flags = LEGACY_IO_RESOURCE;
-			}
-		}
 		break;
 
 	case PCI_HEADER_TYPE_BRIDGE:		    /* bridge header */

drivers/pci/quirks.c +56 -3

81 lines not on this page · raw message

Signature · 1 line

1.5.0.rc0.g1d42

Alan

2007-01-02 11:48 UTC #14 lore raw

PATCH 1/1 libata: fix combined mode (was Re: Happy New Year (and v2.6.20-rc3 released))

In reply to Jeff Garzik

This is a slight variant on the patch I posted December 16th to fix libata combined mode handling. The only real change is that we now correctly also reserve BAR1,2,4. That is basically a neatness issue.

Jeff was unhappy about two things

1. That it didn't work in the case of one channel native one channel legacy.

This is a silly complaint because the SFF layer in libata doesn't handle this case yet anyway.

2. The case where combined mode is in use and IDE=n.

In this case the libata quirk code reserves the resources in question correctly already.

Once the combined mode stuff is redone properly (2.6.21) then the entire mess turns into a single pci_request_regions() for all cases and all the ugly resource hackery goes away.

I'm sending this now rather than after running full test suites so that it can get the maximal testing in a short time. I'll be running tests on this after lunch.

Signed-off-by Alan Cox <[email protected]>

drivers/ata/libata-sff.c +30 ~~-12~~

@@ -1027,13 +1027,15 @@
 #endif
 	}
 
-	rc = pci_request_regions(pdev, DRV_NAME);
-	if (rc) {
-		disable_dev_on_err = 0;
-		goto err_out;
-	}
-
-	if (legacy_mode) {
+	if (!legacy_mode) {
+		rc = pci_request_regions(pdev, DRV_NAME);
+		if (rc) {
+			disable_dev_on_err = 0;
+			goto err_out;
+		}
+	} else {
+		/* Deal with combined mode hack. This side of the logic all
+		   goes away once the combined mode hack is killed in 2.6.21 */
 		if (!request_region(ATA_PRIMARY_CMD, 8, "libata")) {
 			struct resource *conflict, res;
 			res.start = ATA_PRIMARY_CMD;

@@ -1071,6 +1073,13 @@
 			}
 		} else
 			legacy_mode |= ATA_PORT_SECONDARY;
+
+		if (legacy_mode & ATA_PORT_PRIMARY)
+			pci_request_region(pdev, 1, DRV_NAME);
+		if (legacy_mode & ATA_PORT_SECONDARY)
+			pci_request_region(pdev, 3, DRV_NAME);
+		/* If there is a DMA resource, allocate it */
+		pci_request_region(pdev, 4, DRV_NAME);
 	}
 
 	/* we have legacy mode, but all ports are unavailable */

@@ -1114,11 +1123,20 @@
 err_out_ent:
 	kfree(probe_ent);
 err_out_regions:
-	if (legacy_mode & ATA_PORT_PRIMARY)
-		release_region(ATA_PRIMARY_CMD, 8);
-	if (legacy_mode & ATA_PORT_SECONDARY)
-		release_region(ATA_SECONDARY_CMD, 8);
-	pci_release_regions(pdev);
+	/* All this conditional stuff is needed for the combined mode hack
+	   until 2.6.21 when it can go */
+	if (legacy_mode) {
+		pci_release_region(pdev, 4);
+		if (legacy_mode & ATA_PORT_PRIMARY) {
+			release_region(ATA_PRIMARY_CMD, 8);
+			pci_release_region(pdev, 1);
+		}
+		if (legacy_mode & ATA_PORT_SECONDARY) {
+			release_region(ATA_SECONDARY_CMD, 8);
+			pci_release_region(pdev, 3);
+		}
+	} else
+		pci_release_regions(pdev);
 err_out:
 	if (disable_dev_on_err)
 		pci_disable_device(pdev);

Alessandro Suardi

2007-01-02 12:07 UTC #15 lore raw

Re: [PATCH] libata: fix combined mode (was Re: Happy New Year (and v2.6.20-rc3 released))

Quoted 83 lines · Alan

Jeff was unhappy about two things

1. That it didn't work in the case of one channel native one channel legacy.

This is a silly complaint because the SFF layer in libata doesn't handle this case yet anyway.

2. The case where combined mode is in use and IDE=n.

In this case the libata quirk code reserves the resources in question correctly already.

Once the combined mode stuff is redone properly (2.6.21) then the entire mess turns into a single pci_request_regions() for all cases and all the ugly resource hackery goes away.

I'm sending this now rather than after running full test suites so that it can get the maximal testing in a short time. I'll be running tests on this after lunch.

Signed-off-by Alan Cox <[email protected]>

drivers/ata/libata-sff.c 2007-01-02 11:15:53.000000000 +0000 renamed from drivers/ata/libata-sff.c 2007-01-01 21:43:27.000000000 +0000 +23 ~~-12~~

@@ -1027,13 +1027,15 @@
 #endif
        }
 
-       rc = pci_request_regions(pdev, DRV_NAME);
-       if (rc) {
-               disable_dev_on_err = 0;
-               goto err_out;
-       }
-
-       if (legacy_mode) {
+       if (!legacy_mode) {
+               rc = pci_request_regions(pdev, DRV_NAME);
+               if (rc) {
+                       disable_dev_on_err = 0;
+                       goto err_out;
+               }
+       } else {
+               /* Deal with combined mode hack. This side of the logic all
+                  goes away once the combined mode hack is killed in 2.6.21 */
                if (!request_region(ATA_PRIMARY_CMD, 8, "libata")) {
                        struct resource *conflict, res;
                        res.start = ATA_PRIMARY_CMD;

@@ -1071,6 +1073,13 @@
                        }
                } else
                        legacy_mode |= ATA_PORT_SECONDARY;
+
+               if (legacy_mode & ATA_PORT_PRIMARY)
+                       pci_request_region(pdev, 1, DRV_NAME);
+               if (legacy_mode & ATA_PORT_SECONDARY)
+                       pci_request_region(pdev, 3, DRV_NAME);
+               /* If there is a DMA resource, allocate it */
+               pci_request_region(pdev, 4, DRV_NAME);
        }
 
        /* we have legacy mode, but all ports are unavailable */

@@ -1114,11 +1123,20 @@
 err_out_ent:
        kfree(probe_ent);
 err_out_regions:
-       if (legacy_mode & ATA_PORT_PRIMARY)
-               release_region(ATA_PRIMARY_CMD, 8);
-       if (legacy_mode & ATA_PORT_SECONDARY)
-               release_region(ATA_SECONDARY_CMD, 8);
-       pci_release_regions(pdev);
+       /* All this conditional stuff is needed for the combined mode hack
+          until 2.6.21 when it can go */
+       if (legacy_mode) {
+               pci_release_region(pdev, 4);
+               if (legacy_mode & ATA_PORT_PRIMARY) {
+                       release_region(ATA_PRIMARY_CMD, 8);
+                       pci_release_region(pdev, 1);

drivers/ata/libata-sff.c 2007-01-02 11:15:53.000000000 +0000 line 1142

Quoted 10 lines

drivers/ata/libata-sff.c 2007-01-02 11:15:53.000000000 +0000 renamed from drivers/ata/libata-sff.c 2007-01-01 21:43:27.000000000 +0000 +7 -0

+               }
+               if (legacy_mode & ATA_PORT_SECONDARY) {
+                       release_region(ATA_SECONDARY_CMD, 8);
+                       pci_release_region(pdev, 3);
+               }
+       } else
+               pci_release_regions(pdev);
 err_out:
        if (disable_dev_on_err)
                pci_disable_device(pdev);

Appears to work just fine here (compiles, boots and I'm typing this email :). The build warnings below seem new to me - but I guess they're harmless...

CC drivers/ata/libata-sff.o
drivers/ata/libata-sff.c: In function 'ata_pci_init_one':
drivers/ata/libata-sff.c:1078: warning: ignoring return value of 'pci_request_region', declared with attribute warn_unused_result drivers/ata/libata-sff.c:1080: warning: ignoring return value of 'pci_request_region', declared with attribute warn_unused_result drivers/ata/libata-sff.c:1082: warning: ignoring return value of 'pci_request_region', declared with attribute warn_unused_result

Thanks, ciao,

--alessandro

"but I thought that I should let you know
the things that I don't always show
might not be worth the time it took"

(Steve Wynn, 'If My Life Was An Open Book')

Alan

2007-01-02 13:50 UTC #16 lore raw

Re: [PATCH] libata: fix combined mode (was Re: Happy New Year (and v2.6.20-rc3 released))

Quoted 3 lines

Appears to work just fine here (compiles, boots and I'm
typing this email :). The build warnings below seem new to me - but I guess they're harmless...

They are harmless. For the 2.6.21 code base they will go away as well.

Theodore Tso

2007-01-02 16:12 UTC #17 lore raw

Re: [PATCH] libata: fix combined mode (was Re: Happy New Year (and v2.6.20-rc3 released))

Quoted 3 lines · Alan

This is a slight variant on the patch I posted December 16th to fix libata combined mode handling. The only real change is that we now correctly also reserve BAR1,2,4. That is basically a neatness issue.

Thanks,

I can confirm that with this patch applied, I can boot 2.6.20-rc3 on my Thinkpad T60p. My primary laptop is now running the with the patch, and I'll start pushing it through its paces. If start losing any files or seeing any disk corruption I'll let folks now.

- Ted

Jeff Garzik

2007-01-02 21:01 UTC #18 lore raw

Re: [PATCH] libata: fix combined mode (was Re: Happy New Year (and v2.6.20-rc3 released))

Quoted 11 lines · Alan

This is a slight variant on the patch I posted December 16th to fix libata combined mode handling. The only real change is that we now correctly also reserve BAR1,2,4. That is basically a neatness issue.
Jeff was unhappy about two things
1. That it didn't work in the case of one channel native one channel legacy.
This is a silly complaint because the SFF layer in libata doesn't handle this case yet anyway.

Yes, it's "silly" people people use configurations you find inconvenient.

At least one embedded x86 case cares, that I know of. They only needed to make two minor changes to make it work.

Quoted 4 lines

2. The case where combined mode is in use and IDE=n.
In this case the libata quirk code reserves the resources in question correctly already.

Not /all/ the resources. And YOU were the person harping me about acquiring all resources, so that even races no one cares about[1] are avoided.

But those two items were just from my five-minute, on-vacation review. Obvious bug #3:

The code no long reserves resources for the "extra" PCI BAR that often exists on PCI controllers regardless of legacy/native mode. Previously, the code called pci_request_regions() to reserve ALL regions attached to the PCI device.

You have suddenly decided that it's OK to --not reserve at all-- these additional regions.

Proof: The AHCI PCI BAR (#5, zero-based) is clearly NOT reserved, even though we talk to it, in piix_disable_ahci() of ata_piix.c.

Jeff

Alan

2007-01-02 21:17 UTC #19 lore raw

Re: [PATCH] libata: fix combined mode (was Re: Happy New Year (and v2.6.20-rc3 released))

Quoted 7 lines

Quoted 2 lines
This is a silly complaint because the SFF layer in libata doesn't handle this case yet anyway.
Yes, it's "silly" people people use configurations you find inconvenient.
At least one embedded x86 case cares, that I know of. They only needed to make two minor changes to make it work.

*It is not part of 2.6.20*

Quoted 4 lines

The code no long reserves resources for the "extra" PCI BAR that often exists on PCI controllers regardless of legacy/native mode. Previously, the code called pci_request_regions() to reserve ALL regions attached to the PCI device.

We use BAR5 on two devices in legacy mode. Both of those reserve all the other resources. We can fix BAR5 in .21 when all the combined mode crap goes away.

Quoted 2 lines

You have suddenly decided that it's OK to --not reserve at all-- these additional regions.

It's not ideal - but it is perfectly sufficient for 2.6.20

Quoted 2 lines

Proof: The AHCI PCI BAR (#5, zero-based) is clearly NOT reserved, even though we talk to it, in piix_disable_ahci() of ata_piix.c.

We always claim the other BARs so catch a collision.

Alan

Jeff Garzik

2007-01-02 21:29 UTC #20 lore raw

Re: [PATCH] libata: fix combined mode (was Re: Happy New Year (and v2.6.20-rc3 released))

Quoted 4 lines · Alan

Quoted 4 lines
Quoted 2 lines
This is a silly complaint because the SFF layer in libata doesn't handle this case yet anyway.
Yes, it's "silly" people people use configurations you find inconvenient.

Quoted 8 lines

Quoted 1 line
At least one embedded x86 case cares, that I know of. They only needed to make two minor changes to make it work.
*It is not part of 2.6.20*
Quoted 1 line
The code no long reserves resources for the "extra" PCI BAR that often exists on PCI controllers regardless of legacy/native mode. Previously, the code called pci_request_regions() to reserve ALL regions attached to the PCI device.
We use BAR5 on two devices in legacy mode. Both of those reserve all the other resources.

Translation: You want to hand-wave away an obvious regression that YOU have created with your fix-to-a-fix.

Quoted 2 lines

We can fix BAR5 in .21 when all the combined mode crap goes away.

Translation: Problems disappear in 2.6.21 because Jeff will revert the code I touched to its previous state -- always calling pci_request_regions() -- and all the problems I introduced by avoiding pci_request_regions() will go away.

Why INTRODUCE these 2.6.20 Alan-isms, if they are going away in 2.6.21?

Quoted 7 lines

Quoted 1 line
You have suddenly decided that it's OK to --not reserve at all-- these additional regions.
It's not ideal - but it is perfectly sufficient for 2.6.20
Quoted 1 line
Proof: The AHCI PCI BAR (#5, zero-based) is clearly NOT reserved, even though we talk to it, in piix_disable_ahci() of ata_piix.c.
We always claim the other BARs so catch a collision.

Where? AFAICS, it is crystal clear the behavior:

* Prior to your patch, ata_piix in legacy mode calls pci_request_regions() to intentionally reserve ALL regions on the PCI device.

* After your patch, the code explicitly calls pci_request_region() for BARs 0-4, but never for BAR5.

Another driver is now free to claim a PCI BAR, and start running the hardware in AHCI mode, whee!

Jeff

Jeff Garzik

2007-01-02 21:32 UTC #21 lore raw

Re: [PATCH] libata: fix combined mode (was Re: Happy New Year (and v2.6.20-rc3 released))

Quoted 1 line · Jeff Garzik

* After your patch, the code explicitly calls pci_request_region() for BARs 0-4, but never for BAR5.

Without checking for failures, I might add.

Let's call that regression/obvious bug #4, because the previous code actually CARED if the resource was reserved.

Quoted 6 lines

                if (legacy_mode & ATA_PORT_PRIMARY)
                        pci_request_region(pdev, 1, DRV_NAME);
                if (legacy_mode & ATA_PORT_SECONDARY)
                        pci_request_region(pdev, 3, DRV_NAME);
                /* If there is a DMA resource, allocate it */
                pci_request_region(pdev, 4, DRV_NAME);

I agree this is one way to avoid conflicts! ;-)

Jeff

Alan

2007-01-02 22:38 UTC #22 lore raw

Re: [PATCH] libata: fix combined mode (was Re: Happy New Year (and v2.6.20-rc3 released))

Quoted 5 lines · On Tue, 02 Jan 2007 16:32:01 -0500 Jeff Garzik <[email protected]> wrote:

Quoted 2 lines · Jeff Garzik
* After your patch, the code explicitly calls pci_request_region() for BARs 0-4, but never for BAR5.
Without checking for failures, I might add.

The old code didn't reserve 1 or 3 at all let alone check them!

Quoted 1 line

I agree this is one way to avoid conflicts! ;-)

I did actually go through and verify that there are no drivers where this would cause a problem including reading some of the painful crap in drivers/ide to double check.

Is it perfection - no, does it fix 2.6.20 - yes, is it causing any problems for a 2.6.21 roadmap - no.

Alan

2007-01-02 22:36 UTC #23 lore raw

Re: [PATCH] libata: fix combined mode (was Re: Happy New Year (and v2.6.20-rc3 released))

In reply to Jeff Garzik

Quoted 5 lines

Quoted 2 lines
We use BAR5 on two devices in legacy mode. Both of those reserve all the other resources.
Translation: You want to hand-wave away an obvious regression that YOU have created with your fix-to-a-fix.

It's not regressing anything.

Quoted 1 line

Why INTRODUCE these 2.6.20 Alan-isms, if they are going away in 2.6.21?

To fix the problem I introduced ? and because that patch to do so is trivial and easy to test and verify.

Quoted 3 lines

* Prior to your patch, ata_piix in legacy mode calls pci_request_regions() to intentionally reserve ALL regions on the PCI device.

Actually it didn't reserve BAR1 and BAR3 in legacy mode precisely because of the PCI resource mismanagement in the old tree. So you take your pick. BAR1 and BAR3 were used on all devices and not reserved, BAR5 is used on two. Neither case is actually a problem in the current tree and driver set. Both will be fixed when the combined mode junk gets fired into hyperspace.

Alan

Jeff Garzik

2007-01-02 23:01 UTC #24 lore raw

Re: [PATCH] libata: fix combined mode (was Re: Happy New Year (and v2.6.20-rc3 released))

Quoted 5 lines · Alan

Quoted 3 lines
Quoted 2 lines
We use BAR5 on two devices in legacy mode. Both of those reserve all the other resources.
Translation: You want to hand-wave away an obvious regression that YOU have created with your fix-to-a-fix.
It's not regressing anything.

False:

2.6.0 - 2.6.19: libata guarantees that all PCI BARs are reserved to the libata driver.

2.6.20: no guarantee that all PCI BARs are reserved to libata driver. Real-life ata_piix example already provided, where a PCI BAR is no longer reserved to the driver.

2.6.21 - infinity: libata guarantees that all PCI BARs are reserved to the driver.

Jeff

Alan

2007-01-02 23:16 UTC #25 lore raw

Re: [PATCH] libata: fix combined mode (was Re: Happy New Year (and v2.6.20-rc3 released))

Quoted 2 lines

2.6.0 - 2.6.19: libata guarantees that all PCI BARs are reserved to the libata driver.

Please read the code Jeff. The old IDE quirk code in the PCI layer blanked BAR 0 to BAR 3 of a compatibility mode controller

You then request_region 0x1f0 and 0x170 (BAR 0 and BAR 2) directly. You never request the legacy BAR 1 and BAR 3 because they were erased by the PCI quirk code and thus never claim the other port. Thats been a bug since day one but it never seemed worth fixing in the short term.

Alan

Jeff Garzik

2007-01-02 23:43 UTC #26 lore raw

Re: [PATCH] libata: fix combined mode (was Re: Happy New Year (and v2.6.20-rc3 released))

Quoted 4 lines · Alan

Quoted 1 line
2.6.0 - 2.6.19: libata guarantees that all PCI BARs are reserved to the libata driver.
Please read the code Jeff. The old IDE quirk code in the PCI layer blanked BAR 0 to BAR 3 of a compatibility mode controller

(a) I'm well of aware of this, and (b) that changes nothing.

I said "PCI BARs" for a reason. libata was written according to the following model:

1) Programmatically reserve /all/ resources associated with our PCI device
2) Manually reserve resources associated with our PCI device, but are not listed in struct pci_dev.

You have changed this to:

1) Manually reserve /some/ resources associated with PCI device
2) Manually reserve resources associated with our PCI device, but are not listed in struct pci_dev.

But then 2.6.21 goes back to:

1) Programmatically reserve /all/ resources associated with our PCI device
2) Manually reserve resources associated with our PCI device, but are not listed in struct pci_dev.

Maybe I can say it more clearly by telling you how to fix the regression you have introduced: Loop through all BAR resources in struct pci_dev, and reserve them if they are not already reserved by libata earlier in the code. There. Regression fixed.

(but then we rewrite this code again in 2.6.21)

Quoted 4 lines

You then request_region 0x1f0 and 0x170 (BAR 0 and BAR 2) directly. You never request the legacy BAR 1 and BAR 3 because they were erased by the PCI quirk code and thus never claim the other port. Thats been a bug since day one but it never seemed worth fixing in the short term.

Yes -- that's a bug, one that existed prior to the "it doesn't boot" combined mode regression everybody complained about. I'm talking about a new regression just introduced via dc3c3377f03634d351fafdfe35b237b283586c04, not a old bug that existed prior to the regression introduced in 368c73d4f689dae0807d0a2aa74c61fd2b9b075f.

Jeff

Alan

2007-01-03 00:27 UTC #27 lore raw

Re: [PATCH] libata: fix combined mode (was Re: Happy New Year (and v2.6.20-rc3 released))

Quoted 4 lines

1) Programmatically reserve /all/ resources associated with our PCI device
2) Manually reserve resources associated with our PCI device, but are not listed in struct pci_dev.

Which it doesn't actually do. You reserve 0x1F0-0x1F7 but forget the other register. BTW on unload you forget to release 0x1F0-7 too. I've not fixed that as its not a regression just a bug. It's just another symptom of a pile of code trying to do things the wrong way, in the wrong place.

Quoted 6 lines

But then 2.6.21 goes back to:
1) Programmatically reserve /all/ resources associated with our PCI device
2) Manually reserve resources associated with our PCI device, but are not listed in struct pci_dev.

Nope. You are either very confused about how PCI bus resources work or you are trying to implement the future code in a very very peculiar way 8)

Remember with the resource tree now correct all the resources for an IDE controller *are* in the pci_dev struct properly - the special cases are all gone in libata and in drivers/ide.

Once combined mode is fixed not to abuse resources (and it originally did it that way for a good reason I grant and am not criticising that) the entire management for legacy mode, mixed mode and native mode resources for an ATA device (including 0x170, 0x3F6 and other wacky magic) becomes

	if (pci_request_regions(pdev, "libata")) ...

You'll note:
- No special cases for differing modes
- No libata knowledge of PCI legacy mapping rules and addresses
- The death of the magic ATA_PRIMARY/SECONDARY constants and their magic numbers
- Support for platforms that map legacy space differently
- Trivial cleanup from failure unlike the current code

all in one line. This will also fix all the existing bugs where unloading a libata driver fails to free resources as pci_release_regions() will also now do the correct thing.

*That* is one key reason why getting the PCI resource map right is so important. We turn fifty lines of bug ridden hard to debug code into one line of code that actually does more than the original, and gets it right. For free we get the leaked resources after rmmod fixed, we get the mixed mode resources fixed, we get all this stuff for free. We get to shoot a chunk of code in drivers/ide if we want as well.

If we want to keep a combined mode in 2.6.21 with drivers/ide (which seems dumb as libata has progressed far beyond the need for it) then the -mm tree has a pci_request_regions_mask() function which we can push to .21 development and we end up with five lines not three for these cases.

Make sense ?

Alan

Jeff Garzik

2007-01-03 01:02 UTC #28 lore raw

Re: [PATCH] libata: fix combined mode (was Re: Happy New Year (and v2.6.20-rc3 released))

Quoted 8 lines · Alan

Once combined mode is fixed not to abuse resources (and it originally did it that way for a good reason I grant and am not criticising that) the entire management for legacy mode, mixed mode and native mode resources for an ATA device (including 0x170, 0x3F6 and other wacky magic) becomes
	if (pci_request_regions(pdev, "libata")) ...
Make sense ?

Yes. For 2.6.21. As I've always said.

But for 2.6.20, we are only HALFWAY there, and all these /new/ bugs exist as a result.

Your patch makes far more sense for 2.6.21, where the "halfway to salvation" state, and associated rough edges, is not exposed to users.

Fixing the resource tree was only half the solution, since the drivers that /use/ the resource tree now need updating.

Jeff

Jeff Garzik

2007-01-02 23:54 UTC #29 lore raw

Re: [PATCH] libata: fix combined mode (was Re: Happy New Year (and v2.6.20-rc3 released))

Or maybe this rephrase helps:

Regardless of how the IDE quirks have configured the PCI BARs, libata is written to assume that /all/ struct pci_dev resources for a single PCI device are reserved to the libata driver.

Thus, if you avoid calling pci_request_regions (as your patch does), you must manually provide the same guarantees that pci_request_regions provides to its callers.

Jeff

Alan

2007-01-03 00:29 UTC #30 lore raw

Re: [PATCH] libata: fix combined mode (was Re: Happy New Year (and v2.6.20-rc3 released))

Quoted 3 lines

Thus, if you avoid calling pci_request_regions (as your patch does), you must manually provide the same guarantees that pci_request_regions provides to its callers.

pci_request_regions reserves only BAR4/BAR5 in legacy mode because of the fact the resources are mashed and eventually cleaare by the existing (pre 2.6.20-rc) PCI code. The new code does provide that guarantee which is (unfortunately) precisely why you get the problem - because the combined mode hack currently relies on it failing to do so.

Alan

Jeff Garzik

2007-01-02 23:04 UTC #31 lore raw

Re: [PATCH] libata: fix combined mode (was Re: Happy New Year (and v2.6.20-rc3 released))

Quoted 2 lines · Alan

Actually it didn't reserve BAR1 and BAR3 in legacy mode precisely because of the PCI resource mismanagement in the old tree. So you take your pick.

I pick old bugs over new regressions.

Jeff

Steve Wise

2007-01-03 19:59 UTC #32 lore raw

Re: [PATCH] libata: fix combined mode (was Re: Happy New Year (and v2.6.20-rc3 released))

On Tue, 2007-01-02 at 11:58 +0000, Alan wrote:

...

Quoted 62 lines

I'm sending this now rather than after running full test suites so that it can get the maximal testing in a short time. I'll be running tests on this after lunch.

Signed-off-by Alan Cox <[email protected]>

drivers/ata/libata-sff.c +23 ~~-12~~

@@ -1027,13 +1027,15 @@
 #endif
 	}
 
-	rc = pci_request_regions(pdev, DRV_NAME);
-	if (rc) {
-		disable_dev_on_err = 0;
-		goto err_out;
-	}
-
-	if (legacy_mode) {
+	if (!legacy_mode) {
+		rc = pci_request_regions(pdev, DRV_NAME);
+		if (rc) {
+			disable_dev_on_err = 0;
+			goto err_out;
+		}
+	} else {
+		/* Deal with combined mode hack. This side of the logic all
+		   goes away once the combined mode hack is killed in 2.6.21 */
 		if (!request_region(ATA_PRIMARY_CMD, 8, "libata")) {
 			struct resource *conflict, res;
 			res.start = ATA_PRIMARY_CMD;

@@ -1071,6 +1073,13 @@
 			}
 		} else
 			legacy_mode |= ATA_PORT_SECONDARY;
+
+		if (legacy_mode & ATA_PORT_PRIMARY)
+			pci_request_region(pdev, 1, DRV_NAME);
+		if (legacy_mode & ATA_PORT_SECONDARY)
+			pci_request_region(pdev, 3, DRV_NAME);
+		/* If there is a DMA resource, allocate it */
+		pci_request_region(pdev, 4, DRV_NAME);
 	}
 
 	/* we have legacy mode, but all ports are unavailable */

@@ -1114,11 +1123,20 @@
 err_out_ent:
 	kfree(probe_ent);
 err_out_regions:
-	if (legacy_mode & ATA_PORT_PRIMARY)
-		release_region(ATA_PRIMARY_CMD, 8);
-	if (legacy_mode & ATA_PORT_SECONDARY)
-		release_region(ATA_SECONDARY_CMD, 8);
-	pci_release_regions(pdev);
+	/* All this conditional stuff is needed for the combined mode hack
+	   until 2.6.21 when it can go */
+	if (legacy_mode) {
+		pci_release_region(pdev, 4);
+		if (legacy_mode & ATA_PORT_PRIMARY) {
+			release_region(ATA_PRIMARY_CMD, 8);
+			pci_release_region(pdev, 1);

drivers/ata/libata-sff.c line 1142

Quoted 10 lines

drivers/ata/libata-sff.c +7 -0

+		}
+		if (legacy_mode & ATA_PORT_SECONDARY) {
+			release_region(ATA_SECONDARY_CMD, 8);
+			pci_release_region(pdev, 3);
+		}
+	} else
+		pci_release_regions(pdev);
 err_out:
 	if (disable_dev_on_err)
 		pci_disable_device(pdev);

This patch works for me too.

Steve.

Alan

2007-01-01 21:16 UTC #33 lore raw

Quoted 4 lines · On Mon, 1 Jan 2007 12:13:08 -0800 (PST) Linus Torvalds <[email protected]>…

Jeff,
what was the resolution to this one? Just revert the offending commit, or
what?

If you revert the commit you end with all the PCI resource tree breakage back

Quoted 5 lines

We're about five weeks into the 2.6.20-rc series. I was hoping for a two-month release rather than the usual dragged-out three months, so I'd like to get these regressions to be actively fixed. By forcible reverts if that is what it takes.

The patch I sent ages back is perfectly adequate for 2.6.20-rc/2.6.20 final. Jeff is correct that it isn't perfection in all cases but it does no real harm and the right fix (removing the whole bogus combined mode garbage) is short and simple.

If Jeff doesn't get you a patch please let me know before reverting it and I'll send you the one I'm using that folks have tested and works.

Alan

Linus Torvalds

author

2007-01-02 16:10 UTC #34 lore raw

Quoted 3 lines · Alan

If you revert the commit you end with all the PCI resource tree breakage back

Which weren't a regression or anything new.

Alan: regressions are what we don't do. Ever. If your second patch is found to have some other problems, we revert them both. It's that simple. It's better to stay in place than walk backwards, even if the "backwards" is just for a few people.

So far, it fixed at least Alessandro's problems, so here's to hoping there aren't any others..

Linus

Olaf Hering

2007-01-01 15:52 UTC #35 lore raw

The final 2.6.20 release note should mention the following commit in some
way: "[NETFILTER]: Kconfig: improve conntrack selection"

It will break existing iptable setups without warning becausee it disables all related .config options. If one says NO to the new NF_CONNTRACK_ENABLED "Netfilter connection tracking support", NAT and other stuff will disappear.
One has to choose '2 "Layer 3 Dependent Connection tracking (OBSOLETE)"' in a following question, to keep most of the existing modules during a make oldconfig.
Its not obvious why make oldconfig still asks that many questions about existing .config options.

Adrian Bunk

2007-01-02 19:16 UTC #36 lore raw

2.6.20-rc3: known unfixed regressions

This email lists some known regressions in 2.6.20-rc3 compared to 2.6.19 that are not yet fixed in Linus' tree.

If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.

Subject : kernel immediately reboots
References : http://lkml.org/lkml/2007/1/2/15
Submitter : Steve Youngs <[email protected]>
Status : unknown

Subject : Acer Extensa 3002 WLMi: 'shutdown -h now' reboots the system
References : http://lkml.org/lkml/2006/12/25/40
Submitter : Berthold Cogel <[email protected]>
Status : unknown

Subject : USB keyboard unresponsive after some time
References : http://lkml.org/lkml/2006/12/25/35

             http://lkml.org/lkml/2006/12/26/106

Submitter : Florin Iucha <[email protected]>
Status : unknown

Subject : BUG: scheduling while atomic
References : http://lkml.org/lkml/2006/12/26/105
Submitter : Jon Smirl <[email protected]>
Status : unknown

Subject : SPARC64: Can't mount /
References : http://lkml.org/lkml/2006/12/13/181
Submitter : Horst H. von Brand <[email protected]>
Status : unknown

Subject : ftp: get or put stops during file-transfer
References : http://lkml.org/lkml/2006/12/16/174
Submitter : Komuro <[email protected]>

             commit cfb6eeb4c860592edd123fdea908d23c6ad1c7dc

Status : problem is being debugged

Subject : forcedeth.c 0.59: problem with sideband managment
References : http://bugzilla.kernel.org/show_bug.cgi?id=7684
Submitter : Michael Reske <[email protected]>

Handled-By Ayaz Abdulla <[email protected]>

Status : problem is being debugged

Subject : x86_64 boot failure: "IO-APIC + timer doesn't work"
References : http://lkml.org/lkml/2006/12/16/101
Submitter : Tobias Diedrich <[email protected]>

             commit b026872601976f666bae77b609dc490d1834bf77

Eric W. Biederman <[email protected]>
Status : problem is being debugged

Steve Youngs

2007-01-03 18:24 UTC #37 lore raw

Re: 2.6.20-rc3: known unfixed regressions

Quoted 4 lines · Adrian Bunk

Subject : kernel immediately reboots
References : http://lkml.org/lkml/2007/1/2/15
Submitter : Steve Youngs <[email protected]>
Status : unknown

I'm very happy to report that this is now fixed for me. See commit c6b33cc4e9882b44f1b0c36396f420076e04a4e2.

Thanks very much for the fast response and fix.

Signature · 4 lines

|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|                   Te audire no possum.                   |
|             Musa sapientum fixa est in aure.             |
|----------------------------------<[email protected]>---|

Adrian Bunk

2007-01-03 20:03 UTC #38 lore raw

Re: 2.6.20-rc3: known unfixed regressions

Quoted 11 lines · Steve Youngs

Quoted 4 lines · Adrian Bunk
Subject : kernel immediately reboots
References : http://lkml.org/lkml/2007/1/2/15
Submitter : Steve Youngs <[email protected]>
Status : unknown
I'm very happy to report that this is now fixed for me. See commit c6b33cc4e9882b44f1b0c36396f420076e04a4e2.
Thanks very much for the fast response and fix.

Thanks for both your bug report and your confirmation that it's fixed.

cu
Adrian

Signature · 4 lines

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Adrian Bunk

2007-01-02 19:24 UTC #39 lore raw

2.6.20-rc3: known regressions with patches available (part 1)

This email lists some known regressions in 2.6.20-rc3 compared to 2.6.19 with patches available.

Due to the huge amount of recipients, please trim the Cc when answering.

Subject : suspend to disk no longer works
References : http://lkml.org/lkml/2007/1/1/72

             http://lkml.org/lkml/2006/12/31/13

Submitter : Andrey Borzenkov <[email protected]>
Robert Hancock <[email protected]>

Handled-By Rafael J. Wysocki <[email protected]>

Patch : http://lkml.org/lkml/2007/1/1/117
Status : patch available

Subject : "i386: Relocatable kernel support" causes instant reboot
References : http://lkml.org/lkml/2006/12/20/114
Submitter : Jean Delvare <[email protected]>

Caused-By Eric W. Biederman <[email protected]>

             commit 968de4f02621db35b8ae5239c8cfc6664fb872d8

Handled-By Vivek Goyal <[email protected]>

Patch : http://lkml.org/lkml/2007/1/2/9
Status : patch available

Subject : bluetooth oopses because of multiple kobject_add()
References : http://lkml.org/lkml/2007/1/2/101
Submitter : Pavel Machek <[email protected]>

Handled-By Marcel Holtmann <[email protected]>

Patch : http://lkml.org/lkml/2007/1/2/147
Status : patch available

Subject : CFQ disk throughput halved
References : http://lkml.org/lkml/2007/01/1/104
Submitter : Rene Herman <[email protected]>
Mark Lord <[email protected]>

Caused-By Jens Axboe <[email protected]>

             commit 719d34027e1a186e46a3952e8a24bf91ecc33837

Handled-By Jens Axboe <[email protected]>

Patch : http://lkml.org/lkml/2007/1/2/75
Status : patch available

Subject : BUG at drivers/scsi/scsi_lib.c:1118 by "pktsetup dvd /dev/sr0"
References : http://bugzilla.kernel.org/show_bug.cgi?id=7667
Submitter : Laurent Riffard <[email protected]>

Caused-By Christoph Hellwig <[email protected]>

             commit 3b00315799d78f76531b71435fbc2643cd71ae4c

Handled-By Christoph Hellwig <[email protected]>

Patch : http://bugzilla.kernel.org/show_bug.cgi?id=7667
Status : patch available

Jens Axboe

2007-01-02 19:26 UTC #40 lore raw

Re: 2.6.20-rc3: known regressions with patches available (part 1)

Quoted 9 lines · Adrian Bunk

Subject : CFQ disk throughput halved
References : http://lkml.org/lkml/2007/01/1/104
Submitter : Rene Herman <[email protected]>
Mark Lord <[email protected]>
Caused-By Jens Axboe <[email protected]>
             commit 719d34027e1a186e46a3952e8a24bf91ecc33837
Handled-By Jens Axboe <[email protected]>
Patch : http://lkml.org/lkml/2007/1/2/75
Status : patch available

Patch is already merged in -git.

Signature · 1 line

Jens Axboe

Adrian Bunk

2007-01-02 19:34 UTC #41 lore raw

Re: 2.6.20-rc3: known regressions with patches available (part 1)

Quoted 11 lines · Jens Axboe

Quoted 9 lines · Adrian Bunk
Subject : CFQ disk throughput halved
References : http://lkml.org/lkml/2007/01/1/104
Submitter : Rene Herman <[email protected]>
Mark Lord <[email protected]>
Caused-By Jens Axboe <[email protected]>
             commit 719d34027e1a186e46a3952e8a24bf91ecc33837
Handled-By Jens Axboe <[email protected]>
Patch : http://lkml.org/lkml/2007/1/2/75
Status : patch available

Quoted 1 line

Patch is already merged in -git.

Thanks for this information, I missed this (as well as the merged SATA fix) since it isn't yet at the git mirrors.

Quoted 1 line

Jens Axboe

cu
Adrian

Signature · 4 lines

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Rene Herman

2007-01-02 20:45 UTC #42 lore raw

Re: 2.6.20-rc3: known regressions with patches available (part 1)

Quoted 5 lines · Adrian Bunk

Quoted 1 line · Jens Axboe
Patch is already merged in -git.
Thanks for this information, I missed this (as well as the merged SATA fix) since it isn't yet at the git mirrors.

What's "-git" here? I just now pulled

git://git2.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

and it's not there.

Otherwise, patch confirmed to work by me as well.

Cheers,
Rene

Jens Axboe

2007-01-02 20:48 UTC #43 lore raw

Re: 2.6.20-rc3: known regressions with patches available (part 1)

Quoted 9 lines · Rene Herman

Quoted 6 lines · Adrian Bunk
Quoted 1 line · Jens Axboe
Patch is already merged in -git.
Thanks for this information, I missed this (as well as the merged SATA fix) since it isn't yet at the git mirrors.

Quoted 7 lines

What's "-git" here? I just now pulled
git://git2.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
and it's not there.
Otherwise, patch confirmed to work by me as well.

Perhaps not mirrored out yet, I pulled it from master/hera some hours ago though. The top of Linus' tree is ec8acb6904fabb8e741f741ec99bb1c18f2b3dee, which is the commit with that patch.

Signature · 1 line

Jens Axboe

Adrian Bunk

2007-01-02 19:29 UTC #44 lore raw

2.6.20-rc3: known regressions with patches available (part 2)

This email lists some known regressions in 2.6.20-rc3 compared to 2.6.19 with patches available

Due to the huge amount of recipients, please trim the Cc when answering.

Subject : selinux networking: sleeping function called from invalid context
References : http://lkml.org/lkml/2006/12/24/78
Submitter : Adam J. Richter <[email protected]>

Caused-By Paul Moore <[email protected]>

Handled-By Parag Warudkar <[email protected]>

Patch : http://lkml.org/lkml/2006/12/24/89
Status : patch available

Subject : kernel panics on boot (libata-sff)
References : http://lkml.org/lkml/2006/12/3/99

             http://lkml.org/lkml/2006/12/14/153
             http://lkml.org/lkml/2006/12/24/33
             http://lkml.org/lkml/2007/1/1/84

Submitter : Alessandro Suardi <[email protected]>
Theodore Tso <[email protected]>

Caused-By Alan Cox <[email protected]>

             commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f

Handled-By Alan Cox <[email protected]>

Jeff Garzik <[email protected]>
Patch : http://lkml.org/lkml/2007/1/2/64
Status : patch available

Subject : PCI_MULTITHREAD_PROBE breakage
References : http://lkml.org/lkml/2006/12/12/21
Submitter : Ben Castricum <[email protected]>

Caused-By Greg Kroah-Hartman <[email protected]>

             commit 009af1ff78bfc30b9a27807dd0207fc32848218a

Handled-By Greg Kroah-Hartman <[email protected]>

Status : patch available

Tilman Schmidt

2007-01-03 19:06 UTC #45 lore raw

[2.6.20-rc3] INFO: possible recursive locking detected (was: Happy New Year (and v2.6.20-rc3 released))

Quoted 2 lines · Linus Torvalds

In order to not get in trouble with MADR ("Mothers Against Drunk Releases") I decided to cut the 2.6.20-rc3 release early rather than wait

[...]

Quoted 2 lines

At which point the first thing on any self-respecting geek's mind should obviously be: "is there a new kernel release for me to try?"

2.6.20-rc3 produces the following lockdep warning when hald is started during system startup:

=============================================
[ INFO: possible recursive locking detected ] 2.6.20-rc3-noinitrd #0
---------------------------------------------
hald-subfs-moun/4608 is trying to acquire lock:
(&inode->i_mutex){--..}, at: [<c035bb02>] mutex_lock+0x1c/0x1f

but task is already holding lock:
(&inode->i_mutex){--..}, at: [<c035bb02>] mutex_lock+0x1c/0x1f

other info that might help us debug this:
3 locks held by hald-subfs-moun/4608:

 #0:  (&inode->i_mutex){--..}, at: [<c035bb02>] mutex_lock+0x1c/0x1f
 #1:  (&REISERFS_I(inode)->xattr_sem){----}, at: [<c01c0098>] reiserfs_setxattr+0x51/0xe9
 #2:  (&REISERFS_SB(s)->xattr_dir_sem){----}, at: [<c01c00be>] reiserfs_setxattr+0x77/0xe9

stack backtrace:
 [<c0103c72>] show_trace_log_lvl+0x19/0x2e
 [<c0103d6b>] show_trace+0x12/0x14
 [<c0103d81>] dump_stack+0x14/0x16
 [<c01303b3>] __lock_acquire+0x116/0xa5c
 [<c0130fe6>] lock_acquire+0x56/0x70
 [<c035b95c>] __mutex_lock_slowpath+0xdc/0x266
 [<c035bb02>] mutex_lock+0x1c/0x1f
 [<c01c07d0>] reiserfs_xattr_set+0xe4/0x2c0
 [<c01c0c21>] trusted_set+0x74/0x80
 [<c01c00e9>] reiserfs_setxattr+0xa2/0xe9
 [<c0177b45>] vfs_setxattr+0xa6/0x1ff
 [<c0177d57>] setxattr+0xb9/0xd1
 [<c0177e14>] sys_lsetxattr+0x3e/0x50
 [<c0102d9a>] sysenter_past_esp+0x5f/0x99
 =======================

I guess it's really the same ReiserFS issue I already reported for the previous releases, just triggered at an earlier point in the system's life.

Other than that, everything seems fine and dandy on this plain old P3.

HTH, and Happy New Year everyone
Tilman

Adrian Bunk

2007-01-03 20:59 UTC #46 lore raw

2.6.20-rc3: known unfixed regressions (v2)

This email lists some known regressions in 2.6.20-rc3 compared to 2.6.19 that are not yet fixed in Linus' tree.

Due to the huge amount of recipients, please trim the Cc when answering.

Subject : Acer Extensa 3002 WLMi: 'shutdown -h now' reboots the system
References : http://lkml.org/lkml/2006/12/25/40
Submitter : Berthold Cogel <[email protected]>
Status : unknown

Subject : USB keyboard unresponsive after some time
References : http://lkml.org/lkml/2006/12/25/35

             http://lkml.org/lkml/2006/12/26/106

Submitter : Florin Iucha <[email protected]>
Status : unknown

Subject : BUG: scheduling while atomic
References : http://lkml.org/lkml/2006/12/26/105
Submitter : Jon Smirl <[email protected]>
Status : unknown

Subject : SPARC64: Can't mount /
References : http://lkml.org/lkml/2006/12/13/181
Submitter : Horst H. von Brand <[email protected]>
Status : unknown

Subject : ftp: get or put stops during file-transfer
References : http://lkml.org/lkml/2006/12/16/174
Submitter : Komuro <[email protected]>

             commit cfb6eeb4c860592edd123fdea908d23c6ad1c7dc

Status : problem is being debugged

Subject : x86_64 boot failure: "IO-APIC + timer doesn't work"
References : http://lkml.org/lkml/2006/12/16/101

             http://lkml.org/lkml/2007/1/3/9

Submitter : Tobias Diedrich <[email protected]>

             commit b026872601976f666bae77b609dc490d1834bf77

Eric W. Biederman <[email protected]>
Status : patches are being discussed

Horst H. von Brand

2007-01-04 13:23 UTC #47 lore raw

Re: 2.6.20-rc3: known unfixed regressions (v2)

Quoted 9 lines · Adrian Bunk

This email lists some known regressions in 2.6.20-rc3 compared to 2.6.19 that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.

I hope I cut it down sensibly...

[...]

Quoted 4 lines

Subject : SPARC64: Can't mount /
References : http://lkml.org/lkml/2006/12/13/181
Submitter : Horst H. von Brand <[email protected]>
Status : unknown

Works for me now with 2.6.20-rc3. Might have been some form of pilot error (perhaps setting SCSI_TGT=m and/or SCSI_SCAN_ASYNC=y, I unset them for the current trial run).

I see CONFIG_SCSI_SCAN_ASYNC introduced in 21db1882f79a1ad5977cae6766376a63f60ec414 ([SCSI] Add Kconfig option for asynchronous SCSI scanning). If this is the cause, the override provided:

scsi_mod.scan="sync"

seems not to work. Are the '"' necessary? How do you give them via silo, which in its configuration file for strings with spaces uses:

append="some string here"

How do you say '"'? The silo documentation is silent on this.

Signature · 4 lines

Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513

Adrian Bunk

2007-01-03 21:03 UTC #48 lore raw

2.6.20-rc3: known regressions with patches (v2)

This email lists some known regressions in 2.6.20-rc3 compared to 2.6.19 with patches available.

Due to the huge amount of recipients, please trim the Cc when answering.

Subject : suspend to disk no longer works
References : http://lkml.org/lkml/2007/1/1/72

             http://lkml.org/lkml/2006/12/31/13

Submitter : Andrey Borzenkov <[email protected]>
Robert Hancock <[email protected]>

Handled-By Rafael J. Wysocki <[email protected]>

Patch : http://lkml.org/lkml/2007/1/1/117
Status : patch available

Subject : BUG at drivers/scsi/scsi_lib.c:1118 by "pktsetup dvd /dev/sr0"
References : http://bugzilla.kernel.org/show_bug.cgi?id=7667
Submitter : Laurent Riffard <[email protected]>

Caused-By Christoph Hellwig <[email protected]>

             commit 3b00315799d78f76531b71435fbc2643cd71ae4c

Handled-By Christoph Hellwig <[email protected]>

Patch : http://bugzilla.kernel.org/show_bug.cgi?id=7667
Status : patch available

Subject : forcedeth.c 0.59: problem with sideband managment
References : http://bugzilla.kernel.org/show_bug.cgi?id=7684
Submitter : Michael Reske <[email protected]>

Handled-By Ayaz Abdulla <[email protected]>

Status : patch available

Subject : bluetooth oopses because of multiple kobject_add()
References : http://lkml.org/lkml/2007/1/2/101
Submitter : Pavel Machek <[email protected]>

Handled-By Marcel Holtmann <[email protected]>

Patch : http://lkml.org/lkml/2007/1/2/147
Status : patch available

Subject : PCI_MULTITHREAD_PROBE breakage
References : http://lkml.org/lkml/2006/12/12/21
Submitter : Ben Castricum <[email protected]>

Caused-By Greg Kroah-Hartman <[email protected]>

             commit 009af1ff78bfc30b9a27807dd0207fc32848218a

Handled-By Greg Kroah-Hartman <[email protected]>

Status : patch available

Jiri Kosina

2007-01-03 21:32 UTC #49 lore raw

Re: 2.6.20-rc3: known regressions with patches (v2)

Quoted 2 lines · Adrian Bunk

This email lists some known regressions in 2.6.20-rc3 compared to 2.6.19 with patches available.

Hi Adrian,

where did the

Subject : USB keyboard unresponsive after some time
References : http://lkml.org/lkml/2006/12/25/35

             http://lkml.org/lkml/2006/12/26/106

Submitter : Florin Iucha <[email protected]>
Status : unknown

go? (it was in a previous version of this list you sent on Tue, 2 Jan 2007 20:16:06 +0100 and I am not aware of any existing fix).

Thanks,

Signature · 1 line

Jiri Kosina

Jiri Kosina

2007-01-03 21:33 UTC #50 lore raw

Re: 2.6.20-rc3: known regressions with patches (v2)

Quoted 8 lines · Jiri Kosina

where did the
Subject : USB keyboard unresponsive after some time
References : http://lkml.org/lkml/2006/12/25/35
             http://lkml.org/lkml/2006/12/26/106
Submitter : Florin Iucha <[email protected]>
Status : unknown
go?

Silly me, I by mistake looked on the wrong list, ignore me.

Sorry,

Signature · 1 line

Jiri Kosina

Adrian Bunk

2007-01-04 17:46 UTC #51 lore raw

2.6.20-rc3: known unfixed regressions (v3)

This email lists some known regressions in 2.6.20-rc3 compared to 2.6.19 that are not yet fixed in Linus' tree.

Due to the huge amount of recipients, please trim the Cc when answering.

Subject : BUG: scheduling while atomic: hald-addon-stor/...
cdrom_{open,release,ioctl} in trace
References : http://lkml.org/lkml/2006/12/26/105

             http://lkml.org/lkml/2006/12/29/22
             http://lkml.org/lkml/2006/12/31/133

Submitter : Jon Smirl <[email protected]>
Damien Wyart <[email protected]>
Aaron Sethman <[email protected]>
Status : unknown

Subject : Acer Extensa 3002 WLMi: 'shutdown -h now' reboots the system
References : http://lkml.org/lkml/2006/12/25/40
Submitter : Berthold Cogel <[email protected]>
Status : unknown

Subject : USB keyboard unresponsive after some time
References : http://lkml.org/lkml/2006/12/25/35

             http://lkml.org/lkml/2006/12/26/106

Submitter : Florin Iucha <[email protected]>
Status : unknown

Subject : SPARC64: Can't mount / (CONFIG_SCSI_SCAN_ASYNC=y ?)
References : http://lkml.org/lkml/2006/12/13/181

             http://lkml.org/lkml/2007/01/04/75

Submitter : Horst H. von Brand <[email protected]>
Status : unknown

Subject : ftp: get or put stops during file-transfer
References : http://lkml.org/lkml/2006/12/16/174
Submitter : Komuro <[email protected]>

             commit cfb6eeb4c860592edd123fdea908d23c6ad1c7dc

Status : problem is being debugged

Subject : x86_64 boot failure: "IO-APIC + timer doesn't work"
References : http://lkml.org/lkml/2006/12/16/101

             http://lkml.org/lkml/2007/1/3/9

Submitter : Tobias Diedrich <[email protected]>

             commit b026872601976f666bae77b609dc490d1834bf77

Eric W. Biederman <[email protected]>
Status : patches are being discussed

Matthew Wilcox

2007-01-04 18:13 UTC #52 lore raw

Re: 2.6.20-rc3: known unfixed regressions (v3)

Quoted 5 lines · Adrian Bunk

Subject : SPARC64: Can't mount / (CONFIG_SCSI_SCAN_ASYNC=y ?)
References : http://lkml.org/lkml/2006/12/13/181
             http://lkml.org/lkml/2007/01/04/75
Submitter : Horst H. von Brand <[email protected]>
Status : unknown

It'd be nice if people bothered to cc authors on bug reports, eh?

It seems to me that you're building scsi as modules. In which case you need to follow the instructions in the help text to load the scsi_wait_scan module. Or just say 'n' to the CONFIG_SCSI_SCAN_ASYNC option, of course.

You're right that the quotes need to disappear from the Kconfig help text as they're just confusing.

drivers/scsi/Kconfig +3 -2

index 60f5827..103d0da 100644
@@ -230,6 +230,7 @@ config SCSI_SCAN_ASYNC
 	  The SCSI subsystem can probe for devices while the rest of the
 	  system continues booting, and even probe devices on different
 	  busses in parallel, leading to a significant speed-up.
+
 	  If you have built SCSI as modules, enabling this option can
 	  be a problem as the devices may not have been found by the
 	  time your system expects them to have been.  You can load the

@@ -237,8 +238,8 @@ config SCSI_SCAN_ASYNC
 	  If you build your SCSI drivers into the kernel, then everything
 	  will work fine if you say Y here.
 
-	  You can override this choice by specifying scsi_mod.scan="sync"
-	  or "async" on the kernel's command line.
+	  You can override this choice by specifying "scsi_mod.scan=sync"
+	  or async on the kernel's command line.
 
 menu "SCSI Transports"
 	depends on SCSI

Horst H. von Brand

2007-01-05 00:25 UTC #53 lore raw

Re: 2.6.20-rc3: known unfixed regressions (v3)

In reply to Adrian Bunk

Quoted 9 lines · Adrian Bunk

This email lists some known regressions in 2.6.20-rc3 compared to 2.6.19 that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.

[...]

Quoted 5 lines

Subject : SPARC64: Can't mount / (CONFIG_SCSI_SCAN_ASYNC=y ?)
References : http://lkml.org/lkml/2006/12/13/181
             http://lkml.org/lkml/2007/01/04/75
Submitter : Horst H. von Brand <[email protected]>
Status : unknown

Fixed in 2.6.20-rc3 (perhaps was due to SCSI_SCAN_ASYNC)

Signature · 4 lines

Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513

Adrian Bunk

2007-01-06 21:04 UTC #54 lore raw

2.6.20-rc3: known unfixed regressions (v4)

This email lists some known regressions in 2.6.20-rc3 compared to 2.6.19 that are not yet fixed in Linus' tree.

Due to the huge amount of recipients, please trim the Cc when answering.

Subject : x86_64 boot failure: "IO-APIC + timer doesn't work"
References : http://lkml.org/lkml/2006/12/16/101

             http://lkml.org/lkml/2007/1/3/9

Submitter : Tobias Diedrich <[email protected]>

             commit b026872601976f666bae77b609dc490d1834bf77

Eric W. Biederman <[email protected]>
Status : patches are being discussed

Subject : BUG: scheduling while atomic: hald-addon-stor/...
cdrom_{open,release,ioctl} in trace
References : http://lkml.org/lkml/2006/12/26/105

             http://lkml.org/lkml/2006/12/29/22
             http://lkml.org/lkml/2006/12/31/133

Submitter : Jon Smirl <[email protected]>
Damien Wyart <[email protected]>
Aaron Sethman <[email protected]>
Status : unknown

Subject : problems with CD burning
References : http://www.spinics.net/lists/linux-ide/msg06545.html
Submitter : Uwe Bugla <[email protected]>
Status : unknown

Subject : USB keyboard unresponsive after some time
References : http://lkml.org/lkml/2006/12/25/35

             http://lkml.org/lkml/2006/12/26/106

Submitter : Florin Iucha <[email protected]>
Status : unknown

Subject : Acer Extensa 3002 WLMi: 'shutdown -h now' reboots the system
References : http://lkml.org/lkml/2006/12/25/40
Submitter : Berthold Cogel <[email protected]>

Handled-By Alexey Starikovskiy <[email protected]>

Status : problem is being debugged

Subject : ftp: get or put stops during file-transfer
References : http://lkml.org/lkml/2006/12/16/174
Submitter : Komuro <[email protected]>

             commit cfb6eeb4c860592edd123fdea908d23c6ad1c7dc