New: tlan network driver does not work

Bugme-new Andrew Morton 4 participants 6 messages Oct 14, 2008 – Oct 25, 2008 4 messages not in the archive

Subsystems (2)

Networking Network drivers

lore

Share & tools

lore

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

Andrew Morton

author

2008-10-14 12:33 UTC #1 lore raw

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 18 lines · On Mon, 13 Oct 2008 15:26:04 -0700 (PDT) [email protected] wrote:

http://bugzilla.kernel.org/show_bug.cgi?id=11754

           Summary: tlan network driver does not work
           Product: Drivers
           Version: 2.5
     KernelVersion: 2.6.27
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: high
          Priority: P1
         Component: Network
        AssignedTo: [email protected]
        ReportedBy: [email protected]

Quoted 2 lines

Latest working kernel version: 2.6.26
Earliest failing kernel version: 2.6.27

A 2.6.27 regression.

Not much has happened in tlan.c - a single fix from Robert. This regression might be in pppoe?

Quoted 46 lines

Distribution: SuSE 9.2
Hardware Environment:
/var/log/boot.msg:
<6>ThunderLAN driver v1.15
<6>tlan 0000:00:0d.0: found PCI INT A -> IRQ 11
<6>tlan 0000:00:0d.0: sharing IRQ 11 with 0000:00:09.0
<6>TLAN: eth1 irq=11, io=c400, Compaq Netelligent 10/100 TX PCI UTP, Rev. 16 <6>TLAN: 1 device installed, PCI: 1 EISA: 0
...
Setting up network interfaces:
    lo
    lo        IP address: 127.0.0.1/8
done    eth0      device: Realtek Semiconductor Co., Ltd. RTL-8029(AS)
    eth0      configuration: eth-id-52:54:00:db:15:ff
    eth0      IP address: 192.168.0.99/24
done    eth1      device: Compaq Computer Corporation Compaq Netelligent 10/100
TX PCI UTP TLAN 2.3 (rev 10)
    eth1      IP address: 192.168.1.22/24
done dsl0
dsl0 Startmode is 'manual'
Software Environment:
Problem Description:
PPPoe does not work
see /var/log/messages:
Oct 13 14:39:06 pc1 pppd[10123]: Plugin rp-pppoe.so loaded.
Oct 13 14:39:06 pc1 kernel: PPP generic driver version 2.4.2
Oct 13 14:39:06 pc1 pppd[10123]: RP-PPPoE plugin version 3.3 compiled against
pp
pd 2.4.2
Oct 13 14:39:06 pc1 pppd[10123]: Plugin passwordfd.so loaded.
Oct 13 14:39:06 pc1 kernel: NET: Registered protocol family 17
Oct 13 14:39:06 pc1 pppd[10123]: pppd 2.4.2 started by root, uid 0
Oct 13 14:39:41 pc1 pppd[10123]: Timeout waiting for PADO packets
Oct 13 14:39:41 pc1 pppd[10123]: Unable to complete PPPoE Discovery
Oct 13 14:39:41 pc1 pppd[10123]: Exit.
Steps to reproduce:
start dsl-connection to internet.

Manfred Scherer

2008-10-14 19:40 UTC #2 lore raw

so far as I can see there are no changes in drivers/net/pppoe.c

pc1:/kernel/linux-2.6.27/drivers/net # diff -u /mnt_md10/kernelbaeckerei/linux-2.6.26/drivers/net/pppoe.c pppoe.c pc1:/kernel/linux-2.6.27/drivers/net # echo $?
0
pc1:/kernel/linux-2.6.27/drivers/net #

but a lot of changes in tlan.c

thus I think tlan.c is much more the causer for this problem.

Manfred Scherer
____________________________________________________________________________________

Am Dienstag, 14. Oktober 2008 14:32 schrieb Andrew Morton:

Quoted 80 lines

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).
Quoted 18 lines · On Mon, 13 Oct 2008 15:26:04 -0700 (PDT) [email protected] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=11754
           Summary: tlan network driver does not work
           Product: Drivers
           Version: 2.5
     KernelVersion: 2.6.27
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: high
          Priority: P1
         Component: Network
        AssignedTo: [email protected]
        ReportedBy: [email protected]
Quoted 2 lines
Latest working kernel version: 2.6.26
Earliest failing kernel version: 2.6.27
A 2.6.27 regression.
Not much has happened in tlan.c - a single fix from Robert. This regression might be in pppoe?
Quoted 46 lines
Distribution: SuSE 9.2
Hardware Environment:
/var/log/boot.msg:
<6>ThunderLAN driver v1.15
<6>tlan 0000:00:0d.0: found PCI INT A -> IRQ 11
<6>tlan 0000:00:0d.0: sharing IRQ 11 with 0000:00:09.0
<6>TLAN: eth1 irq=11, io=c400, Compaq Netelligent 10/100 TX PCI UTP, Rev. 16 <6>TLAN: 1 device installed, PCI: 1 EISA: 0
...
Setting up network interfaces:
    lo
    lo        IP address: 127.0.0.1/8
done    eth0      device: Realtek Semiconductor Co., Ltd. RTL-8029(AS)
    eth0      configuration: eth-id-52:54:00:db:15:ff
    eth0      IP address: 192.168.0.99/24
done    eth1      device: Compaq Computer Corporation Compaq Netelligent 10/100
TX PCI UTP TLAN 2.3 (rev 10)
    eth1      IP address: 192.168.1.22/24
done dsl0
dsl0 Startmode is 'manual'
Software Environment:
Problem Description:
PPPoe does not work
see /var/log/messages:
Oct 13 14:39:06 pc1 pppd[10123]: Plugin rp-pppoe.so loaded.
Oct 13 14:39:06 pc1 kernel: PPP generic driver version 2.4.2
Oct 13 14:39:06 pc1 pppd[10123]: RP-PPPoE plugin version 3.3 compiled against
pp
pd 2.4.2
Oct 13 14:39:06 pc1 pppd[10123]: Plugin passwordfd.so loaded.
Oct 13 14:39:06 pc1 kernel: NET: Registered protocol family 17
Oct 13 14:39:06 pc1 pppd[10123]: pppd 2.4.2 started by root, uid 0
Oct 13 14:39:41 pc1 pppd[10123]: Timeout waiting for PADO packets
Oct 13 14:39:41 pc1 pppd[10123]: Unable to complete PPPoE Discovery
Oct 13 14:39:41 pc1 pppd[10123]: Exit.
Steps to reproduce:
start dsl-connection to internet.

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

Manfred Scherer

2008-10-21 22:37 UTC #5 lore raw

I did this test again. This time I get an output for tcpdump but I don't understand why. Anyway maybe it helps.

Original kernel 2.6.27:

pc1:/var/log # tcpdump -i eth1 -vv
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes 16:08:19.131281 PPPoE PADI [Service-Name] [Host-Uniq 0xC55D0000] 16:08:24.130603 PPPoE PADI [Service-Name] [Host-Uniq 0xC55D0000] 16:08:34.129227 PPPoE PADI [Service-Name] [Host-Uniq 0xC55D0000] ^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel
pc1:/var/log #

And now with the tlan module from kernel 2.6.26 compiled and tested in kernel 2.6.27:

pc1:/var/log # tcpdump -i eth1 -vv
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
16:21:34.890207 PPPoE PADI [Service-Name] [Host-Uniq 0xA7670000]
16:21:35.011875 PPPoE PADO [AC-Name "MANX48-erx"] [Host-Uniq 0xA7670000] [Service-Name] [AC-Cookie 0xCE73D7BB289D47261BF087A3B4AD1699] 16:21:35.011955 PPPoE PADR [Service-Name] [Host-Uniq 0xA7670000] [AC-Cookie 0xCE73D7BB289D47261BF087A3B4AD1699] 16:21:35.087761 PPPoE PADS [ses 0xc0b] [Service-Name] [Host-Uniq 0xA7670000] [AC-Name "MANX48-erx"] [AC-Cookie 0xCE73D7BB289D47261BF087A3B4AD1699] 16:21:35.125039 PPPoE [ses 0xc0b] LCP, Conf-Request (0x01), id 1, MRU 1492, Magic-Num 0xe1c8a370, length 14

        0x0000:  c021 0101 000e 0104 05d4 0506 e1c8 a370
16:21:35.276745 PPPoE  [ses 0xc0b] LCP, Conf-Request (0x01), id 176, MRU  1492, Auth-Prot  PAP, Magic-Num  0x6ef0246c, length 18
        0x0000:  c021 01b0 0012 0104 05d4 0304 c023 0506
        0x0010:  6ef0 246c
16:21:35.276824 PPPoE  [ses 0xc0b] LCP, Conf-Ack (0x02), id 176, MRU  1492, Auth-Prot  PAP, Magic-Num  0x6ef0246c, length 18
        0x0000:  c021 02b0 0012 0104 05d4 0304 c023 0506
        0x0010:  6ef0 246c
16:21:35.277259 PPPoE  [ses 0xc0b] LCP, Conf-Ack (0x02), id 1, MRU  1492, Magic-Num  0xe1c8a370, length 14
        0x0000:  c021 0201 000e 0104 05d4 0506 e1c8 a370
16:21:35.277357 PPPoE  [ses 0xc0b] LCP, Echo-Request (0x09), id 0, Magic-Num 0xe1c8a370, length 8
        0x0000:  c021 0900 0008 e1c8 a370
16:21:35.277387 PPPoE  [ses 0xc0b] Auth-Req(1), Peer 000012341234123434#[email protected], Name XXXXXX
16:21:35.320362 PPPoE  [ses 0xc0b] LCP, Echo-Reply (0x0a), id 0, Magic-Num 0x6ef0246c, length 8
        0x0000:  c021 0a00 0008 6ef0 246c

Manfred Scherer
_________________________________________________________________________________

Am Dienstag, 21. Oktober 2008 17:43 schrieb Michal Ostrowski:

Quoted 205 lines

The strace shows that the rp-pppoe daemon did send a packet out over the raw socket. The problem here appears to be that nothing showed up in the tcpdump
output --- indicating the packet never hit the wire.
--
Michal Ostrowski
[email protected]
Quoted 191 lines · Manfred Scherer
In the SuSE-9.2 distribution is the approach to connect to the Internet via DSL a bit tricky. There are a bunch of human interfaces, like kinternet (KDE), cinternet (commandline tool), and so on. All these human interfaces uses the same service smpppd.
I use the commandline tool cinternet in shell scripts to do the connect to the internet.
pc1:~ # ps -ef|grep ppp
root 4721 1 0 Oct18 ? 00:01:23 /usr/sbin/smpppd
It makes no sense to start cinternet via strace but control smpppd via strace:
strace -f -p 4721 -o /var/log/strace_pppd_2_6_27_.log
I've done both cases, in the some way. In my last mail was an extract from these trace files. Here are now the complete one as attachment.
bug_11754_logfiles_2.zip:
(quoted diff) +0 -2
-rw-r--r--  1 root root 684114 Oct 19 16:35 strace_pppd_2_6_26_.log
-rw-r--r--  1 root root 807244 Oct 19 16:36 strace_pppd_2_6_27_.log
Manfred Scherer
_____________________________________________________________________________
Am Sonntag, 19. Oktober 2008 21:52 schrieb Michal Ostrowski:
Quoted 5 lines
One interesting thing to note is that there are no packets in the 2.6.27 tcpdump -- which indicates that
the initial transmission by pppoe did not result in a packet going out.
It might be interesting to see an strace, but one done with the "-f"
flag.
Quoted 4 lines
These straces don't show
the pppoe process that pppd spawns.
Quoted 10 lines
--
Michal Ostrowski
[email protected]
Quoted 2 lines · Manfred Scherer
here some logfiles (bug_11754_logfiles.zip) for compare 2.6.26 to
2.6.27:
Quoted 7 lines
Review
Quoted 7 lines
(quoted diff) +0 -6
-rw-r--r--  1 root root   6465 Oct 15 15:52 pppd_2_6_26.log
-rw-r--r--  1 root root    566 Oct 15 13:24 pppd_2_6_27.log
-rw-r--r--  1 root root 130438 Oct 15 15:41 strace_pppd_2_6_26_7719.log
-rw-r--r--  1 root root  28123 Oct 15 15:41 strace_pppd_2_6_27_8852.log
-rw-r--r--  1 root root  14337 Oct 15 13:12 tcpdump_eth1_2_6_26.log
-rw-r--r--  1 root root      0 Oct 15 13:21 tcpdump_eth1_2_6_27.log
(is
Quoted 5 lines
Quoted 5 lines
empty because no output)
Manfred Scherer
__________________________________________________________________________________
Quoted 4 lines
Quoted 4 lines
Am Dienstag, 14. Oktober 2008 15:52 schrieb Michal Ostrowski:
Quoted 2 lines
The failure occurs during PPPOE negotiation.
The pppoe kernel driver does not do the negotiation phase, which is
done
Quoted 3 lines
Quoted 3 lines
in
Quoted 2 lines
user space.
At this stage we're just using a raw socket to grab those packets
from
Quoted 18 lines
Quoted 18 lines
the
Quoted 2 lines
eth device,
and it appears we were not able to receive the first packet from the
server
Quoted 4 lines
- there's no
indication that any packets came in over the eth device at all.
To debug this one would need: verbose logs from pppd/rp-pppoe and a
tcpdump
Quoted 9 lines
trace
showing packets on the specified interface.
--
Michal Ostrowski
[email protected]
Quoted 5 lines
Quoted 5 lines
Quoted 1 line
On Tue, Oct 14, 2008 at 7:32 AM, Andrew Morton <
Quoted 3 lines · [email protected]>wrote:
Quoted 3 lines
(switched to email. Please respond via emailed reply-to-all, not
via
Quoted 31 lines
Quoted 31 lines
the
Quoted 30 lines
Quoted 30 lines
bugzilla web interface).
Quoted 1 line
On Mon, 13 Oct 2008 15:26:04 -0700 (PDT)
Quoted 17 lines · [email protected] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=11754
           Summary: tlan network driver does not work
           Product: Drivers
           Version: 2.5
     KernelVersion: 2.6.27
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: high
          Priority: P1
         Component: Network
        AssignedTo: [email protected]
        ReportedBy: [email protected]
Quoted 2 lines
Latest working kernel version: 2.6.26
Earliest failing kernel version: 2.6.27
A 2.6.27 regression.
Not much has happened in tlan.c - a single fix from Robert. This regression might be in pppoe?
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Distribution: SuSE 9.2
Hardware Environment:
/var/log/boot.msg:
<6>ThunderLAN driver v1.15
<6>tlan 0000:00:0d.0: found PCI INT A -> IRQ 11 <6>tlan 0000:00:0d.0: sharing IRQ 11 with 0000:00:09.0 <6>TLAN: eth1 irq=11, io=c400, Compaq Netelligent 10/100 TX PCI
UTP,
Quoted 22 lines
Quoted 22 lines
Rev.
Quoted 7 lines
Quoted 7 lines
16
Quoted 6 lines
<6>TLAN: 1 device installed, PCI: 1 EISA: 0
...
Setting up network interfaces:
    lo
    lo        IP address: 127.0.0.1/8
done eth0 device: Realtek Semiconductor Co., Ltd.
RTL-8029(AS)
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
    eth0      configuration: eth-id-52:54:00:db:15:ff
    eth0      IP address: 192.168.0.99/24
done eth1 device: Compaq Computer Corporation Compaq
Netelligent
Quoted 9 lines
Quoted 9 lines
10/100
Quoted 8 lines
TX PCI UTP TLAN 2.3 (rev 10)
    eth1      IP address: 192.168.1.22/24
done dsl0
dsl0 Startmode is 'manual'
Software Environment:
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Problem Description:
PPPoe does not work
see /var/log/messages:
Oct 13 14:39:06 pc1 pppd[10123]: Plugin rp-pppoe.so loaded.
Oct 13 14:39:06 pc1 kernel: PPP generic driver version 2.4.2
Oct 13 14:39:06 pc1 pppd[10123]: RP-PPPoE plugin version 3.3
compiled
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
against
Quoted 5 lines
pp
pd 2.4.2
Oct 13 14:39:06 pc1 pppd[10123]: Plugin passwordfd.so loaded.
Oct 13 14:39:06 pc1 kernel: NET: Registered protocol family 17
Oct 13 14:39:06 pc1 pppd[10123]: pppd 2.4.2 started by root, uid
0
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Oct 13 14:39:41 pc1 pppd[10123]: Timeout waiting for PADO packets
Oct 13 14:39:41 pc1 pppd[10123]: Unable to complete PPPoE
Discovery
Quoted 12 lines
Quoted 11 lines
Quoted 10 lines
Quoted 9 lines
Quoted 7 lines
Oct 13 14:39:41 pc1 pppd[10123]: Exit.
Steps to reproduce:
start dsl-connection to internet.

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

Manfred Scherer

2008-10-24 12:14 UTC #7 lore raw

I had a look on the ethernet pci-card LAN-LED and the DSL-Modem LAN-LED. It seems to be that the packets were sent out are going over the wire, the ethernet pci-card LAN-LED and the DSL-Modem LAN-LED blinks three times. It seems so that the replayed packets are dropped.

Manfred Scherer
_____________________________________________________________________________

Am Mittwoch, 22. Oktober 2008 00:40 schrieb Michal Ostrowski:

Quoted 76 lines

As far as linux is concerned 3 "PADI" packets were sent out; in other words 3 such
packets were given to the driver.
Given that there's no "PADO" reply, then either the driver dropped the packet transmission, or
it dropped the reply.
--
Michal Ostrowski
[email protected]
Quoted 59 lines · Manfred Scherer
I did this test again. This time I get an output for tcpdump but I don't understand why. Anyway maybe it helps.
Original kernel 2.6.27:
pc1:/var/log # tcpdump -i eth1 -vv
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes 16:08:19.131281 PPPoE PADI [Service-Name] [Host-Uniq 0xC55D0000] 16:08:24.130603 PPPoE PADI [Service-Name] [Host-Uniq 0xC55D0000] 16:08:34.129227 PPPoE PADI [Service-Name] [Host-Uniq 0xC55D0000] ^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel
pc1:/var/log #
And now with the tlan module from kernel 2.6.26 compiled and tested in kernel 2.6.27:
pc1:/var/log # tcpdump -i eth1 -vv
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
16:21:34.890207 PPPoE PADI [Service-Name] [Host-Uniq 0xA7670000] 16:21:35.011875 PPPoE PADO [AC-Name "MANX48-erx"] [Host-Uniq 0xA7670000] [Service-Name] [AC-Cookie 0xCE73D7BB289D47261BF087A3B4AD1699] 16:21:35.011955 PPPoE PADR [Service-Name] [Host-Uniq 0xA7670000] [AC-Cookie 0xCE73D7BB289D47261BF087A3B4AD1699]
16:21:35.087761 PPPoE PADS [ses 0xc0b] [Service-Name] [Host-Uniq 0xA7670000] [AC-Name "MANX48-erx"] [AC-Cookie 0xCE73D7BB289D47261BF087A3B4AD1699]
16:21:35.125039 PPPoE [ses 0xc0b] LCP, Conf-Request (0x01), id 1, MRU
1492, Magic-Num 0xe1c8a370, length 14
       0x0000:  c021 0101 000e 0104 05d4 0506 e1c8 a370
16:21:35.276745 PPPoE  [ses 0xc0b] LCP, Conf-Request (0x01), id 176, MRU
 1492, Auth-Prot  PAP, Magic-Num  0x6ef0246c, length 18
       0x0000:  c021 01b0 0012 0104 05d4 0304 c023 0506
       0x0010:  6ef0 246c
16:21:35.276824 PPPoE  [ses 0xc0b] LCP, Conf-Ack (0x02), id 176, MRU  1492,
Auth-Prot  PAP, Magic-Num  0x6ef0246c, length 18
       0x0000:  c021 02b0 0012 0104 05d4 0304 c023 0506
       0x0010:  6ef0 246c
16:21:35.277259 PPPoE  [ses 0xc0b] LCP, Conf-Ack (0x02), id 1, MRU  1492,
Magic-Num  0xe1c8a370, length 14
       0x0000:  c021 0201 000e 0104 05d4 0506 e1c8 a370
16:21:35.277357 PPPoE  [ses 0xc0b] LCP, Echo-Request (0x09), id 0,
Magic-Num 0xe1c8a370, length 8
       0x0000:  c021 0900 0008 e1c8 a370
16:21:35.277387 PPPoE [ses 0xc0b] Auth-Req(1), Peer 000012341234123434# [email protected], Name XXXXXX
16:21:35.320362 PPPoE [ses 0xc0b] LCP, Echo-Reply (0x0a), id 0, Magic-Num 0x6ef0246c, length 8
       0x0000:  c021 0a00 0008 6ef0 246c
Manfred Scherer

Robert Fitzsimons

2008-10-25 00:01 UTC #8 lore raw

I've double checked my patch and still think it's correct. Lets quickly review it:

@@ -360,8 +360,8 @@ TLan_GetSKB( const struct tlan_list_tag *tag)
{
unsigned long addr;

- addr = tag->buffer[8].address;
- addr |= (tag->buffer[9].address << 16) << 16;
+ addr = tag->buffer[9].address;
+ addr |= (tag->buffer[8].address << 16) << 16;
return (struct sk_buff *) addr;
}

The hardware structure tlan_list_tag is used (abused?) to store non-hardware related data. So buffer[8].address is used to store the upper 32 bits and buffer[9].address is the lower 32 bits of the sk_buffer address.

@@ -1984,7 +1984,6 @@ static void TLan_ResetLists( struct net_device *dev )
TLanList *list;
dma_addr_t list_phys;
struct sk_buff *skb;
- void *t = NULL;

priv->txHead = 0;
priv->txTail = 0;
@@ -2022,7 +2021,8 @@ static void TLan_ResetLists( struct net_device *dev )
}

skb_reserve( skb, NET_IP_ALIGN );
- list->buffer[0].address = pci_map_single(priv->pciDev, t,
+ list->buffer[0].address = pci_map_single(priv->pciDev,
+ skb->data,
TLAN_MAX_FRAME_SIZE, PCI_DMA_FROMDEVICE);
TLan_StoreSKB(list, skb);

buffer[0].address is the hardware address which the card can DMA the received frame to. The previous version of the code mapped a null pointer. So my change uses the sk_buffer data pointer which is what the TLan_HandleRxEOF does and expected objective.

Manfred, where are you getting the source from, how much ram does the computer have, and can you send your .config file.

Robert

Quoted 6 lines · Manfred Scherer

I had a look on the ethernet pci-card LAN-LED and the DSL-Modem LAN-LED. It seems to be that the packets were sent out are going over the wire, the ethernet pci-card LAN-LED and the DSL-Modem LAN-LED blinks three times. It seems so that the replayed packets are dropped.
Manfred Scherer

Stephen Hemminger

2008-10-25 00:18 UTC #9 lore raw

Review TLan_GetSKB( const struct tlan_list_tag *tag) · line 364

Quoted 11 lines · On Sat, 25 Oct 2008 01:00:33 +0100 Robert Fitzsimons <[email protected]> wrote:

I've double checked my patch and still think it's correct. Lets quickly review it:

(quoted diff) +2 -2

@@ -360,8 +360,8 @@ TLan_GetSKB( const struct tlan_list_tag *tag)
 {
 	unsigned long addr;
 
-	addr = tag->buffer[8].address;
-	addr |= (tag->buffer[9].address << 16) << 16;
+	addr = tag->buffer[9].address;
+	addr |= (tag->buffer[8].address << 16) << 16;

There is upper_32_bits(x) and lower_32_bits(x) for this (see kernel.h)