1st, the Sony Vaio Z505HS appears to be an example of a machine which
will not boot a bzImage correctly, compaining about the compression
format.
2nd, trying to build kernel 2.4.0, I stripped out or module-ized
everything I could (I think) including SCSCI support, the smallest I've
gotten zImage
On Friday, January 12, 2001 04:30:44 PM -0500 Alexander Viro
[EMAIL PROTECTED] wrote:
On Fri, 12 Jan 2001, Chris Mason wrote:
Hi guys,
This code for generic_file_write calls vmtruncate without i_sem held. Is
that intentional? It should cause problems for reiserfs at least...
linux-2.4.1-pre2 changed cpu_has_xmm references in
include/asm-i386/xor.h into HAVE_XMM references, which it that
patch also defined. linux-2.4.1-pre3 removed the definition of
HAVE_XMM but did not revert the references in include/asm-i386/xor.h.
My guess is that cpu_has_xmm is the
Make sure your kernel build .config file contains the line:
# CONFIG_INET_ECN is not set
not
CONFIG_INET_ECN=y
Here's what the kernel configuration help has to say:
Explicit Congestion Notification (ECN) allows routers to notify
clients about network congestion, resulting
Hi!
The bottom line: rmdir(".") is gone. Replace it with portable equivalent,
namely
p = getcwd(pwd, sizeof(pwd));
if (!p)
/* handle error - ERANGE or ENOENT */
rmdir(p);
Shell equivalent is rmdir `pwd`. Also portable.
...when you are lucky and all
On Fri, Jan 12, 2001 at 04:37:35PM -0500, Shawn Starr wrote:
Here's something strange that i've been noticing with 2.4.0. Some
websites I am unable to access now. For example:
This is FAQish thing. DON'T USE TCP_ECN unless you want trouble!
# echo 0 /proc/sys/net/ipv4/tcp_ecn
Shawn
Oh, hrm Guess I shouldn't have turned that on ;)
Sorry. nevermind :)
Miles Lane wrote:
Make sure your kernel build .config file contains the line:
# CONFIG_INET_ECN is not set
not
CONFIG_INET_ECN=y
Here's what the kernel configuration help has to say:
Explicit
Hi.
Here's something strange that i've been noticing with 2.4.0. Some websites I am
unable to access now. For example:
snip about sites
This is a FAQ. Check if you compiled with ECN enabled (CONFIG_INET_ECN).
Some sites have broken firewalls that drop packets of that type. Either
don't surf
On Fri, Jan 12, 2001 at 03:48:23PM -0600, Jordan wrote:
1st, the Sony Vaio Z505HS appears to be an example of a machine which
will not boot a bzImage correctly, compaining about the compression
format.
I can say from experience that this is not the case. In fact, the kernel
binaries (RPM) I
Hi Alan,
Will you incorporate Andre IDE patches into the 2.2.19preXX
kernel? If not, do you have any plan to do so in the very near future?
I know this issue has been discussed before. But there has not been
any progress.
I have been following the kernel development for years. I have seen
many
This is to report a possible 2.4.0 bug in either the kernel or
in pppd regarding wakeup after an apmsleep command.
The problem is as follows:
After successful return from an apmsleep command, issued the night
before, ppp does not seem to work. The fix is to rmmod slhc, ppp_generic,
and
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
engineered very poorly; these errors are due to that fact alone.
Talk to you
i have a problem:
when i try to copy a big (maybe 200MB) from my CDROM to my disk the system
gives me an input/output error...
if I run dmesg i have this:
[root@localhost andyrock]# dmesg
Linux version 2.4.0 ([EMAIL PROTECTED]) (gcc version 2.95.3
19991030 (prerelease)) #1 Qui Jan 11 12:22:42
On Fri, Jan 12, 2001 at 12:50:10PM +0100, Danny ter Haar wrote:
eth0: PCnet/FAST III 79C973 at 0xfce0, 00 00 e2 24 41 1d
pcnet32: pcnet32_private lp=c3c42000 lp_dma_addr=0x3c42000 assigned IRQ 9.
pcnet32.c:v1.25kf 26.9.1999 [EMAIL PROTECTED]
same chip works for me von my P5 SMP box.
irq
As suggested in the thread "Subtle MM bug (really 830MB barrier
question)", it would be beneficial on 32-bit hardware for mmap()
allocations without MAP_FIXED to grow downward from TASK_SIZE, rather than
upwards from TASK_UNMAPPED_BASE. This would allow both brk()-using and
mmap()-using
Using 2.4.0 on Red Hat Linux 7.0 with most updates applied. Modified the
Makefile to use kgcc.
My system is an SGI 1200 (something like a VALinux 2xxx), dual PIII/700, 512
MB RAM, Intel L440GX+ motherboard, 2 x Intel Pro/100 netcards
When i boot the system, X Window
Jordan [EMAIL PROTECTED] writes:
1st, the Sony Vaio Z505HS appears to be an example of a machine which
will not boot a bzImage correctly, compaining about the compression
format.
Maybe you need to upgrade to a newer version of lilo?
2nd, trying to build kernel 2.4.0, I stripped out or
I know there has been some talk arround this topic on this list so If I
missed the answer I apologize, i just joined the list today. I read
through the archive and all I could find relative to mass storage is the
scsi dependancy, which I am aware of. Here is my situation.
I have a Fujufilm
Please turn on USB Mass Storage debugging and send me the dmesg output from
when you attach the device and load the drivers.
Matt
On Fri, Jan 12, 2001 at 02:46:46PM -0800, Robert J. Bell wrote:
I know there has been some talk arround this topic on this list so If I
missed the answer I
On Sat, 13 Jan 2001, Andrew Morton wrote:
Nigel Gamble wrote:
Spinlocks should not be held for lots of time. This adversely affects
SMP scalability as well as latency. That's why MontaVista's kernel
preemption patch uses sleeping mutex locks instead of spinlocks for the
long held
Nigel Gamble wrote:
Spinlocks should not be held for lots of time. This adversely affects
SMP scalability as well as latency. That's why MontaVista's kernel
preemption patch uses sleeping mutex locks instead of spinlocks for the
long held locks.
Nigel,
what worries me about this is the
On Sat, Jan 13, 2001 at 12:30:46AM +1100, Andrew Morton wrote:
what worries me about this is the Apache-flock-serialisation saga.
Back in -test8, kumon@fujitsu demonstrated that changing this:
lock_kernel()
down(sem)
stuff
up(sem)
unlock_kernel()
into
Matthew here is the info you requested, thanks for your help.
dmsg.out
Hrm... from these logs, everything looks okay, except for the fact that the
device refuses to return any INQUIRY data.
Can you reproduce the conditions under which it was working and send logs
from that? Or at least remember what the /proc/scsi/scsi info looked like?
Matt
On Fri, Jan 12, 2001
interrupt controllers (io-apic definitely included). Drivers would
generally be better off if they disabled their own chip from sending
interrupts, rather than disabling the interrupt line the chip is on.
That doesn't work very well because the device irq can arrive a measurable
number of
Has anyone gotten Intel's (non-GPL) e100 driver working in 2.4.x yet? What
about their e100-ANS driver that supports FEC 800mbps?
Dan Browning, Cyclone Computer Systems,
[EMAIL PROTECTED]
At 02:14 PM 1/11/2001 -0800, you wrote:
On Tue, Jan 09, 2001, Kambo Lohan [EMAIL PROTECTED] wrote:
; I
Unfortunately I lost everything on my system (the one that worked) and I
don't believe I ever looked in /proc/scsi/scsi because It was working
and I didn't feel the need to go poking around. I had this problem
initially the first time I compiled 2.4.0 but I went back and added SCSI
Generic
Could you disable both bandaids? I disabled them, no problems so far.
Now back to the disable_irq_nosync().
Ok so it looks like the disable_irq code is buggy. Unfortunately its not
just used for these drivers they are just the heaviest users.
Given that we can see the IRQ is still set on the
I'd like to hear about such reports so that I can start debugging (and
perhaps get me one of those failing boards, they must be quite cheap
these days).
This is one of the most precise reports I have
|The system is an AMD K6-3 on a FIC PA-2013 mobo with 3 IDE disks. The
|size of hda is 4.3
I just booted to 2.4.0-ac8 (from 2.4.0-ac6) and noticed the mouse was
going rather slow in X, so I pumped up the "Resolution" a bit more and
restarted it.. Didn't help, and when I exited the kernel gave a nice
big OOPS in kapm-idled (sorry, i don't have the output), and don't
know if it's related
However - Alan's IDE patch for 2.2 kills autodma on ALL VIA chipsets.
That's because all VIA chipsets starting from vt82c586 to vt82c686b
(UDMA100), share the same PCI ID.
I have no reports of problems with the later stuff
Would you prefer to filter just vt82c586 and vt82c586a as the
When i boot the system, X Window doesn't start automatically (but if i boot a
2.2 kernel, it does). This is very strange.
Also, seems like Sendmail waits forever until it starts. But this might be a
network card driver problem (not sure, though).
Its the behaviour changes in 2.4
pc_keyb.c.. I also have the cuecat patch applied, and use it over
the PS/2 mouse port, but I don't think it's interfering.. I doubt
this will be noticable to people not using the "Resolution" option to
speed up the mouse, and mine's rather insane:
Can you tell me if the problem can be
Dan B wrote:
Has anyone gotten Intel's (non-GPL) e100 driver working in 2.4.x yet? What
about their e100-ANS driver that supports FEC 800mbps?
My system at home has an Intel 815 motherboard (video, sound and network are
included into the motherboard), and works quite well with
Alan Cox wrote:
Could you disable both bandaids? I disabled them, no problems so far.
Now back to the disable_irq_nosync().
Ok so it looks like the disable_irq code is buggy. Unfortunately its not
just used for these drivers they are just the heaviest users.
Given that we can see the
On Fri, 12 Jan 2001, Vojtech Pavlik wrote:
However - Alan's IDE patch for 2.2 kills autodma on ALL VIA chipsets.
That's because all VIA chipsets starting from vt82c586 to vt82c686b
(UDMA100), share the same PCI ID.
Would you prefer to filter just vt82c586 and vt82c586a as the comment in
Do you have an OHCI controller or an UHCI controller? I noticed that
you're using the "alternate" UHCI driver... can you try this with the
standard UHCI driver?
Matt
On Fri, Jan 12, 2001 at 03:34:41PM -0800, Robert J. Bell wrote:
Unfortunately I lost everything on my system (the one that
On Fri, 12 Jan 2001, Frank de Lange wrote:
Gentleman, this (the patch to 8390.c) seems to fix the problem.
The problem with this patch is that anybody with a slow ISA ne2000 clone
will basically have absolutely _horrible_ interrupt latency because we
hold the irq lock over some quite
Hi all,
a tarball of the Linux Logical Volume Manager 0.9.1 beta1 is available now at
http://www.sistina.com/
for download (Follow the "LVM download page" link).
This release fixes several bugs including the vgextend(8) related oops.
See the CHANGELOG file contained in the tarball for
what the bug is, and whether there is some other work-around, and whether
it is 100% certain that it is just those two controllers (maybe the other
ones are buggy too, but the 2.2.x tests basically cured their symptoms too
and peopl ehaven't reported them because they are "fixed").
I've not
The spin_lock_irqsave() is absolutely my preferred fix, and if I remember
correctly this is in fact how some early 2.1.x code fixed the ne2000
driver when the original irq scalability stuff happened (for some time
during development we did not have a working "disable_irq()" AT ALL
On Fri, 12 Jan 2001, Alan Cox wrote:
interrupt controllers (io-apic definitely included). Drivers would
generally be better off if they disabled their own chip from sending
interrupts, rather than disabling the interrupt line the chip is on.
That doesn't work very well because the
On Fri, 12 Jan 2001, Alan Cox wrote:
Could you disable both bandaids? I disabled them, no problems so far.
Now back to the disable_irq_nosync().
Ok so it looks like the disable_irq code is buggy. Unfortunately its not
just used for these drivers they are just the heaviest users.
It
interrupt_handler()
{
status = readl(dev-status);
if (status MY_IRQ_DISABLE)
return;
Unfortunately on the 8390 the IRQ statud register is on page 0. The code
on the other CPU might not be on page 0. That means we can't even
Hi,
a tarball of the Linux Logical Volume Manager 0.9.1 beta1 is available now at
http://www.sistina.com/
for download (Follow the "LVM download page" link).
Have a look at 2.4, arch/sparc64/kernel/ioctl32.c
Would it be possible to clean up the ioctl interface so we dont need
such
On Sat, 13 Jan 2001, Alan Cox wrote:
Date: Sat, 13 Jan 2001 00:25:28 + (GMT)
From: Alan Cox [EMAIL PROTECTED]
To: Linus Torvalds [EMAIL PROTECTED]
Cc: Vojtech Pavlik [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: ide.2.4.1-p3.01112001.patch
what the bug is, and whether there is
On Fri, Jan 12, 2001 at 04:36:33PM -0800, Linus Torvalds wrote:
It may well not be disable_irq() that is buggy. In fact, there's good
reason to believe that it's a hardware problem.
I am inclined to believe it IS a hardware problem... If disable_irq were buggy,
wouldn't the problem occur more
On Sat, 13 Jan 2001, Alan Cox wrote:
interrupt_handler()
{
status = readl(dev-status);
if (status MY_IRQ_DISABLE)
return;
Unfortunately on the 8390 the IRQ statud register is on page 0. The code
on the other CPU might not be on
On Fri, 12 Jan 2001, John Heil wrote:
On Sat, 13 Jan 2001, Alan Cox wrote:
Date: Sat, 13 Jan 2001 00:25:28 + (GMT)
From: Alan Cox [EMAIL PROTECTED]
To: Linus Torvalds [EMAIL PROTECTED]
Cc: Vojtech Pavlik [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re:
On Wed, Jan 10, 2001 at 04:48:42AM +0100, Wolfgang Spraul wrote:
Incompatibility with "Sarotech FHD-352F/U Rev 1.0"
Using an external IDE drive in the Sarotech FireWire enclosure fails, even
though the Sarotech unit works with Win2K and other SBP2 drives work for me
(with Linux).
I'm
On Sat, 13 Jan 2001, Frank de Lange wrote:
On Fri, Jan 12, 2001 at 04:36:33PM -0800, Linus Torvalds wrote:
It may well not be disable_irq() that is buggy. In fact, there's good
reason to believe that it's a hardware problem.
I am inclined to believe it IS a hardware problem... If
On Fri, 12 Jan 2001, Linus Torvalds wrote:
Date: Fri, 12 Jan 2001 16:52:00 -0800 (PST)
From: Linus Torvalds [EMAIL PROTECTED]
To: John Heil [EMAIL PROTECTED]
Cc: Alan Cox [EMAIL PROTECTED], Vojtech Pavlik [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: Re: ide.2.4.1-p3.01112001.patch
On Fri, 12 Jan 2001 20:11:30 +0100,
Christian Zander [EMAIL PROTECTED] wrote:
Saying that I should have made use of this mechanism for the specific
code in the Nvidia driver that we are talking about clearly shows that
you didn't look at it. The module used get_module_symbol to search its
own
On Fri, 12 Jan 2001, John Heil wrote:
Yes, initially the 686a was problematic, now with an 80 wire cable its
fine.
One point of clarification... I started out with a simple hdparm -d1
which failed 85% of the time. I added the other stuff only to enhance the
-d0 state I was left with.
On Fri, 12 Jan 2001, Andre Hedrick wrote:
I told you that I have the new code that is scheduled for 2.5 certified on
analizers to be technically correct as it relates to the "state diagrams"
in the standard.
"Technically correct" and "state diagrams as in the standard" mean less
that
On Sat, Jan 13, 2001 at 12:02:35AM +, Alan Cox wrote:
pc_keyb.c.. I also have the cuecat patch applied, and use it over
the PS/2 mouse port, but I don't think it's interfering.. I doubt
this will be noticable to people not using the "Resolution" option to
speed up the mouse, and
On Fri, 12 Jan 2001, Linus Torvalds wrote:
On Fri, 12 Jan 2001, Andre Hedrick wrote:
I told you that I have the new code that is scheduled for 2.5 certified on
analizers to be technically correct as it relates to the "state diagrams"
in the standard.
"Technically correct" and
On Fri, Jan 12, 2001 at 04:56:24PM -0800, Linus Torvalds wrote:
IDE is not my favourite example of a "known stable driver". Also, in many
cases IDE is for historical reasons connected to an EDGE io-apic pin (ie
it's still considered an ISA interrupt). Which probably wouldn't show this
problem
On Fri, 12 Jan 2001, Andre Hedrick wrote:
It works perfectly and exactly as it is defined to work by the rules.
Getting the rules correct == 'the concept of "working"'.
Don't be silly.
You're entirely ignoring the concept of hardware bugs. Which is one very
likely reason for this whole
No luck using the standard UHCI driver, attached logs.
Matthew Dharm wrote:
Do you have an OHCI controller or an UHCI controller? I noticed that
you're using the "alternate" UHCI driver... can you try this with the
standard UHCI driver?
Matt
On Fri, Jan 12, 2001 at 03:34:41PM -0800,
Anton, you write:
Have a look at 2.4, arch/sparc64/kernel/ioctl32.c
Yuk.
Would it be possible to clean up the ioctl interface so we dont need
such large hacks for LVM support? I can do the work but I want to be
sure you guys will agree to it.
What is the reason for all this?
On Fri, 12 Jan 2001, Linus Torvalds wrote:
On Fri, 12 Jan 2001, Andre Hedrick wrote:
It works perfectly and exactly as it is defined to work by the rules.
Getting the rules correct == 'the concept of "working"'.
Don't be silly.
You're entirely ignoring the concept of hardware
On Fri, Jan 12 2001, Linus Torvalds wrote:
[...] With disks it is very hard
to get the same kind of irq load - Linux will merge the requests and do at
least 1kB worth of transfer per interrupt etc. On a ne2k 100Mbps PCI card,
Actually, without mult count you will do only 512b of I/O per
On Fri, 12 Jan 2001, Linus Torvalds wrote:
On Fri, 12 Jan 2001, Andre Hedrick wrote:
It works perfectly and exactly as it is defined to work by the rules.
Getting the rules correct == 'the concept of "working"'.
Don't be silly.
You're entirely ignoring the concept of hardware
Frank de Lange wrote:
It could be that people using those cards are not the ones who tend
to go for the (somewhat tricky) BP6 board...
I doubt that it's BP6 specific: I have the problem with a Gigabyte BXD
board and I doubt that Ingo used an BP6. Perhaps 82093AA specific (the
IO APIC chip
I'm using the following and its been flawless under 2.4x:
eepro100.c:v1.09j-t 9/29/99 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/driv
ers/eepro100.html
eepro100.c: $Revision: 1.35 $ 2000/11/17 Modified by Andrey V.
Savochkin saw@sa
w.sw.com.sg and others
PCI: Found IRQ 11 for device 00:0b.0
On Fri, Jan 12 2001, Jordan wrote:
1st, the Sony Vaio Z505HS appears to be an example of a machine which
will not boot a bzImage correctly, compaining about the compression
format.
I have this exact model too, and it boots bzImage just fine. In fact,
I've never booted anything but bzImage's
Alan Cox wrote:
Could you disable both bandaids? I disabled them, no problems so far.
Now back to the disable_irq_nosync().
Ok so it looks like the disable_irq code is buggy. Unfortunately its not
just used for these drivers they are just the heaviest users.
Given that we can see the
Linus Torvalds wrote:
On Sat, 13 Jan 2001, Frank de Lange wrote:
On Fri, Jan 12, 2001 at 04:36:33PM -0800, Linus Torvalds wrote:
It may well not be disable_irq() that is buggy. In fact, there's good
reason to believe that it's a hardware problem.
I am inclined to believe it IS a
It's not gonna be started on for a while yet, but if you've got any
ideas you wanna throw around, now's the time.
Scott
--
Scott James Remnant Have you ever, ever felt like this? Had strange
http://netsplit.com/ things happen? Are you going round the twist?
-
To unsubscribe from this
On Sat, Jan 13, 2001 at 02:51:54AM +0100, Manfred Spraul wrote:
Frank de Lange wrote:
It could be that people using those cards are not the ones who tend
to go for the (somewhat tricky) BP6 board...
I doubt that it's BP6 specific: I have the problem with a Gigabyte BXD
board and I
I am getting complete lockups of the NIC, up/down the interface doesn't
restore it. rmmod/insmod of ne2k-pci and 8390 doesn't restore it. A
reboot does.
The m/c with this card in isn't normally highly loaded on the network,
but under heavy load it will lockup completely (fairly reliably I
Apologies for this. I have absolutely no idea what happened, but
somehow I managed to post this to three groups when it was only
mean't for one.
*gets more coffee*
Scott
--
Scott James Remnant Have you ever, ever felt like this? Had strange
http://netsplit.com/ things happen? Are
On Fri, Jan 12, 2001, Dan B [EMAIL PROTECTED] wrote:
; Has anyone gotten Intel's (non-GPL) e100 driver working in 2.4.x yet? What
; about their e100-ANS driver that supports FEC 800mbps?
I don't think the intels driver is using pci_dma yet so it's
going to take a while before they port all
On Fri, 12 Jan 2001, Alan Cox wrote:
|The system is an AMD K6-3 on a FIC PA-2013 mobo with 3 IDE disks. The
|size of hda is 4.3 GB, the size of hdb is 854 MB and the size of hdc is
|1.2 GB. Hdd is an IDE CDROM drive
I think its significant that two reports I have are FIC PA-2013 but not
On Sat, 13 Jan 2001, Andrew Morton wrote:
3c59x calls disable_irq() once per minute, and seems to be
one of the most-affected drivers.
The ne2k thing seems to be the _most_ affected one, as far as I can tell.
However, it could easily be a matter of timing - for example, if the
driver does
Hi,
What is the reason for all this? Alignment/wordsize/other? If you look
at the IOP10 code, much of the in-core data structs were changed to int
or long, so this sparc code may not be necessary. It may in fact be
damaging, because I don't know if any of the LVM developers even know it
Andrew Morton wrote:
Jay Ts wrote:
Now about the only thing left is to get it included
in the standard kernel. Do you think Linus Torvalds is more likely
to accept these patches than Ingo's? I sure hope this one works out.
We (or "he") need to decide up-front that Linux is to
Andrew Morton wrote:
Nigel Gamble wrote:
Spinlocks should not be held for lots of time. This adversely affects
SMP scalability as well as latency. That's why MontaVista's kernel
preemption patch uses sleeping mutex locks instead of spinlocks for the
long held locks.
Nigel,
www.dosemu.org
On Fri, 12 Jan 2001, Jim M. wrote:
Hi,
There is a compiler package that runs on DOS but not on Linux.
I was wondered how can i emulate DOS under linux so that i run the compile
package?. I have kernel 2.2.14-12. RH 6.2.
Tim Wright wrote:
Hmmm...
if stuff is very quick, and is guaranteed not to sleep, then a semaphore
is the wrong way to protect it. A spinlock is the correct choice. If it's
always slow, and can sleep, then a semaphore makes more sense, although if
it's highly contented, you're going to
every kernel after 2.4.0-test5 hangs my sparc10
at the same spot. Has anyone looked into this?
here is screen output:
SPARCstation 10 (1 X 390Z50), No Keyboard
ROM Rev. 2.12, 512 MB memory installed, Serial
#6299671.
Ethernet address
Boot device: /iommu/sbus/espdma/esp/sd@3,0:c File
and
If I do the dd line in the title under 2.4.0 I get an
out.txt file of 591 bytes.
If I do the same thing from /dev/zero, I get the
expected 1,000,000 byte file.
I've shoehorned 2.4.0 into a fresh red hat 7.0 install
which could quite easily be a bad thing, yes ripped
out their strange gcc and
Rob Landley wrote:
If I do the dd line in the title under 2.4.0 I get an
out.txt file of 591 bytes.
It isn't broken, you have no more entropy. You must have some system
activity of various sorts before you regain some entropy. Moving the mouse
around, hitting keys, etc, will slowly add more
dd says it completes happily even when copying from
random. 0+100 records in, 0+100 records out. It
This means that dd completed 100 reads, and none of them were of the
requested length (1 bytes).
takes about thirty seconds to finish on the dual
gigahertz processor intel box I'm using
Hi,
short question: How cabn I activate/where can I find the raw devices
often described as /dev/raw[12]* in/with kernel linux-2.4.0.
And where can I find the "raw" utility...
Thank you very much in advance for any help!
Kind regards,
Meino Cramer
-
To unsubscribe from this list: send
hello all.
-
ksymoops 2.3.4 on i686 2.4.0-prerelease. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-prerelease/ (default)
-m
--- David Ford [EMAIL PROTECTED] wrote:
Rob Landley wrote:
If I do the dd line in the title under 2.4.0 I get
an
out.txt file of 591 bytes.
It isn't broken, you have no more entropy. You must
have some system
activity of various sorts before you regain some
entropy. Moving the
I think that `##' operator for string concatination produces the token.
In pci.h, we have bogus `##' operator which doesn't produce valid
token. We don't need (must not) have ## between `s' and the open
paren.
Here's the patch.
diff -ruN v2.4.1-pre3/include/linux/pci.h
I applied the persistent khttpd patch + my vhost patch and now khttpd
beats boa!!! (patch against 2.4.0 follows at the end of the message)
The connection times of boa are still better but khttpd wins in transfers.
Re: TUX: Way WAAAYYY too much overkill.
clameter@melchi:~$ ./zb localhost
Nothing interesting or new, just merges up with the latest 2.4.1-pre1
patch from Linus.
ftp.kernel.org:/pub/linux/kernel/people/davem/zerocopy-2.4.1p1-1.diff.gz
I haven't had any reports from anyone, which must mean that it is
working perfectly fine and adds no new bugs, testers
On 12 Jan 2001, Linus Torvalds wrote:
In article [EMAIL PROTECTED],
Andre Hedrick [EMAIL PROTECTED] wrote:
Well that "experimental patch" is designed to get out of the dreaded
"DMA Timeout Hang" or deadlock that is most noted by the PIIX4 on the
Intel 440*X Chipset groups. Since it
2.4.0 doesn't seem to want to boot on my W6Li with two PPRO 150's.
THis machine has no problems with 2.2 kernels, and is currently running
2.2.17.
It uncompresses, and prints that it is booting, then locks hard. Must
reset.
I have tried the noapic option, with no effect.
I have searched
a few comments...
- localhost is a meaningless benchmark. it's useful to catch some low
hanging fruit, but it really doesn't help in the long run.
- contrast the max connection times between kHTTPd and Boa. if that 9
second maximum for kHTTPd is any indication of its latency performance on
a
Hello kernel gurus,
updating to 2.4.0 final i get a lot of this in my logs
reset_xmit_timer sk=c07929a0 1 when=0x3c61, caller=c01b68c5
reset_xmit_timer sk=c85d8360 1 when=0x3c87, caller=c01b68c5
reset_xmit_timer sk=c29309a0 1 when=0x3ce7, caller=c01b68c5
sending pkt_too_big to self
I think
401 - 495 of 495 matches
Mail list logo