sk driver

2006-09-05 Thread Brian
I thought the issue with the watchdog timing out was fixed.  I was seeding a
torrent file this morning, so when I came home and turned it off, I received
these errors:

sk0: watchdog timeout
sk0: cannot stop transfer of Tx descriptors

I am running a kernel compiled as of last Saturday.

Here's my dmesg:

OpenBSD 4.0 (GENERIC) #0: Sat Sep  2 14:06:26 MDT 2006
[EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 1073278976 (1048124K)
avail mem = 907919360 (886640K)
using 22937 buffers containing 107536384 bytes (105016K) of memory
mainbus0 (root)
bios0 at mainbus0: SMBIOS rev. 2.2 @ 0xf (39 entries)
cpu0 at mainbus0: (uniprocessor)
cpu0: AMD Athlon(tm) 64 Processor 3000+, 1808.55 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line
16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
pci0 at mainbus0 bus 0: configuration mode 1
NVIDIA nForce4 DDR rev 0xa3 at pci0 dev 0 function 0 not configured
pcib0 at pci0 dev 1 function 0 NVIDIA nForce4 ISA rev 0xa3
nviic0 at pci0 dev 1 function 1 NVIDIA nForce4 SMBus rev 0xa2
iic0 at nviic0
adt0 at iic0 addr 0x2e: sch5017 rev 0x89
iic1 at nviic0
adt1 at iic1 addr 0x2e: sch5017 rev 0x89
ohci0 at pci0 dev 2 function 0 NVIDIA nForce4 USB rev 0xa2: irq 5, version
1.0, legacy support
usb0 at ohci0: USB revision 1.0
uhub0 at usb0
uhub0: NVIDIA OHCI root hub, rev 1.00/1.00, addr 1
uhub0: 10 ports with 10 removable, self powered
ehci0 at pci0 dev 2 function 1 NVIDIA nForce4 USB rev 0xa3: irq 10
usb1 at ehci0: USB revision 2.0
uhub1 at usb1
uhub1: NVIDIA EHCI root hub, rev 2.00/1.00, addr 1
uhub1: 10 ports with 10 removable, self powered
auich0 at pci0 dev 4 function 0 NVIDIA nForce4 AC97 rev 0xa2: irq 5, nForce4
AC97
ac97: codec id 0x414c4760 (Avance Logic ALC655 rev 0)
audio0 at auich0
pciide0 at pci0 dev 6 function 0 NVIDIA nForce4 IDE rev 0xa2: DMA, channel 0
configured to compatibility, channel 1 configured to compatibility
pciide0: channel 0 disabled (no drives)
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: HL-DT-ST, DVDRAM GSA-4163B, A103 SCSI0 5/cdrom
removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
pciide1 at pci0 dev 7 function 0 NVIDIA nForce4 SATA rev 0xa3: DMA
pciide1: using irq 10 for native-PCI interrupt
wd0 at pciide1 channel 0 drive 0: WDC WD360GD-00FLA2
wd0: 16-sector PIO, LBA48, 35304MB, 72303840 sectors
wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 5
wd1 at pciide1 channel 1 drive 0: WDC WD3200KS-00PFB0
wd1: 16-sector PIO, LBA48, 305245MB, 625142448 sectors
wd1(pciide1:1:0): using PIO mode 4, Ultra-DMA mode 5
pciide2 at pci0 dev 8 function 0 NVIDIA nForce4 SATA rev 0xa3: DMA
pciide2: using irq 11 for native-PCI interrupt
ppb0 at pci0 dev 9 function 0 NVIDIA nForce4 PCI-PCI rev 0xa2
pci1 at ppb0 bus 1
ATI Rage XL rev 0x27 at pci1 dev 5 function 0 not configured
VIA VT6306 FireWire rev 0x80 at pci1 dev 6 function 0 not configured
skc0 at pci1 dev 10 function 0 D-Link Systems DGE-530T A1 rev 0x11, Marvell
Yukon Lite (0x9): irq 5
sk0 at skc0 port A, address 00:15:e9:2e:28:e6
eephy0 at sk0 phy 0: Marvell 88E1011 Gigabit PHY, rev. 5
nfe0 at pci0 dev 10 function 0 NVIDIA CK804 LAN rev 0xa3: irq 11, address
00:e0:81:56:8f:67
eephy1 at nfe0 phy 1: Marvell 88E Gigabit PHY, rev. 1
ppb1 at pci0 dev 11 function 0 NVIDIA nForce4 PCIE rev 0xa3
pci2 at ppb1 bus 2
ppb2 at pci0 dev 12 function 0 NVIDIA nForce4 PCIE rev 0xa3
pci3 at ppb2 bus 3
ppb3 at pci0 dev 13 function 0 NVIDIA nForce4 PCIE rev 0xa3
pci4 at ppb3 bus 4
bge0 at pci4 dev 0 function 0 Broadcom BCM5721 rev 0x11, BCM5750 B1 (0x4101):
irq 11, address 00:e0:81:56:8f:66
brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0
ppb4 at pci0 dev 14 function 0 NVIDIA nForce4 PCIE rev 0xa3
pci5 at ppb4 bus 5
vga1 at pci5 dev 0 function 0 NVIDIA GeForce 6600 GT rev 0xa2
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pchb0 at pci0 dev 24 function 0 AMD AMD64 HyperTransport rev 0x00
pchb1 at pci0 dev 24 function 1 AMD AMD64 Address Map rev 0x00
pchb2 at pci0 dev 24 function 2 AMD AMD64 DRAM Cfg rev 0x00
pchb3 at pci0 dev 24 function 3 AMD AMD64 Misc Cfg rev 0x00
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pmsi0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pmsi0 mux 0
pcppi0 at isa0 port 0x61
midi0 at pcppi0: PC speaker
spkr0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
umass0 at 

Re: sk driver

2006-09-05 Thread Sam Chill

On 9/5/06, Brian [EMAIL PROTECTED] wrote:

I thought the issue with the watchdog timing out was fixed.  I was seeding a
torrent file this morning, so when I came home and turned it off, I received
these errors:

sk0: watchdog timeout
sk0: cannot stop transfer of Tx descriptors

I am running a kernel compiled as of last Saturday.

Here's my dmesg:

OpenBSD 4.0 (GENERIC) #0: Sat Sep  2 14:06:26 MDT 2006
[EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC

snip

skc0 at pci1 dev 10 function 0 D-Link Systems DGE-530T A1 rev 0x11, Marvell
Yukon Lite (0x9): irq 5
sk0 at skc0 port A, address 00:15:e9:2e:28:e6

snip
I own this exact card as well and I'm still having this problem with
-current snapshots too.
-Sam



sk driver: watchdog timeout fix?

2006-06-07 Thread Elias Malago
Hi,

I am very new to OpenBSD, so please forgive me if I say something
stupid here.

I have also come across this very same problem recently. And I 
noticed there is a very recent commit in the FreeBSD CVS that
is supposed to help on this matter.

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/sk/if_sk.c?rev=1.125content-type=text/x-cvsweb-markup

I noticed that the OpenBSD driver is somehow derived from the FreeBSD
one, I was wondering if this fix could be imported into the OpenBSD
source so that we could check if the problem occurs less often.

Thanks in advance.

Regards,

Elias



SysKonnect sk driver high CPU interrupt rate after 3.8 upgrade

2006-02-20 Thread Paul B. Henson
We have been running a pair of firewalls under 3.3 for quite some time, and
just upgraded them to 3.8. Before the upgrade, they would typically run at
about 35-40% interrupts. After the upgrade, they are running at 90-95%
interrupt utilization.

It looks like a lot of changes have been made to the sk driver over the
past couple of years, apparently for the worse for our particular cards :(.

The cards in particular are:

skc0 at pci6 dev 1 function 0 Schneider  Koch 984x GE rev 0x12: irq 11
skc0: SysKonnect GEnesis (0x0)
sk0 at skc0 port A: address 00:00:5a:9a:7f:d4
xmphy0 at sk0 phy 0: XaQti Corp. XMAC II Gigabit PHY, rev. 2


Any suggestions on reducing the interrupt load to the previous levels?

Thanks...


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  [EMAIL PROTECTED]
California State Polytechnic University  |  Pomona CA 91768