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
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
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 <[email protected]>
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 <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
When I revert that commit from the 2.6.30-rc1 revision, I get a bootable
system.
Thanks,
Robin
[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.
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
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.
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 [email protected]
> 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: http://www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663
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
On Wed, Apr 8, 2009 at 8:20 AM, Linus Torvalds
<[email protected]> 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
git-bisect points at:
[holt@attica 20090408-tg3]$ git-bisect good
e4f341103e4a2b35f56a0f89802f1b1448e8d04b is first bad commit
commit e4f341103e4a2b35f56a0f89802f1b1448e8d04b
Author: Matt Carlson <[email protected]>
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 <[email protected]>
Signed-off-by: Benjamin Li <[email protected]>
Signed-off-by: Michael Chan <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
: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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
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
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
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 <[email protected]>
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 <[email protected]>
Tested-by: Jeremy Higdon <[email protected]>
---
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
[email protected] Intel Corporation
2009/4/8 Linus Torvalds <[email protected]>:
>
> 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
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
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
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
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 <[email protected]>
> 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 <[email protected]>
> Signed-off-by: Benjamin Li <[email protected]>
> Signed-off-by: Michael Chan <[email protected]>
> Signed-off-by: David S. Miller <[email protected]>
>
> :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 [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
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
From: Robin Holt <[email protected]>
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?
From: "Matt Carlson" <[email protected]>
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.