Re: Changing IRQ setting from console/userland
On Mon, Jan 05, 2009 at 03:03:47PM +0700, Insan Praja SW wrote: > Hi Misc@, > is there anything on man (8) how to set irq allocation for certain > devices like NICs? I tried apropos but I can't find userland application > on base to change this. > Thanks, In general allocating IRQs is a kernel thing and not something you want to tweak. What problem are you trying to solve? -Otto
Re: Changing IRQ setting from console/userland
On Mon, 05 Jan 2009 15:29:01 +0700, Otto Moerbeek wrote: On Mon, Jan 05, 2009 at 03:03:47PM +0700, Insan Praja SW wrote: Hi Misc@, is there anything on man (8) how to set irq allocation for certain devices like NICs? I tried apropos but I can't find userland application on base to change this. Thanks, In general allocating IRQs is a kernel thing and not something you want to tweak. What problem are you trying to solve? -Otto I always got a; ping: sendto: No buffer space available ping: wrote 202.abc.de.fgh 64 chars, ret=-1 which is on sk0 and I notice; ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01: irq 9 ppb1 at pci0 dev 28 function 4 "Intel 82801G PCIE" rev 0x01: irq 9 ppb2 at pci0 dev 28 function 5 "Intel 82801G PCIE" rev 0x01: irq 11 em0 at pci3 dev 0 function 0 "Intel PRO/1000MT (82573E)" rev 0x03: irq 9, address 00:15:17:25:0a:9d uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: irq 11 uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x01: irq 10 uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x01: irq 11 uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x01: irq 11 ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x01: irq 11 skc0 at pci4 dev 0 function 0 "D-Link Systems DGE-530T B1" rev 0x11, Yukon Lite (0x9): irq 11 ste0 at pci5 dev 4 function 0 "D-Link Systems 550TX" rev 0x15: irq 11, address 00:0d:88:68:53:84 ste1 at pci5 dev 5 function 0 "D-Link Systems 550TX" rev 0x15: irq 11, address 00:0d:88:68:53:85 ste2 at pci5 dev 6 function 0 "D-Link Systems 550TX" rev 0x15: irq 11, address 00:0d:88:68:53:86 ste3 at pci5 dev 7 function 0 "D-Link Systems 550TX" rev 0x15: irq 11, address 00:0d:88:68:53:87 radeondrm0 at vga1: irq 11 em1 at pci4 dev 5 function 0 "Intel PRO/1000MT (82541GI)" rev 0x05: irq 9, address 00:15:17:25:0a:9e pciide1: using irq 10 for native-PCI interrupt ichiic0 at pci0 dev 31 function 3 "Intel 82801GB SMBus" rev 0x01: irq 10 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pckbc0: using irq 1 for kbd slot fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01: irq 9 ppb1 at pci0 dev 28 function 4 "Intel 82801G PCIE" rev 0x01: irq 9 ppb2 at pci0 dev 28 function 5 "Intel 82801G PCIE" rev 0x01: irq 11 em0 at pci3 dev 0 function 0 "Intel PRO/1000MT (82573E)" rev 0x03: irq 9, address 00:15:17:25:0a:9d uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: irq 11 uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x01: irq 10 uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x01: irq 11 uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x01: irq 11 ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x01: irq 11 skc0 at pci4 dev 0 function 0 "D-Link Systems DGE-530T B1" rev 0x11, Yukon Lite (0x9): irq 11 ste0 at pci5 dev 4 function 0 "D-Link Systems 550TX" rev 0x15: irq 11, address 00:0d:88:68:53:84 ste1 at pci5 dev 5 function 0 "D-Link Systems 550TX" rev 0x15: irq 11, address 00:0d:88:68:53:85 ste2 at pci5 dev 6 function 0 "D-Link Systems 550TX" rev 0x15: irq 11, address 00:0d:88:68:53:86 ste3 at pci5 dev 7 function 0 "D-Link Systems 550TX" rev 0x15: irq 11, address 00:0d:88:68:53:87 radeondrm0 at vga1: irq 11 em1 at pci4 dev 5 function 0 "Intel PRO/1000MT (82541GI)" rev 0x05: irq 9, address 00:15:17:25:0a:9e pciide1: using irq 10 for native-PCI interrupt ichiic0 at pci0 dev 31 function 3 "Intel 82801GB SMBus" rev 0x01: irq 10 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pckbc0: using irq 1 for kbd slot fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 sk0 shares the same irq as uhci, which is nothing attached to them. Our plan is to disable/change setting for usb config from BIOS. But We really need to gather more info on this. Any hints and suggestion will be appreciated. Thanks, Insan -- insandotpraja(at)gmaildotcom
Re: Changing IRQ setting from console/userland
On Mon, Jan 5, 2009 at 12:48 AM, Insan Praja SW wrote: ... > I always got a; > ping: sendto: No buffer space available > ping: wrote 202.abc.de.fgh 64 chars, ret=-1 To quote a message on this list from Claudio Jeker: > I think I mentionened this already a few times but I'll do it again. > "sendto: No buffer space available" means an ENOBUF error was returned. > On modern systems ENOBUF is almost only generated by the interfaces and > their queues (e.g. if you enable a too restrictive altq limit). > So if you have altq enabled I would look at the pfctl -sq -vv output. A quick examination of the if_sk code shows that many of the ENOBUFS return cases also write something to the dmesg/syslog. Does dmesg show any messages after the 'root on' line? > sk0 shares the same irq as uhci, which is nothing attached to them. Our plan > is to disable/change setting for usb config from BIOS. But We really need to > gather more info on this. Any hints and suggestion will be appreciated. PCI, unlike ISA, works just fine with shared interrupts. Do you have a specific reason to suspect the source of the problem is the sharing of interrupts? Philip Guenther
Re: Changing IRQ setting from console/userland
On Mon, Jan 05, 2009 at 03:48:57PM +0700, Insan Praja SW wrote: > On Mon, 05 Jan 2009 15:29:01 +0700, Otto Moerbeek wrote: > >> On Mon, Jan 05, 2009 at 03:03:47PM +0700, Insan Praja SW wrote: >> >>> Hi Misc@, >>> is there anything on man (8) how to set irq allocation for certain >>> devices like NICs? I tried apropos but I can't find userland application >>> on base to change this. >>> Thanks, >> >> In general allocating IRQs is a kernel thing and not something you >> want to tweak. >> >> What problem are you trying to solve? >> >> -Otto >> > I cannot help you with this, others probably can. But the first thing you should do is send a COMPLETE dmesg. I can see skc(4) devices in your dmesg, but no sk(4). -Otto > I always got a; > ping: sendto: No buffer space available > ping: wrote 202.abc.de.fgh 64 chars, ret=-1 > > which is on sk0 and I notice; > ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01: irq 9 > ppb1 at pci0 dev 28 function 4 "Intel 82801G PCIE" rev 0x01: irq 9 > ppb2 at pci0 dev 28 function 5 "Intel 82801G PCIE" rev 0x01: irq 11 > em0 at pci3 dev 0 function 0 "Intel PRO/1000MT (82573E)" rev 0x03: irq 9, > address 00:15:17:25:0a:9d > uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: irq 11 > uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x01: irq 10 > uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x01: irq 11 > uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x01: irq 11 > ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x01: irq 11 > skc0 at pci4 dev 0 function 0 "D-Link Systems DGE-530T B1" rev 0x11, > Yukon Lite (0x9): irq 11 > ste0 at pci5 dev 4 function 0 "D-Link Systems 550TX" rev 0x15: irq 11, > address 00:0d:88:68:53:84 > ste1 at pci5 dev 5 function 0 "D-Link Systems 550TX" rev 0x15: irq 11, > address 00:0d:88:68:53:85 > ste2 at pci5 dev 6 function 0 "D-Link Systems 550TX" rev 0x15: irq 11, > address 00:0d:88:68:53:86 > ste3 at pci5 dev 7 function 0 "D-Link Systems 550TX" rev 0x15: irq 11, > address 00:0d:88:68:53:87 > radeondrm0 at vga1: irq 11 > em1 at pci4 dev 5 function 0 "Intel PRO/1000MT (82541GI)" rev 0x05: irq > 9, address 00:15:17:25:0a:9e > pciide1: using irq 10 for native-PCI interrupt > ichiic0 at pci0 dev 31 function 3 "Intel 82801GB SMBus" rev 0x01: irq 10 > com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo > pckbc0: using irq 1 for kbd slot > fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 > ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01: irq 9 > ppb1 at pci0 dev 28 function 4 "Intel 82801G PCIE" rev 0x01: irq 9 > ppb2 at pci0 dev 28 function 5 "Intel 82801G PCIE" rev 0x01: irq 11 > em0 at pci3 dev 0 function 0 "Intel PRO/1000MT (82573E)" rev 0x03: irq 9, > address 00:15:17:25:0a:9d > uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: irq 11 > uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x01: irq 10 > uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x01: irq 11 > uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x01: irq 11 > ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x01: irq 11 > skc0 at pci4 dev 0 function 0 "D-Link Systems DGE-530T B1" rev 0x11, > Yukon Lite (0x9): irq 11 > ste0 at pci5 dev 4 function 0 "D-Link Systems 550TX" rev 0x15: irq 11, > address 00:0d:88:68:53:84 > ste1 at pci5 dev 5 function 0 "D-Link Systems 550TX" rev 0x15: irq 11, > address 00:0d:88:68:53:85 > ste2 at pci5 dev 6 function 0 "D-Link Systems 550TX" rev 0x15: irq 11, > address 00:0d:88:68:53:86 > ste3 at pci5 dev 7 function 0 "D-Link Systems 550TX" rev 0x15: irq 11, > address 00:0d:88:68:53:87 > radeondrm0 at vga1: irq 11 > em1 at pci4 dev 5 function 0 "Intel PRO/1000MT (82541GI)" rev 0x05: irq > 9, address 00:15:17:25:0a:9e > pciide1: using irq 10 for native-PCI interrupt > ichiic0 at pci0 dev 31 function 3 "Intel 82801GB SMBus" rev 0x01: irq 10 > com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo > pckbc0: using irq 1 for kbd slot > fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 > > sk0 shares the same irq as uhci, which is nothing attached to them. Our > plan is to disable/change setting for usb config from BIOS. But We really > need to gather more info on this. Any hints and suggestion will be > appreciated. > Thanks, > > Insan > > -- > insandotpraja(at)gmaildotcom
Re: Changing IRQ setting from console/userland
On Mon, Jan 05, 2009 at 03:03:47PM +0700, Insan Praja SW wrote: > Hi Misc@, > is there anything on man (8) how to set irq allocation for certain devices > like NICs? I tried apropos but I can't find userland application on base no. but some bioses allow it. > to change this. > Thanks, > > > Insan, > -- > insandotpraja(at)gmaildotcom -- Alexander Yurchenko
Re: Changing IRQ setting from console/userland
On Mon, 05 Jan 2009 15:29:01 +0700, Otto Moerbeek wrote:
On Mon, Jan 05, 2009 at 03:03:47PM +0700, Insan Praja SW wrote:
Hi Misc@,
is there anything on man (8) how to set irq allocation for certain
devices like NICs? I tried apropos but I can't find userland application
on base to change this.
Thanks,
In general allocating IRQs is a kernel thing and not something you
want to tweak.
What problem are you trying to solve?
-Otto
The dmesg:
OpenBSD 4.4-current (GENERIC) #55: Thu Dec 25 00:00:31 WIT 2008
r...@greenservicerouter.mygreenlinks.net:/usr/src/sys/arch/i386/compile/GENERIC
RTC BIOS diagnostic error e
cpu0: Intel(R) Pentium(R) 4 CPU 3.00GHz ("GenuineIntel" 686-class) 3.01 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,S
SE3,MWAIT,DS-CPL,EST,TM2,CNXT-ID,CX16,xTPR
real mem = 2142744576 (2043MB)
avail mem = 2063761408 (1968MB)
RTC BIOS diagnostic error e
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 09/13/07, SMBIOS rev. 2.4 @
0x7fbe4000 (43 entries)
bios0: vendor Intel Corporation version
"S3000.86B.02.00.0051.091720081311" date 09/17/2008
bios0: Intel S3000AH
acpi0 at bios0: rev 0
acpi0: tables DSDT SLIC FACP APIC WDDT HPET MCFG ASF! SSDT SSDT SSDT SSDT
SSDT HEST BERT ERST EINJ
acpi0: wakeup devices SLPB(S4) P32_(S4) UAR1(S1) PEX4(S4) PEX5(S4)
UHC1(S1) UHC2(S1) UHC3(S1) UHC4(S1) EHCI(S1) AC9M(S4) AZAL(
S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 4 (P32_)
acpiprt2 at acpi0: bus 1 (PEX0)
acpiprt3 at acpi0: bus -1 (PEX1)
acpiprt4 at acpi0: bus -1 (PEX2)
acpiprt5 at acpi0: bus -1 (PEX3)
acpiprt6 at acpi0: bus 2 (PEX4)
acpiprt7 at acpi0: bus 3 (PEX5)
acpicpu0 at acpi0: FVS, 3000, 2400 MHz
acpibtn0 at acpi0: SLPB
bios0: ROM list: 0xc/0x9000 0xc9000/0x1000 0xca000/0x1000
cpu0 at mainbus0: (uniprocessor)
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel E7230 Host" rev 0x00
ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01: irq 9
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 4 "Intel 82801G PCIE" rev 0x01: irq 9
pci2 at ppb1 bus 2
ppb2 at pci0 dev 28 function 5 "Intel 82801G PCIE" rev 0x01: irq 11
pci3 at ppb2 bus 3
em0 at pci3 dev 0 function 0 "Intel PRO/1000MT (82573E)" rev 0x03: irq 9,
address 00:15:17:25:0a:9d
"Intel 82573E Serial" rev 0x03 at pci3 dev 0 function 3 not configured
"Intel 82573E KCS" rev 0x03 at pci3 dev 0 function 4 not configured
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x01: irq 11
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x01: irq 10
uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x01: irq 11
uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x01: irq 11
ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x01: irq 11
ehci0: timed out waiting for BIOS
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb3 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xe1
pci4 at ppb3 bus 4
skc0 at pci4 dev 0 function 0 "D-Link Systems DGE-530T B1" rev 0x11, Yukon
Lite (0x9): irq 11
sk0 at skc0 port A: address 00:1b:11:10:07:26
eephy0 at sk0 phy 0: 88E1011 Gigabit PHY, rev. 5
ppb4 at pci4 dev 1 function 0 "Intel S21152BB PCI-PCI" rev 0x00
pci5 at ppb4 bus 5
ste0 at pci5 dev 4 function 0 "D-Link Systems 550TX" rev 0x15: irq 11,
address 00:0d:88:68:53:84
ukphy0 at ste0 phy 1: Generic IEEE 802.3u media interface, rev. 0: OUI
0x0090c3, model 0x0004
ste1 at pci5 dev 5 function 0 "D-Link Systems 550TX" rev 0x15: irq 11,
address 00:0d:88:68:53:85
ukphy1 at ste1 phy 1: Generic IEEE 802.3u media interface, rev. 0: OUI
0x0090c3, model 0x0004
ste2 at pci5 dev 6 function 0 "D-Link Systems 550TX" rev 0x15: irq 11,
address 00:0d:88:68:53:86
ukphy2 at ste2 phy 1: Generic IEEE 802.3u media interface, rev. 0: OUI
0x0090c3, model 0x0004
ste3 at pci5 dev 7 function 0 "D-Link Systems 550TX" rev 0x15: irq 11,
address 00:0d:88:68:53:87
ukphy3 at ste3 phy 1: Generic IEEE 802.3u media interface, rev. 0: OUI
0x0090c3, model 0x0004
vga1 at pci4 dev 4 function 0 "ATI ES1000" rev 0x02
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
radeondrm0 at vga1: irq 11
drm0 at radeondrm0
em1 at pci4 dev 5 function 0 "Intel PRO/1000MT (82541GI)" rev 0x05: irq 9,
address 00:15:17:25:0a:9e
ichpcib0 at pci0 dev 31 function 0 "Intel 82801GB LPC" rev 0x01: PM
disabled
pciide0 at pci0 dev 31 function 1 "Intel 82801GB IDE" rev 0x01: DMA,
channel 0 configured to compatibility, channel 1 configur
ed to compatibility
pciide0: channel 0 disabled (no drives)
pciide0: channel 1 disabled (no drives)
pciide1 at pci0 dev 31 function 2 "Intel 82801GB SATA" rev 0x01: DMA,
channel 0 configured to native-PCI, channel 1 configured
to native-PCI
pciide1: using irq 10 for native-PCI interrupt
wd0 at
Re: Changing IRQ setting from console/userland
On Mon, 05 Jan 2009 23:53:01 +0700, Philip Guenther wrote: On Mon, Jan 5, 2009 at 12:48 AM, Insan Praja SW wrote: ... I always got a; ping: sendto: No buffer space available ping: wrote 202.abc.de.fgh 64 chars, ret=-1 To quote a message on this list from Claudio Jeker: I think I mentionened this already a few times but I'll do it again. "sendto: No buffer space available" means an ENOBUF error was returned. On modern systems ENOBUF is almost only generated by the interfaces and their queues (e.g. if you enable a too restrictive altq limit). So if you have altq enabled I would look at the pfctl -sq -vv output. I do have restrictive altq limit, using upperlimit, since this client should not be over 22Mbps. At first, I put it at child queue, now I move them to parent queue (interface). It began to show some noise reduction. A quick examination of the if_sk code shows that many of the ENOBUFS return cases also write something to the dmesg/syslog. Does dmesg show any messages after the 'root on' line? No, nothing on dmesg. sk0 shares the same irq as uhci, which is nothing attached to them. Our plan is to disable/change setting for usb config from BIOS. But We really need to gather more info on this. Any hints and suggestion will be appreciated. PCI, unlike ISA, works just fine with shared interrupts. Do you have a specific reason to suspect the source of the problem is the sharing of interrupts? Actually this suspicion came from an old thread on a milis, which I gather from google. AFAIK, sk devices don't have interrupt mitigation, unlike em devices. Philip Guenther Thanks, Insan -- insandotpraja(at)gmaildotcom
Re: Changing IRQ setting from console/userland
On 2009-01-06, Insan Praja SW wrote: > On Mon, 05 Jan 2009 23:53:01 +0700, Philip Guenther > wrote: > >> On Mon, Jan 5, 2009 at 12:48 AM, Insan Praja SW >> wrote: >> ... >>> I always got a; >>> ping: sendto: No buffer space available >>> ping: wrote 202.abc.de.fgh 64 chars, ret=-1 >> >> To quote a message on this list from Claudio Jeker: >>> I think I mentionened this already a few times but I'll do it again. >>> "sendto: No buffer space available" means an ENOBUF error was returned. >>> On modern systems ENOBUF is almost only generated by the interfaces and >>> their queues (e.g. if you enable a too restrictive altq limit). >>> So if you have altq enabled I would look at the pfctl -sq -vv output. >> > I do have restrictive altq limit, using upperlimit, since this client > should not be over 22Mbps. At first, I put it at child queue, now I move > them to parent queue (interface). It began to show some noise reduction. When the queue is full, you get this error. >> A quick examination of the if_sk code shows that many of the ENOBUFS >> return cases also write something to the dmesg/syslog. Does dmesg >> show any messages after the 'root on' line? >> > No, nothing on dmesg. >> >>> sk0 shares the same irq as uhci, which is nothing attached to them. Our >>> plan >>> is to disable/change setting for usb config from BIOS. But We really >>> need to >>> gather more info on this. Any hints and suggestion will be appreciated. >> >> PCI, unlike ISA, works just fine with shared interrupts. Do you have >> a specific reason to suspect the source of the problem is the sharing >> of interrupts? >> > Actually this suspicion came from an old thread on a milis, which I > gather from google. AFAIK, sk devices don't have interrupt mitigation, > unlike em devices. http://www.mail-archive.com/misc@openbsd.org/msg05854.html
Re: Changing IRQ setting from console/userland
On Tue, 06 Jan 2009 18:07:12 +0700, Stuart Henderson wrote: On 2009-01-06, Insan Praja SW wrote: On Mon, 05 Jan 2009 23:53:01 +0700, Philip Guenther wrote: On Mon, Jan 5, 2009 at 12:48 AM, Insan Praja SW wrote: ... I always got a; ping: sendto: No buffer space available ping: wrote 202.abc.de.fgh 64 chars, ret=-1 To quote a message on this list from Claudio Jeker: I think I mentionened this already a few times but I'll do it again. "sendto: No buffer space available" means an ENOBUF error was returned. On modern systems ENOBUF is almost only generated by the interfaces and their queues (e.g. if you enable a too restrictive altq limit). So if you have altq enabled I would look at the pfctl -sq -vv output. I do have restrictive altq limit, using upperlimit, since this client should not be over 22Mbps. At first, I put it at child queue, now I move them to parent queue (interface). It began to show some noise reduction. When the queue is full, you get this error. On the interface SNMP statistic, it's still below 22Mbps. Weird. Maybe because it's burstyness? A quick examination of the if_sk code shows that many of the ENOBUFS return cases also write something to the dmesg/syslog. Does dmesg show any messages after the 'root on' line? No, nothing on dmesg. sk0 shares the same irq as uhci, which is nothing attached to them. Our plan is to disable/change setting for usb config from BIOS. But We really need to gather more info on this. Any hints and suggestion will be appreciated. PCI, unlike ISA, works just fine with shared interrupts. Do you have a specific reason to suspect the source of the problem is the sharing of interrupts? Actually this suspicion came from an old thread on a milis, which I gather from google. AFAIK, sk devices don't have interrupt mitigation, unlike em devices. http://www.mail-archive.com/misc@openbsd.org/msg05854.html I got to admit, I was wrong about these cards capabilities. I'm going to install INTEL EXPI9402PT, dual ports PCI-express NIC with Intel. 82572GI Gigabit Controller just to see where the problem is. Anyone knows if this one support interrupt mitigation? Best Regards, Insan -- insandotpraja(at)gmaildotcom
