After upgrading to xfree 4.1.0, after switching back to the console after
starting X, suspending, and resuming, the text-mode terminals are corrupt
(but look like they're in text mode). There were some messages in the
XFree lists about X no longer restoring previous graphics state (since it
has
Presumably from the ac merge, console_conditional_schedule made it's way
into pre1 fbcon.c, but neither the prototype from console.h nor the
function from printk.c came with it. (perhaps this requires merging the
console lock removal too?)
justin
-
To unsubscribe from this list: send the line
Presumably from the ac merge, console_conditional_schedule made it's way
into pre1 fbcon.c, but neither the prototype from console.h nor the
function from printk.c came with it. (perhaps this requires merging the
console lock removal too?)
justin
-
To unsubscribe from this list: send the line
After upgrading to xfree 4.1.0, after switching back to the console after
starting X, suspending, and resuming, the text-mode terminals are corrupt
(but look like they're in text mode). There were some messages in the
XFree lists about X no longer restoring previous graphics state (since it
has
With apic enabled on this board, some normal amount of disk access
(including building a kernel) is successful. However, irqs are messed up.
The eepro100 module for the onboard 82559 nic loads, but prints this after
the revision history: PCI: No IRQ known for interrupt pin A of device
00:07.0.
On Sun, 1 Jul 2001, Marius Nita wrote:
> _I_ think it's childish to claim the above. You _may_ have a choice, yes, but
> is that choice equal or fair? Microsoft has infected both the user area as
Problem: I don't like company policy
Solution: Deal or get another job
Why should I have to spend
On Mon, 2 Jul 2001, Chris Wedgwood wrote:
> On Sun, Jul 01, 2001 at 01:50:00PM +0100, Alan Cox wrote:
>
> > I'm not a file sustem hacker, nor since I work for one vendor the
> > appropriate owner for larg chunks of code in some people's eyes. I
> > suspect the FSF is a much much better asignee
On Sun, 1 Jul 2001, Marius Nita wrote:
_I_ think it's childish to claim the above. You _may_ have a choice, yes, but
is that choice equal or fair? Microsoft has infected both the user area as
Problem: I don't like company policy
Solution: Deal or get another job
whine
Why should I have to
With apic enabled on this board, some normal amount of disk access
(including building a kernel) is successful. However, irqs are messed up.
The eepro100 module for the onboard 82559 nic loads, but prints this after
the revision history: PCI: No IRQ known for interrupt pin A of device
00:07.0.
On Mon, 2 Jul 2001, Chris Wedgwood wrote:
On Sun, Jul 01, 2001 at 01:50:00PM +0100, Alan Cox wrote:
I'm not a file sustem hacker, nor since I work for one vendor the
appropriate owner for larg chunks of code in some people's eyes. I
suspect the FSF is a much much better asignee for the
prototypes weren't updated.
--- linux/drivers/sound/cs46xx.c.orig Sat Jun 30 20:16:06 2001
+++ linux/drivers/sound/cs46xx.cSat Jun 30 20:26:57 2001
@@ -383,8 +383,8 @@
static int cs46xx_powerup(struct cs_card *card, unsigned int type);
static int cs461x_powerdown(struct cs_card
prototypes weren't updated.
--- linux/drivers/sound/cs46xx.c.orig Sat Jun 30 20:16:06 2001
+++ linux/drivers/sound/cs46xx.cSat Jun 30 20:26:57 2001
@@ -383,8 +383,8 @@
static int cs46xx_powerup(struct cs_card *card, unsigned int type);
static int cs461x_powerdown(struct cs_card
still hangs with ac21. mem trace attached.
recap: after boot, i log into vc/1 through vc/3 as regular users, in 1 I
do find / -name foo, in 2 I run basically ptr=malloc(192*1024*1024);
memset(ptr, 0, 192*1024*1024; while(1) sleep(1);
disk activity continues a while (shouldn't be much if any
still hangs with ac21. mem trace attached.
recap: after boot, i log into vc/1 through vc/3 as regular users, in 1 I
do find / -name foo, in 2 I run basically ptr=malloc(192*1024*1024);
memset(ptr, 0, 192*1024*1024; while(1) sleep(1);
disk activity continues a while (shouldn't be much if any
On Thu, 28 Jun 2001, Ralf Baechle wrote:
> Some versions of the 3c59x driver emit a NUL character on bootup which makes
> klogd suck CPU. This is fixed in 2.4.5, dunno about 2.4.4.
sysklogd 1.4.1 changelog lists a no busyloop fix.
justin
-
To unsubscribe from this list: send the line
On Thu, 28 Jun 2001, Ralf Baechle wrote:
Some versions of the 3c59x driver emit a NUL character on bootup which makes
klogd suck CPU. This is fixed in 2.4.5, dunno about 2.4.4.
sysklogd 1.4.1 changelog lists a no busyloop fix.
justin
-
To unsubscribe from this list: send the line
On Thu, 21 Jun 2001, Jason McMullan wrote:
> One we know how we would 'train' our little VM critter, we
> will know how to measure its performance. Once we have measures, we
> can have good benchmarks. Once we have good benchmarks - we can pick
> a good VM alg.
>
> Or heck, let's
On Wed, 20 Jun 2001, Justin Guyett wrote:
> the offending process is memeat (allocates 192*1024*1024 bytes, then
> memsets it to 0, then sleeps forever, though apparently it never gets to
> that part). It has to be in memset(ptr, 0, 192*1024*1024).
> ksymoops from sysrq-m attached
On Wed, 20 Jun 2001, Justin Guyett wrote:
the offending process is memeat (allocates 192*1024*1024 bytes, then
memsets it to 0, then sleeps forever, though apparently it never gets to
that part). It has to be in memset(ptr, 0, 192*1024*1024).
ksymoops from sysrq-m attached,
hmm, well
On Thu, 21 Jun 2001, Jason McMullan wrote:
One we know how we would 'train' our little VM critter, we
will know how to measure its performance. Once we have measures, we
can have good benchmarks. Once we have good benchmarks - we can pick
a good VM alg.
Or heck, let's just make
On Wed, 20 Jun 2001, Marcelo Tosatti wrote:
> > happened again (vt1 and 2 echo but shells are unresponsive, vt3+ don't
> > echo) only active process was the program allocating 192mb and writing to
> > it, no find this time.
>
> Can you get the backtrace of this process?
the offending process is
On Wed, 20 Jun 2001, Justin Guyett wrote:
> I got it to freeze in console (two generic find / -type f / type d), one
> process allocating and writing 0 to 192mb
>
> machine responds to pings, switching VTs works
>
> (256 physical, 512 swap)
happened again (vt1 and
I got it to freeze in console (two generic find / -type f / type d), one
process allocating and writing 0 to 192mb
machine responds to pings, switching VTs works
(256 physical, 512 swap)
Mem-info
Free pages: 1524kB (0kB High)
( Active: 39586, inactive_dirty: 18590, inactive_clean: 0, free: 381
I got it to freeze in console (two generic find / -type f / type d), one
process allocating and writing 0 to 192mb
machine responds to pings, switching VTs works
(256 physical, 512 swap)
Mem-info
Free pages: 1524kB (0kB High)
( Active: 39586, inactive_dirty: 18590, inactive_clean: 0, free: 381
On Wed, 20 Jun 2001, Justin Guyett wrote:
I got it to freeze in console (two generic find / -type f / type d), one
process allocating and writing 0 to 192mb
machine responds to pings, switching VTs works
(256 physical, 512 swap)
happened again (vt1 and 2 echo but shells are unresponsive
On Wed, 20 Jun 2001, Marcelo Tosatti wrote:
happened again (vt1 and 2 echo but shells are unresponsive, vt3+ don't
echo) only active process was the program allocating 192mb and writing to
it, no find this time.
Can you get the backtrace of this process?
the offending process is memeat
On Mon, 18 Jun 2001, Shawn Starr wrote:
> 1) It broke apparently with gcc 2.95.3 when patching from 2.4.6-pre2 ->
> 2.4.6pre3
>
> 2) I tried building it with gcc 3.00 and had same result.
hmm, how ironic, i just had 2.4.5ac15 lock up when untarring gcc 3.0 on a
reiserfs partition (/)
This
On Mon, 18 Jun 2001, Shawn Starr wrote:
1) It broke apparently with gcc 2.95.3 when patching from 2.4.6-pre2 -
2.4.6pre3
2) I tried building it with gcc 3.00 and had same result.
hmm, how ironic, i just had 2.4.5ac15 lock up when untarring gcc 3.0 on a
reiserfs partition (/)
This after
This is a pretty minor nitpick...
hardware: ibm thinkpad t21 using the apm driver
With 2.4.5-ac13, unplugging from AC, reconnecting to AC no longer causes
sound to be scratchy/garbled, but if something already has /dev/sound/dsp
open and AC state changes, the sound is garbled until the program
I remember seeing something about how some via ide chipsets (686b I think)
and [some?] ide promise controllers had problems with data corruption on
the IBM dtla-series udma drives, and that IBM stated the problem was with
the controllers. Is there a chance a problem like that could be screwing
I remember seeing something about how some via ide chipsets (686b I think)
and [some?] ide promise controllers had problems with data corruption on
the IBM dtla-series udma drives, and that IBM stated the problem was with
the controllers. Is there a chance a problem like that could be screwing
This is a pretty minor nitpick...
hardware: ibm thinkpad t21 using the apm driver
With 2.4.5-ac13, unplugging from AC, reconnecting to AC no longer causes
sound to be scratchy/garbled, but if something already has /dev/sound/dsp
open and AC state changes, the sound is garbled until the program
On Wed, 13 Jun 2001, Daniel wrote:
> math-emu
> If support for i386 and i486 is going away, then so should math emulation.
> Every intel processor since the 486DX has an FPU unit built in. In fact
> shouldn't FPU support be a userspace responsibility anyway?
hmm... what about processors like
On Wed, 13 Jun 2001, Daniel wrote:
math-emu
If support for i386 and i486 is going away, then so should math emulation.
Every intel processor since the 486DX has an FPU unit built in. In fact
shouldn't FPU support be a userspace responsibility anyway?
hmm... what about processors like cris?
34 matches
Mail list logo
