On Mon, 2008-11-17 at 02:21 -0800, Kevin Diggs wrote:
> Benjamin Herrenschmidt wrote:
> >
> >
> > That's definitely strange. I would expect the kernel to be able to get
> > interrupts fast enough to service a 1200 bauds serial port. Maybe
> > there's something else wrong, or an other driver caus
Benjamin Herrenschmidt wrote:
That's definitely strange. I would expect the kernel to be able to get
interrupts fast enough to service a 1200 bauds serial port. Maybe
there's something else wrong, or an other driver causing undue interrupt
latencies
As far as I can see the system is NOT
> > Well, the main thing is that when using DMA, it doesn't need to wait for
> > the kernel to come fetch the bytes, and thus the only latency that
> > matters if the DMA list is appropriately provisioned is the bus latency,
> > which is much less likely to be an issue even with a small buffer.
>
Benjamin Herrenschmidt wrote:
On Thu, 2008-11-13 at 14:29 -0800, Kevin Diggs wrote:
Benjamin Herrenschmidt wrote:
On Thu, 2008-11-13 at 03:38 -0800, Kevin Diggs wrote:
12,206 PowerMac Zilog interrupts
Interrupt load is higher without the DMA support.
Is it possible that this hardware wa
On Thu, 2008-11-13 at 14:29 -0800, Kevin Diggs wrote:
> Benjamin Herrenschmidt wrote:
> > On Thu, 2008-11-13 at 03:38 -0800, Kevin Diggs wrote:
> >
> >
> >>12,206 PowerMac Zilog interrupts
> >>
> >>Interrupt load is higher without the DMA support.
> >>
> >>Is it possible that this hardware was no
Benjamin Herrenschmidt wrote:
On Thu, 2008-11-13 at 03:38 -0800, Kevin Diggs wrote:
12,206 PowerMac Zilog interrupts
Interrupt load is higher without the DMA support.
Is it possible that this hardware was not meant to be used without the
DMA (i.e. it does not work quite right?)?
Well, the
On Thu, 2008-11-13 at 03:38 -0800, Kevin Diggs wrote:
> 12,206 PowerMac Zilog interrupts
>
> Interrupt load is higher without the DMA support.
>
> Is it possible that this hardware was not meant to be used without the
> DMA (i.e. it does not work quite right?)?
Well, the HW Rx buffer is only 3
Benjamin Herrenschmidt wrote:
On Fri, 2008-11-07 at 13:38 -0800, Kevin Diggs wrote:
to connect an 8600 to a laptop via ppp the link will lock up in short
order from "payloaded" pings. Any advice on how to figure out where it
is locking up? This command works fine to connect two x86 laptops. At
On Sat, 2008-11-08 at 16:52 +1100, Paul Mackerras wrote:
> Kevin Diggs writes:
>
> > pppd ttyS0 1200 satellites: netmask 255.255.255.0 lock crtscts mru 1064
> > noauth debug kdebug 7
> > logfile /tmp/pppd.log local
> >
> > to connect an 8600 to a laptop via ppp the link will lock up in short
>
Kevin Diggs writes:
> pppd ttyS0 1200 satellites: netmask 255.255.255.0 lock crtscts mru 1064
> noauth debug kdebug 7
> logfile /tmp/pppd.log local
>
> to connect an 8600 to a laptop via ppp the link will lock up in short
> order from "payloaded" pings. Any advice on how to figure out where it
On Fri, 2008-11-07 at 13:38 -0800, Kevin Diggs wrote:
> to connect an 8600 to a laptop via ppp the link will lock up in short
> order from "payloaded" pings. Any advice on how to figure out where it
> is locking up? This command works fine to connect two x86 laptops. At
> 1200 it does take a while
Hi,
If I use a command similar to:
pppd ttyS0 1200 satellites: netmask 255.255.255.0 lock crtscts mru 1064 noauth debug kdebug 7
logfile /tmp/pppd.log local
to connect an 8600 to a laptop via ppp the link will lock up in short
order from "payloaded" pings. Any advice on how to figure
12 matches
Mail list logo