On Sun, Jun 10, 2001 at 06:44:56PM -0700, Lucca wrote:
> Not incorrect, but you might experiment with soft mounts, which will rapidly
> timeout and die with io-errors rather than hanging.
Gombas also replied with such information.
I didn't know that this was causing it. I changed the (default
On Sun, Jun 10, 2001 at 06:44:56PM -0700, Lucca wrote:
Not incorrect, but you might experiment with soft mounts, which will rapidly
timeout and die with io-errors rather than hanging.
Gombas also replied with such information.
I didn't know that this was causing it. I changed the (default
On Sun, Jun 10, 2001 at 10:34:28PM +, Roeland Th. Jansen wrote:
> I have a network with a different linux system hat exports a few dirs to
> this system.
oops, this is 2.4.5. but happened before as well.
--
Grobbebol's Home | Don't give in to spammers. -o
hi *
I have a network with a different linux system hat exports a few dirs to
this system.
what happens is this : the other system reboots into windows o the nfs
connection gets lost. however, what happens is that now the process
table starts to fill with cron initiated mrtg calls and all get
hi *
I have a network with a different linux system hat exports a few dirs to
this system.
what happens is this : the other system reboots into windows o the nfs
connection gets lost. however, what happens is that now the process
table starts to fill with cron initiated mrtg calls and all get
On Sun, Jun 10, 2001 at 10:34:28PM +, Roeland Th. Jansen wrote:
I have a network with a different linux system hat exports a few dirs to
this system.
oops, this is 2.4.5. but happened before as well.
--
Grobbebol's Home | Don't give in to spammers. -o)
http
On Fri, Jun 01, 2001 at 03:45:46PM +, Danny ter Haar wrote:
> >the current 'ac' patches or a previous version on
> >http://sf.net/projects/gkernel/ temporarily.
>
> also on :
> www.bzimage.org/kernel-patches/v2.4/alan/v2.4.5/
>
> 8139_too_work.c (62kB)
>
> And also there:
>
>
2.4.5 :
when quote some xfers have taken place, the realtek card dies here.
Jun 1 14:58:12 grobbebol kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jun 1 14:58:12 grobbebol kernel: eth0: Tx timed out, lost interrupt? TSR=0x3,
ISR=0x3, t=1303.
Jun 1 14:58:14 grobbebol kernel: NETDEV
2.4.5 :
when quote some xfers have taken place, the realtek card dies here.
Jun 1 14:58:12 grobbebol kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jun 1 14:58:12 grobbebol kernel: eth0: Tx timed out, lost interrupt? TSR=0x3,
ISR=0x3, t=1303.
Jun 1 14:58:14 grobbebol kernel: NETDEV
On Fri, Jun 01, 2001 at 03:45:46PM +, Danny ter Haar wrote:
the current 'ac' patches or a previous version on
http://sf.net/projects/gkernel/ temporarily.
also on :
www.bzimage.org/kernel-patches/v2.4/alan/v2.4.5/
8139_too_work.c (62kB)
And also there:
I have mentioned this weird behaviour under 2.4.3 as well.
if I use X for some time, I alwasy switch and forth between the (IMHO)
idel CLI and sometimes switch back to the clumsy GUI.
now, what happens is that sometimes, after I switch from X back to a VC,
the display gets black and stays that
I have mentioned this weird behaviour under 2.4.3 as well.
if I use X for some time, I alwasy switch and forth between the (IMHO)
idel CLI and sometimes switch back to the clumsy GUI.
now, what happens is that sometimes, after I switch from X back to a VC,
the display gets black and stays that
the reference to zyxel (from Jeff G ?) :
>ZyXEL P681 -> firmware v2.50(T.05)b6 | 03/28/2001)
btw: it is already offically release version 2.50(T.05)| 04/13/2001
and the ECN issue is fixed.
I have asked if the developers would ake actoin on the other
routers/firewalls as well to fix the
the reference to zyxel (from Jeff G ?) :
ZyXEL P681 - firmware v2.50(T.05)b6 | 03/28/2001)
btw: it is already offically release version 2.50(T.05)| 04/13/2001
and the ECN issue is fixed.
I have asked if the developers would ake actoin on the other
routers/firewalls as well to fix the ECN
On Tue, Apr 17, 2001 at 10:26:26PM -0400, Byron Stanoszek wrote:
> I've seen this on my Dell P3 700 machine several times. Seems to happen at odd
> intervals after I use my CD burner, but that just might be coincidental. But
I have seen this related to the cd burner as well. it's not a via board
On Tue, Apr 17, 2001 at 10:26:26PM -0400, Byron Stanoszek wrote:
I've seen this on my Dell P3 700 machine several times. Seems to happen at odd
intervals after I use my CD burner, but that just might be coincidental. But
I have seen this related to the cd burner as well. it's not a via board
hi all
regently I see weird things with X.
XFree86 Version 4.0.2 / X Window System
(protocol Version 11, revision 0, vendor release 6400)
Release Date: 18 December 2000
(II) NV: driver for NVIDIA chipsets: RIVA128, RIVATNT, RIVATNT2,
RIVATNT2 (Ultra), RIVATNT2 (Vanta), RIVATNT2 M64,
hi all
regently I see weird things with X.
XFree86 Version 4.0.2 / X Window System
(protocol Version 11, revision 0, vendor release 6400)
Release Date: 18 December 2000
(II) NV: driver for NVIDIA chipsets: RIVA128, RIVATNT, RIVATNT2,
RIVATNT2 (Ultra), RIVATNT2 (Vanta), RIVATNT2 M64,
is there a way to dynamically change the limit : kernel: ip_conntrack:
maximum limit of 16384 entries exceeded ?
grepping in the documentation didn't tell much here.
either a newssus scan or a weird ftp server I tried to connect to,
caused the table to fill pretty fast and all other
is there a way to dynamically change the limit : kernel: ip_conntrack:
maximum limit of 16384 entries exceeded ?
grepping in the documentation didn't tell much here.
either a newssus scan or a weird ftp server I tried to connect to,
caused the table to fill pretty fast and all other
On Thu, Mar 08, 2001 at 10:01:57AM -0500, Venkatesh Ramamurthy wrote:
> Please check out this article. Looks like microsoft know open source is the
> thing of the future. I would consider that it is a begining step for full
> blown GPL
>
>
On Thu, Mar 08, 2001 at 10:01:57AM -0500, Venkatesh Ramamurthy wrote:
Please check out this article. Looks like microsoft know open source is the
thing of the future. I would consider that it is a begining step for full
blown GPL
On Mon, Feb 26, 2001 at 01:14:11PM +0100, Maciej W. Rozycki wrote:
> On Mon, 26 Feb 2001, Roeland Th. Jansen wrote:
> > if you like, I can start banging the machine on it's head now.
>
> Please do. I believe the code is safe to be included in 2.4.3, but if
> any problem
On Mon, Feb 26, 2001 at 01:14:11PM +0100, Maciej W. Rozycki wrote:
On Mon, 26 Feb 2001, Roeland Th. Jansen wrote:
if you like, I can start banging the machine on it's head now.
Please do. I believe the code is safe to be included in 2.4.3, but if
any problem is going to pop up, it'd
On Mon, Feb 26, 2001 at 01:14:11PM +0100, Maciej W. Rozycki wrote:
> It is already present in 2.4.2-ac3.
Yep, I just noticed it. there was a backlog from here to tokyo.
> There is a small performance impact at every interrupt -- the code that
> checks for mismatches incurs it. It's just a
Maciej,
with the patch you sent (with MIS counter code) :
CPU0 CPU1
0: 50644222 50826974IO-APIC-edge timer
1: 239631 233690IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
3: 344151 345715IO-APIC-edge serial
4:
Maciej,
with the patch you sent (with MIS counter code) :
CPU0 CPU1
0: 50644222 50826974IO-APIC-edge timer
1: 239631 233690IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
3: 344151 345715IO-APIC-edge serial
4:
On Mon, Feb 26, 2001 at 01:14:11PM +0100, Maciej W. Rozycki wrote:
It is already present in 2.4.2-ac3.
Yep, I just noticed it. there was a backlog from here to tokyo.
There is a small performance impact at every interrupt -- the code that
checks for mismatches incurs it. It's just a few
On Sat, Feb 17, 2001 at 12:46:30PM +, Henning P. Schmiedehausen wrote:
> >1- GPL code is the opposite of crap
>
> No. A license doesn't automatically make good code.
true but at least with GPL, people can work on crap GPL code and make
it good. that's an option you don't have with closed
On Sat, Feb 17, 2001 at 12:46:30PM +, Henning P. Schmiedehausen wrote:
1- GPL code is the opposite of crap
No. A license doesn't automatically make good code.
true but at least with GPL, people can work on crap GPL code and make
it good. that's an option you don't have with closed
On Fri, Feb 16, 2001 at 10:40:53AM +0100, Rogier Wolff wrote:
> Why would it completely "not work"?
experience maybe. telnet works just fine. a copy would end in a _very_
slow transfer. and if I say slow, I mean a few kbytes/sec. depends on
the number of colls as well.
besides, what gains are
On Thu, Feb 15, 2001 at 04:38:37PM -0800, David D.W. Downey wrote:
> I've tried the Abit VP6 and the MSI 6321 (694D Pro). Both give me the APIC
> errors with system lockups on heavy I/O using the 2.4.1-ac1# and the
> 2.4.2-pre# kernels. (The ac-## line doesn't die ANYWHERE near as often as
> the
On Fri, Feb 16, 2001 at 10:40:53AM +0100, Rogier Wolff wrote:
Why would it completely "not work"?
experience maybe. telnet works just fine. a copy would end in a _very_
slow transfer. and if I say slow, I mean a few kbytes/sec. depends on
the number of colls as well.
besides, what gains are
On Thu, Feb 15, 2001 at 04:38:37PM -0800, David D.W. Downey wrote:
I've tried the Abit VP6 and the MSI 6321 (694D Pro). Both give me the APIC
errors with system lockups on heavy I/O using the 2.4.1-ac1# and the
2.4.2-pre# kernels. (The ac-## line doesn't die ANYWHERE near as often as
the
On Wed, Feb 14, 2001 at 05:30:57PM +, Roeland Th. Jansen wrote:
> other observations -- approx 6000 ints from the ne2k card/sec.
> MIS shows approx 1% that goes wrong with a ping flood.
oops. had to count both CPU0 and CPU1's interrupts. after 23 minutes :
CPU0 CP
On Tue, Feb 13, 2001 at 09:13:10PM +0100, Maciej W. Rozycki wrote:
> Please test it extensively, as much as you can, before I submit it for
> inclusion. If you ever get "Aieee!!! Remote IRR still set after unlock!"
> message, please report it to me immediately -- it means the code failed.
On Tue, Feb 13, 2001 at 09:13:10PM +0100, Maciej W. Rozycki wrote:
Please test it extensively, as much as you can, before I submit it for
inclusion. If you ever get "Aieee!!! Remote IRR still set after unlock!"
message, please report it to me immediately -- it means the code failed.
ok,
On Wed, Feb 14, 2001 at 05:30:57PM +, Roeland Th. Jansen wrote:
other observations -- approx 6000 ints from the ne2k card/sec.
MIS shows approx 1% that goes wrong with a ping flood.
oops. had to count both CPU0 and CPU1's interrupts. after 23 minutes :
CPU0 CPU1
19
I was busy with X, sound, bcast2000 and slab :
Feb 12 20:46:57 grobbebol kernel: audio: Buffer error 3 (fe01bf00,16384), (fe00ff00,
-16777216)
Feb 12 20:46:58 grobbebol kernel: Unable to handle kernel paging request at virtual
address c100
Feb 12 20:46:58 grobbebol kernel: printing eip:
I was busy with X, sound, bcast2000 and slab :
Feb 12 20:46:57 grobbebol kernel: audio: Buffer error 3 (fe01bf00,16384), (fe00ff00,
-16777216)
Feb 12 20:46:58 grobbebol kernel: Unable to handle kernel paging request at virtual
address c100
Feb 12 20:46:58 grobbebol kernel: printing eip:
On Sun, Feb 11, 2001 at 10:20:33PM +1100, john slee wrote:
> i'm fairly sure its not ram at fault, since nothing else is acting
> strangely, and it only crops up when i use /dev/dsp.
>
> anything else i can try to narrow it down? this is just a home
> workstation, so i can try practically
On Sun, Feb 11, 2001 at 10:20:33PM +1100, john slee wrote:
i'm fairly sure its not ram at fault, since nothing else is acting
strangely, and it only crops up when i use /dev/dsp.
anything else i can try to narrow it down? this is just a home
workstation, so i can try practically anything
On Mon, Feb 05, 2001 at 08:49:47PM +0100, Frank de Lange wrote:
> Same here (although I just changed #if 1 to #if 0 to disable focus processor
> support), the net stays up and the chops are gone.
so did I (change the 1 into 0). just didn't cut/paste it enough...
--
Grobbebol's Home
On Mon, Feb 05, 2001 at 06:26:52PM +, Roeland Th. Jansen wrote:
>
> I'll report further. an Maciej -- thanks for your work !
with the extra patch in arch/i386/kernel/apic.c:
#else
/* Disable focus processor (bit==1) */
value |= (1<<9);
#endif
used, eth0 (ne2k)
On Fri, Feb 02, 2001 at 02:52:16PM +0100, Frank de Lange wrote:
> I'm currently running 2.4.1 with Maciej's patch-2.4.0-io_apic-4. Additionally,
> I disabled focus_processor in apic.c to get rid of some network delays. Flood
> pings both from and to this system do not cause any problems, other
On Fri, Feb 02, 2001 at 02:52:16PM +0100, Frank de Lange wrote:
I'm currently running 2.4.1 with Maciej's patch-2.4.0-io_apic-4. Additionally,
I disabled focus_processor in apic.c to get rid of some network delays. Flood
pings both from and to this system do not cause any problems, other than
On Mon, Feb 05, 2001 at 06:26:52PM +, Roeland Th. Jansen wrote:
I'll report further. an Maciej -- thanks for your work !
with the extra patch in arch/i386/kernel/apic.c:
#else
/* Disable focus processor (bit==1) */
value |= (19);
#endif
used, eth0 (ne2k) doesn't die
On Mon, Feb 05, 2001 at 08:49:47PM +0100, Frank de Lange wrote:
Same here (although I just changed #if 1 to #if 0 to disable focus processor
support), the net stays up and the chops are gone.
so did I (change the 1 into 0). just didn't cut/paste it enough...
--
Grobbebol's Home
On Fri, Feb 02, 2001 at 09:42:30PM +0100, Maciej W. Rozycki wrote:
> Could you please apply the following patch, wait for a lockup, then hit
> SysRq+A (you need to have CONFIG_MAGIC_SYSRQ enabled) and send me the
> resulting output? You need to include debug messages, so I recommend to
> use
On Fri, Feb 02, 2001 at 09:42:30PM +0100, Maciej W. Rozycki wrote:
Could you please apply the following patch, wait for a lockup, then hit
SysRq+A (you need to have CONFIG_MAGIC_SYSRQ enabled) and send me the
resulting output? You need to include debug messages, so I recommend to
use
On Fri, Feb 02, 2001 at 02:52:16PM +0100, Frank de Lange wrote:
> I'm currently running 2.4.1 with Maciej's patch-2.4.0-io_apic-4. Additionally,
> I disabled focus_processor in apic.c to get rid of some network delays. Flood
> pings both from and to this system do not cause any problems, other
On Fri, Feb 02, 2001 at 03:44:07AM -0600, Mark Orr wrote:
> Well that surely shouldnt happen...I use minicom all the time (I still
> call BBSes), and havent had any crashes. I can quit/disconnect, or
> quit/stay connected and it works okay. I've even got it set up to
> use 23bps, which is
On Fri, Feb 02, 2001 at 12:13:45AM +, Alan Cox wrote:
> > the used board BP6 (abit), apics enabled. non-overclocked. card is a
> >
> > 00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> > RTL-8029(AS)
>
> Try 2.4.1ac - that should fix it
ok, it doesn't crash (the first test)
On Fri, Feb 02, 2001 at 12:13:45AM +, Alan Cox wrote:
> > the used board BP6 (abit), apics enabled. non-overclocked. card is a
> >
> > 00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> > RTL-8029(AS)
>
> Try 2.4.1ac - that should fix it
ok, downloading the -ac1 patch; I'll
On Fri, Feb 02, 2001 at 12:13:45AM +, Alan Cox wrote:
the used board BP6 (abit), apics enabled. non-overclocked. card is a
00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8029(AS)
Try 2.4.1ac - that should fix it
ok, downloading the -ac1 patch; I'll report.
--
On Fri, Feb 02, 2001 at 12:13:45AM +, Alan Cox wrote:
the used board BP6 (abit), apics enabled. non-overclocked. card is a
00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8029(AS)
Try 2.4.1ac - that should fix it
ok, it doesn't crash (the first test) but the
On Fri, Feb 02, 2001 at 03:44:07AM -0600, Mark Orr wrote:
Well that surely shouldnt happen...I use minicom all the time (I still
call BBSes), and havent had any crashes. I can quit/disconnect, or
quit/stay connected and it works okay. I've even got it set up to
use 23bps, which is the
On Fri, Feb 02, 2001 at 02:52:16PM +0100, Frank de Lange wrote:
I'm currently running 2.4.1 with Maciej's patch-2.4.0-io_apic-4. Additionally,
I disabled focus_processor in apic.c to get rid of some network delays. Flood
pings both from and to this system do not cause any problems, other than
2.4.1. rebuilt here and with a floodping towards my machine causes a
hard crash where nothing works anymore.
just before it happens :
Feb 1 13:07:24 grobbebol kernel: NETDEV WATCHDOG: eth0: transmit timed out
Feb 1 13:07:24 grobbebol kernel: eth0: Tx timed out, lost interrupt? TSR=0x3,
On Thu, Feb 01, 2001 at 03:38:28PM -0600, Mark Orr wrote:
> I dont like to be the sort of person who, when people report problems,
> fires back "it works fine here!"...but...just as a point of reference,
> I have a Hayes ESP too -- it's connected to a 56k modem. I havent
> had any crashes or
On Thu, Feb 01, 2001 at 03:38:28PM -0600, Mark Orr wrote:
I dont like to be the sort of person who, when people report problems,
fires back "it works fine here!"...but...just as a point of reference,
I have a Hayes ESP too -- it's connected to a 56k modem. I havent
had any crashes or hangs
2.4.1. rebuilt here and with a floodping towards my machine causes a
hard crash where nothing works anymore.
just before it happens :
Feb 1 13:07:24 grobbebol kernel: NETDEV WATCHDOG: eth0: transmit timed out
Feb 1 13:07:24 grobbebol kernel: eth0: Tx timed out, lost interrupt? TSR=0x3,
[mike -- included you for refs only]
recently I started to dive into a problem that causes 2.2.x and 2.4.x to
crash at shutdown and when minicom/mgetty is used. e.g. shutdown almost
always crashed the system; if a fax is received, 3 out of 4 faxes ok,
but also crashes system.
I tried to contact
[mike -- included you for refs only]
recently I started to dive into a problem that causes 2.2.x and 2.4.x to
crash at shutdown and when minicom/mgetty is used. e.g. shutdown almost
always crashed the system; if a fax is received, 3 out of 4 faxes ok,
but also crashes system.
I tried to contact
On Wed, Jan 17, 2001 at 03:11:52AM -0500, John O'Donnell wrote:
> Please tell me I just didn't just see this message??!?!?!?!
> Please??!?!?!? What are you doing?
> I mean no one person here any disrespect - please do the same.
you just got paid for what you did I guess. if you block a whole
On Wed, Jan 17, 2001 at 03:11:52AM -0500, John O'Donnell wrote:
Please tell me I just didn't just see this message??!?!?!?!
Please??!?!?!? What are you doing?
I mean no one person here any disrespect - please do the same.
you just got paid for what you did I guess. if you block a whole TLD,
On Mon, Jan 15, 2001 at 06:45:06PM +, Petr Vandrovec wrote:
> I think that on BP6 hardware there is no way around except using 'noapic',
> or passing board through Abit replacement program. There is only two bit
> checksum which guards 8 or 22 data bits. I have no idea how frequent two
>
On Fri, Jan 12, 2001 at 12:04:21PM -0800, Linus Torvalds wrote:
> Ok, so it's tentatively the IOAPIC disable/enable code. But it could
> obviously be something that just interacts with it, including just a
> timing issue (ie the _real_ bug might just be bad behaviour when
> changing IO-APIC
On Fri, Jan 12, 2001 at 12:04:21PM -0800, Linus Torvalds wrote:
Ok, so it's tentatively the IOAPIC disable/enable code. But it could
obviously be something that just interacts with it, including just a
timing issue (ie the _real_ bug might just be bad behaviour when
changing IO-APIC state at
On Mon, Jan 15, 2001 at 06:45:06PM +, Petr Vandrovec wrote:
I think that on BP6 hardware there is no way around except using 'noapic',
or passing board through Abit replacement program. There is only two bit
checksum which guards 8 or 22 data bits. I have no idea how frequent two
bits
On Fri, Jan 12, 2001 at 09:03:49PM +0100, Ingo Molnar wrote:
> well, some time ago i had an ne2k card in an SMP system as well, and found
> this very problem. Disabling/enabling focus-cpu appeared to make a
> difference, but later on i made experiments that show that in both cases
> the hang
On Fri, Jan 12, 2001 at 02:27:07PM -0800, Dr. Kelsey Hudson wrote:
>
> This is due to your piece of trash motherboard. The reason that the older
> kernel didn't catch these errors is because (IIRC) it wasn't looking for
> them; they were there even then. The BP6 is a low-end mainboard and was
>
On Fri, Jan 12, 2001 at 02:27:07PM -0800, Dr. Kelsey Hudson wrote:
This is due to your piece of trash motherboard. The reason that the older
kernel didn't catch these errors is because (IIRC) it wasn't looking for
them; they were there even then. The BP6 is a low-end mainboard and was
On Fri, Jan 12, 2001 at 09:03:49PM +0100, Ingo Molnar wrote:
well, some time ago i had an ne2k card in an SMP system as well, and found
this very problem. Disabling/enabling focus-cpu appeared to make a
difference, but later on i made experiments that show that in both cases
the hang happens.
On Mon, Jan 08, 2001 at 06:40:21PM -0200, Rik van Riel wrote:
> I wasn't aware Andrea switched the way he stored his patches
> lately ;)
he's doing that for quite some time now (for suse's kernels too) and
that works pretty well :-)
> OTOH, the advantage of having a big patch means that it's
>
On Mon, Jan 08, 2001 at 06:40:21PM -0200, Rik van Riel wrote:
I wasn't aware Andrea switched the way he stored his patches
lately ;)
he's doing that for quite some time now (for suse's kernels too) and
that works pretty well :-)
OTOH, the advantage of having a big patch means that it's
I recall I have asked this before but now in order to get udf working
under 2.2.19pre*, I mailed the developers/maintainers about a fix.
Dave wrote :
>I forwarded your email to the development list:
>[EMAIL PROTECTED]
>
>Hopefully there's a fix. I dunno, I'm still on 2.2.16.
>As far as
I recall I have asked this before but now in order to get udf working
under 2.2.19pre*, I mailed the developers/maintainers about a fix.
Dave wrote :
I forwarded your email to the development list:
[EMAIL PROTECTED]
Hopefully there's a fix. I dunno, I'm still on 2.2.16.
As far as including
never seen this before.
I run 2.2.19pre3 on a BP6. No OC, no vmware. just the kernel wilt
lm-sensors stuff patched in.
I found that the kernel was somewhat sluggish now and then, and
this morning, this popped up in the logs :
Dec 24 02:05:05 grobbebol kernel: probable hardware bug: clock
never seen this before.
I run 2.2.19pre3 on a BP6. No OC, no vmware. just the kernel wilt
lm-sensors stuff patched in.
I found that the kernel was somewhat sluggish now and then, and
this morning, this popped up in the logs :
Dec 24 02:05:05 grobbebol kernel: probable hardware bug: clock
On Fri, Dec 22, 2000 at 12:29:23AM +, Alan Cox wrote:
> > I thought the 2.2.18 vm would be better :-)... nver have seen so much
> > VM: do_try_to_free_pages failed for... messages.
>
> Try 2.2.19pre2 or higher
ok, will monitor this. uname -a now :
Linux grobbebol 2.2.19pre3 #1 SMP Fri Dec
On Fri, Dec 22, 2000 at 12:29:23AM +, Alan Cox wrote:
I thought the 2.2.18 vm would be better :-)... nver have seen so much
VM: do_try_to_free_pages failed for... messages.
Try 2.2.19pre2 or higher
ok, will monitor this. uname -a now :
Linux grobbebol 2.2.19pre3 #1 SMP Fri Dec 22
I thought the 2.2.18 vm would be better :-)... nver have seen so much
VM: do_try_to_free_pages failed for... messages.
at first the system froze for several seconds. an emer sync worked just
fine so I waited..
Dec 22 00:06:10 grobbebol kernel: VM: do_try_to_free_pages failed for telnet...
I thought the 2.2.18 vm would be better :-)... nver have seen so much
VM: do_try_to_free_pages failed for... messages.
at first the system froze for several seconds. an emer sync worked just
fine so I waited..
Dec 22 00:06:10 grobbebol kernel: VM: do_try_to_free_pages failed for telnet...
On Sat, Oct 21, 2000 at 07:37:36PM -0400, Jason Slagle wrote:
> I'm SMP here 2 Celeron 300A's at 450 in an Abit BP6. 256M of RAM, all
> SCSI.
>
> These bad? They worked well under 2.2 but who knows under 2.4
1) clock the system to specs -- overclocking could kill the stuff
2) there are
On Sat, Oct 21, 2000 at 07:37:36PM -0400, Jason Slagle wrote:
I'm SMP here 2 Celeron 300A's at 450 in an Abit BP6. 256M of RAM, all
SCSI.
These bad? They worked well under 2.2 but who knows under 2.4
1) clock the system to specs -- overclocking could kill the stuff
2) there are batches
On Mon, Oct 02, 2000 at 10:29:50PM +0100, Alan Cox wrote:
> Im intentionally avoiding these right now. The 2.2.18 kernel has a very large
> amount of updates to drivers/extra functionality. I don't want to mix any of
> that with core internal changes of any kind. The VM fixes in paticular look
>
On Mon, Oct 02, 2000 at 10:29:50PM +0100, Alan Cox wrote:
Im intentionally avoiding these right now. The 2.2.18 kernel has a very large
amount of updates to drivers/extra functionality. I don't want to mix any of
that with core internal changes of any kind. The VM fixes in paticular look
good
On Thu, Sep 07, 2000 at 11:26:56PM +1100, Matthew Hawkins wrote:
> I'd like to advocate the inclusion of the majority of these patches of
> Andrea's. I've been patching most of them in for a while now simply
> because I've found my SMP system much more stable and useable.
I also takled with
On Thu, Sep 07, 2000 at 11:26:56PM +1100, Matthew Hawkins wrote:
I'd like to advocate the inclusion of the majority of these patches of
Andrea's. I've been patching most of them in for a while now simply
because I've found my SMP system much more stable and useable.
I also takled with
90 matches
Mail list logo
