Linux 2.6.30-rc1

Linux 2.6.30-rc1

[Linus Torvalds]

So the two week merge window has closed, and just as well - because we had 
a lot of changes. As usual. Certainly I had no urges to keep the window 
open to get those last remaining few megabytes of patches..

The changes follow roughly the same pattern they have before: one third 
crap (that is, "staging" - the new random drivers that aren't really ready 
to be merged properly but get into the tree in the hope that they'll get 
better some day), one third real drivers, and one third "rest".

And just to not break a new tradition, there's a few new filesystems in 
this release too:

 - "nilfs2" has been brewing for a long while, and is another 
   log-structured filesystem that does snapshotting. Just google for 
   'nilfs2' for more details.

 - "exofs" implements a filesystem on top of an external object store 
   (ie not a traditional storage of a linear array of anonymous blocks, 
   but a "smart" disk that does objects). See 

		Documentation/filesystems/exofs.txt

   for some details.

 - fscache/cachefiles is not really a filesystem, but infrastructure to do 
   caching of remote filesystems in the local filesystem, and NFS and AFS 
   have been updated to be able to use it.

I'm personally hoping that we'll run out of filesystems rather than 
continue this new tradition indefinitely, but we'll see.

But we've got older filesystems updated too: btrfs hopefully uses less 
stack space and is usable with a 4k stack, reiserfs got some updates, and 
a lot of other filesystems got minor refreshes. The ext3 changes are small 
enough to not show up in any dirstat, but hey, I think the fsync latency 
changes are interesting and probably more relevant to lots of people than 
most of the other changes.

Other? Arch updates - amainly rm, powerpc, sh and x86. Firmware updates. 
And lots and lots of driver updates, including some more core 
suspend/resume changes (hopefully the last really fundamental ones). 

Go out and try it,

		Linus

Re: Linux 2.6.30-rc1

[Kevin Bowling]

Linus Torvalds wrote:

> 
> So the two week merge window has closed, and just as well - because we had
> a lot of changes. As usual. Certainly I had no urges to keep the window
> open to get those last remaining few megabytes of patches..


I was really hoping some of the Xen dom0 patches would be merged to lessen 
the load as time goes on an prevent a large Xen dump all at once.  Is there 
any reason NONE of these patches made it upstream this round, or the past 
few for the matter?

Regards,

Kevin Bowling

Re: Linux 2.6.30-rc1 boot failure on ia64 w/ QLA12160. Bisected.

[Robin Holt]

On and ia64 system with a QLA12160 adapter, my boot fails with:

qla1280: QLA12160 found on PCI bus 0, dev 3
qla1280 0001:00:03.0: PCI INT A -> GSI 61 (level, low) -> IRQ 61
scsi(0): Enabling SN2 PCI DMA dual channel lockup workaround
qla1280 0001:00:03.0: firmware: using built-in firmware qlogic/12160.bin
qla1280_mailbox_command: Command failed, mailbox0 = 0x0007, mailbox_out0 = 0x4003, istatus = 0x6000
m0 4003, m1 b141, m2 5555, m3 aa55
m4 55aa, m5 a5a5, m6 5a5a, m7 2525
scsi(0): RISC checksum failed.
scsi(0): initialize: pci probe failed!
qla1x160: Failed to initialize adapter
qla1280 0001:00:03.0: PCI INT A disabled


I did a git-bisect and narrowed it down to:

commit 1bfa11db712cbf4af1ae037cd25fd4f781f0c215
Author: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Date:   Thu Apr 2 11:13:17 2009 +0530

    [SCSI] qla1280: use request_firmware

    Firmware blob is little endian looks like this...
            unsigned char  Version1
            unsigned char  Version2
            unsigned char  Version3
            unsigned char  Padding
            unsigned short start_address
    	unsigned short data

    Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
    Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>


When I revert that commit from the 2.6.30-rc1 revision, I get a bootable
system.

Thanks,
Robin

Re: Linux 2.6.30-rc1

[Christian Kujau]

[cc'ing Jeremy]

On Tue, 7 Apr 2009, Kevin Bowling wrote:
> I was really hoping some of the Xen dom0 patches would be merged to lessen 
> the load as time goes on an prevent a large Xen dump all at once.  Is there 
> any reason NONE of these patches made it upstream this round, or the past 
> few for the matter?

/me was interested in this as well, Jeremy - can you comment on that?

Thanks,
Christian.
-- 
Bruce Schneier has an Olympic-sized entropy pool.

Re: Linux 2.6.30-rc1

[Robin Holt]

Booting an ia64 box with a tg3 adapter results in no network.  If I look
at the MAC address of the adapter, it has changed radically from the
original MAC.  The original MAC continues to be reported by EFI and
booting an old kernel gets the correct MAC.

Good MAC:	08:00:69:13:E6:3C
Bad MAC:	00:00:3C:E6:13:69 (recreated from memory)

If I set the MAC using ifconfig, then everything works normally.

Robin

Re: Linux 2.6.30-rc1

[Michael Chan]

Robin Holt wrote:

> Booting an ia64 box with a tg3 adapter results in no network.
>  If I look
> at the MAC address of the adapter, it has changed radically from the
> original MAC.  The original MAC continues to be reported by EFI and
> booting an old kernel gets the correct MAC.
>
> Good MAC:     08:00:69:13:E6:3C
> Bad MAC:      00:00:3C:E6:13:69 (recreated from memory)

Looks like endian swapped.  Can you provide the entire tg3 signon
string?  Please also dump the beginning part of the nvram:

ethtool -e eth0 length 0x90

>
> If I set the MAC using ifconfig, then everything works normally.
>

The bad MAC address that has been swapped is also a valid MAC address
and should still work though.

Re: Linux 2.6.30-rc1

[Michal Simek]

Hi Linus,
> Other? Arch updates - amainly rm, powerpc, sh and x86. Firmware updates. 
> And lots and lots of driver updates, including some more core 
> suspend/resume changes (hopefully the last really fundamental ones). 
>
>   
I would like to ask again if you can pull new Microblaze arch to your
tree. All patches go
to arch/microblaze folder (+ one change in serial Kconfig). Ingo
reviewed all patches.
Ingo told me that you are just busy and you added Microblaze at the end
you huge merge list. I was OK with it
and wait and I see that Microblaze wasn't there.
My request is in LKML from 28.3.2008. We sent you some private email but
we don't have any your response.
Thomas Gleixner wrote you private email too. Do you have any response?
I am going to send you my request in special email again.

Is that anything wrong with Microblaze or don't you want to add new arch?

Thanks,
Michal


> Go out and try it,
>
> 		Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>   


-- 
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663

Re: Linux 2.6.30-rc1

[Robin Holt]

On Tue, Apr 07, 2009 at 10:54:33PM -0700, Michael Chan wrote:
> Robin Holt wrote:
> 
> > Booting an ia64 box with a tg3 adapter results in no network.
> >  If I look
> > at the MAC address of the adapter, it has changed radically from the
> > original MAC.  The original MAC continues to be reported by EFI and
> > booting an old kernel gets the correct MAC.
> >
> > Good MAC:     08:00:69:13:E6:3C
> > Bad MAC:      00:00:3C:E6:13:69 (recreated from memory)
> 
> Looks like endian swapped.  Can you provide the entire tg3 signon
> string?  Please also dump the beginning part of the nvram:
> 
> ethtool -e eth0 length 0x90

>From a good boot (2.6.27):
tg3.c:v3.94 (August 14, 2008)
tg3 0006:00:01.0: PCI INT A -> GSI 65 (level, low) -> IRQ 65
eth0: Tigon3 [partno(9210292) rev 2003 PHY(5704)] (PCIX:133MHz:64-bit) 10/100/1000Base-T Ethernet 00:e0:ed:08:6c:18
eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[1] TSOcap[1]
eth0: dma_rwctrl[769f4000] dma_mask[64-bit] tg3 0006:00:01.1: PCI INT B -> GSI 66 (level, low) -> IRQ 66
eth1: Tigon3 [partno(9210292) rev 2003 PHY(5704)] (PCIX:133MHz:64-bit) 10/100/1000Base-T Ethernet 00:e0:ed:08:6c:19
eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[1] TSOcap[1]
eth1: dma_rwctrl[769f4000] dma_mask[64-bit]
tg3 0001:00:04.0: PCI INT A -> GSI 62 (level, low) -> IRQ 62
eth2: Tigon3 [partno(030-1771-000) rev 0105 PHY(5701)] (PCI:66MHz:64-bit) 10/100/1000Base-T Ethernet 08:00:69:13:e6:3c
eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[1] TSOcap[0]

ethtool -e eth2 length 0x90
Address   	Data
----------	----
0x00000000	0x66
0x00000001	0x99
0x00000002	0x55
0x00000003	0xaa
0x00000004	0x08
0x00000005	0x00
0x00000006	0x00
0x00000007	0x00
0x00000008	0x00
0x00000009	0x00
0x0000000a	0x02
0x0000000b	0xa5
0x0000000c	0x00
0x0000000d	0x00
0x0000000e	0x02
0x0000000f	0x00
0x00000010	0x08
0x00000011	0xdf
0x00000012	0x2a
0x00000013	0xb1
0x00000014	0x00
0x00000015	0x01
0x00000016	0x00
0x00000017	0x00
0x00000018	0x00
0x00000019	0x00
0x0000001a	0x3c
0x0000001b	0x00
0x0000001c	0x00
0x0000001d	0x00
0x0000001e	0x10
0x0000001f	0x00
0x00000020	0x00
0x00000021	0x00
0x00000022	0x00
0x00000023	0x00
0x00000024	0x00
0x00000025	0x00
0x00000026	0x00
0x00000027	0x00
0x00000028	0x00
0x00000029	0x00
0x0000002a	0x00
0x0000002b	0x00
0x0000002c	0x00
0x0000002d	0x00
0x0000002e	0x00
0x0000002f	0x00
0x00000030	0x00
0x00000031	0x00
0x00000032	0x00
0x00000033	0x00
0x00000034	0x00
0x00000035	0x00
0x00000036	0x00
0x00000037	0x00
0x00000038	0x00
0x00000039	0x00
0x0000003a	0x00
0x0000003b	0x00
0x0000003c	0x00
0x0000003d	0x00
0x0000003e	0x00
0x0000003f	0x00
0x00000040	0x00
0x00000041	0x00
0x00000042	0x00
0x00000043	0x00
0x00000044	0x00
0x00000045	0x00
0x00000046	0x00
0x00000047	0x00
0x00000048	0x00
0x00000049	0x00
0x0000004a	0x00
0x0000004b	0x00
0x0000004c	0x00
0x0000004d	0x00
0x0000004e	0x00
0x0000004f	0x00
0x00000050	0x00
0x00000051	0x00
0x00000052	0x00
0x00000053	0x00
0x00000054	0x00
0x00000055	0x00
0x00000056	0x00
0x00000057	0x00
0x00000058	0x00
0x00000059	0x00
0x0000005a	0x00
0x0000005b	0x00
0x0000005c	0x00
0x0000005d	0x00
0x0000005e	0x00
0x0000005f	0x00
0x00000060	0x00
0x00000061	0x00
0x00000062	0x00
0x00000063	0x00
0x00000064	0x00
0x00000065	0x00
0x00000066	0x00
0x00000067	0x00
0x00000068	0x00
0x00000069	0x00
0x0000006a	0x00
0x0000006b	0x00
0x0000006c	0x00
0x0000006d	0x00
0x0000006e	0x00
0x0000006f	0x00
0x00000070	0x00
0x00000071	0x00
0x00000072	0x00
0x00000073	0x00
0x00000074	0x43
0x00000075	0x00
0x00000076	0x00
0x00000077	0x8c
0x00000078	0x00
0x00000079	0x00
0x0000007a	0x00
0x0000007b	0x01
0x0000007c	0x00
0x0000007d	0x00
0x0000007e	0x08
0x0000007f	0x00
0x00000080	0x69
0x00000081	0x13
0x00000082	0xe6
0x00000083	0x3c
0x00000084	0x33
0x00000085	0x43
0x00000086	0x39
0x00000087	0x39
0x00000088	0x36
0x00000089	0x42
0x0000008a	0x2d
0x0000008b	0x54
0x0000008c	0x00
0x0000008d	0x00
0x0000008e	0x00
0x0000008f	0x00


>From bad boot (v2.6.30-rc1):
tg3.c:v3.98 (February 25, 2009)
tg3 0006:00:01.0: PCI INT A -> GSI 65 (level, low) -> IRQ 65
tg3 0006:00:01.0: PME# disabled
eth0: Tigon3 [partno(9210292) rev 2003] (PCIX:133MHz:64-bit) MAC address 00:e0:ed:08:6c:18
eth0: attached PHY is 5704 (10/100/1000Base-T Ethernet) (WireSpeed[1])
eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
eth0: dma_rwctrl[769f4000] dma_mask[64-bit]
tg3 0006:00:01.1: PCI INT B -> GSI 66 (level, low) -> IRQ 66
tg3 0006:00:01.1: PME# disabled
eth1: Tigon3 [partno(9210292) rev 2003] (PCIX:133MHz:64-bit) MAC address 00:e0:ed:08:6c:19
eth1: attached PHY is 5704 (10/100/1000Base-T Ethernet) (WireSpeed[1])
eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
eth1: dma_rwctrl[769f4000] dma_mask[64-bit]
tg3 0001:00:04.0: PCI INT A -> GSI 62 (level, low) -> IRQ 62
tg3 0001:00:04.0: PME# disabled
eth2: Tigon3 [partno(030-1771-000) rev 0105] (PCI:66MHz:64-bit) MAC address 00:00:3c:e6:13:69
eth2: attached PHY is 5701 (10/100/1000Base-T Ethernet) (WireSpeed[1])
eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[0]
eth2: dma_rwctrl[76ff3f0f] dma_mask[64-bit]

ethtool -e eth2 length 0x90
Address   	Data
----------	----
0x00000000	0x66
0x00000001	0x99
0x00000002	0x55
0x00000003	0xaa
0x00000004	0x08
0x00000005	0x00
0x00000006	0x30
0x00000007	0x00
0x00000008	0x00
0x00000009	0x00
0x0000000a	0x03
0x0000000b	0x15
0x0000000c	0x00
0x0000000d	0x00
0x0000000e	0x02
0x0000000f	0xf8
0x00000010	0xaf
0x00000011	0xfc
0x00000012	0x24
0x00000013	0xb1
0x00000014	0x00
0x00000015	0x01
0x00000016	0x00
0x00000017	0x00
0x00000018	0x00
0x00000019	0x00
0x0000001a	0x3d
0x0000001b	0xaa
0x0000001c	0x00
0x0000001d	0x00
0x0000001e	0x1f
0x0000001f	0xb0
0x00000020	0x00
0x00000021	0x00
0x00000022	0x00
0x00000023	0x00
0x00000024	0x00
0x00000025	0x00
0x00000026	0x00
0x00000027	0x00
0x00000028	0x00
0x00000029	0x00
0x0000002a	0x00
0x0000002b	0x00
0x0000002c	0x00
0x0000002d	0x00
0x0000002e	0x00
0x0000002f	0x00
0x00000030	0x00
0x00000031	0x00
0x00000032	0x00
0x00000033	0x00
0x00000034	0x00
0x00000035	0x00
0x00000036	0x00
0x00000037	0x00
0x00000038	0x00
0x00000039	0x00
0x0000003a	0x00
0x0000003b	0x00
0x0000003c	0x00
0x0000003d	0x00
0x0000003e	0x00
0x0000003f	0x00
0x00000040	0x00
0x00000041	0x00
0x00000042	0x00
0x00000043	0x00
0x00000044	0x00
0x00000045	0x00
0x00000046	0x00
0x00000047	0x00
0x00000048	0x00
0x00000049	0x00
0x0000004a	0x00
0x0000004b	0x00
0x0000004c	0x00
0x0000004d	0x00
0x0000004e	0x00
0x0000004f	0x00
0x00000050	0x00
0x00000051	0x00
0x00000052	0x00
0x00000053	0x00
0x00000054	0x00
0x00000055	0x00
0x00000056	0x00
0x00000057	0x00
0x00000058	0x00
0x00000059	0x00
0x0000005a	0x00
0x0000005b	0x00
0x0000005c	0x00
0x0000005d	0x00
0x0000005e	0x00
0x0000005f	0x00
0x00000060	0x00
0x00000061	0x00
0x00000062	0x00
0x00000063	0x00
0x00000064	0x00
0x00000065	0x00
0x00000066	0x00
0x00000067	0x00
0x00000068	0x00
0x00000069	0x00
0x0000006a	0x00
0x0000006b	0x00
0x0000006c	0x00
0x0000006d	0x00
0x0000006e	0x00
0x0000006f	0x00
0x00000070	0x00
0x00000071	0x00
0x00000072	0x00
0x00000073	0x00
0x00000074	0x43
0x00000075	0x00
0x00000076	0x00
0x00000077	0x8c
0x00000078	0x00
0x00000079	0x20
0x0000007a	0x61
0x0000007b	0x10
0x0000007c	0x00
0x0000007d	0x00
0x0000007e	0x00
0x0000007f	0xe0
0x00000080	0xed
0x00000081	0x08
0x00000082	0x6c
0x00000083	0x18
0x00000084	0x39
0x00000085	0x32
0x00000086	0x31
0x00000087	0x30
0x00000088	0x32
0x00000089	0x39
0x0000008a	0x32
0x0000008b	0x00
0x0000008c	0x00
0x0000008d	0x00
0x0000008e	0x00
0x0000008f	0x00


> > If I set the MAC using ifconfig, then everything works normally.
> >
> 
> The bad MAC address that has been swapped is also a valid MAC address
> and should still work though.

Our network dhcp servers on this test network only hand out IPs to known
MACs so we detect situations like this.

Robin

Re: Linux 2.6.30-rc1

[Jike Song]

On Wed, Apr 8, 2009 at 8:20 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> So the two week merge window has closed, and just as well - because we had
> a lot of changes. As usual. Certainly I had no urges to keep the window
> open to get those last remaining few megabytes of patches..
>
> The changes follow roughly the same pattern they have before: one third
> crap (that is, "staging" - the new random drivers that aren't really ready
> to be merged properly but get into the tree in the hope that they'll get
> better some day), one third real drivers, and one third "rest".
>
> And just to not break a new tradition, there's a few new filesystems in
> this release too:
>
>  - "nilfs2" has been brewing for a long while, and is another
>   log-structured filesystem that does snapshotting. Just google for
>   'nilfs2' for more details.
>
>  - "exofs" implements a filesystem on top of an external object store
>   (ie not a traditional storage of a linear array of anonymous blocks,
>   but a "smart" disk that does objects). See
>
>                Documentation/filesystems/exofs.txt
>
>   for some details.
>
>  - fscache/cachefiles is not really a filesystem, but infrastructure to do
>   caching of remote filesystems in the local filesystem, and NFS and AFS
>   have been updated to be able to use it.
>
> I'm personally hoping that we'll run out of filesystems rather than
> continue this new tradition indefinitely, but we'll see.
>
> But we've got older filesystems updated too: btrfs hopefully uses less
> stack space and is usable with a 4k stack, reiserfs got some updates, and
> a lot of other filesystems got minor refreshes. The ext3 changes are small
> enough to not show up in any dirstat, but hey, I think the fsync latency
> changes are interesting and probably more relevant to lots of people than
> most of the other changes.
>
> Other? Arch updates - amainly rm, powerpc, sh and x86. Firmware updates.
> And lots and lots of driver updates, including some more core
> suspend/resume changes (hopefully the last really fundamental ones).
>
> Go out and try it,
>
>                Linus

There is no way to build if one has CONFIG_SERIAL_MAX3100 selected to
be 'y' or 'm' - there is not max3100.c at all...


-- 
Thanks,
Jike

Re: Linux 2.6.30-rc1 tg3 endian issues with MAC addresses on BCM5701. Bisected.

[Robin Holt]

git-bisect points at:

[holt@attica 20090408-tg3]$ git-bisect good
e4f341103e4a2b35f56a0f89802f1b1448e8d04b is first bad commit
commit e4f341103e4a2b35f56a0f89802f1b1448e8d04b
Author: Matt Carlson <mcarlson@broadcom.com>
Date:   Wed Feb 25 14:25:00 2009 +0000

    tg3: Invert nvram_read() and nvram_read_swab()
    
    This patch removes the blind byteswap of NVRAM data as it is read in.
    To preserve the logic at the call sites, this patch also inverts every
    call to tg3_nvram_read() and tg3_nvram_read_swab().  The call swap gets
    confusing within tg3_nvram_read_le() (LE is a misnomer), but the reader
    should be able to convince himself / herself that the resulting behavior
    is still unchanged.
    
    Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
    Signed-off-by: Benjamin Li <benli@broadcom.com>
    Signed-off-by: Michael Chan <mchan@broadcom.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

:040000 040000 847eba840b1c0fceeb2378dc3b0fb8c1628f441d 80c40390c38976d0ca9cdb59d21bc39c145aa9ce M      drivers

On Wed, Apr 08, 2009 at 01:25:59AM -0500, Robin Holt wrote:
> On Tue, Apr 07, 2009 at 10:54:33PM -0700, Michael Chan wrote:
> > Robin Holt wrote:
> > 
> > > Booting an ia64 box with a tg3 adapter results in no network.
> > >  If I look
> > > at the MAC address of the adapter, it has changed radically from the
> > > original MAC.  The original MAC continues to be reported by EFI and
> > > booting an old kernel gets the correct MAC.
> > >
> > > Good MAC:     08:00:69:13:E6:3C
> > > Bad MAC:      00:00:3C:E6:13:69 (recreated from memory)
> > 
> > Looks like endian swapped.  Can you provide the entire tg3 signon
> > string?  Please also dump the beginning part of the nvram:
> > 
> > ethtool -e eth0 length 0x90
> 
> >From a good boot (2.6.27):
> tg3.c:v3.94 (August 14, 2008)
> tg3 0006:00:01.0: PCI INT A -> GSI 65 (level, low) -> IRQ 65
> eth0: Tigon3 [partno(9210292) rev 2003 PHY(5704)] (PCIX:133MHz:64-bit) 10/100/1000Base-T Ethernet 00:e0:ed:08:6c:18
> eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[1] TSOcap[1]
> eth0: dma_rwctrl[769f4000] dma_mask[64-bit] tg3 0006:00:01.1: PCI INT B -> GSI 66 (level, low) -> IRQ 66
> eth1: Tigon3 [partno(9210292) rev 2003 PHY(5704)] (PCIX:133MHz:64-bit) 10/100/1000Base-T Ethernet 00:e0:ed:08:6c:19
> eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[1] TSOcap[1]
> eth1: dma_rwctrl[769f4000] dma_mask[64-bit]
> tg3 0001:00:04.0: PCI INT A -> GSI 62 (level, low) -> IRQ 62
> eth2: Tigon3 [partno(030-1771-000) rev 0105 PHY(5701)] (PCI:66MHz:64-bit) 10/100/1000Base-T Ethernet 08:00:69:13:e6:3c
> eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[1] TSOcap[0]
> 
> ethtool -e eth2 length 0x90
> Address   	Data
> ----------	----
> 0x00000000	0x66
> 0x00000001	0x99
> 0x00000002	0x55
> 0x00000003	0xaa
> 0x00000004	0x08
> 0x00000005	0x00
> 0x00000006	0x00
> 0x00000007	0x00
> 0x00000008	0x00
> 0x00000009	0x00
> 0x0000000a	0x02
> 0x0000000b	0xa5
> 0x0000000c	0x00
> 0x0000000d	0x00
> 0x0000000e	0x02
> 0x0000000f	0x00
> 0x00000010	0x08
> 0x00000011	0xdf
> 0x00000012	0x2a
> 0x00000013	0xb1
> 0x00000014	0x00
> 0x00000015	0x01
> 0x00000016	0x00
> 0x00000017	0x00
> 0x00000018	0x00
> 0x00000019	0x00
> 0x0000001a	0x3c
> 0x0000001b	0x00
> 0x0000001c	0x00
> 0x0000001d	0x00
> 0x0000001e	0x10
> 0x0000001f	0x00
> 0x00000020	0x00
> 0x00000021	0x00
> 0x00000022	0x00
> 0x00000023	0x00
> 0x00000024	0x00
> 0x00000025	0x00
> 0x00000026	0x00
> 0x00000027	0x00
> 0x00000028	0x00
> 0x00000029	0x00
> 0x0000002a	0x00
> 0x0000002b	0x00
> 0x0000002c	0x00
> 0x0000002d	0x00
> 0x0000002e	0x00
> 0x0000002f	0x00
> 0x00000030	0x00
> 0x00000031	0x00
> 0x00000032	0x00
> 0x00000033	0x00
> 0x00000034	0x00
> 0x00000035	0x00
> 0x00000036	0x00
> 0x00000037	0x00
> 0x00000038	0x00
> 0x00000039	0x00
> 0x0000003a	0x00
> 0x0000003b	0x00
> 0x0000003c	0x00
> 0x0000003d	0x00
> 0x0000003e	0x00
> 0x0000003f	0x00
> 0x00000040	0x00
> 0x00000041	0x00
> 0x00000042	0x00
> 0x00000043	0x00
> 0x00000044	0x00
> 0x00000045	0x00
> 0x00000046	0x00
> 0x00000047	0x00
> 0x00000048	0x00
> 0x00000049	0x00
> 0x0000004a	0x00
> 0x0000004b	0x00
> 0x0000004c	0x00
> 0x0000004d	0x00
> 0x0000004e	0x00
> 0x0000004f	0x00
> 0x00000050	0x00
> 0x00000051	0x00
> 0x00000052	0x00
> 0x00000053	0x00
> 0x00000054	0x00
> 0x00000055	0x00
> 0x00000056	0x00
> 0x00000057	0x00
> 0x00000058	0x00
> 0x00000059	0x00
> 0x0000005a	0x00
> 0x0000005b	0x00
> 0x0000005c	0x00
> 0x0000005d	0x00
> 0x0000005e	0x00
> 0x0000005f	0x00
> 0x00000060	0x00
> 0x00000061	0x00
> 0x00000062	0x00
> 0x00000063	0x00
> 0x00000064	0x00
> 0x00000065	0x00
> 0x00000066	0x00
> 0x00000067	0x00
> 0x00000068	0x00
> 0x00000069	0x00
> 0x0000006a	0x00
> 0x0000006b	0x00
> 0x0000006c	0x00
> 0x0000006d	0x00
> 0x0000006e	0x00
> 0x0000006f	0x00
> 0x00000070	0x00
> 0x00000071	0x00
> 0x00000072	0x00
> 0x00000073	0x00
> 0x00000074	0x43
> 0x00000075	0x00
> 0x00000076	0x00
> 0x00000077	0x8c
> 0x00000078	0x00
> 0x00000079	0x00
> 0x0000007a	0x00
> 0x0000007b	0x01
> 0x0000007c	0x00
> 0x0000007d	0x00
> 0x0000007e	0x08
> 0x0000007f	0x00
> 0x00000080	0x69
> 0x00000081	0x13
> 0x00000082	0xe6
> 0x00000083	0x3c
> 0x00000084	0x33
> 0x00000085	0x43
> 0x00000086	0x39
> 0x00000087	0x39
> 0x00000088	0x36
> 0x00000089	0x42
> 0x0000008a	0x2d
> 0x0000008b	0x54
> 0x0000008c	0x00
> 0x0000008d	0x00
> 0x0000008e	0x00
> 0x0000008f	0x00
> 
> 
> >From bad boot (v2.6.30-rc1):
> tg3.c:v3.98 (February 25, 2009)
> tg3 0006:00:01.0: PCI INT A -> GSI 65 (level, low) -> IRQ 65
> tg3 0006:00:01.0: PME# disabled
> eth0: Tigon3 [partno(9210292) rev 2003] (PCIX:133MHz:64-bit) MAC address 00:e0:ed:08:6c:18
> eth0: attached PHY is 5704 (10/100/1000Base-T Ethernet) (WireSpeed[1])
> eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
> eth0: dma_rwctrl[769f4000] dma_mask[64-bit]
> tg3 0006:00:01.1: PCI INT B -> GSI 66 (level, low) -> IRQ 66
> tg3 0006:00:01.1: PME# disabled
> eth1: Tigon3 [partno(9210292) rev 2003] (PCIX:133MHz:64-bit) MAC address 00:e0:ed:08:6c:19
> eth1: attached PHY is 5704 (10/100/1000Base-T Ethernet) (WireSpeed[1])
> eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
> eth1: dma_rwctrl[769f4000] dma_mask[64-bit]
> tg3 0001:00:04.0: PCI INT A -> GSI 62 (level, low) -> IRQ 62
> tg3 0001:00:04.0: PME# disabled
> eth2: Tigon3 [partno(030-1771-000) rev 0105] (PCI:66MHz:64-bit) MAC address 00:00:3c:e6:13:69
> eth2: attached PHY is 5701 (10/100/1000Base-T Ethernet) (WireSpeed[1])
> eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[0]
> eth2: dma_rwctrl[76ff3f0f] dma_mask[64-bit]
> 
> ethtool -e eth2 length 0x90
> Address   	Data
> ----------	----
> 0x00000000	0x66
> 0x00000001	0x99
> 0x00000002	0x55
> 0x00000003	0xaa
> 0x00000004	0x08
> 0x00000005	0x00
> 0x00000006	0x30
> 0x00000007	0x00
> 0x00000008	0x00
> 0x00000009	0x00
> 0x0000000a	0x03
> 0x0000000b	0x15
> 0x0000000c	0x00
> 0x0000000d	0x00
> 0x0000000e	0x02
> 0x0000000f	0xf8
> 0x00000010	0xaf
> 0x00000011	0xfc
> 0x00000012	0x24
> 0x00000013	0xb1
> 0x00000014	0x00
> 0x00000015	0x01
> 0x00000016	0x00
> 0x00000017	0x00
> 0x00000018	0x00
> 0x00000019	0x00
> 0x0000001a	0x3d
> 0x0000001b	0xaa
> 0x0000001c	0x00
> 0x0000001d	0x00
> 0x0000001e	0x1f
> 0x0000001f	0xb0
> 0x00000020	0x00
> 0x00000021	0x00
> 0x00000022	0x00
> 0x00000023	0x00
> 0x00000024	0x00
> 0x00000025	0x00
> 0x00000026	0x00
> 0x00000027	0x00
> 0x00000028	0x00
> 0x00000029	0x00
> 0x0000002a	0x00
> 0x0000002b	0x00
> 0x0000002c	0x00
> 0x0000002d	0x00
> 0x0000002e	0x00
> 0x0000002f	0x00
> 0x00000030	0x00
> 0x00000031	0x00
> 0x00000032	0x00
> 0x00000033	0x00
> 0x00000034	0x00
> 0x00000035	0x00
> 0x00000036	0x00
> 0x00000037	0x00
> 0x00000038	0x00
> 0x00000039	0x00
> 0x0000003a	0x00
> 0x0000003b	0x00
> 0x0000003c	0x00
> 0x0000003d	0x00
> 0x0000003e	0x00
> 0x0000003f	0x00
> 0x00000040	0x00
> 0x00000041	0x00
> 0x00000042	0x00
> 0x00000043	0x00
> 0x00000044	0x00
> 0x00000045	0x00
> 0x00000046	0x00
> 0x00000047	0x00
> 0x00000048	0x00
> 0x00000049	0x00
> 0x0000004a	0x00
> 0x0000004b	0x00
> 0x0000004c	0x00
> 0x0000004d	0x00
> 0x0000004e	0x00
> 0x0000004f	0x00
> 0x00000050	0x00
> 0x00000051	0x00
> 0x00000052	0x00
> 0x00000053	0x00
> 0x00000054	0x00
> 0x00000055	0x00
> 0x00000056	0x00
> 0x00000057	0x00
> 0x00000058	0x00
> 0x00000059	0x00
> 0x0000005a	0x00
> 0x0000005b	0x00
> 0x0000005c	0x00
> 0x0000005d	0x00
> 0x0000005e	0x00
> 0x0000005f	0x00
> 0x00000060	0x00
> 0x00000061	0x00
> 0x00000062	0x00
> 0x00000063	0x00
> 0x00000064	0x00
> 0x00000065	0x00
> 0x00000066	0x00
> 0x00000067	0x00
> 0x00000068	0x00
> 0x00000069	0x00
> 0x0000006a	0x00
> 0x0000006b	0x00
> 0x0000006c	0x00
> 0x0000006d	0x00
> 0x0000006e	0x00
> 0x0000006f	0x00
> 0x00000070	0x00
> 0x00000071	0x00
> 0x00000072	0x00
> 0x00000073	0x00
> 0x00000074	0x43
> 0x00000075	0x00
> 0x00000076	0x00
> 0x00000077	0x8c
> 0x00000078	0x00
> 0x00000079	0x20
> 0x0000007a	0x61
> 0x0000007b	0x10
> 0x0000007c	0x00
> 0x0000007d	0x00
> 0x0000007e	0x00
> 0x0000007f	0xe0
> 0x00000080	0xed
> 0x00000081	0x08
> 0x00000082	0x6c
> 0x00000083	0x18
> 0x00000084	0x39
> 0x00000085	0x32
> 0x00000086	0x31
> 0x00000087	0x30
> 0x00000088	0x32
> 0x00000089	0x39
> 0x0000008a	0x32
> 0x0000008b	0x00
> 0x0000008c	0x00
> 0x0000008d	0x00
> 0x0000008e	0x00
> 0x0000008f	0x00
> 
> 
> > > If I set the MAC using ifconfig, then everything works normally.
> > >
> > 
> > The bad MAC address that has been swapped is also a valid MAC address
> > and should still work though.
> 
> Our network dhcp servers on this test network only hand out IPs to known
> MACs so we detect situations like this.
> 
> Robin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.30-rc1 boot failure on ia64 w/ QLA12160. Bisected.

[David Woodhouse]

On Tue, 2009-04-07 at 23:27 -0500, Robin Holt wrote:
> On and ia64 system with a QLA12160 adapter, my boot fails with:
> 
> qla1280: QLA12160 found on PCI bus 0, dev 3
> qla1280 0001:00:03.0: PCI INT A -> GSI 61 (level, low) -> IRQ 61
> scsi(0): Enabling SN2 PCI DMA dual channel lockup workaround
> qla1280 0001:00:03.0: firmware: using built-in firmware qlogic/12160.bin
> qla1280_mailbox_command: Command failed, mailbox0 = 0x0007, mailbox_out0 = 0x4003, istatus = 0x6000

Does this fix it?

diff --git a/drivers/scsi/qla1280.c b/drivers/scsi/qla1280.c
index 351b56c..b6f8382 100644
--- a/drivers/scsi/qla1280.c
+++ b/drivers/scsi/qla1280.c
@@ -1663,7 +1663,7 @@ qla1280_load_firmware_pio(struct scsi_qla_host
*ha)
 
 	/* Load RISC code. */
 	risc_address = ha->fwstart;
-	fw_data = (const __le16 *)&fw->data[4];
+	fw_data = (const __le16 *)&fw->data[3];
 	risc_code_size = (fw->size - 6) / 2;
 
 	for (i = 0; i < risc_code_size; i++) {
@@ -1722,7 +1722,7 @@ qla1280_load_firmware_dma(struct scsi_qla_host
*ha)
 
 	/* Load RISC code. */
 	risc_address = ha->fwstart;
-	fw_data = (const __le16 *)&fw->data[4];
+	fw_data = (const __le16 *)&fw->data[3];
 	risc_code_size = (fw->size - 6) / 2;
 
 	dprintk(1, "%s: DMA RISC code (%i) words\n",

-- 
dwmw2

Re: Linux 2.6.30-rc1 boot failure on ia64 w/ QLA12160. Bisected.

[David Woodhouse]

On Wed, 2009-04-08 at 00:33 -0700, David Woodhouse wrote:
> Does this fix it?

Brain fade; don't bother with that one. I think it should be
&fw->data[6] instead.

-- 
dwmw2

Re: Linux 2.6.30-rc1 boot failure on ia64 w/ QLA12160. Bisected.

[David Woodhouse]

On Tue, 2009-04-07 at 23:27 -0500, Robin Holt wrote:
> On and ia64 system with a QLA12160 adapter, my boot fails with:

Thanks for the report. After successful feedback from Jeremy, I've added
the commit below to git://git.infradead.org/~dwmw2/firmware-2.6.git,
which I asked Linus to pull already on Monday...

>From 0ce49d6da993adf8b17b7f3ed9805ade14a6a6f3 Mon Sep 17 00:00:00 2001
From: David Woodhouse <David.Woodhouse@intel.com>
Date: Wed, 8 Apr 2009 01:22:36 -0700
Subject: [PATCH] qla1280: Fix off-by-some error in firmware loading.

We were calculating the wrong address for the start of the data.

Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Tested-by: Jeremy Higdon <jeremy@sgi.com>
---
 drivers/scsi/qla1280.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/qla1280.c b/drivers/scsi/qla1280.c
index 351b56c..d030db9 100644
--- a/drivers/scsi/qla1280.c
+++ b/drivers/scsi/qla1280.c
@@ -1663,7 +1663,7 @@ qla1280_load_firmware_pio(struct scsi_qla_host *ha)
 
 	/* Load RISC code. */
 	risc_address = ha->fwstart;
-	fw_data = (const __le16 *)&fw->data[4];
+	fw_data = (const __le16 *)&fw->data[6];
 	risc_code_size = (fw->size - 6) / 2;
 
 	for (i = 0; i < risc_code_size; i++) {
@@ -1722,7 +1722,7 @@ qla1280_load_firmware_dma(struct scsi_qla_host *ha)
 
 	/* Load RISC code. */
 	risc_address = ha->fwstart;
-	fw_data = (const __le16 *)&fw->data[4];
+	fw_data = (const __le16 *)&fw->data[6];
 	risc_code_size = (fw->size - 6) / 2;
 
 	dprintk(1, "%s: DMA RISC code (%i) words\n",
-- 
1.6.2.2



-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

Re: Linux 2.6.30-rc1

[Morten P.D. Stevens]

2009/4/8 Linus Torvalds <torvalds@linux-foundation.org>:
>
> So the two week merge window has closed, and just as well - because we had
> a lot of changes. As usual. Certainly I had no urges to keep the window
> open to get those last remaining few megabytes of patches..

And what is with xen dom0 support ???

Where is it???

-

Morten

Re: Linux 2.6.30-rc1 boot failure on ia64 w/ QLA12160. Bisected.

[Robin Holt]

On Wed, Apr 08, 2009 at 12:36:29AM -0700, David Woodhouse wrote:
> On Wed, 2009-04-08 at 00:33 -0700, David Woodhouse wrote:
> > Does this fix it?
> 
> Brain fade; don't bother with that one. I think it should be
> &fw->data[6] instead.

According to Jeremy, that fixed it.  Just added it to my workarea and
started a build.

Thanks,
Robin

Re: Linux 2.6.30-rc1 boot failure on ia64 w/ QLA12160. Bisected.

[Jaswinder Singh Rajput]

Hello David,

On Wed, 2009-04-08 at 01:31 -0700, David Woodhouse wrote:
> On Tue, 2009-04-07 at 23:27 -0500, Robin Holt wrote:
> > On and ia64 system with a QLA12160 adapter, my boot fails with:
> 
> Thanks for the report. After successful feedback from Jeremy, I've added
> the commit below to git://git.infradead.org/~dwmw2/firmware-2.6.git,
> which I asked Linus to pull already on Monday...

you have updated the tree, so better send new pull request to Linus to
avoid any confusions :-)

Thanks,
--
JSR

Re: Linux 2.6.30-rc1 boot failure on ia64 w/ QLA12160. Bisected.

[David Woodhouse]

On Thu, 2009-04-09 at 21:13 +0530, Jaswinder Singh Rajput wrote:
> Hello David,
> 
> On Wed, 2009-04-08 at 01:31 -0700, David Woodhouse wrote:
> > On Tue, 2009-04-07 at 23:27 -0500, Robin Holt wrote:
> > > On and ia64 system with a QLA12160 adapter, my boot fails with:
> > 
> > Thanks for the report. After successful feedback from Jeremy, I've added
> > the commit below to git://git.infradead.org/~dwmw2/firmware-2.6.git,
> > which I asked Linus to pull already on Monday...
> 
> you have updated the tree, so better send new pull request to Linus to
> avoid any confusions :-)

The URL is above; he's clever enough to work it out. If he still hasn't
pulled it by the time I get home, I'll send another request.

-- 
dwmw2

Re: Linux 2.6.30-rc1 tg3 endian issues with MAC addresses on BCM5701. Bisected.

[Matt Carlson]

Thank you for doing this bisection Robin.  This, and the data you
provided in your previous email is really helpful.  Unfortunately, they
raise more questions than answers.

I reviewed this patch again, and it still looks correct to me.  It
should be one big behavioral no-op.  Obviously something is wrong, but
I'm not seeing the root cause at the moment.  I need to think about this
some more.

On Wed, Apr 08, 2009 at 12:12:04AM -0700, Robin Holt wrote:
> git-bisect points at:
> 
> [holt@attica 20090408-tg3]$ git-bisect good
> e4f341103e4a2b35f56a0f89802f1b1448e8d04b is first bad commit
> commit e4f341103e4a2b35f56a0f89802f1b1448e8d04b
> Author: Matt Carlson <mcarlson@broadcom.com>
> Date:   Wed Feb 25 14:25:00 2009 +0000
> 
>     tg3: Invert nvram_read() and nvram_read_swab()
>     
>     This patch removes the blind byteswap of NVRAM data as it is read in.
>     To preserve the logic at the call sites, this patch also inverts every
>     call to tg3_nvram_read() and tg3_nvram_read_swab().  The call swap gets
>     confusing within tg3_nvram_read_le() (LE is a misnomer), but the reader
>     should be able to convince himself / herself that the resulting behavior
>     is still unchanged.
>     
>     Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
>     Signed-off-by: Benjamin Li <benli@broadcom.com>
>     Signed-off-by: Michael Chan <mchan@broadcom.com>
>     Signed-off-by: David S. Miller <davem@davemloft.net>
> 
> :040000 040000 847eba840b1c0fceeb2378dc3b0fb8c1628f441d 80c40390c38976d0ca9cdb59d21bc39c145aa9ce M      drivers
> 
> On Wed, Apr 08, 2009 at 01:25:59AM -0500, Robin Holt wrote:
> > On Tue, Apr 07, 2009 at 10:54:33PM -0700, Michael Chan wrote:
> > > Robin Holt wrote:
> > > 
> > > > Booting an ia64 box with a tg3 adapter results in no network.
> > > >  If I look
> > > > at the MAC address of the adapter, it has changed radically from the
> > > > original MAC.  The original MAC continues to be reported by EFI and
> > > > booting an old kernel gets the correct MAC.
> > > >
> > > > Good MAC:     08:00:69:13:E6:3C
> > > > Bad MAC:      00:00:3C:E6:13:69 (recreated from memory)
> > > 
> > > Looks like endian swapped.  Can you provide the entire tg3 signon
> > > string?  Please also dump the beginning part of the nvram:
> > > 
> > > ethtool -e eth0 length 0x90
> > 
> > >From a good boot (2.6.27):
> > tg3.c:v3.94 (August 14, 2008)
> > tg3 0006:00:01.0: PCI INT A -> GSI 65 (level, low) -> IRQ 65
> > eth0: Tigon3 [partno(9210292) rev 2003 PHY(5704)] (PCIX:133MHz:64-bit) 10/100/1000Base-T Ethernet 00:e0:ed:08:6c:18
> > eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[1] TSOcap[1]
> > eth0: dma_rwctrl[769f4000] dma_mask[64-bit] tg3 0006:00:01.1: PCI INT B -> GSI 66 (level, low) -> IRQ 66
> > eth1: Tigon3 [partno(9210292) rev 2003 PHY(5704)] (PCIX:133MHz:64-bit) 10/100/1000Base-T Ethernet 00:e0:ed:08:6c:19
> > eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[1] TSOcap[1]
> > eth1: dma_rwctrl[769f4000] dma_mask[64-bit]
> > tg3 0001:00:04.0: PCI INT A -> GSI 62 (level, low) -> IRQ 62
> > eth2: Tigon3 [partno(030-1771-000) rev 0105 PHY(5701)] (PCI:66MHz:64-bit) 10/100/1000Base-T Ethernet 08:00:69:13:e6:3c
> > eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[1] TSOcap[0]
> > 
> > ethtool -e eth2 length 0x90
> > Address   	Data
> > ----------	----
> > 0x00000000	0x66
> > 0x00000001	0x99
> > 0x00000002	0x55
> > 0x00000003	0xaa
> > 0x00000004	0x08
> > 0x00000005	0x00
> > 0x00000006	0x00
> > 0x00000007	0x00
> > 0x00000008	0x00
> > 0x00000009	0x00
> > 0x0000000a	0x02
> > 0x0000000b	0xa5
> > 0x0000000c	0x00
> > 0x0000000d	0x00
> > 0x0000000e	0x02
> > 0x0000000f	0x00
> > 0x00000010	0x08
> > 0x00000011	0xdf
> > 0x00000012	0x2a
> > 0x00000013	0xb1
> > 0x00000014	0x00
> > 0x00000015	0x01
> > 0x00000016	0x00
> > 0x00000017	0x00
> > 0x00000018	0x00
> > 0x00000019	0x00
> > 0x0000001a	0x3c
> > 0x0000001b	0x00
> > 0x0000001c	0x00
> > 0x0000001d	0x00
> > 0x0000001e	0x10
> > 0x0000001f	0x00
> > 0x00000020	0x00
> > 0x00000021	0x00
> > 0x00000022	0x00
> > 0x00000023	0x00
> > 0x00000024	0x00
> > 0x00000025	0x00
> > 0x00000026	0x00
> > 0x00000027	0x00
> > 0x00000028	0x00
> > 0x00000029	0x00
> > 0x0000002a	0x00
> > 0x0000002b	0x00
> > 0x0000002c	0x00
> > 0x0000002d	0x00
> > 0x0000002e	0x00
> > 0x0000002f	0x00
> > 0x00000030	0x00
> > 0x00000031	0x00
> > 0x00000032	0x00
> > 0x00000033	0x00
> > 0x00000034	0x00
> > 0x00000035	0x00
> > 0x00000036	0x00
> > 0x00000037	0x00
> > 0x00000038	0x00
> > 0x00000039	0x00
> > 0x0000003a	0x00
> > 0x0000003b	0x00
> > 0x0000003c	0x00
> > 0x0000003d	0x00
> > 0x0000003e	0x00
> > 0x0000003f	0x00
> > 0x00000040	0x00
> > 0x00000041	0x00
> > 0x00000042	0x00
> > 0x00000043	0x00
> > 0x00000044	0x00
> > 0x00000045	0x00
> > 0x00000046	0x00
> > 0x00000047	0x00
> > 0x00000048	0x00
> > 0x00000049	0x00
> > 0x0000004a	0x00
> > 0x0000004b	0x00
> > 0x0000004c	0x00
> > 0x0000004d	0x00
> > 0x0000004e	0x00
> > 0x0000004f	0x00
> > 0x00000050	0x00
> > 0x00000051	0x00
> > 0x00000052	0x00
> > 0x00000053	0x00
> > 0x00000054	0x00
> > 0x00000055	0x00
> > 0x00000056	0x00
> > 0x00000057	0x00
> > 0x00000058	0x00
> > 0x00000059	0x00
> > 0x0000005a	0x00
> > 0x0000005b	0x00
> > 0x0000005c	0x00
> > 0x0000005d	0x00
> > 0x0000005e	0x00
> > 0x0000005f	0x00
> > 0x00000060	0x00
> > 0x00000061	0x00
> > 0x00000062	0x00
> > 0x00000063	0x00
> > 0x00000064	0x00
> > 0x00000065	0x00
> > 0x00000066	0x00
> > 0x00000067	0x00
> > 0x00000068	0x00
> > 0x00000069	0x00
> > 0x0000006a	0x00
> > 0x0000006b	0x00
> > 0x0000006c	0x00
> > 0x0000006d	0x00
> > 0x0000006e	0x00
> > 0x0000006f	0x00
> > 0x00000070	0x00
> > 0x00000071	0x00
> > 0x00000072	0x00
> > 0x00000073	0x00
> > 0x00000074	0x43
> > 0x00000075	0x00
> > 0x00000076	0x00
> > 0x00000077	0x8c
> > 0x00000078	0x00
> > 0x00000079	0x00
> > 0x0000007a	0x00
> > 0x0000007b	0x01
> > 0x0000007c	0x00
> > 0x0000007d	0x00
> > 0x0000007e	0x08
> > 0x0000007f	0x00
> > 0x00000080	0x69
> > 0x00000081	0x13
> > 0x00000082	0xe6
> > 0x00000083	0x3c
> > 0x00000084	0x33
> > 0x00000085	0x43
> > 0x00000086	0x39
> > 0x00000087	0x39
> > 0x00000088	0x36
> > 0x00000089	0x42
> > 0x0000008a	0x2d
> > 0x0000008b	0x54
> > 0x0000008c	0x00
> > 0x0000008d	0x00
> > 0x0000008e	0x00
> > 0x0000008f	0x00
> > 
> > 
> > >From bad boot (v2.6.30-rc1):
> > tg3.c:v3.98 (February 25, 2009)
> > tg3 0006:00:01.0: PCI INT A -> GSI 65 (level, low) -> IRQ 65
> > tg3 0006:00:01.0: PME# disabled
> > eth0: Tigon3 [partno(9210292) rev 2003] (PCIX:133MHz:64-bit) MAC address 00:e0:ed:08:6c:18
> > eth0: attached PHY is 5704 (10/100/1000Base-T Ethernet) (WireSpeed[1])
> > eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
> > eth0: dma_rwctrl[769f4000] dma_mask[64-bit]
> > tg3 0006:00:01.1: PCI INT B -> GSI 66 (level, low) -> IRQ 66
> > tg3 0006:00:01.1: PME# disabled
> > eth1: Tigon3 [partno(9210292) rev 2003] (PCIX:133MHz:64-bit) MAC address 00:e0:ed:08:6c:19
> > eth1: attached PHY is 5704 (10/100/1000Base-T Ethernet) (WireSpeed[1])
> > eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
> > eth1: dma_rwctrl[769f4000] dma_mask[64-bit]
> > tg3 0001:00:04.0: PCI INT A -> GSI 62 (level, low) -> IRQ 62
> > tg3 0001:00:04.0: PME# disabled
> > eth2: Tigon3 [partno(030-1771-000) rev 0105] (PCI:66MHz:64-bit) MAC address 00:00:3c:e6:13:69
> > eth2: attached PHY is 5701 (10/100/1000Base-T Ethernet) (WireSpeed[1])
> > eth2: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[0]
> > eth2: dma_rwctrl[76ff3f0f] dma_mask[64-bit]
> > 
> > ethtool -e eth2 length 0x90
> > Address   	Data
> > ----------	----
> > 0x00000000	0x66
> > 0x00000001	0x99
> > 0x00000002	0x55
> > 0x00000003	0xaa
> > 0x00000004	0x08
> > 0x00000005	0x00
> > 0x00000006	0x30
> > 0x00000007	0x00
> > 0x00000008	0x00
> > 0x00000009	0x00
> > 0x0000000a	0x03
> > 0x0000000b	0x15
> > 0x0000000c	0x00
> > 0x0000000d	0x00
> > 0x0000000e	0x02
> > 0x0000000f	0xf8
> > 0x00000010	0xaf
> > 0x00000011	0xfc
> > 0x00000012	0x24
> > 0x00000013	0xb1
> > 0x00000014	0x00
> > 0x00000015	0x01
> > 0x00000016	0x00
> > 0x00000017	0x00
> > 0x00000018	0x00
> > 0x00000019	0x00
> > 0x0000001a	0x3d
> > 0x0000001b	0xaa
> > 0x0000001c	0x00
> > 0x0000001d	0x00
> > 0x0000001e	0x1f
> > 0x0000001f	0xb0
> > 0x00000020	0x00
> > 0x00000021	0x00
> > 0x00000022	0x00
> > 0x00000023	0x00
> > 0x00000024	0x00
> > 0x00000025	0x00
> > 0x00000026	0x00
> > 0x00000027	0x00
> > 0x00000028	0x00
> > 0x00000029	0x00
> > 0x0000002a	0x00
> > 0x0000002b	0x00
> > 0x0000002c	0x00
> > 0x0000002d	0x00
> > 0x0000002e	0x00
> > 0x0000002f	0x00
> > 0x00000030	0x00
> > 0x00000031	0x00
> > 0x00000032	0x00
> > 0x00000033	0x00
> > 0x00000034	0x00
> > 0x00000035	0x00
> > 0x00000036	0x00
> > 0x00000037	0x00
> > 0x00000038	0x00
> > 0x00000039	0x00
> > 0x0000003a	0x00
> > 0x0000003b	0x00
> > 0x0000003c	0x00
> > 0x0000003d	0x00
> > 0x0000003e	0x00
> > 0x0000003f	0x00
> > 0x00000040	0x00
> > 0x00000041	0x00
> > 0x00000042	0x00
> > 0x00000043	0x00
> > 0x00000044	0x00
> > 0x00000045	0x00
> > 0x00000046	0x00
> > 0x00000047	0x00
> > 0x00000048	0x00
> > 0x00000049	0x00
> > 0x0000004a	0x00
> > 0x0000004b	0x00
> > 0x0000004c	0x00
> > 0x0000004d	0x00
> > 0x0000004e	0x00
> > 0x0000004f	0x00
> > 0x00000050	0x00
> > 0x00000051	0x00
> > 0x00000052	0x00
> > 0x00000053	0x00
> > 0x00000054	0x00
> > 0x00000055	0x00
> > 0x00000056	0x00
> > 0x00000057	0x00
> > 0x00000058	0x00
> > 0x00000059	0x00
> > 0x0000005a	0x00
> > 0x0000005b	0x00
> > 0x0000005c	0x00
> > 0x0000005d	0x00
> > 0x0000005e	0x00
> > 0x0000005f	0x00
> > 0x00000060	0x00
> > 0x00000061	0x00
> > 0x00000062	0x00
> > 0x00000063	0x00
> > 0x00000064	0x00
> > 0x00000065	0x00
> > 0x00000066	0x00
> > 0x00000067	0x00
> > 0x00000068	0x00
> > 0x00000069	0x00
> > 0x0000006a	0x00
> > 0x0000006b	0x00
> > 0x0000006c	0x00
> > 0x0000006d	0x00
> > 0x0000006e	0x00
> > 0x0000006f	0x00
> > 0x00000070	0x00
> > 0x00000071	0x00
> > 0x00000072	0x00
> > 0x00000073	0x00
> > 0x00000074	0x43
> > 0x00000075	0x00
> > 0x00000076	0x00
> > 0x00000077	0x8c
> > 0x00000078	0x00
> > 0x00000079	0x20
> > 0x0000007a	0x61
> > 0x0000007b	0x10
> > 0x0000007c	0x00
> > 0x0000007d	0x00
> > 0x0000007e	0x00
> > 0x0000007f	0xe0
> > 0x00000080	0xed
> > 0x00000081	0x08
> > 0x00000082	0x6c
> > 0x00000083	0x18
> > 0x00000084	0x39
> > 0x00000085	0x32
> > 0x00000086	0x31
> > 0x00000087	0x30
> > 0x00000088	0x32
> > 0x00000089	0x39
> > 0x0000008a	0x32
> > 0x0000008b	0x00
> > 0x0000008c	0x00
> > 0x0000008d	0x00
> > 0x0000008e	0x00
> > 0x0000008f	0x00
> > 
> > 
> > > > If I set the MAC using ifconfig, then everything works normally.
> > > >
> > > 
> > > The bad MAC address that has been swapped is also a valid MAC address
> > > and should still work though.
> > 
> > Our network dhcp servers on this test network only hand out IPs to known
> > MACs so we detect situations like this.
> > 
> > Robin
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: Linux 2.6.30-rc1 tg3 endian issues with MAC addresses on BCM5701. Bisected.

[Robin Holt]

On Mon, Apr 13, 2009 at 10:57:24AM -0700, Matt Carlson wrote:
> Thank you for doing this bisection Robin.  This, and the data you
> provided in your previous email is really helpful.  Unfortunately, they
> raise more questions than answers.
> 
> I reviewed this patch again, and it still looks correct to me.  It
> should be one big behavioral no-op.  Obviously something is wrong, but
> I'm not seeing the root cause at the moment.  I need to think about this
> some more.

If you want me to build test kernels with debug printk's, etc.  Let me
know.  I will be working that issue on the side, so my responses may be
slightly delayed.  I have access to many tests machines that exhibit
this problem.

The problem seems to affect BCM5701 based systems only.  BCM5704 have
the correct MAC addresses.  Nearly all of our SGI Altix 3700/4700
machines have the BCM5701 adapters on their base I/O board.

Thanks,
Robin

Re: Linux 2.6.30-rc1 tg3 endian issues with MAC addresses on BCM5701. Bisected.

[David Miller]

From: Robin Holt <holt@sgi.com>
Date: Mon, 13 Apr 2009 15:15:58 -0500

> On Mon, Apr 13, 2009 at 10:57:24AM -0700, Matt Carlson wrote:
>> Thank you for doing this bisection Robin.  This, and the data you
>> provided in your previous email is really helpful.  Unfortunately, they
>> raise more questions than answers.
>> 
>> I reviewed this patch again, and it still looks correct to me.  It
>> should be one big behavioral no-op.  Obviously something is wrong, but
>> I'm not seeing the root cause at the moment.  I need to think about this
>> some more.
> 
> If you want me to build test kernels with debug printk's, etc.  Let me
> know.  I will be working that issue on the side, so my responses may be
> slightly delayed.  I have access to many tests machines that exhibit
> this problem.
> 
> The problem seems to affect BCM5701 based systems only.  BCM5704 have
> the correct MAC addresses.  Nearly all of our SGI Altix 3700/4700
> machines have the BCM5701 adapters on their base I/O board.

I think it's only going to hit chips that access those particular
NVRAM chip read/write paths.

Matt, realize that on big-endian there are implicit endian
conversions going on.  The read*/write* macros are converting
little-to-big endian on big-endian systems.

Actually, is that the case, that we only see this corrupt MAC
address bug on big-endian systems?  Or are we seeing this on
little-endian too?

Re: Linux 2.6.30-rc1 tg3 endian issues with MAC addresses on BCM5701. Bisected.

[David Miller]

From: "Matt Carlson" <mcarlson@broadcom.com>
Date: Mon, 13 Apr 2009 10:57:24 -0700

> Thank you for doing this bisection Robin.  This, and the data you
> provided in your previous email is really helpful.  Unfortunately, they
> raise more questions than answers.
> 
> I reviewed this patch again, and it still looks correct to me.  It
> should be one big behavioral no-op.  Obviously something is wrong, but
> I'm not seeing the root cause at the moment.  I need to think about this
> some more.

Matt, look at James Bottomly's patch posted earlier today, he
describes the problem perfectly.