sip*: reset in interrupt logic

	i need the following patch to make the following interface work.
	does it make sense?

itojun

sip0 at pci0 dev 18 function 0: NatSemi DP83815 10/100 Ethernet, rev 00
sip0: interrupting at irq 10
sip0: Ethernet address 00:00:24:c0:55:dc
nsphyter0 at sip0 phy 0: DP83815 10/100 media interface, rev. 1
nsphyter0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto

>	does sip* interface work for you on Soekris 4501?  for me it goes
>	into infinite loop in sip_intr and sip_init.

itojun

Index: if_sip.c
===================================================================
RCS file: /cvsroot/syssrc/sys/dev/pci/if_sip.c,v
retrieving revision 1.61
diff -u -r1.61 if_sip.c

Re: sip*: reset in interrupt logic

> > 	i need the following patch to make the following interface work.
> > 	does it make sense?
>I certainly have not needed any patch like that for my Soekris or any
>of my other sip-using machines...  Which interrupt is pending when you
>get the loop?

	i haven't tracked down yet, i guess intr - reset - intr - reset
	loop (and commenting out "reset" within intr does not raise any
	problem).

itojun

Re: sip*: reset in interrupt logic

On Mon, Aug 05, 2002 at 08:55:42AM +0900, Jun-ichiro itojun Hagino wrote:

 > 	i haven't tracked down yet, i guess intr - reset - intr - reset
 > 	loop (and commenting out "reset" within intr does not raise any
 > 	problem).

Yah, it would just be good to know which interrupt is coming in that
causes the problem.

--

-- 
        -- Jason R. Thorpe <thorpej <at> wasabisystems.com>

Re: sip*: reset in interrupt logic

On Sun, Aug 04, 2002 at 05:40:40PM -0700, Jason R Thorpe wrote:

 > On Mon, Aug 05, 2002 at 08:55:42AM +0900, Jun-ichiro itojun Hagino wrote:
 > 
 >  > 	i haven't tracked down yet, i guess intr - reset - intr - reset
 >  > 	loop (and commenting out "reset" within intr does not raise any
 >  > 	problem).
 > 
 > Yah, it would just be good to know which interrupt is coming in that
 > causes the problem.

So, the things that call sip_init() from within sip_intr() are:

	* Transmit FIFO underrun
	* PCI parity error
	* PCI system error
	* PCI master abort
	* PCI target abort
	* Receive status FIFO overrun

A message will be displayed on the console indicating which error it is.

--

-- 
        -- Jason R. Thorpe <thorpej <at> wasabisystems.com>

Re: sip*: reset in interrupt logic

>So, the things that call sip_init() from within sip_intr() are:
>	* Transmit FIFO underrun
>	* PCI parity error
>	* PCI system error
>	* PCI master abort
>	* PCI target abort
>	* Receive status FIFO overrun
>A message will be displayed on the console indicating which error it is.

	with my Net4501, it hangs up before the above message is printed.
	here's the printf trace - looks to me some interrupt source is not
	cleared (not sure why NOT calling sip_reset() solves the problem).

	btw, what is the baudrate of serial console for Net4501?  i see garbage
	on the reboot.

itojun

Script started on Mon Aug  5 10:04:02 2002
itojun[starfruit:/home/itojun] tip tty00
connected

tiny# 
tiny# dmesg
NetBSD 1.6E (GENERIC) #2: Mon Aug  5 09:56:21 JST 2002
    itojun <at> starfruit.itojun.rrg:/usr/home/itojun/NetBSD/src/sys/arch/i386/compile/GENERIC
cpu0: AMD Am5x86 W/B 133/160 (486cclass)
cpu0: features 1<FPU>

Re: sip*: reset in interrupt logic

On Mon, Aug 05, 2002 at 10:09:42AM +0900, Jun-ichiro itojun Hagino wrote:

 > 	btw, what is the baudrate of serial console for Net4501?  i see garbage
 > 	on the reboot.

I simply reconfigured comBIOS on mine to use 9600.  I think it defaults
to 38400.

--

-- 
        -- Jason R. Thorpe <thorpej <at> wasabisystems.com>

adding an 802.11 data link type

I would like to add an 802.11 DLT to NetBSD so that I can observe 802.11
mgmt/ctl frames through bpf.

In the discussion on the 802.11 DLT in May, it appears that a rough consensus
was reached, namely that

 0) DLTs DLT_802_11, DLT_PRISM_802_11, DLT_AIRONET_802_11 are desirable
    in addition to DLT_EN10MB.
 1) A driver supporting more than one DLT will call bpf with a new
    procedure, bpfattach_multidlt, passing bpfattach_multidlt a mask
    describing the DLTs the driver supports.
 2) 802.11 interfaces will default to handing up 802.3 frames to bpf,
    so that dhclient, tcpdump, etc. do not break.
 3) Two new ioctl's list/choose the DLT used by bpf:

      BIOCGDLTS -- returns a bit vector. "Lit" bits indicate supported DLTs.
                   For example, on an 802.11 interface, the DLT_EN10MB'th
                   bit and the DLT_802_11'th bit will be set.

      BIOCSDLT  -- change the DLT for the bpf socket to one of the supported
                   types

 4) a driver will only build frames that listeners want

If this is not substantially how people desire for the 802.11 DLT to work,
let me know.

If somebody has already begun to program this feature, stop me.

Re: adding an 802.11 data link type

> I would like to add an 802.11 DLT to NetBSD so that I can observe 802.11
> mgmt/ctl frames through bpf.

Sorry for lazy activities on this topic...

> In the discussion on the 802.11 DLT in May, it appears that a rough consensus
> was reached, namely that
> 
>  0) DLTs DLT_802_11, DLT_PRISM_802_11, DLT_AIRONET_802_11 are desirable
>     in addition to DLT_EN10MB.

I think it would be better if we define DLT_DRVSPEC for all driver specific
raw format, since I don't want to implement DLT_AIRONET_ for 'wi' driver.

>  1) A driver supporting more than one DLT will call bpf with a new
>     procedure, bpfattach_multidlt, passing bpfattach_multidlt a mask
>     describing the DLTs the driver supports.

Since the number of supported DLTs for a driver would be limited,
multiple calls to bpfattach_dlt() may be accepted.
This would help to implement streight forward implementation which splits
bpf_if for each DLT.

>  2) 802.11 interfaces will default to handing up 802.3 frames to bpf,
>     so that dhclient, tcpdump, etc. do not break.

>  3) Two new ioctl's list/choose the DLT used by bpf:
> 
>       BIOCGDLTS -- returns a bit vector. "Lit" bits indicate supported DLTs.
>                    For example, on an 802.11 interface, the DLT_EN10MB'th

Re: adding an 802.11 data link type

On Mon, Aug 05, 2002 at 02:54:06PM +0900, Atsushi Onoe wrote:
> David Young wrote:
> >  0) DLTs DLT_802_11, DLT_PRISM_802_11, DLT_AIRONET_802_11 are desirable
> >     in addition to DLT_EN10MB.
> 
> I think it would be better if we define DLT_DRVSPEC for all driver specific
> raw format, since I don't want to implement DLT_AIRONET_ for 'wi' driver.

How will a bpf listener distinguish Aironet's DLT_DRVSPEC from Prism's
DLT_DRVSPEC? Only driver 'an' should implement DLT_AIRONET_. Only driver
'wi' will implement DLT_PRISM_, and only when it drives a Prism NIC.

> Since the number of supported DLTs for a driver would be limited,
> multiple calls to bpfattach_dlt() may be accepted.
> This would help to implement streight forward implementation which splits
> bpf_if for each DLT.

Ok.

> >  3) Two new ioctl's list/choose the DLT used by bpf:
> > 
> >       BIOCGDLTS -- returns a bit vector. "Lit" bits indicate supported DLTs.
> >                    For example, on an 802.11 interface, the DLT_EN10MB'th
> >                    bit and the DLT_802_11'th bit will be set.
> 
> It seems that the range of the value for DLT is not defined. BIOCGDLT
> just uses u_int to pass it.  So returning array of supported DLTs would
> be better.

Re: adding an 802.11 data link type

On Mon, 5 Aug 2002, David Young wrote:

>
>
>  0) DLTs DLT_802_11, DLT_PRISM_802_11, DLT_AIRONET_802_11 are desirable
>     in addition to DLT_EN10MB.

Is one of the 802.11 types a superset of the others? if so would it make
sense to use that exclusivly and leave the missing fields blank in the
other drivers?

I'm worried about things like ethereal only supporting some DLT_* types and
not others.

--

-- 
[http://pointless.net/]                                   [0x2ECA0975]