On Sun, 11 Aug 2002, Maksim Yevmenkin wrote:

> On Fri, 9 Aug 2002, Maksim Yevmenkin wrote:
> > > OS: FreeBSD-current DP1 (dmesg attached)
> > > Laptop: Toshiba Tecra 8100 (docked)
> > > Hardware: 3Com Bluetooth USB dongle, 3Com Bluetooth PC-CARD
> > >           Xircom CBT PC-CARD (with 16550A UART)
> > >
> > > First of all, irq 11 gets shared between PC-CARD controller,
> > > USB controller, NIC in docking station (see dmesg). Everything
> > This configuration should be expected to work poorly at best.
> hmmm... i have a couple of latops here at home, one made by
> Toshiba and another by IBM and they both have similar configuration.
> may be such configuration is normal for laptops?

Unfortunately it seems to be fairly normal.  Warner knows a lot more about
this than me (see his reply).  I don't even have a laptop.

I expect this problem will be "fixed" by doing more polling for USB devices
in a more automatic way.  I hoped that more irqs would be standard by now,
but instead they seem to be standard on xaly on big SMP systems that don't
need them so much.  It's systems with lots of interactive and/or real-time
deives that need them more.

> > > The Xircom card just does not work :( I' getting a lot of
> > > "silo overflow" messages no matter what i try. I checked
> > > list archives and source - not much look. Is "sio" driver
> > > totally hopeless?
> >
> > No, but the 3Com driver apparently is.  The sio driver wants to have
> > fast interrupts.  It can't have them with the irq is shared, so its
> > worst-case interrupt latency for a single serial port is increased
> > from about 50 usec to many msec, depending other interrupt activity
> > in the system (not limited to that for the shared irq except in some
> > configurations).  Silo overflows occur at 115200 bps when the latency
> > is more than about 1.5 msec.
> perhaps, i said it wrong. I only plug *one* PC-CARD at a time, so
> it only 3com *or* Xircom. So irq11 gets shared between USB, NIC in
> docking station, PC-CARD controller and Xircom card.

That should help a bit.  There is still the software problem that the
irq wiring for attached devices doesn't change when some devices using
the interrupt are detached, so the sio interrupt probably remains
shared and non-fast so sio interrupt handling is often delayed by other
interrupt activity (if any).  Hmmm, there is always some interrupt
activity for clocks.  Perhaps the largest source of latency is that
timeouts have (or not so temporarily borrow) too high a priority in

> BTW, i see "silo overflow" messages when i run ppp via null-modem
> cable. in this configuration i'm using serial port 0 which is on
> board and hase irq 4 with fast interrupts.

What else is active when you get these?

> > This points to  bug(s) in the 3Com driver.  Perhaps its interrupt
> > handler just runs for too long to determine that irq11's for the
> > serial device are not for it.  Running in polled mode decreases
> yes, and that is what i was thinking too. but now i think it is
> not only 3com driver's fault. The driver just reads one port and
> check one bit, if it not set then interrupt is not for it.

Yes, this shows that it is not primarily the 3Com driver's fault.

> > > I just can't believe that
> > > FreeBSD on my Pentium-III/600 can't handle lousy 500-700
> > > interrupts a second from PC-CARD. Can anyone point me
> > > into right direction, because i'm obviously doing something
> > > wrong here.
> >
> > FreeBSD on a 486/33 can handle about 40000 serial interrupts per second
> > to do one character of i/o per interrupt).  Pessimizations in -current
> > have only degraded this by a small factor (2?), provided the driver
> > uses fast interrupts.  Lose another small factor (2?) for normal interrupts
> > (using normal interrupts only loses a large factor for latency).
> if my calculations are correct -current should handle about 10,000
> interrupt/sec from sio, right? i'm sorry, but it is not what i see
> here.

That's 10000 on a 486/33 :-).


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to