Danny ter Haar wrote:
According to Andi Kleen:
"Doesn't work" isn't a very useful bug report. What happens exactly?
Do the RX/TX/error counters increase when you try to send packets?
no, the counters you see with ifconfig eth0 are set to zero
for rx and to 1 for tx.
So it's trying
Frank de Lange wrote:
Hi'all,
Ever since I put two ethernet-cards (cheap Winbond W89C940 based PCI NE2K
clones) in my BP-6 system, I've been experiencing intermittent network hangs. A
hang manifests itself as a total failure to communicate through either network
card, and can only be
David Hinds wrote:
On Wed, Jan 10, 2001 at 06:56:22PM -0800, Miles Lane wrote:
There's one other annoyance:
The config files for pcmcia-cs expect the 3c575_cb driver,
so I either have to hack the configuration files or load
the 3c59x driver by hand.
Yes, I'm not sure how to best
Troels Walsted Hansen wrote:
Hi all.
I found a bug in the sysklogd package version 1.4. When it encounters a zero
byte in the kernel logging output, the text parser enters a busy loop. I
came upon it when the 3c59x driver from kernel 2.4.0 started outputting two
zero bytes for the
Jay Ts wrote:
A patch against kernel 2.4.0 final which provides low-latency
scheduling is at
http://www.uow.edu.au/~andrewm/linux/schedlat.html#downloads
Some notes:
- Worst-case scheduling latency with *very* intense workloads is now
0.8 milliseconds on a 500MHz
Ingo Molnar wrote:
On Tue, 9 Jan 2001, David S. Miller wrote:
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
"David S. Miller" wrote:
Date: Thu, 11 Jan 2001 10:45:13 -0600 (CST)
From: Paul Cassella [EMAIL PROTECTED]
I'm not familiar enough with the tcp code to know if this patch
(against -ac6) is a solution, band-aid, or, in fact, wrong, but
I've run with it (on -ac3) and haven't
Frank de Lange wrote:
Quick and dirty conclusion: as soon as the apic comes in to play, things get
messy...
Yup.
Frank, for over a year there have been sporadic reports
of APIC's forgetting how to deliver interrupts. Not only
on BP6's. Often with 3com NICs, so I've never been 100% sure
Jon Miles wrote:
Hey,
After upgrading from -test11 to 2.4.0, I find that under heavy network
load the eth0 interface seems to lockup... with the following output in
dmesg:
NETDEV WATCHDOG: eth0: transmit timed out
eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x97, t=18556.
What
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
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
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
Andrew Morton wrote:
A patch against kernel 2.4.0 final which provides low-latency
scheduling is at
http://www.uow.edu.au/~andrewm/linux/schedlat.html#downloads
This has been updated for 2.4.1-pre3
- Fixed latency problems with some /proc files and forking
when many files
Gregory Maxwell wrote:
On Sun, Jan 14, 2001 at 10:35:51PM +1100, Andrew Morton wrote:
[snip]
- The patch now works properly on SMP.
[snip]
Any benchmark results on SMP yet?
SMP and UP are much the same.
Workload is `make -j3 bzImage', the measured time
is from entry to an ISR
James Simmons wrote:
Some time ago a intel i810 framebuffer driver was written. It only worked
for 2.2.X. With 2.4.X a spinlock is used in the upper layers of the
console system. Sooner or later we are going to run into the situtation
where we will have graphics hardware which has no vga
James Simmons wrote:
...
By you saying couldn't be acquired from interrupt context do you mean
from a process context or do you mean it failed to aquire it while in
the interrupt context?
Actually, printk() must always use __down_trylock().
- Get rid of console_tasklet. Do it in process
Jeff Lightfoot wrote:
Nothing special with this box. SMP no modules, Squid proxy and
running VNC/Pan at the time. Using kernel version of reiserfs on
filesystems other than root.
Be glad to offer any other info if needed.
Would I be correct in assuming that you're using a serial
Another NMI oops?
You've deadlocked over my old friend console_lock. I can't
see _why_ though. Was this with the same setup, using the
serial console? If so then probably the other CPU was
stuck in the serial console driver, holding console_lock.
Jeff Lightfoot wrote:
On Sunday 21
Tigran Aivazian wrote:
Asset Tag: ^L.
Asset Tag: ^L.
Btw, that Asset Tag printk's are surely buggy, aren't they? Aren't they
supposed to dump in hex instead of some unprintable stuff?
I bugged Alan about that a few weeks back and he mumbled
something cryptic. It seems he's going to take
Bill Hartner wrote:
Hubertus wrote :
The only problem I have with sched_yield like benchmarks is that it
creates
artificial lock contention as we basically spent most of the time other
then context switching + syscall under the scheduler lock. This we won't
see in real apps, that's
Larry McVoy wrote:
Please don't listen to this. The only place you really want comments is
a) at the top of files, describing the point of the file;
b) at the top of functions, if the purpose of the function is not obvious;
c) in line, when the code is not obvious.
One other
John Roll wrote:
Hi,
I read about some problems with my ethernet card (3c59x) but it was rumored
that they were fixed in 2.4.1-pre8. I have 6 IDE drives raided together and
was stress testing the disk IO. Suddenly there was no network!
...
Linux image.harvard.edu 2.4.1-pre9 #1 SMP
Daniel Phillips wrote:
I don't know much about the history of this bug but it's quite clear
it's deliberately inserted:
void * kmalloc (size_t size, int flags)
if allocation succeeds, exit
BUG(); // too big size
return NULL;
I
"Maciej W. Rozycki" wrote:
On Wed, 24 Jan 2001, Andrew Morton wrote:
This is due to a lost APIC interrupt acknowledgement. A workaround
is to boot with the `noapic' LILO option.
This long-standing and very nasty problem was discussed extensively
a week or two ago. Suspi
"David S. Miller" wrote:
I'm back from OZ, and to help deal with my sudden lack of Victoria
Bitter,
aww.. Poor Dave. I'll have an extra one for you.
...
There is one critical failure I saw reported with zerocopy, where all
transmits basically failed using a 3c59x card. This indicates
[EMAIL PROTECTED] wrote:
Hello!
no problems. I simply mounted an NFS server with rsize=wsize=8192
and read a few files - I assume this is sufficient?
This is orthogonal.
Only TCP uses this and you need not to do something special
to test it. Any TCP connection going through 3c
Shawn,
I've pretty much completed the low-latency patch against reiserfs.
It seems to be a little more latency-prone than ext2, but under normal
workloads it's not significant. The worst-case is 100 milliseconds,
but that's when you're doing insane things to it.
You may care to apply
Aaron Lehmann wrote:
On Sat, Jan 27, 2001 at 04:45:43PM +1100, Andrew Morton wrote:
2.4.1-pre10-vanilla, using read()/write(): 34.5% CPU
2.4.1-pre10+zercopy, using read()/write(): 38.1% CPU
Am I right to be bothered by this?
The majority of Unix network traffic is handled
Ion Badulescu wrote:
On Sat, 27 Jan 2001 19:19:01 +1100, Andrew Morton [EMAIL PROTECTED] wrote:
The figures I quoted for the no-hw-checksum case were still
using scatter/gather. That can be turned off as well and
it makes it a tiny bit quicker.
Hmm. Are you sure the differences
jamal wrote:
..
It is also useful to have both client and server stats.
BTW, since the laptop (with the 3C card) is the client, the SG
shouldnt kick in at all.
The `client' here is doing the sendfiling, so yes, the
gathering occurs on the client.
...
The test tool is, of course,
Stefani Seibold wrote:
Second, i had change the macro so it calls now a inline funciton
printk_inline which always return 0. So it should be now compatibel to the
standard printk funciton.
A #define is better.
You see, even if printk is a null inline function,
printk("foo");
will
Shawn Starr wrote:
Andrew, the patch HAS made a difference. For example, while untaring
glibc-2.2.1.tar.gz the
system was not sluggish (mouse movements in X) etc.
Seems to be a go for latency improvements on this system.
hmm.. OK, thanks.
Chris, this seems to be a worthwhile
[EMAIL PROTECTED] wrote:
Hello!
2.4.1-pre10+zercopy, using read()/write(): 38.1% CPU
write() on zc card is worse than normal write() by definition.
It generates split buffers.
yes. The figures below show this. Disabling SG+checksums speeds
up write() and send().
Split buffers
Shawn Starr wrote:
Andrew, the patch HAS made a difference. For example, while untaring
glibc-2.2.1.tar.gz the
system was not sluggish (mouse movements in X) etc.
Seems to be a go for latency improvements on this system.
Shawn,
could you please try this patch in a pristine 2.4.1-pre10?
[EMAIL PROTECTED] wrote:
...
I suggest that you get your hearing checked. I'm fully in favor of sensible
low latency Linux. I believe however that low latency in Linux will
A. be "soft realtime", close to deadline most of the time.
B. millisecond level on present
Bill Huey wrote:
Andrew Morton's patch uses 10 rescheduling points (maybe less from memory)
err... It grew. More like 50 now reiserfs is in there. That's counting
real instances - it's not counting ones which are expanded multiple times
as "1".
It could be brought down to 20-25 with good
jamal wrote:
PS:- can you try it out with the ttcp testcode i posted?
Yup. See below. The numbers are almost the same as
with `zcs' and `zcc'.
The CPU utilisation code which was in `zcc' has been
broken out into a standalone tool, so the new `cyclesoak'
app is a general-purpose system load
Arnaldo Carvalho de Melo wrote:
Please send additions and corrections to me and I'll try
to keep it updated.
Here - have about 300 bugs:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0005.3/0269.html
A lot of the timer deletion races are hard to fix because of
the deadlock problem.
Tobias Ringstrom wrote:
When shutting down my computer with Linux, I cannot wake it up using
wake-on-LAN, which I can do if I shut it down from WinME or the LILO
prompt using the power button.
I see some "interesting" code in 3c59x.c and acpi_set_WOL, and there is
the following little
"Maciej W. Rozycki" wrote:
Following is the 82489DX-ized version of the patch. I believe it's fine,
but I would feel safer if others test it before I send it to Linus.
Your latest patch passes all my testing.
2.4.1+irq-whacker+netperf:APIC dies instantly
Juri Haberland wrote:
[EMAIL PROTECTED] wrote:
Hi there,
when i install kernel 2.4.3 or higher on my slackware
system the card (3c900) gets detected but doesn't do
anything, i also get the line using NWAY 8 or something
like that (had to switch back to 2.4.2 to type e-mail)
Marcell GAL wrote:
int pppoe_backlog_rcv(struct sock *sk, struct sk_buff *skb)
{
lock_sock(sk);
pppoe_rcv_core(sk, skb);
release_sock(sk);
return 0;
}
The backlog_rcv() method is called inside local_bh_disable()
and so cannot call lock_sock().
Jonathan Lundell wrote:
...
I *like* eth0..n (I'd like net0..n better). And I *can't* ask what
eth0 and eth1 are, by the way, but I should be able to (Jeff Garzik
has proposed an extension to ethtool to help out this lack, but it's
not in Linux today, and needs concrete implementation
Julian Anastasov wrote:
eth0: Interrupt posted but not delivered -- IRQ blocked by another device?
This is a failure of the APIC interrupt controller in
the 2.4 kernel. You'll need to boot your kernel with
the `noapic' LILO option. Or run -ac kernels, which
have a software workaround which
[EMAIL PROTECTED] wrote:
How can I bind a user space process to a particular processor in a SMP
environment?
You can't.
Nick Pollitt had an implementation of prcctl() which does this
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0102.2/0214.html
I have a /proc based one at
When one has several machines it is nice to keep each
machine's .config under revision control. Then, on
each machine,
ln [-s] .config-$(hostname -s) .config
Problem is, `make menuconfig/oldconfig/config' goes and
removes your link, causing much irritation.
---
Alan Cox wrote:
drivers and fix their open/close routines to work with this patch? Peter
and I can take some time to do that--if that would help.
That would be one big help. Having done that I'd like to go over it all with
Ted first (if he has time) before I push it to Linus
So
Santiago Garcia Mantinan wrote:
Hi!
I was tracking down a problem with Debian installation freezing when doing
the ifconfig of the 8139too driver on 2.2.19 kernel, and found that this was
caused by 8139too for 2.2.19 not closing it's file descriptors.
The original code by Jeff for the
Andrea Arcangeli wrote:
[ cc'ed to l-k ]
DMA-mapping.txt assumes that it cannot fail.
DMA-mapping.txt is wrong. Both pci_map_sg and pci_map_single failed if
they returned zero. You either have to drop the skb or to try again later
if they returns zero.
Well this is news to me. No
Andrea Arcangeli wrote:
On Sun, May 20, 2001 at 03:49:58PM +0200, Andrea Arcangeli wrote:
they returned zero. You either have to drop the skb or to try again later
if they returns zero.
BTW, pci_map_single is not a nice interface, it cannot return bus
address 0, so once we start the
Andrea Arcangeli wrote:
I can't find *any* pci_map_single() in the 2.4.4-ac9 tree
which can fail, BTW.
I assume you mean that no one single caller of pci_map_single is
checking if it failed or not (because all pci_map_single can fail).
No. Most of the pci_map_single() implementations
Ingo Molnar wrote:
On Sat, 19 May 2001, Jacob Luna Lundberg wrote:
This is 2.4.4 with the aic7xxx driver version 6.1.13 dropped in.
Unable to handle kernel paging request at virtual address 78626970
this appears to be some sort of DMA-corruption or other memory scribble
problem.
Alexander Viro wrote:
(2) what about bootstrapping? how do you find the root device?
Do you do root=/dev/hda/offset=63,limit=1235823? Bit nasty.
Ben's patch makes initrd mandatory.
Can this be fixed? I've *never* had to futz with initrd.
Probably most systems are the same. It
Robert Vojta wrote:
This is a `transamit reclaim' error. It is almost always
caused by this host being in half-duplex mode, and another
host on the network being in full-duplex mode.
Hi,
I tried to force this to be in fullduplex mode by options=0x204 (0x200 + 0x4)
and it works
Carlos Laviola wrote:
invalid operand:
CPU:0
EIP:0010:[c48fb709]
EFLAGS: 00010282
eax: 0019 ebx: ecx: c1272000 edx: c3f7bc20
esi: 00206c60 edi: c3ca5240 ebp: c0695aa0 esp: c1273e68
ds: 0018 es: 0018 ss: 0018
Process snarf (pid: 324,
If -f_pos is positioned exactly at sb-s_maxbytes, a non-zero-length
write to the file doesn't write anything, and write() returns zero.
Consequently applications which try to append to a file which
is s_maxbytes in length hang up, because write() just keeps
on returning zero.
We need to return
Alexander Viro wrote:
Locking rules: both require mount_sem and dcache_lock being
held by callers.
It would help a lot if locking rules were commented in
the source, rather than on linux-kernel.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of
Manas Garg wrote:
I am not sure if it should be classified as a bug, that's why I am calling it a
problem. Here is the description:
It works fine with ext3 :)
That's because ext3 has per-file block preallocation
disabled.
When you truncated your file, the blocks remained preallocated
on
Stephen C. Tweedie wrote:
On Wed, May 23, 2001 at 07:55:48PM +1000, Andrew Morton wrote:
When you truncated your file, the blocks remained preallocated
on behalf of the file, and were hence considered used. For
some reason, a subsequent attempt to allocate blocks for the
same file
[EMAIL PROTECTED] wrote:
Hello!
Note that using dev-name during probe was always incorrect. Think
about the error case:
...
So, using interface name in this manner was always buggy because it
conveys no useful information to the user.
I used to think about cases of success. 8)
Andreas Dilger wrote:
Andrew writes:
Stephen C. Tweedie wrote:
On Wed, May 23, 2001 at 07:55:48PM +1000, Andrew Morton wrote:
When you truncated your file, the blocks remained preallocated
on behalf of the file, and were hence considered used. For
some reason, a subsequent
Andreas Dilger wrote:
Dawson Engler writes:
Here are 37 errors where variables = 1024 bytes are allocated on a
function's stack.
First of all, thanks very much for the work you are doing. It really
is useful, and a good way to catch those very rare error cases that
would not
[EMAIL PROTECTED] wrote:
Hello!
It protects the as-yet-unchanged PCI and Cardbus drivers from a
fatal race.
Fatal race remained.
Don't think so. We have exclusion against all netdevice ioctls
across probe. Still. It doesn't matter.
Andrew, you start again the story about white
Arthur Naseef wrote:
All:
I have been diagnosing kernel panics for over a week and I have
concerns with the use of tq_scheduler for which I was hoping I
could get some assistance.
Is it considered acceptable for functions in the tq_scheduler
task list to call schedule? Is it
Arthur Naseef wrote:
Andrew:
Excellent. I will look at the 2.4 sources.
In addition to the TASK_ZOMBIE issue you mention, I believe there
is an issue of false termination of wait queues. Consider this:
- Task places itself on a wait queue
- Calls schedule()
[EMAIL PROTECTED] wrote:
Hmm. You know that I wrote this long ago?
Well, let's not get too hung up on the disk thing (yeah,
I started it...).
Ben's intent here is to *demonstrate* how argv-style
info can be passed into device nodes. It seems neat,
and nice.
We can also make use of a strong
Alexander Viro wrote:
It's way past ugly.
I knew you'd like it.
It kind of makes sense, because it puts the two primary stream-of-bytes
objects in Unix into the same namespace, with the same accessors.
So if some random application is expecting a filename well heck, you
just give it a
Alan Cox wrote:
Yeas it is stil the same as 2.4.5-ac1, but did not
happen with 2.4.5; You can try running pppd in the
console (tty1) without any argument.
Looks like an interaction with the newer console locking code. The BUG() is
caused when the ppp code tries to write to the console
safemode wrote:
this is just a general question about low latency patches on 2.2, I
remember hearing about low latency patches for 2.4 not playing well with X
4.x, is this true for 2.2 low latency patches as well?
Yes, it would be the case.
Some video cards have a PCI cheat-mode in which
This patch fixes some long-standing problems which people
have been experiencing on collisiony half-duplex 10baseT LANs.
It also syncs up some device names and types with the latest
pcmcia_cs release.
Many thanks to David Hinds for sorting all this out.
Changelog entry (maintained at
Alexander Viro wrote:
if (CONFIG_FOO) {
} else {
}
There are a zillion reasons why this technique is superior
to using `#ifdef CONFIG_FOO'. But, alas, gcc fumbles
the ball:
cat t.c
foo()
{
if (0)
Richard Gooch wrote:
It will probably take about 5 years after a new version of GCC which
has this fix before we can trust it to produce correct code for the
kernel.
I don't think it's that bad, Richard. As davem points out, the dead
code elimination works OK. Chris has a counter-example
George Anzinger wrote:
This patch, for 2.4.0-test6, allows the kernel to be built with full
preemption.
Neat. Congratulations.
...
The measured context switch latencies with this patch
have been as high as 12 ms, however, we are actively working to
isolate and fix the areas of the
"Claude LeFrancois (LMC)" wrote:
Thanks for the info. I can run the script manually to get the NIC on the
network. But, by the mean time before a permanent fix, would it be a good
idea to apply the change I did to allow at least correct initilization for
eth0 ?
Hi, Claude.
Your suggestion
Daniel Stone wrote:
OK.
When I boot up, I have a netfilter init script. It loads many netfilter
modules, among them, ipt_LOG, ipt_state, and ipt_limit. When they load,
whammo, instant OOPS.
(Well, gee. This would be a lot easier to diagnose if your
kernel came with a built-in debugger)
Alex Romosan wrote:
Andrew Morton [EMAIL PROTECTED] writes:
you should upgrade to pcmcia-cs-3.1.20. That release
has these things fixed and the 3com driver will be
significantly better.
i finally got a chance to upgrade to pcmcia-cs-3.1.20 but my card
still locks up with (i think
Michael Elizabeth Chastain wrote:
Rather than discussing what he's said, I ask: OK, if an integrated kernel
debugger is inimical to developing more gurus, what contributions would
Linus welcome?
More documentation, so that more people can understand more deeply?
Cleanup patches, to
Alexander Viro wrote:
Search for proc_register() inside the kernel sources.
_Don't_
proc_register() is dead. Use create_proc_read_entry() instead.
Folks, support of the static procfs entries is gone and it will not be
back. Any initializer for struct proc_dir_entry is a LARTable
Frederic Magniette wrote:
This can be really awful if your code is called very often and then saturate the
logs.
One trick you can pull is:
if (current-uid == )
printk(stuff);
and then exercise the offending code path as user . It
works for some things.
-
Jonathan Earle wrote:
Hi,
I've been having kernel oopses with the 2.4.0-test series and am
including ksymoops processed output from both test4 and test5
kernels. The same oops happens in later kernels too (Tested with
test6, test7 and test8).
Presumably mpls_output() is doing a
Tigran Aivazian wrote:
Hi Martin,
I just found out that my earlier statement "2.2.x is okay" should be
changed to "win98 is okay" so there are definitely problems with sharing
PCI irqs between eepro100/3c59x/(rtl)8139(too) in both 2.2.x and 2.4.x. I
utterly don't care about 2.2.x but I
This one...
- Fix some warnings which resulted from turning off
debug in cardbus.c
- sleep for the correct duration after taking the
reset away (this was left over from some testing. Sorry).
--- linux-2.4.0-test9-pre2/drivers/pcmcia/cardbus.c Mon Sep 18 20:31:49 2000
+++
Horst von Brand wrote:
I've been using a 3com 3CCFE575CT 10/100 Eth cardbus card without any
trouble in 2.2.18pre and 2.4.0-test8 together with pcmcia-cs-3.1.21 (Sep 5
snapshot). I'm running Red Hat 6.2 on that machine (Toshiba Satellite Pro
4280 XDVD) with DHCP. pump works, and sets up the
Keith Owens wrote:
Just because the traces end up in stext_lock does not mean that they
are the same bug. Locks are optimized for pipeline performance, the
code for "got the lock" is in the main text section, the code for
"cannot get lock, need to wait" is moved to a separate text section.
Marco d'Itri wrote:
At the end of a UUCP poll this message was logged:
Sep 19 23:42:47 wonderland kernel: Warning: null TTY for (04:40) in tty_fasync
What does it mean?
Very hard to say.
Ted, Google says this has only been reported three or four times. Could
we please have a BUG()
Keith Owens wrote:
...
Waiting on spinlock! Spinner's EIP is [c0130d7a]
...
Is the extra code worth it? The ix86 oops dump runs the stack printing
anything that looks like a kernel address.
Fair enough.
What about the ALT-SYSRQ-P thing? I guess that wouldn't be necessary
Jeff Garzik wrote:
Andrew Morton wrote:
Having stared sleepily at the code for several evenings I see no way in
which serial_driver.refcount can be non-zero while serial.o's module
refcount is zero. But it happened.
Is it possible to replace serial_driver.refcount with calls
Byron Stanoszek wrote:
After about 3 days running 2.4.0-test9-pre2 (32mb i586 machine), I switched on
the system console and saw these messages. Nothing seems to be wrong with the
system. Can anyone enlighten me?
Flags; bus-master 1, full 0; dirty 1267452(12) current 1267456(0).
Bogus
Andi Kleen wrote:
On Mon, Sep 18, 2000 at 10:06:37AM -0600, Andreas Dilger wrote:
Chris, you write:
my box sometimes hang up at high load avarage with "stuck on TLB
IPI wait (CPU#0)" messages.
This is a known issue with the way reiserfs uses the scheduler task queue.
The
Arnaud Installe wrote:
Hi,
Has anyone else seen a lot of overruns while serving multicast on a pretty
loaded (60%) network, with 3c59x cards ?
One other thing: if something is diabling interrupts for more than 500
microseconds you can get Rx overruns.
IDE can block interrupts for several
MOHAMMED AZAD wrote:
Hi all,
Any one using crystal lan cs8920 adapters.???
A few people.
.. mine is a cs8920
crystal lan adapter.. as per the driver source.. driver does not support
pnp.. and i need to disable it... after disabling pnp and giving an irq and
i/o address the driver
Hi, Ted.
The patch applies the industry-standard `struct module *owner' stuff to
tty_driver and tty_ldisc (as per the TODO list!). It also closes the
schedule()-with-zero-module-refcount hole in release_dev().
There is still no explanation for Harley Anderson's crash though.
serial.c and
Donald Becker wrote:
On Tue, 19 Sep 2000, Andrew Morton wrote:
This patch, against 2.4.0-test9-pre2, moves ethtool.h from the private
domain of the sparc ports into include/linux. This publishes an
...
This is good. It would be useful to have this in place ASAP so driver
authors
jamal wrote:
The FF code of the tulip does have skb recycling code.
And i belive Jes' acenic code does or did at some point.
But this isn't preallocation. Unless you got cute, this scheme would
limit the "preallocation" to the DMA ring size.
For network-intensive applications, a larger
Tom Sightler wrote:
Hi all,
My Xircom RBEM56G-100 almost completely stops working in the latest test9-pre8
and pre9 versions. It will still get an IP address via DHCP, but that's it, no
pings or anything.
It works mostly correctly with test8 (quits responding when leaving promisuous
Tom Sightler wrote:
Is there a better location to report the issues for this driver?
David prefers to use a web system.
Current:
http://sourceforge.net/forum/forum.php?forum_id=33427
Old:
http://pcmcia.sourceforge.org/cgi-bin/HyperNews/get/pcmcia/xircom.html
-
To unsubscribe from this list:
Jeff Garzik wrote:
This patch, against 2.4.0-test9-pre2, moves ethtool.h from the private
domain of the sparc ports into include/linux. This publishes an
existing interface, and has been discussed before. (search past lkml
subject headers for "media tool" and "ethtool")
This updated
p2 wrote:
Hi *,
Attached you will find a patch which adds support for CS89x0 base PCMCIA
cards such as the IBM EtherJet.
Great work!
Did you know that Danilo Beuche has written a Card Services driver for
this device? An old version of that driver currently resides somewhere
in the
The little-low-latency patch for test9 is at
http://www.uow.edu.au/~andrewm/linux/2.4.0-test9-low-latency.patch
Notes:
- It now passes Benno's tests with 50% headroom (thanks to
Ingo's scheduler race fix).
- Updated to follow the wandering ext2 truncate code.
- Updated for the new
1 - 100 of 25528 matches
Mail list logo
