[PATCH] avoid negative (and full-width) shifts in radix-tree.c, take 4

2007-08-29 Thread Peter Lund
From: Peter Lund <[EMAIL PROTECTED]> Negative shifts are not allowed in C (the result is undefined). Same thing with full-width shifts. It works on most platforms but not on the VAX with gcc 4.0.1 (it results in an "operand reserved" fault). Applies to Linux 2.6.22. Signed-of

[PATCH] avoid negative (and full-width) shifts in radix-tree.c, take 3

2007-08-29 Thread Peter Lund
From: Peter Lund <[EMAIL PROTECTED]> Negative shifts are not allowed in C (the result is undefined). Same thing with full-width shifts. It works on most platforms but not on the VAX with gcc 4.0.1 (it results in an "operand reserved" fault). Applies to Linux 2.6.22. Signed-of

[PATCH] avoid negative shifts in radix-tree.c, take 2

2007-08-29 Thread Peter Lund
From: Peter Lund <[EMAIL PROTECTED]> Negative shifts are not allowed in C (the result is undefined). It works on most platforms but not on the VAX with gcc 4.0.1 (it results in an "operand reserved" fault). Applies to Linux 2.6.22. Signed-off-by: Peter Lund <[EMAIL PROTECTE

Re: esound (esd), 2.4.[12] chopped up sound -- solved

2001-03-20 Thread Peter Lund
Pozsar Balazs wrote: > Are you sure that the problem isn't at the mp3->raw conversino point? In > mandrake for example, mpg123 is badly compiled, and plays nicely on 2.2, > but awfully on 2.4. Positive. Anyway, the problem is solved now...I just want to investigate it a little bit further becau

esound (esd), 2.4.[12] chopped up sound

2001-03-19 Thread Peter Lund
Hi On my home machine playing sound through esd has worked beautifully on various kernels from 2.2.5 and up to 2.2.18. On 2.4.1 and 2.4.2 it stinks. It sounds like there are small pauses or repetitions in the sound, as if esd doesn't get the data quickly enough from the client or something.

Re: [PATCH] eepro100.c, kernel 2.4.1

2001-02-09 Thread Peter Lund
Alan Cox, Thu Feb 08 2001 - 02:42:52 EST: > > It's the printk that gets it wrong, although that's harmless. > > Intel's documentation states that the bug does NOT exist if the > > bits 0 and 1 in eeprom[3] are 1. Thus, the workaround is correct, > > the printk is wrong. > > So why does it fi