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
> 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
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
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
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
>
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.
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
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
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.
Christoph
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 programming
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 give
double ups
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
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
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 can't
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 problems
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;
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
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:
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:[c01269f9]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010086
David Ford wrote:
EIP; c01269f9 proc_getdata+4d/154 =
Trace; c01b1021 read_eeprom+131/1a8
Trace; c01b1c43 rtl8139_tx_timeout+143/148
Trace; c01b2643 rtl8139_interrupt+5f/170
Trace; c0137fc0 __emul_lookup_dentry+a4/fc
Trace; c0138871 open_namei+4d1/560
Trace; c0167ccb
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 proc_getdata+4d/154 =
Trace; c01b1021 read_eeprom+131/1a8
Trace; c01b1c43 rtl8139_tx_timeout+143/148
Trace; c01b2643 rtl8139_interrupt+5f/170
22 matches
Mail list logo
