Another week, another batch of mostly pretty small fixes. Hopefully the

regression list is shrinking, and we've fixed at least a couple of the

oopses on Arjan's list.
As usual, the bulk of the changes are in drivers and arch code - together

they are about 70% of the diffstat. And the arch stats are bloated by some

new/updated SH and avr defconfig files, which is also fairly common at

this stage.
Perhaps unusually, 13% is in kernel/, almost all of it fixing up some

scheduler issues - with the bulk of it by far being a couple of reverts

due to performance regressions. But there's a few other fixes too.
And then there is networking and some ocfs2 updates. Along with various

one-liners sprinkled all around.
   5.9% arch/avr32/configs/

   5.9% arch/avr32/

   2.7% arch/blackfin/mach-bf537/boards/

   2.6% arch/blackfin/mach-bf548/boards/

   5.4% arch/blackfin/

  20.6% arch/sh/configs/

  21.3% arch/sh/

  38.0% arch/

   5.6% drivers/ata/

   3.4% drivers/char/hw_random/

   3.1% drivers/net/

   2.1% drivers/pci/hotplug/

   2.3% drivers/pci/

   2.4% drivers/scsi/qla2xxx/

   2.6% drivers/scsi/

   3.0% drivers/usb/misc/

   2.7% drivers/usb/serial/

   8.3% drivers/usb/

  31.7% drivers/

   2.0% fs/

   3.7% include/

  13.0% kernel/

   2.9% net/ipv6/

   2.5% net/sctp/

   8.8% net/
The shortlog (appended) gives a reasonable view of it all. Nothing hugely

exciting sticks to my mind, but then I don't think we've had any really

hugely exciting problem spots either..
		Linus
---

Abhijeet Kolekar (1):

      mac80211 : Fixes the status message for iwconfig
Adrian Bunk (5):

      avr32: export copy_page

      avr32: export strnlen_user

      show_schedstat(): fix memleak

      sh/kernel/cpu/irq/intc-sh5.c build fix

      bridge: update URL
Adrian-Ken Rueegsegger (1):

      xfrm: xfrm_algo: correct usage of RIPEMD-160
Al Viro (9):

      ibmaem endianness annotations

      usb/c67x00 endianness annotations

      cdc-wdm endianness fixes

      isp1760-if ...
[ message continues ]

There is another one .. very noisy, but still not something that

seems to effect the usability of the system.
[   26.738367] ck804xrom ck804xrom_init_one(): Unable to register

resource 0x00000000ffb00000-0x00000000ffffffff - kernel bug?

[   26.758371] CFI: Found no ck804xrom @ffc00000 device at location zero

[   26.798790] JEDEC: Found no ck804xrom @ffc00000 device at location zero

[   26.798790] CFI: Found no ck804xrom @ffc00000 device at location zero

[   26.798790] JEDEC: Found no ck804xrom @ffc00000 device at location zero

[   26.798790] CFI: Found no ck804xrom @ffc00000 device at location zero

[   26.798790] JEDEC: Found no ck804xrom @ffc00000 device at location zero

[   26.798790] CFI: Found no ck804xrom @ffc10000 device at location zero

[   26.798790] JEDEC: Found no ck804xrom @ffc10000 device at location zero

[   26.798790] CFI: Found no ck804xrom @ffc10000 device at location zero

[   26.798790] JEDEC: Found no ck804xrom @ffc10000 device at location zero

[   26.798790] CFI: Found no ck804xrom @ffc10000 device at location zero

... and so on.. 192 times.
full dmesg here http://krogh.cc/~jesper/dmesg
--

Jesper Krogh

--

Not that they seem critical to the system but I do get alot of these. I

cant remember having seen that before.
[    2.874884] Switched to high resolution mode on CPU 13

[    2.904452] system 00:06: ioport range 0x190-0x193 has been reserved

[    2.904456] system 00:06: ioport range 0x4d0-0x4d1 has been reserved

[    2.904465] system 00:06: iomem range 0xffb80000-0xfffffffe could not

be reserved

[    2.904467] system 00:06: iomem range 0x0-0x0 could not be reserved

[    2.904469] system 00:06: iomem range 0x0-0x0 could not be reserved

[    2.904471] system 00:06: iomem range 0x0-0x0 could not be reserved

[    2.904473] system 00:06: iomem range 0x0-0x0 could not be reserved

[    2.904475] system 00:06: iomem range 0x0-0x0 could not be reserved

[    2.904477] system 00:06: iomem range 0x0-0x0 could not be reserved

[    2.904479] system 00:06: iomem range 0x0-0x0 could not be reserved

[    2.904481] system 00:06: iomem range 0x0-0x0 could not be reserved

[    2.904483] system 00:06: iomem range 0x0-0x0 could not be reserved

[    2.904484] system 00:06: iomem range 0x0-0x0 could not be reserved

[    2.904486] system 00:06: iomem range 0x0-0x0 could not be reserved

[    2.904488] system 00:06: iomem range 0x0-0x0 could not be reserved

[    2.904490] system 00:06: iomem range 0x0-0x0 could not be reserved

[    2.904492] system 00:06: iomem range 0x0-0x0 could not be reserved

[    2.904494] system 00:06: iomem range 0x0-0x0 could not be reserved

[    2.904496] system 00:06: iomem range 0x0-0x0 could not be reserved

[    2.904498] system 00:06: iomem range 0x0-0x0 could not be reserved

[    2.904500] system 00:06: iomem range 0x0-0x0 could not be reserved

[    2.904502] system 00:06: iomem range 0x0-0x0 could not be reserved

[    2.904504] system 00:06: iomem range 0x0-0x0 could not be reserved

[    2.904506] system 00:06: iomem range 0x0-0x0 could not be reserved

[    2.904508] system 00:06: iomem range 0x0-0x0 could not be reserved

[    2.904510] system 00:06: iomem range 0x0-0x0 could ...
[ message continues ]

[...]
I'm getting these too. Not present in the last -rc4 kernel I built.
Reverting this commit (the only recent one to the file the message

originates from), gets rid of the extra zero-range messages:
commit 4b34fe156455d26ee6ed67b61539f136bf4e439c

Author: Bjorn Helgaas <bjorn.helgaas@hp.com>

Date:   Mon Jun 2 16:42:49 2008 -0600
    PNP: mark resources that conflict with PCI devices "disabled"
    Both the PNP/PCI conflict detection quirk and the PNP system

    driver must use the same mechanism to mark resources as disabled.
    I think it's best to keep the resource and to keep the type bit

    (IORESOURCE_MEM, etc), so that we match the list from firmware

    as closely as possible.
    Fixes this regression from 2.6.25: http://lkml.org/lkml/2008/6/1/82
    Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>

    Tested-by: Avuton Olrich <avuton@gmail.com>

    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Relevant CCs added.
Cheers,

FJP

--

The patch below should fix this and is already in Linus' tree.

Can you give it a whirl to confirm?  Thanks!
PNP: skip UNSET MEM resources as well as DISABLED ones
We don't need to reserve "unset" resources.  Trying to reserve

them results in messages like this, which are ugly but harmless:
    system 00:08: iomem range 0x0-0x0 could not be reserved
Future PNP patches will remove use of IORESOURCE_UNSET, but

we still need it for now.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work11/drivers/pnp/system.c

===================================================================

--- work11.orig/drivers/pnp/system.c	2008-06-05 09:46:33.000000000 -0600

+++ work11/drivers/pnp/system.c	2008-06-05 10:29:10.000000000 -0600

@@ -81,7 +81,7 @@ static void reserve_resources_of_dev(str

 	}
 	for (i = 0; (res = pnp_get_resource(dev, IORESOURCE_MEM, i)); i++) {

-		if (res->flags & IORESOURCE_DISABLED)

+		if (res->flags & (IORESOURCE_UNSET | IORESOURCE_DISABLED))

 			continue;
 		reserve_range(dev, res->start, res->end, 0);
--

[...]
Yes, that does the trick. Tested using a kernel built from git head.
Thanks,

FJP

--

i get the following oops trying to mount an ntfs partition on thinkpad

t61 running a 64-bit kernel:
 BUG: unable to handle kernel paging request at ffffc20005bb0000

 IP: [<ffffffffa004fd83>] :ntfs:load_system_files+0x6ce/0x1892

 PGD 13bc0b067 PUD 13bc0c067 PMD 139491067 PTE 0

 Oops: 0000 [1] PREEMPT SMP

 CPU 1

 Modules linked in: nls_utf8 ntfs loop i2c_i801 i2c_core ehci_hcd uhci_hcd video output joydev evdev

 Pid: 1884, comm: mount Not tainted 2.6.26-rc5 #10

 RIP: 0010:[<ffffffffa004fd83>]  [<ffffffffa004fd83>] :ntfs:load_system_files+0x6ce/0x1892

 RSP: 0018:ffff810138c41bf8  EFLAGS: 00010287

 RAX: ffffc20005bb1000 RBX: 000000000000ffff RCX: 000000000001fffe

 RDX: 000000000000ffff RSI: 0000000000010000 RDI: ffffc20005b90000

 RBP: ffff810138d84c00 R08: 0000000000000062 R09: 8000000000000000

 R10: 000000620447de10 R11: ffffffffa0044978 R12: 0000000000000020

 R13: ffff810137c50778 R14: ffff810138d43800 R15: 0000000000000000

 FS:  00007f18f447d7e0(0000) GS:ffff81013ba1b580(0000) knlGS:0000000000000000

 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b

 CR2: ffffc20005bb0000 CR3: 00000001383de000 CR4: 00000000000006e0

 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000

 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400

 Process mount (pid: 1884, threadinfo ffff810138c40000, task ffff81013958e8a0)

 Stack:  0000001000020052 ffff81013958e8a0 ffffc20005baffff ffff810138c41c88

  0000000000000163 ffffffff80201c20 0000000405bb0000 0000000000000001

  ffffe200044825d0 ffff810138d43800 0000000000000020 ffff810138d43800

 Call Trace:

  [<ffffffffa00521ff>] ? :ntfs:generate_default_upcase+0x47/0xdc

  [<ffffffffa00517fb>] ? :ntfs:ntfs_fill_super+0x8b4/0xd03

  [<ffffffff80518b04>] ? _spin_lock_irqsave+0x18/0x34

  [<ffffffffa0050f47>] ? :ntfs:ntfs_fill_super+0x0/0xd03

  [<ffffffff8028b9e0>] ? get_sb_bdev+0xfa/0x146

  [<ffffffff8028a925>] ? vfs_kern_mount+0x4f/0x95

  [<ffffffff8028a9be>] ? do_kern_mount+0x4...
[ message continues ]

Is it too early to ask how long before 2.6.26 is released?
--

Ben (ben@fluff.org, http://www.fluff.org/)
  'a smiley only costs 4 bytes'

--

Hmm. Depends on just how the regression list ends up looking. I don't

think we're in bad shape, so maybe -rc7 can be the last one. 
		Linus

--

I'm (as usual) not that optimistic, but one remark:
Several ACPI regressions have pending patches, and the last merge from

the ACPI tree was in April.
Having a bigger ACPI merge after what might be the last -rc doesn't

sound good.
cu

Adrian
-- 
       "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
--

Expect an ACPI push later today or early tomorrow.
thanks,

-Len

--

cu

Adrian
-- 
       "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
--

El Wed, 4 Jun 2008 20:36:24 -0700 (PDT)

 I got this on my dmesg; is this expected/harmaless?

 (btw The wireless driver oops that i reported is gone as it is the

 bluetooth one ;)
[    0.232963] system 00:08: ioport range 0x4d0-0x4d1 has been reserved

[    0.233020] system 00:08: ioport range 0x4000-0x40bf could not be reserved

[    0.233075] system 00:08: ioport range 0x40c0-0x40df has been reserved

[    0.233131] system 00:08: ioport range 0x400-0x40f has been reserved

[    0.233186] system 00:08: ioport range 0x480-0x48f has been reserved

[    0.233243] system 00:08: iomem range 0xfff80000-0xffffffff could not be reserved

[    0.233694] system 00:08: iomem range 0xfec10000-0xfec10fff has been reserved

[    0.233750] system 00:08: iomem range 0xfe000000-0xfe0000ff has been reserved

[    0.233795] system 00:08: iomem range 0x0-0x0 could not be reserved

[    0.233795] system 00:08: iomem range 0x0-0x0 could not be reserved

[    0.233795] system 00:08: iomem range 0x0-0x0 could not be reserved

[    0.233795] system 00:08: iomem range 0x0-0x0 could not be reserved

[    0.233795] system 00:08: iomem range 0x0-0x0 could not be reserved

[    0.233795] system 00:08: iomem range 0x0-0x0 could not be reserved

[    0.233795] system 00:08: iomem range 0x0-0x0 could not be reserved

[    0.233795] system 00:08: iomem range 0x0-0x0 could not be reserved

[    0.233795] system 00:08: iomem range 0x0-0x0 could not be reserved

[    0.233795] system 00:08: iomem range 0x0-0x0 could not be reserved

[    0.233857] system 00:08: iomem range 0x0-0x0 could not be reserved

[    0.233912] system 00:08: iomem range 0x0-0x0 could not be reserved

[    0.233967] system 00:08: iomem range 0x0-0x0 could not be reserved

[    0.234023] system 00:08: iomem range 0x0-0x0 could not be reserved

[    0.234078] system 00:08: iomem range 0x0-0x0 could not be reserved

[    0.234695] system 00:08: iomem range 0x0-0x0 could not be reserved

[    0.234750] system 00:08: iomem range 0x0-0x0 could not be reserved

[    0.234805] ...
[ message continues ]

.. repeated a lot ..
It's harmless but obviously irritating. The PnP resource manager changes

need a few cleanups still - it's getting confused about IORESOURCE_UNSET

vs IORESOURCE_DISABLED.
Björn?
		Linus

--

Here's the patch.  I reproduced the problem and verified that this

fixes it.
This should not add conflicts with any of the PNP patches that are

currently in -mm (let me know if it does, of course).  After all

those patches, IORESOURCE_UNSET is never set by PNP, but it should

still be harmless to check for it.
PNP: skip UNSET MEM resources as well as DISABLED ones
We don't need to reserve "unset" resources.  Trying to reserve

them results in messages like this, which are ugly but harmless:
    system 00:08: iomem range 0x0-0x0 could not be reserved
Future PNP patches will remove use of IORESOURCE_UNSET, but

we still need it for now.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work11/drivers/pnp/system.c

===================================================================

--- work11.orig/drivers/pnp/system.c	2008-06-05 09:46:33.000000000 -0600

+++ work11/drivers/pnp/system.c	2008-06-05 09:48:09.000000000 -0600

@@ -81,7 +81,8 @@ static void reserve_resources_of_dev(str

 	}
 	for (i = 0; (res = pnp_get_resource(dev, IORESOURCE_MEM, i)); i++) {

-		if (res->flags & IORESOURCE_DISABLED)

+		if (res->flags & IORESOURCE_UNSET ||

+		    res->flags & IORESOURCE_DISABLED)

 			continue;
 		reserve_range(dev, res->start, res->end, 0);

--

Umm. If I was a compiler, I'd be warning about this. You don't get a

warning about suggesting parentheses around the '&'?
Also, regardless of lack of warnings, the natural way to do this is to

just say
	if (res->flags & (IORESOURCE_DISABLED | IORESOURCE_UNSET))

		continue;
which is what any sane compiler would rewrite it to anyway, but since it's

not just more readable for computers, but for humans too, why not do it

that way?
			Linus

--

Geez, I dreamed about this very question last night, but forgot to

take care this morning.
Actually, I didn't get a warning (gcc 4.1.3), but your way is better.

Here's the updated patch if you haven't fixed it already:
PNP: skip UNSET MEM resources as well as DISABLED ones
We don't need to reserve "unset" resources.  Trying to reserve

them results in messages like this, which are ugly but harmless:
    system 00:08: iomem range 0x0-0x0 could not be reserved
Future PNP patches will remove use of IORESOURCE_UNSET, but

we still need it for now.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Index: work11/drivers/pnp/system.c

===================================================================

--- work11.orig/drivers/pnp/system.c	2008-06-05 09:46:33.000000000 -0600

+++ work11/drivers/pnp/system.c	2008-06-05 10:29:10.000000000 -0600

@@ -81,7 +81,7 @@ static void reserve_resources_of_dev(str

 	}
 	for (i = 0; (res = pnp_get_resource(dev, IORESOURCE_MEM, i)); i++) {

-		if (res->flags & IORESOURCE_DISABLED)

+		if (res->flags & (IORESOURCE_UNSET | IORESOURCE_DISABLED))

 			continue;
 		reserve_range(dev, res->start, res->end, 0);

--

Yep, Tony Luck reported this yesterday as well.  I'll work up a

patch this morning.
Bjorn

--

SATA on a dualcore G5 is broken, it happend between

c3b25b32e8bef526cca748e1ba023c6bdd705a99..53c8ba95402be65d412a806cda3430f0e72cd107
irq 18: nobody cared (try booting with the "irqpoll" option)

Disabling IRQ #18
ctrl alt del on the USB keyboard does not trigger a reboot.

Sometimes the cursor stops blinking, sometimes just nothing happens

after ctrl alt del.
Does 53c8ba95402be65d412a806cda3430f0e72cd107 work for others on G5?

--

On Thu, 5 Jun 2008 13:24:36 +0200
See the patch I just posted to Nick/Jeff should fix it. I always said

ata_sff_check_status() was asking for trouble as a name and neither I nor

Jeff nor Linus noticed the bug...

--

I've been bisecting that on Quad G5 (sata_svw): irq 18: nobody cared ...,

then later endless ata1.00: exception..., blah blah, ata1: EH complete.

It comes down to:
commit a57c1bade5a0ee5cd8b74502db9cbebb7f5780b2

Author: Alan Cox <alan@lxorguk.ukuu.org.uk>

Date:   Thu May 29 22:10:58 2008 +0100

libata-sff: Fix oops reported in kerneloops.org for pnp devices with no ctl
And the patch I'm finding successful is below: I won't sign it off,

for all I know it's reverting part of what Alan is trying to achieve;

but I expect it'll help towards the right fix.
Hugh
--- 2.6.26-rc5/drivers/ata/libata-sff.c	2008-06-05 07:18:07.000000000 +0100

+++ linux/drivers/ata/libata-sff.c	2008-06-05 12:42:39.000000000 +0100

@@ -278,7 +278,7 @@ static u8 ata_sff_irq_status(struct ata_

 		    	return status;

 	}

 	/* Clear INTRQ latch */

-	status = ata_sff_check_status(ap);

+	status = ap->ops->sff_check_status(ap);

 	return status;

 }
--

Thanks for finding that !
/me likes when he wakes up in the morning to find a G5 bug ... and the

fix in the same thread :-)
Cheers,

Ben.
--

Its the right fix 
	ata_sff_check_altstatus() is a routine which does the altstatus

check and may or may not call the helper
	ata_sff_check_status() is a default method for ap->ops->
This lunatic naming leads to mistakes 8(

--

Fix G5 SATA irq 18: nobody cared, reported on -rc5 by Olaf Hering:

fixlet to a57c1bade5a0ee5cd8b74502db9cbebb7f5780b2 libata-sff:

Fix oops reported in kerneloops.org for pnp devices with no ctl
Signed-off-by: Hugh Dickins <hugh@veritas.com>

Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>

---
 drivers/ata/libata-sff.c |    2 +-

 1 file changed, 1 insertion(+), 1 deletion(-)
--- 2.6.26-rc5/drivers/ata/libata-sff.c	2008-06-05 07:18:07.000000000 +0100

+++ linux/drivers/ata/libata-sff.c	2008-06-05 12:42:39.000000000 +0100

@@ -278,7 +278,7 @@ static u8 ata_sff_irq_status(struct ata_

 		    	return status;

 	}

 	/* Clear INTRQ latch */

-	status = ata_sff_check_status(ap);

+	status = ap->ops->sff_check_status(ap);

 	return status;

 }
--

Tested-by: Olaf Hering <olaf@aepfle.de>
--