Re: [Bugme-new] [Bug 11754] New: tlan network driver does not work

Re: [Bugme-new] [Bug 11754] New: tlan network driver does not work

[Andrew Morton]

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

> On Mon, 13 Oct 2008 15:26:04 -0700 (PDT) bugme-daemon@bugzilla.kernel.org 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: jgarzik@pobox.com
>         ReportedBy: Manfred.Scherer.Mhm@t-online.de
> 
> 
> 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?


> 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.
> 

Re: [Bugme-new] [Bug 11754] New: tlan network driver does not work

[Manfred Scherer]

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:
> 
> (switched to email.  Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
> 
> > On Mon, 13 Oct 2008 15:26:04 -0700 (PDT) bugme-daemon@bugzilla.kernel.org 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: jgarzik@pobox.com
> >         ReportedBy: Manfred.Scherer.Mhm@t-online.de
> > 
> > 
> > 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?
> 
> 
> > 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.
> > 
> 
> 
> 

Re: [Bugme-new] [Bug 11754] New: tlan network driver does not work

[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#0001@t-online.de, 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:
> 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
> mostrows@gmail.com
> 
> 
> On Tue, Oct 21, 2008 at 1:36 AM, Manfred Scherer <
> manfred.scherer.mhm@t-online.de> wrote:
> 
> >
> > 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:
> > -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:
> > > 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.
> > > These straces don't show
> > > the pppoe process that pppd spawns.
> > >
> > >
> > > --
> > > Michal Ostrowski
> > > mostrows@gmail.com
> > >
> > >
> > > On Wed, Oct 15, 2008 at 9:06 AM, Manfred Scherer <
> > > manfred.scherer.mhm@t-online.de> wrote:
> > >
> > > >
> > > > here some logfiles (bug_11754_logfiles.zip) for compare 2.6.26 to
> > 2.6.27:
> > > >
> > > > -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
> > > > empty because no output)
> > > >
> > > > Manfred Scherer
> > > >
> > > >
> > __________________________________________________________________________________
> > > >
> > > > Am Dienstag, 14. Oktober 2008 15:52 schrieb Michal Ostrowski:
> > > > > The failure occurs during PPPOE negotiation.
> > > > > The pppoe kernel driver does not do the negotiation phase, which is
> > done
> > > > in
> > > > > user space.
> > > > > At this stage we're just using a raw socket to grab those packets
> > from
> > > > the
> > > > > eth device,
> > > > > and it appears we were not able to receive the first packet from the
> > > > server
> > > > > - 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
> > > > > trace
> > > > > showing packets on the specified interface.
> > > > >
> > > > >
> > > > > --
> > > > > Michal Ostrowski
> > > > > mostrows@gmail.com
> > > > >
> > > > >
> > > > > On Tue, Oct 14, 2008 at 7:32 AM, Andrew Morton <
> > > > akpm@linux-foundation.org>wrote:
> > > > >
> > > > > >
> > > > > > (switched to email.  Please respond via emailed reply-to-all, not
> > via
> > > > the
> > > > > > bugzilla web interface).
> > > > > >
> > > > > > > On Mon, 13 Oct 2008 15:26:04 -0700 (PDT)
> > > > > > bugme-daemon@bugzilla.kernel.org 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: jgarzik@pobox.com
> > > > > > >         ReportedBy: Manfred.Scherer.Mhm@t-online.de
> > > > > > >
> > > > > > >
> > > > > > > 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?
> > > > > >
> > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> 

Re: [Bugme-new] [Bug 11754] New: tlan network driver does not work

[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
_____________________________________________________________________________

Am Mittwoch, 22. Oktober 2008 00:40 schrieb Michal Ostrowski:
> 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
> mostrows@gmail.com
> 
> 
> On Tue, Oct 21, 2008 at 9:34 AM, Manfred Scherer <
> manfred.scherer.mhm@t-online.de> wrote:
> 
> >
> > 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#
> > 0001@t-online.de, 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
> >

Re: [Bugme-new] [Bug 11754] New: tlan network driver does not work

[Robert Fitzsimons]

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


On Fri, Oct 24, 2008 at 06:12:12AM +0200, Manfred Scherer wrote:
> 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

Re: [Bugme-new] [Bug 11754] New: tlan network driver does not work

[Stephen Hemminger]

On Sat, 25 Oct 2008 01:00:33 +0100
Robert Fitzsimons <robfitz@273k.net> wrote:

> 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;

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

Re: [Bugme-new] [Bug 11754] New: tlan network driver does not work

[Manfred Scherer]

I've tested this patch with success.

here are my test scenarios:

load the pached module:

pc1:/lib/modules/2.6.27/kernel/drivers/net # rmmod tlan
pc1:/lib/modules/2.6.27/kernel/drivers/net # cp -p tlan.ko.2.6.27_sakari.ailus tlan.ko
pc1:/lib/modules/2.6.27/kernel/drivers/net # modprobe tlan

browser access to the DSL-modem:

pc1:/lib/modules/2.6.27/kernel/drivers/net # tcpdump -i eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
09:37:50.167945 arp who-has 192.168.1.1 tell 192.168.1.22
09:37:50.168179 arp reply 192.168.1.1 is-at 00:19:15:47:0e:11
09:37:50.168197 IP 192.168.1.22.avsecuremgmt > 192.168.1.1.http: S 3925686798:3925686798(0) win 5840 <sackOK,timestamp 91699898 0,mss 1460,nop,wscale 6>
09:37:50.168693 arp who-has 192.168.1.22 tell 192.168.1.1
09:37:50.168719 arp reply 192.168.1.22 is-at 00:08:c7:28:5a:96
09:37:50.169204 IP 192.168.1.1.http > 192.168.1.22.avsecuremgmt: S 0:0(0) ack 3925686799 win 49152 <mss 1400>
09:37:50.169344 IP 192.168.1.22.avsecuremgmt > 192.168.1.1.http: . ack 1 win 5840
09:37:50.169475 IP 192.168.1.22.avsecuremgmt > 192.168.1.1.http: P 1:364(363) ack 1 win 5840
09:37:50.169716 IP 192.168.1.1.http > 192.168.1.22.avsecuremgmt: . ack 1 win 49152
09:37:50.170227 IP 192.168.1.1.http > 192.168.1.22.avsecuremgmt: . 1:28(27) ack 364 win 49152
09:37:50.170292 IP 192.168.1.22.avsecuremgmt > 192.168.1.1.http: . ack 28 win 5840
09:37:50.170738 IP 192.168.1.1.http > 192.168.1.22.avsecuremgmt: . 28:398(370) ack 364 win 49152
09:37:50.170796 IP 192.168.1.22.avsecuremgmt > 192.168.1.1.http: . ack 398 win 6432
...


Access to the internet via ppoe does work also:

Dec 16 09:34:46 pc1 kernel: ThunderLAN driver v1.15
Dec 16 09:34:46 pc1 kernel: TLAN: eth1 irq=11, io=c400, Compaq Netelligent 10/100 TX PCI UTP, Rev. 16
Dec 16 09:34:46 pc1 kernel: TLAN: 1 device installed, PCI: 1  EISA: 0
Dec 16 09:34:57 pc1 kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready
Dec 16 09:34:57 pc1 kernel: TLAN: eth1: Starting autonegotiation.
Dec 16 09:34:59 pc1 kernel: TLAN: eth1: Autonegotiation complete.
Dec 16 09:34:59 pc1 kernel: TLAN: eth1: Link active with AutoNegotiation enabled, at 100Mbps Full-Duplex
Dec 16 09:34:59 pc1 kernel: TLAN: Partner capability: 10BaseT-HD 10BaseT-FD 100baseTx-HD 100baseTx-FD<NULL>
Dec 16 09:34:59 pc1 kernel: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
Dec 16 09:35:10 pc1 kernel: eth1: no IPv6 routers present
Dec 16 09:35:22 pc1 kernel: device eth1 entered promiscuous mode
Dec 16 09:41:26 pc1 kernel: device eth1 left promiscuous mode
Dec 16 09:41:46 pc1 pppd[14895]: Plugin rp-pppoe.so loaded.
Dec 16 09:41:46 pc1 pppd[14895]: RP-PPPoE plugin version 3.3 compiled against pppd 2.4.2
Dec 16 09:41:46 pc1 pppd[14895]: Plugin passwordfd.so loaded.
Dec 16 09:41:46 pc1 pppd[14895]: pppd 2.4.2 started by root, uid 0
Dec 16 09:41:47 pc1 pppd[14895]: PPP session is 1299
Dec 16 09:41:47 pc1 pppd[14895]: Renamed interface ppp0 to dsl0
Dec 16 09:41:47 pc1 pppd[14895]: Using interface dsl0
Dec 16 09:41:47 pc1 pppd[14895]: Connect: dsl0 <--> eth1
Dec 16 09:41:47 pc1 pppd[14895]: Couldn't increase MTU to 1500
Dec 16 09:41:47 pc1 pppd[14895]: Couldn't increase MRU to 1500
Dec 16 09:41:47 pc1 pppd[14895]: PAP authentication succeeded
Dec 16 09:41:47 pc1 pppd[14895]: peer from calling number 00:90:1A:A0:BF:67 authorized
Dec 16 09:41:47 pc1 pppd[14895]: local  IP address 87.178.120.71
Dec 16 09:41:47 pc1 pppd[14895]: remote IP address 217.0.117.13
Dec 16 09:41:47 pc1 pppd[14895]: primary   DNS address 217.237.150.51
Dec 16 09:41:47 pc1 pppd[14895]: secondary DNS address 217.237.148.22
Dec 16 09:41:47 pc1 modify_resolvconf: Service pppd modified /etc/resolv.conf. See info block in this file
Dec 16 09:41:54 pc1 pppd[14895]: Script /etc/ppp/ip-up finished (pid 14919), status = 0x0

... an now I am online and send this email.

Manfred Scherer
____________________________________________________________________________

Am Dienstag, 16. Dezember 2008 00:40 schrieben Sie:
> The TLAN chip does not support tranmissions smaller than 64 bytes. Smaller
> transfers need to be padded up to that size. This was broken by commit id
> 41873e9aff0632d80c74380d58a89e8d420151bd.
> 
> <URL:http://bugzilla.kernel.org/show_bug.cgi?id=11754>
> 
> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
> ---
>  drivers/net/tlan.c |   10 ++++++----
>  1 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/tlan.c b/drivers/net/tlan.c
> index c41d687..cf8cdaf 100644
> --- a/drivers/net/tlan.c
> +++ b/drivers/net/tlan.c
> @@ -1098,6 +1098,7 @@ static int TLan_StartTx( struct sk_buff *skb, struct net_device *dev )
>  	dma_addr_t	tail_list_phys;
>  	u8		*tail_buffer;
>  	unsigned long	flags;
> +	unsigned int    txlen;
>  
>  	if ( ! priv->phyOnline ) {
>  		TLAN_DBG( TLAN_DEBUG_TX, "TRANSMIT:  %s PHY is not ready\n",
> @@ -1108,6 +1109,7 @@ static int TLan_StartTx( struct sk_buff *skb, struct net_device *dev )
>  
>  	if (skb_padto(skb, TLAN_MIN_FRAME_SIZE))
>  		return 0;
> +	txlen = max(skb->len, (unsigned int)TLAN_MIN_FRAME_SIZE);
>  
>  	tail_list = priv->txList + priv->txTail;
>  	tail_list_phys = priv->txListDMA + sizeof(TLanList) * priv->txTail;
> @@ -1125,16 +1127,16 @@ static int TLan_StartTx( struct sk_buff *skb, struct net_device *dev )
>  
>  	if ( bbuf ) {
>  		tail_buffer = priv->txBuffer + ( priv->txTail * TLAN_MAX_FRAME_SIZE );
> -		skb_copy_from_linear_data(skb, tail_buffer, skb->len);
> +		skb_copy_from_linear_data(skb, tail_buffer, txlen);
>  	} else {
>  		tail_list->buffer[0].address = pci_map_single(priv->pciDev,
> -							      skb->data, skb->len,
> +							      skb->data, txlen,
>  							      PCI_DMA_TODEVICE);
>  		TLan_StoreSKB(tail_list, skb);
>  	}
>  
> -	tail_list->frameSize = (u16) skb->len;
> -	tail_list->buffer[0].count = TLAN_LAST_BUFFER | (u32) skb->len;
> +	tail_list->frameSize = (u16) txlen;
> +	tail_list->buffer[0].count = TLAN_LAST_BUFFER | (u32) txlen;
>  	tail_list->buffer[1].count = 0;
>  	tail_list->buffer[1].address = 0;
>