On 2009-01-06, Insan Praja SW <insan.pr...@gmail.com> wrote: > On Mon, 05 Jan 2009 23:53:01 +0700, Philip Guenther <guent...@gmail.com> > wrote: > >> On Mon, Jan 5, 2009 at 12:48 AM, Insan Praja SW <insan.pr...@gmail.com> >> 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
