In article <002e01c0eead$03c6d890$[EMAIL PROTECTED]> you wrote:
>> 2.4.5-ac9
>> o Fix xircom_cb problems with some cisco kit (Ion Badulescu)
> One other note, the version in 2.4.4-ac11 is listed as 1.33 while the
> version in 2.4.5-ac9 is 1.11, why did we go backwards? Were there
> significant
On Wed, 6 Jun 2001 13:20:41 -0400, Tom Sightler <[EMAIL PROTECTED]> wrote:
>> 2.4.5-ac9
>
>> o Fix xircom_cb problems with some cisco kit (Ion Badulescu)
>
> I'm not sure what this is supposed to fix, but it makes my Xircom
> RBEM56G-100 almost useless on my network at the office. Actually, I c
> 2.4.5-ac9
> o Fix xircom_cb problems with some cisco kit (Ion Badulescu)
I'm not sure what this is supposed to fix, but it makes my Xircom
RBEM56G-100 almost useless on my network at the office. Actually, I can't
quite blame just this patch, it only makes the problem worse, the driver
from 2.
I've just tried the orinoco_cs driver with my "Orinoco Gold" pcmcia card in
hopes that I could use this instead of having to rebuild the pcmcia-cs
package everytime I try a new kernel... I am seeing the following messages:
NETDEV WATCHDOG: eth1: transmit timed out
eth1: Tx timeout! Resetting car
On Wed, Jun 06, 2001 at 01:41:31PM +0200, Thomas Sailer wrote:
> Christoph Hellwig schrieb:
> >
> > In article <[EMAIL PROTECTED]> you wrote:
> > > 2.4.5-ac9
> >
> > > o Add es1371 sound driver locking (Frank Davis)
> >
> > It's buggy. The locking in ->read and ->write will
Christoph Hellwig schrieb:
>
> In article <[EMAIL PROTECTED]> you wrote:
> > 2.4.5-ac9
>
> > o Add es1371 sound driver locking (Frank Davis)
>
> It's buggy. The locking in ->read and ->write will give
> double ups when a signal is pending and remove a not added waitq
> when
In article <[EMAIL PROTECTED]> you wrote:
> 2.4.5-ac9
> o Add es1371 sound driver locking (Frank Davis)
It's buggy. The locking in ->read and ->write will give
double ups when a signal is pending and remove a not added waitq
when programming the dmabuf fails.
Christ
Alan Cox schrieb:
> 2.4.5-ac9
> o Add es1371 sound driver locking (Frank Davis)
Looks bogus. Independent processes can open the same device
once for reading and once for writing, now you are serializing
needlessly these processes. Please revert.
Tom
-
To unsubscribe from t
Quite positive it's the right map file. I used -m and specified the
exact file.
David
Jeff Garzik wrote:
>David Ford wrote:
>
>> >>EIP; c01269f9<=
>>Trace; c01b1021
>>Trace; c01b1c43
>>Trace; c01b2643
>>Trace; c0137fc0 <__emul_lookup_dentry+a4/fc>
>>Trace; c0138871
>>Trace; c0167c
David Ford wrote:
> >>EIP; c01269f9<=
> Trace; c01b1021
> Trace; c01b1c43
> Trace; c01b2643
> Trace; c0137fc0 <__emul_lookup_dentry+a4/fc>
> Trace; c0138871
> Trace; c0167ccb
> Trace; c012e389
> Trace; c012e2c2
This trace looks corrupted to me... are you sure that System.map for t
2.4.5-ac8 has a brokenness about it.
sshd stalled in [down] with the following, subsequent sshd attempts
which needed a tty resulted in D state the same as the first:
invalid operand:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010086
eax: 001
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
Intermediate diffs are available from
http://www.bzimage.org
In terms of going through the code audit almost all the sound drivers still
need fixing to lock against format changes during a r
12 matches
Mail list logo
