Re: finding Tekram SCSI dc395U linux patch driver:
Juergen Schoew <[EMAIL PROTECTED]> writes: > Hi, > On 15-Feb-01 Thomas Lau wrote: > > hey, I found this driver on mandrake kernel sources, it's ac3, but I > > need ac14 code, also, why still not port this driver into kernel? > > the patch file already released 1 years ago > > Have you checked http://www.garloff.de/kurt/linux/dc395/index.html > there ist a driver Version 1.32 (2000-12-02). it's the version included with the mandrake kernel. -- MandrakeSoft Inc http://www.chmouel.org --Chmouel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PATCH: linux-2.4.2-pre3/arch/i386/boot/Makefile breaks with binutils-2.10.1.0.7
The "ld" program in binutils-2.10.1.0.7 and in binutils-2.10.91.0.2 now requires "--oformat" instead of "-oformat". This breaks linux-2.4.2-pre3/arch/i386/boot/Makefile. I have attached the fix below. I am running a kernel built with this updated Makefile. -- Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." --- linux-2.4.2-pre3/arch/i386/boot/MakefileMon Dec 20 14:43:39 1999 +++ linux/arch/i386/boot/Makefile Fri Feb 9 15:37:53 2001 @@ -43,7 +43,7 @@ $(HOSTCC) $(HOSTCFLAGS) -o $@ $< -I$(TOPDIR)/include bootsect: bootsect.o - $(LD) -Ttext 0x0 -s -oformat binary -o $@ $< + $(LD) -Ttext 0x0 -s --oformat binary -o $@ $< bootsect.o: bootsect.s $(AS) -o $@ $< @@ -52,7 +52,7 @@ $(CPP) $(CPPFLAGS) -traditional $(SVGA_MODE) $(RAMDISK) $< -o $@ bbootsect: bbootsect.o - $(LD) -Ttext 0x0 -s -oformat binary $< -o $@ + $(LD) -Ttext 0x0 -s --oformat binary $< -o $@ bbootsect.o: bbootsect.s $(AS) -o $@ $< @@ -61,7 +61,7 @@ $(CPP) $(CPPFLAGS) -D__BIG_KERNEL__ -traditional $(SVGA_MODE) $(RAMDISK) $< -o $@ setup: setup.o - $(LD) -Ttext 0x0 -s -oformat binary -e begtext -o $@ $< + $(LD) -Ttext 0x0 -s --oformat binary -e begtext -o $@ $< setup.o: setup.s $(AS) -o $@ $< @@ -70,7 +70,7 @@ $(CPP) $(CPPFLAGS) -traditional $(SVGA_MODE) $(RAMDISK) $< -o $@ bsetup: bsetup.o - $(LD) -Ttext 0x0 -s -oformat binary -e begtext -o $@ $< + $(LD) -Ttext 0x0 -s --oformat binary -e begtext -o $@ $< bsetup.o: bsetup.s $(AS) -o $@ $<
[PATCH] acpi/cpu.c on SMP
Hello!
acpi_idle is disabled on SMP systems with more then 1 cpu. The boot
message sais otherwise. This patch corrects the message.
--- linux-2.4.2/drivers/acpi/cpu.c.orig Sat Feb 10 12:01:52 2001
+++ linux-2.4.2/drivers/acpi/cpu.c Thu Feb 15 08:54:16 2001
@@ -335,13 +335,12 @@
acpi_pm_timer_init();
- if (acpi_use_idle) {
#ifdef CONFIG_SMP
- if (smp_num_cpus == 1)
- pm_idle = acpi_idle;
+ if (acpi_use_idle && (smp_num_cpus == 1)) {
#else
- pm_idle = acpi_idle;
+ if (acpi_use_idle) {
#endif
+ pm_idle = acpi_idle;
printk(KERN_INFO "ACPI: Using ACPI idle\n");
printk(KERN_INFO "ACPI: If experiencing system slowness, try adding
\"acpi=no-idle\" to cmdline\n");
}
BYtE
Philipp
--
/ / (_)__ __ __ Philipp Hahn
/ /__/ / _ \/ // /\ \/ /
//_/_//_/\_,_/ /_/\_\ [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: longjmp problem
On Mon, Feb 12, 2001 at 08:10:01AM +0100, Elena Labruna wrote: > I'm working with a C package written by other > on a linux machine with kernel version 2.2.14, > often in a calls of longjmp routine > the system crash with a SIGSEGV signal. > > Anyone can tell me if it can be a kernel problem ? > > Elena Labruna. > Fwiw, we issue(d) longjmp() in signal catching functions (including segv) without difficulty on 2.2.14 kernels. Perhaps your application is not first calling setjmp() to save the stack context? Reed, - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OTP] SMP board recommendations?
Hi David,
Just to let you and the rest of the world in on a secret, 'ASL, Inc.' is
the premier ATA server system builder. Jeff Nguyen is the only person
that I knew two years ago that was a pioneer and I have shared some
information with him before in the past, but here is ATA and it it here to
stay.
Cheers,
Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035Web: www.aslab.com
*** shameless toys of creation to challenage the GB/$$ ***
http://www.aslab.com/contents/servers/Sovereign-3400T.html
http://www.aslab.com/contents/servers/Sovereign-3450T.html
On Thu, 15 Feb 2001, David D.W. Downey wrote:
> Thank you all for your response.
>
> Andre (ASL), thanks for the assist. Laurie and Janine took care of me.
> Asus CUV4X-D mobo with 1GB of buffered ECC RAM. I'm in the process of
> transfering all the hardware to the new board. I'll let you know if this
> new board solves the APIC errors and the random lockups under heavy I/O
> problems.
>
> I do have one more problem that I just can NOT track down.
>
> 2.4.1-ac10 kernel on the old Abit VP6 mobo. I'm getting curious errors
> from the 2.4.1, 2.4.1-ac10, and 2.4.2-pre[#] kernels.
>
> I've been using
>
> dd if=/dev/zero of=/tmp/testdd.img bs=1024k count=1500
>
> for testing of I/O on the various boards I have here. Now, the funny part
> is that I get "file size limit exceeded" at around 1.0GB. I was getting
> this under the 2.4.2-pre# kernels so i switched to straight 2.4.1 and got
> the same problem. I switched to the 2.4.1-ac# line and the problem
> disappeared. Guess what? It's baaacckk!
>
> So, I did a strace of the dd command and got the following from it
>
> execve("/bin/dd", ["dd", "if=/dev/zero", "of=/tmp/testing.img", "bs=1024k",
>"count=1500"], [/* 22 vars */]) = 0
> brk(0) = 0x804e7b8
> open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
> open("/etc/ld.so.cache", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=7852, ...}) = 0
> old_mmap(NULL, 7852, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40015000
> close(3)= 0
> open("/lib/libc.so.6", O_RDONLY)= 3
> fstat(3, {st_mode=S_IFREG|0755, st_size=1183326, ...}) = 0
> read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\215"..., 4096) = 4096
> old_mmap(NULL, 947548, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40017000
> mprotect(0x400f7000, 30044, PROT_NONE) = 0
> old_mmap(0x400f7000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xdf000)
>= 0x400f7000
> old_mmap(0x400fb000, 13660, PROT_READ|PROT_WRITE,
>MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x400fb000
> close(3)= 0
> old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
>0x400ff000
> mprotect(0x40017000, 917504, PROT_READ|PROT_WRITE) = 0
> mprotect(0x40017000, 917504, PROT_READ|PROT_EXEC) = 0
> munmap(0x40015000, 7852)= 0
> personality(PER_LINUX) = 0
> getpid()= 195
> brk(0) = 0x804e7b8
> brk(0x804e7f0) = 0x804e7f0
> brk(0x804f000) = 0x804f000
> open("/dev/zero", O_RDONLY|O_LARGEFILE) = 3
> open("/tmp/testing.img", O_RDWR|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 4
> rt_sigaction(SIGINT, NULL, {SIG_DFL}, 8) = 0
> rt_sigaction(SIGINT, {0x804ada8, [], 0x400}, NULL, 8) = 0
> rt_sigaction(SIGQUIT, NULL, {SIG_DFL}, 8) = 0
> rt_sigaction(SIGQUIT, {0x804ada8, [], 0x400}, NULL, 8) = 0
> rt_sigaction(SIGPIPE, NULL, {SIG_DFL}, 8) = 0
> rt_sigaction(SIGPIPE, {0x804ada8, [], 0x400}, NULL, 8) = 0
> rt_sigaction(SIGUSR1, NULL, {SIG_DFL}, 8) = 0
> rt_sigaction(SIGUSR1, {0x804ae70, [], 0x400}, NULL, 8) = 0
> old_mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
>0x4010
> read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) =
>1048576
> write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) =
>1048576
>
> * BIG ASS SNIP **
>
> read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) =
>1048576
> write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = -1
>EFBIG (File too large)
> --- SIGXFSZ (File size limit exceeded) ---
> +++ killed by SIGXFSZ +++
>
>
>
> Now, notice the beginning file creation call. It starts out with
> O_LARGEFILE but ends with EFBIG. Since I'm not totally familiar with the
> kernel code I could be wrong on my next statement and if I am, please tell
> me, but it looks like it changes the file creation call from LARGEFILE to
> EFBIG (or is this just the error call
Re: [OTP] SMP board recommendations?
Thank you all for your response.
Andre (ASL), thanks for the assist. Laurie and Janine took care of me.
Asus CUV4X-D mobo with 1GB of buffered ECC RAM. I'm in the process of
transfering all the hardware to the new board. I'll let you know if this
new board solves the APIC errors and the random lockups under heavy I/O
problems.
I do have one more problem that I just can NOT track down.
2.4.1-ac10 kernel on the old Abit VP6 mobo. I'm getting curious errors
from the 2.4.1, 2.4.1-ac10, and 2.4.2-pre[#] kernels.
I've been using
dd if=/dev/zero of=/tmp/testdd.img bs=1024k count=1500
for testing of I/O on the various boards I have here. Now, the funny part
is that I get "file size limit exceeded" at around 1.0GB. I was getting
this under the 2.4.2-pre# kernels so i switched to straight 2.4.1 and got
the same problem. I switched to the 2.4.1-ac# line and the problem
disappeared. Guess what? It's baaacckk!
So, I did a strace of the dd command and got the following from it
execve("/bin/dd", ["dd", "if=/dev/zero", "of=/tmp/testing.img", "bs=1024k",
"count=1500"], [/* 22 vars */]) = 0
brk(0) = 0x804e7b8
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=7852, ...}) = 0
old_mmap(NULL, 7852, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40015000
close(3)= 0
open("/lib/libc.so.6", O_RDONLY)= 3
fstat(3, {st_mode=S_IFREG|0755, st_size=1183326, ...}) = 0
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\215"..., 4096) = 4096
old_mmap(NULL, 947548, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40017000
mprotect(0x400f7000, 30044, PROT_NONE) = 0
old_mmap(0x400f7000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xdf000) =
0x400f7000
old_mmap(0x400fb000, 13660, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,
-1, 0) = 0x400fb000
close(3)= 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x400ff000
mprotect(0x40017000, 917504, PROT_READ|PROT_WRITE) = 0
mprotect(0x40017000, 917504, PROT_READ|PROT_EXEC) = 0
munmap(0x40015000, 7852)= 0
personality(PER_LINUX) = 0
getpid()= 195
brk(0) = 0x804e7b8
brk(0x804e7f0) = 0x804e7f0
brk(0x804f000) = 0x804f000
open("/dev/zero", O_RDONLY|O_LARGEFILE) = 3
open("/tmp/testing.img", O_RDWR|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 4
rt_sigaction(SIGINT, NULL, {SIG_DFL}, 8) = 0
rt_sigaction(SIGINT, {0x804ada8, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGQUIT, NULL, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, {0x804ada8, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGPIPE, NULL, {SIG_DFL}, 8) = 0
rt_sigaction(SIGPIPE, {0x804ada8, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGUSR1, NULL, {SIG_DFL}, 8) = 0
rt_sigaction(SIGUSR1, {0x804ae70, [], 0x400}, NULL, 8) = 0
old_mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x4010
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) =
1048576
* BIG ASS SNIP **
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = 1048576
write(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1048576) = -1
EFBIG (File too large)
--- SIGXFSZ (File size limit exceeded) ---
+++ killed by SIGXFSZ +++
Now, notice the beginning file creation call. It starts out with
O_LARGEFILE but ends with EFBIG. Since I'm not totally familiar with the
kernel code I could be wrong on my next statement and if I am, please tell
me, but it looks like it changes the file creation call from LARGEFILE to
EFBIG (or is this just the error call itself?)
Now, the kernel is supposed to be able to handle creating a 4TB file(?),
so 1.0GB should be nothing to it. NOTHING changed betwen it working and
not working. No hardware changes, no software additions, no recompiles of
existing applications/daemons.. nothing.
So, my question is now one of "What gives?" Any clues on how I can check
to see what's going wrong? Is my gut feeling that it's changing the file
type wrong? (IIUC, there are different open() calls for different size
files? No, I have nothing to base this one, just something I flashed on
and thought might explain the problem.)
I'm learning here guys, so please be gentle. You folks are the only ones I
have with the experience to tell me when I'm just fscked in the head and
when I'm bang on.
--
David D.W. Downey - RHCE
Consulting Engineer
Ensim Corporation - Sunnyvale, CA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Re: calling all gurus! odd and subtle network problem -- followup, possible answer
Chris Friesen wrote: > The kicker is that the NIC with the MAC address in question happened to be in my > G4 box running linux (yellowdog, 2.2.17 kernel). It was a D-Link 530TX NIC, if > it matters. The linux box was not configured as a DHCP server or client, and > both interfaces on the box were configured with static IP addresses. The > motherboard interface was eth0 and was set to an address on the corporate LAN. > The other NIC was eth1 and was set to an address in the 192.168 range for > testing. The machine has been up and running in this configuration since > september of last year with no known issues. I made no changes at the time the > problems started. Okay, so some further digging revealed that someone was testing out the "ethertap" device, which according to him requires ip_forwarding and proxy_arp to be turned on. I suspect this is what changed and caused the problems. Since rebooting cleaned up the /proc filesystem and reset these to zero, the problems went away. This feels like the answer to me. It saw the arp requests coming in the one interface, sent them out the other interface, and the other machines got confused because they saw that arps coming from a different MAC address. Guess this goes to show the problems people can get into with stuff they don't understand Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
calling all gurus! odd and subtle network problem
I am trying to get some ideas on what the heck caused a problem with the network at work, and I was hoping someone might have some ideas. Yesterday we were having some major network problems, many machines were completely bogged down. This morning I came in to work to find my linux box unplugged from the network and a note saying to call the network engineering dept. We have a large pool of IP addresses set aside for assignment by DHCP to support laptops and whatnot. Apparently the network problems were caused by a particular MAC address being associated with essentially the entire pool of DHCP-assigned addresses, so the DHCP client boxes were all trying to negotiate for an address and kept getting error messages and trying again. This apparently caused enough traffic that it bogged down the rest of the network. The kicker is that the NIC with the MAC address in question happened to be in my G4 box running linux (yellowdog, 2.2.17 kernel). It was a D-Link 530TX NIC, if it matters. The linux box was not configured as a DHCP server or client, and both interfaces on the box were configured with static IP addresses. The motherboard interface was eth0 and was set to an address on the corporate LAN. The other NIC was eth1 and was set to an address in the 192.168 range for testing. The machine has been up and running in this configuration since september of last year with no known issues. I made no changes at the time the problems started. My understanding of the evidence is that 1) in the routers my MAC address was associated with hundreds if not thousands of IP addresses. 2) it was sending out packets to all boxes configured via DHCP that there was an IP address conflict and that it in fact owned that IP address (not sure exactly what packet this would be, but I saw a printout of an error message from a DHCP-configured printer). 3) when they pulled my machine off the LAN, the problem stopped. 4) today we pulled the NIC with the MAC address in question and hooked the box back up using only eth0, and everything seems to be working fine. On my box, the linux kernel had no knowledge of the IP addresses, "ifconfig" and "ip addr" both showed just the two addresses assigned to it (I checked it during the problems for work related reasons). /etc/hosts has about 9 entries, all ones that I've put in. Does anyone have any ideas as to what was going on? My only theory is that something is screwy with the card or the drivers, but I have no idea why it would run fine for almost 6 months then suddenly start causing problems. I eagerly await your opinions. Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Loopback status
On Thu, Feb 15 2001, Adam Schrotenboer wrote: > What's the current status of the loop-# patch? Haven't seen anything > since loop-4, which doesn't apply clean to 2.4.1-ac14 (one hunk is > rejected in loop.c, many others apply with fuzz). > > I am waiting in anticipation of the folding of this patch into the > mainline kernel. > > IIRC, Jens said he was working on a loop-5, but that was a week or two ago. I've been busy doing other stuff, sorry. I probably won't have time to try and merge loop-5 with Alan before monday/tuesday, so hang on and it will get there. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: japanese keyboards
> Recently I got some more detailed information on Japanese keyboards > and their scancodes. Maybe there are Japanese readers here who > can look at > http://www.win.tue.nl/~aeb/linux/kbd/scancodes-3.html#ss3.3 > and correct what is wrong? > > Andries Well, I can read Japanese, but what exactly is the problem? I haven't found anything wrong with my Japanese keyboard that would need to be fixed in the kernel. Could you give some more details? -- Bruce Harada [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ServeRaid 4M with IBM netfinity and kernel 2.4.x
We have a problem here that make the filesystem crash during big files transfer (>1M). It only happens with kernel 2.4.x ; with 2.2.18, it is very stable and fast. I have seen a thread some time ago concerning such problem but is there a solution against it now ? I should add that the behaviour of serveraid under 2.4 is somehow strange : during fsck for instance, it seems to get stuck and won't go further if we don't strike a key on the keyboard. -- Stef - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Samba performance / zero-copy network I/O
On Wed, 14 Feb 2001, Tom Sightler wrote: > Quoting "Gord R. Lamb" <[EMAIL PROTECTED]>: > > > On Wed, 14 Feb 2001, Jeremy Jackson wrote: > > > > > "Gord R. Lamb" wrote: > > > > in etherchannel bond, running > > linux-2.4.1+smptimers+zero-copy+lowlatency) > > Not related to network, but why would you have lowlatency patches on > this box? Well, I figured it might reduce deadweight time between the different operations (disk reads, cache operations, network I/O) at the expense of a little throughput. It was just a hunch and I don't fully understand the internals (of any of this, really). Since I wasn't saturating the disk or network controller, I thought the gain from quicker response time (for packet acknowledgement, etc.) would outweigh the loss of individual throughputs. Again, I could be misunderstanding this completely. :) > My testing showed that the lowlatency patches abosolutely destroy a > system thoughput under heavy disk IO. Sure, the box stays nice and > responsive, but something has to give. On a file server I'll trade > console responsivness for IO performance any day (might choose the > opposite on my laptop). Well, I backed out that particular patch, and it didn't seem to make much of a difference either way. I'll look at it in more detail tomorrow though. Cya. > My testing wasn't very complete, but heavy dbench and multiple > simultaneous file copies both showed significantly lower performance > with lowlatency enabled, and returned to normal when disabled. > > Of course you may have had lowlatency disabled via sysctl but I was > mainly curious if your results were different. > > Later, > Tom > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
mke2fs and kernel VM issues
What is believed to be the current status of the typical mke2fs crashes/hangs due to vm issues? I can reliably reproduce the issue on a heavily modifed VA kernel based on 2.2.18. Is there a kernel which is believed to be a known good kernel? (both 2.2.x and 2.4.x) Failure pattern: System: mylex raid 5 array 8 x 9G drives (not really all that big) >=512M of RAM (1G of RAM works) no swap (Not sure if this makes a difference.) The system is attempting to create a single partition containing the most of the entire RAID array. errors: buffy: Installing with LIVE AMMO Creating partitions... Initializing filesystems... Out of Memory: Killed process 106 (portmap), saved process 2165 (mke2fs).<3>Out of Memory: Killed process 2123 (buffy), saved process 2165 (mke2fs).willow: LOAD FAILED <3>Out of Memory: Killed process 195 (sisyphus_upload), saved process 2165 (mke2 fs).<3>Out of Memory: Killed process 2165 (mke2fs). (Note that most of the above proccesses were dialog interfaces waiting for user input or perl scripts waiting for mke2fs or buffy to exit.) PS- Conversations with various VA empolyees indicates that others within VA, and at least one vendor are seeing hangs while creating really large filesystems on RAID arrays. (mostly 1/4 TB or larger) These issues appear to come and go, and are endemic to the 2.2.x kernel line. Both lnz and tytso seem to believe the issues to be vm entirely related. -- Solving people's computer problems always requires more hardware be given to you. (The Second Rule of Hardware Acquisition) Samuel J. Flory <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86 ptep_get_and_clear question
On Thu, 15 Feb 2001, Manfred Spraul wrote: > > > Now, I will agree that I suspect most x86 _implementations_ will not do > > this. TLB's are too timing-critical, and nobody tends to want to make > > them bigger than necessary - so saving off the source address is > > unlikely. Also, setting the D bit is not a very common operation, so > > it's easy enough to say that an internal D-bit-fault will just cause a > > TLB re-load, where the TLB re-load just sets the A and D bits as it > > fetches the entry (and then page fault handling is an automatic result > > of the reload). > > But then the cpu would support setting the D bit in the page directory, > but it doesn't. Not necessarily. The TLB walker is a nasty piece of business, and simplifying it as much as possible is important for hardware. Not setting the D bit in the page directory is likely to be because it is unnecessary, and not because it couldn't be done. > But if we change the interface, could we think about the poor s390 > developers? > > s390 only has a "clear the present bit in the pte and flush the tlb" > instruction. Now, that ends up being fairly close to what it seems mm/vmscan.c needs to do, so yes, it would not necessarily be a bad idea to join the "ptep_get_and_clear()" and "flush_tlb_page()" operations into one. However, the mm/memory.c use (ie region unmapping with zap_page_range()) really needs to do something different, because it inherently works with a range of entries, and abstacting it to be a per-entry thing would be really bad for performance anywhere else (S/390 might be ok with it, assuming that their special instruction is really fast - I don't know. But I do know that everybody else wants to do it with one single flush for the whole region, especially for SMP). > Perhaps try to schedule away, just to improve the probability that > mm->cpu_vm_mask is clear. > > I just benchmarked a single flush_tlb_page(). > > Pentium II 350: ~ 2000 cpu ticks. > Pentium III 850: ~ 3000 cpu ticks. Note that there is some room for concurrency here - we can fire off the IPI, and continue to do "local" work until we actually need the "results" in the form of stable D bits etc. So we _might_ want to take this into account in the interfaces: allow for a "prepare_to_gather()" which just sends the IPI but doesn't wait for it to necessarily get accepted, and then only by the time we actually start checking the dirty bits (ie the second phase, after we've invalidated the page tables) do we need to wait and make sure that nobody else is using the TLB any more. Done right, this _might_ be of the type - prepare_to_gather(): sends IPI to all CPU's indicated in mm->cpu_vm_mask - go on, invalidating all VM entries - busy-wait until "mm->cpu_vm_mask" only contains the local CPU (where the busy-wait is hopefully not a wait at all - the other CPU's would have exited the mm while we were cleaning up the page tables) - go back, gather up any potential dirty bits and free the pages - release the mm Note that there are tons of optimizations for the common case: for example, if we're talking about private read-only mappings, we can possibly skip some or all of this, because we know that we simply won't care about whether the pages were dirty or not as they're going to be thrown away in any case. So we can have several layers of optimizations: for UP or the SMP case where we have "mm->cpu_vm_mask & ~(1 << current_cpu) == 0" we don't need the IPI or the careful multi-CPU case at all. And for private stuff, we need the careful invalidation, but we don't need to go back and gather the dirty bits. So the only case that ends up being fairly heavy may be a case that is very uncommon in practice (only for unmapping shared mappings in threaded programs or the lazy TLB case). I suspect getting a good interface for this, so that zap_page_range() doesn't end up being the function for hell, is the most important thing. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Ping-Pong, the lists are dead?
I haven't received any emails from any vger lists since Jan. 29. Do they still work? Would anyone who gets this message please email "[EMAIL PROTECTED]" to let me know if my message gets to the list? I have to figure out why I can't see anything *from* the list... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86 ptep_get_and_clear question
On Fri, 16 Feb 2001, Jamie Lokier wrote: > > If you want to take it really far, it _could_ be that the TLB data > contains both the pointer and the original pte contents. Then "mark > dirty" becomes > >val |= D >write *ptr No. This is forbidden by the intel documentation. First off, the documentation clearly states that it's a locked r-m-w cycle. Secondly, the documentation also makes it clear that the CPU page table accesses work correctly in SMP environments, which the above simply would not do. It doesn't allow for people marking the entry invalid, which is documented to work (see the very part I quoted). So while the above could be a valid TLB writeback strategy in general for some hypothetical architecture, it would _not_ be an x86 CPU any more if it acted that way. So a plain "just write out our cached value" is definitely not legal. > > Now, I will agree that I suspect most x86 _implementations_ will not do > > this. TLB's are too timing-critical, and nobody tends to want to make > > them bigger than necessary - so saving off the source address is > > unlikely. > > Then again, these hypothetical addresses etc. aren't part of the > associative lookup, so could be located in something like an ordinary > cache ram, with just an index in the TLB itself. True. I'd still consider it unlikely for the other reasons (ie this is not a timing-critical part of the normal CPU behaviour), but you're right - it could be done without making the actual TLB any bigger or different, by just having the TLB fill routine having a separate "source cache" that the dirty-marking can use. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OTP] SMP board recommendations?
Anyone have a recommendation for a motherboard for a homebased SMP box? 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 other board.) I'm looking into the i810 server board with the onboard SCSI controllers. I plan on installing either the Promise PDC20267 ATA100 controller or a Promise FastTrak RAID card (if they come in ATA100) since the only SCSI I have is the Yamaha 8424S SCSI CDR-W. Since this IS off topic of sorts, please reply to me privately. Thanks -- David D.W. Downey - RHCE Consulting Engineer Ensim Corporation - Sunnyvale, CA - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: NFSD die with 2.4.1 (resend with ksymoops)
On Thursday February 15, [EMAIL PROTECTED] wrote:
>
> Here I am again! NFSD died at 11h23, ~12 hours after the last reboot, a
> record :-)
I'm guessing you don't have many symlinks on the exported
filesystem
> I'll try to best answer your questions.
>
> > This trace seems to make sense, except that nfssvc_encode_diropres
> > doesn't seem to make any subroutine calls at offset 100 as seems to be
> > implied.
> >
> > Could you run
> >
> > echo disassemble nfssvc_encode_diropres | gdb -batch -x
> > /dev/stdin vmlinux
>
> It's in the attached file.
> In fact, the Oops was with a new compiled kernel with NFSD in modules... So
> the GDB stuff would not work...
> So attached is the output of GDB recompiled with NFSD in the kernel. Is it
> sufficient for you? It's not the one that was running but just recompiled.
> If not, I'll send you a new Oops + GDB output of a RUNNING kernel with NFSD
> in the kernel.
>
> > giving it the vmlinux that was running when this oops was
> > produced? and
> > also tell me exactly what patches you have ontop of 2.4.1 and where to
> > find them.
>
> I have only ACL patched. You can find them at acl.bestbits.at.
The information you sent was very helpful.
You are getting an Oops here:
> 0xc0173769 : push $0x8000
> 0xc017376e : push %ecx
> 0xc017376f : mov0x48(%eax),%eax
> 0xc0173772 : call *%eax
%eax is zero.
This corresponds to the code fragment:
+ if (IS_POSIX_ACL(inode) && inode->i_op) {
+ posix_acl_t *acl = inode->i_op->get_posix_acl(
+ inode, ACL_TYPE_ACCESS);
%eax has the value of inode->i_op->get_posix_acl. Clearly this field
hasn't been initialised.
A quick look at the patch suggests that it doesn't get initialised for
symlinks, but I haven't poured over it in detail.
I must admit that it appears somewhat courageous to be running 2.4.1
with patches that were made for 2.4.0-test12 on a production machine,
but I guess you know what you are doing.
> I have tried without them, with exactly the same behaviour.
>
That may be, but you have only given evidence that it that there are
problems with the patches installed, and that evidence points very
strongly at a problem with the patch. If you can give me evidence (an
Oops for example) which shows problems without the patches, then I
will be happy to look at it.
Also, the most recent ksymoops output is totally useless. It looks
like the kernel image that ksymoops was using to find symbol
information was different from the kernel image that was running.
It is very important that these two match, or the result is of no use.
NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: IDE DMA Problems...system hangs
You have junk for cables or they are noe sheilded correctly from
crosstalk. But I do not think this is the case.
Go check your power-supply for stality and load.
Then do a ripple noise test to make sure that underload, it does not cause
the clock on the drives to fail.
On Thu, 15 Feb 2001, Jasmeet Sidhu wrote:
>
> >>I've not changed anything related to DMA handling specifically. The current
> >>-ac does have a fix for a couple of cases where an IDE reset on the promise
> >>could hang the box dead. That may be the problem.
>
> I tried the new patches (2.4.1-ac13) and it seemed very stable. After
> moving about 50GB of data to the raid5, the system crashed. here is the
> syslog... (the system had been up for about 20 hours)
>
> Feb 14 03:48:53 bertha kernel: hdo: dma_intr: status=0x51 { DriveReady
> SeekComplete Error }
> Feb 14 03:48:53 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
> BadCRC }
>
> Feb 14 19:35:52 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
> BadCRC }
> Feb 14 19:35:52 bertha kernel: hdo: dma_intr: status=0x51 { DriveReady
> SeekComplete Error }
> Feb 14 19:35:52 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
> BadCRC }
> Feb 14 20:13:06 bertha kernel: hdi: dma_intr: bad DMA status
> Feb 14 20:13:06 bertha kernel: hdi: dma_intr: status=0x50 { DriveReady
> SeekComplete }
>
> Feb 15 01:26:34 bertha kernel: hdo: dma_intr: status=0x51 { DriveReady
> SeekComplete Error }
> Feb 15 01:26:34 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
> BadCRC }
> Feb 15 01:26:34 bertha kernel: hdo: dma_intr: status=0x51 { DriveReady
> SeekComplete Error }
> Feb 15 01:26:34 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
> BadCRC }
> Feb 15 01:26:38 bertha kernel: hdo: dma_intr: status=0x51 { DriveReady
> SeekComplete Error }
> Feb 15 01:26:38 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
> BadCRC }
> Feb 15 01:45:06 bertha kernel: hdo: dma_intr: status=0x53 { DriveReady
> SeekComplete Index Error }
> Feb 15 01:45:06 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
> BadCRC }
> Feb 15 01:45:06 bertha kernel: hdo: dma_intr: status=0x51 { DriveReady
> SeekComplete Error }
> Feb 15 01:45:06 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
> BadCRC }
> Feb 15 01:45:06 bertha kernel: hdo: dma_intr: status=0x51 { DriveReady
> SeekComplete Error }
> Feb 15 01:45:06 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
> BadCRC }
> Feb 15 01:54:01 bertha kernel: hdg: timeout waiting for DMA
>
>
> Jasmeet
>
>
> At 08:54 PM 2/14/2001 +, Alan Cox wrote:
> > > >You will get horribly bad performance off raid5 if you have stripes on
> > both
> > > >hda/hdb or hdc/hdd etc.
> > >
> > > If I am reading this correctly, then by striping on both hda/hdb and
> > > /hdc/hdd you mean that I have two drives per ide channel. In other words,
> > > you think I have a Master and a Slave type of a setup? This is
> > > incorrect. Each drive on the system is a master. I have 5 promise cards
> >
> >Ok then your performance should be fine (at least reasonably so, the lack
> >of tagged queueing does hurt)
> >
> > > ide chanel, the penalty should not be much in terms of performance. Maybe
> > > its just that the hdparam utility is not a good tool for benchamarking a
> > > raid set?
> >
> >Its not a good raid benchmark tool but its a good indication of general
> >problems.
> >Bonnie is a good tool for accurate assessment.
> >
> > > disable DMA if its giving it a lot of problems, but it should not hang. I
> > > have been experiencing this for quite a while with the newer
> > > kernels. Should I try the latest ac13 patch? I glanced of the changes
> > and
> > > didnt seem like anything had changed regarding the ide subsystem.
> >
> >I've not changed anything related to DMA handling specifically. The current
> >-ac does have a fix for a couple of cases where an IDE reset on the promise
> >could hang the box dead. That may be the problem.
> >
> > > Is there anyway I can force the kernel to output more messages...maybe
> > that
> > > could help narrow down the problem?
> >
> >Ask [EMAIL PROTECTED] He may know the status of the promise support
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035Web: www.aslab.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
2.4.1-ac breaks parport_pc when CONFIG_PCI=n
2.4.1-ac breaks parport_pc in PCI-less configs. Attempting to 'make vmlinux' in 2.4.1-ac14 with # CONFIG_MODULES is not set # CONFIG_PCI is not set CONFIG_PARPORT=y CONFIG_PARPORT_PC=y results in drivers/parport/driver.o: In function `parport_pc_init_superio': drivers/parport/driver.o(.text.init+0x1311): undefined reference to `pci_devices' drivers/parport/driver.o(.text.init+0x1316): undefined reference to `pci_devices' drivers/parport/driver.o(.text.init+0x1323): undefined reference to `pci_devices' make: *** [vmlinux] Error 1 parport_pc_init_superio() contains a pci_for_each_dev loop. This macro references pci_devices which doesn't exist when CONFIG_PCI=n. 2.4.1 vanilla has a #ifdef CONFIG_PCI/#endif pair around the offending code, but 2.4.1-ac removes the #ifdef leading to the error above. Either the #ifdef needs to be put back in, or pci_for_each_dev should have a dummy #define in for !CONFIG_PCI, like many of the other pci functions. /Mikael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86 ptep_get_and_clear question
Linus Torvalds wrote: > It _could_ be that the TLB data actually also contains the pointer to > the place where it was fetched, and a "mark dirty" becomes > > read *ptr locked > val |= D > write *ptr unlock If you want to take it really far, it _could_ be that the TLB data contains both the pointer and the original pte contents. Then "mark dirty" becomes val |= D write *ptr > Now, I will agree that I suspect most x86 _implementations_ will not do > this. TLB's are too timing-critical, and nobody tends to want to make > them bigger than necessary - so saving off the source address is > unlikely. Then again, these hypothetical addresses etc. aren't part of the associative lookup, so could be located in something like an ordinary cache ram, with just an index in the TLB itself. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aic7xxx (and sym53c8xx) plans
On 02.15 Chip Salzenberg wrote: > According to J . A . Magallon: > > Might I suggest that Justin imitate the maintainers of lm_sensors, and > create a program (shell script, Perl program, whatever) that *creates* > a patch against any given Linux source tree? Obviously it could break > in the face of weird trees, but even minimal flexibility would save him > a lot of work ... So you can end with 1Mb of patch doing -#endif /* Hello */ +#endif Hello like happens in i2c-lm Better a real patch... -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.4.1-ac14 #1 SMP Thu Feb 15 16:05:52 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE DMA Problems...system hangs
>>I've not changed anything related to DMA handling specifically. The current
>>-ac does have a fix for a couple of cases where an IDE reset on the promise
>>could hang the box dead. That may be the problem.
I tried the new patches (2.4.1-ac13) and it seemed very stable. After
moving about 50GB of data to the raid5, the system crashed. here is the
syslog... (the system had been up for about 20 hours)
Feb 14 03:48:53 bertha kernel: hdo: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Feb 14 03:48:53 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Feb 14 19:35:52 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Feb 14 19:35:52 bertha kernel: hdo: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Feb 14 19:35:52 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Feb 14 20:13:06 bertha kernel: hdi: dma_intr: bad DMA status
Feb 14 20:13:06 bertha kernel: hdi: dma_intr: status=0x50 { DriveReady
SeekComplete }
Feb 15 01:26:34 bertha kernel: hdo: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Feb 15 01:26:34 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Feb 15 01:26:34 bertha kernel: hdo: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Feb 15 01:26:34 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Feb 15 01:26:38 bertha kernel: hdo: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Feb 15 01:26:38 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Feb 15 01:45:06 bertha kernel: hdo: dma_intr: status=0x53 { DriveReady
SeekComplete Index Error }
Feb 15 01:45:06 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Feb 15 01:45:06 bertha kernel: hdo: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Feb 15 01:45:06 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Feb 15 01:45:06 bertha kernel: hdo: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Feb 15 01:45:06 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Feb 15 01:54:01 bertha kernel: hdg: timeout waiting for DMA
Jasmeet
At 08:54 PM 2/14/2001 +, Alan Cox wrote:
> > >You will get horribly bad performance off raid5 if you have stripes on
> both
> > >hda/hdb or hdc/hdd etc.
> >
> > If I am reading this correctly, then by striping on both hda/hdb and
> > /hdc/hdd you mean that I have two drives per ide channel. In other words,
> > you think I have a Master and a Slave type of a setup? This is
> > incorrect. Each drive on the system is a master. I have 5 promise cards
>
>Ok then your performance should be fine (at least reasonably so, the lack
>of tagged queueing does hurt)
>
> > ide chanel, the penalty should not be much in terms of performance. Maybe
> > its just that the hdparam utility is not a good tool for benchamarking a
> > raid set?
>
>Its not a good raid benchmark tool but its a good indication of general
>problems.
>Bonnie is a good tool for accurate assessment.
>
> > disable DMA if its giving it a lot of problems, but it should not hang. I
> > have been experiencing this for quite a while with the newer
> > kernels. Should I try the latest ac13 patch? I glanced of the changes
> and
> > didnt seem like anything had changed regarding the ide subsystem.
>
>I've not changed anything related to DMA handling specifically. The current
>-ac does have a fix for a couple of cases where an IDE reset on the promise
>could hang the box dead. That may be the problem.
>
> > Is there anyway I can force the kernel to output more messages...maybe
> that
> > could help narrow down the problem?
>
>Ask [EMAIL PROTECTED] He may know the status of the promise support
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1-ac$x and timer oddities
On Thu, 15 Feb 2001 15:57:09 -0500 (EST), Richard A Nelson <[EMAIL PROTECTED]> wrote:
> The machine boots and runs for some time without problems, but then
> something makes the clock *very* jittery:
>
> * xscreensaver kicks in after almost no time (even betwixt quick
>keystrokes and in the middle of mouse movement), and the password prompt
>timer zips down to nothing post haste
> * neworking apps gets a time-out on almost all connections (netscape, ftp, etc)
> * It can take quite a while for focus to change after moving the mouse
> * The machine will hang (hard - CAD or SYSREQ B do nothing) after a
>variable amount of time (>8 hours)
>
> I think this may've even started at 2.4.0, but seems to have gotten
> worse recently.
This patch (from Vojtech Pavlik) might help. Alan included it in 2.2.19pre,
so I'm not sure why he didn't add it to 2.4ac as well.
If it doesn't apply cleanly, do it by hand.
Hope this helps,
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
--- linux-2.2.17/arch/i386/kernel/time.c.oldSat Oct 28 00:04:09 2000
+++ linux-2.2.17/arch/i386/kernel/time.cSat Oct 28 00:02:10 2000
@@ -452,6 +452,14 @@
count = inb_p(0x40);/* read the latched count */
count |= inb(0x40) << 8;
+ if (count > LATCH-1) {
+ outb_p(0x34, 0x43);
+ outb_p(LATCH & 0xff, 0x40);
+ outb(LATCH >> 8, 0x40);
+ count = LATCH - 1;
+ }
+
+
count = ((LATCH-1) - count) * TICK_SIZE;
delay_at_last_interrupt = (count + LATCH/2) / LATCH;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
32 bit writes to VRAM
Hello linux kernel listees I remember reading that doing 32-bit writes to VRAM is not a good idea because it somehow interferes with audio. Is this true or still the case? Thanks all, Daniel _ Get your FREE download of MSN Explorer at http://explorer.msn.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4.1-ac15
Ok this one should fix the non booting CPUs problem. Question of the day for the VM folks: If CPU1 is loading the exception tables for a module and CPU2 faults.. what happens 8) ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ 2.4.1-ac15 o Fix the non booting winchip/cyrix problem (me) | Nasty interaction with the vmalloc fix | wants a cleaner solution. This one is a hack | to get people up and running again o Fix typo in vfat changes(OGAWA Hirofumi) o Update scsi blacklist table (Karsten Hopp) o dscc4 wan driver update (Francois Romieu) o Fix clgenfb warning (Bryan Headley) 2.4.1-ac14 o Fix tulip problems introduced by in ac13(Manfred Spraul) o S/390x build fixes (Ulrich Weigand) o Fix off by one error in octagon driver (David Woodhouse) o Fix dasd driver for new queues (Holger Smolinksi) o Networking standards compliance fixes o Fix binary layout assumptions in sym53c416 (Arjan van de Ven) o tmpfs timestamps(Christoph Rohland) o Further mkdep changes (Keith Owens) o Fix 16bit vfat handling (OGAWA Hirofumi) o JIS nls fixes (OGAWA Hirofumi) o Handle more than 8 luns (Eric Youngdale, Doug Gilbert) o Minor scsi clean ups(Eric Youngdale) 2.4.1-ac13 o Fix pnic tulip problems (Manfred Spraul) o Fix USB printer read and poll problems (Johannes Erdfelt) o Fix parport pci list corrupt bug(Tim Waugh) o Fix sbpcd driver crashes(Paul Gortmaker) o Clarify the locking doc (Rusty Russell) o i810 audio doesnt need OSS (Jeff Garzik) o Fix vmalloc fault race (Mark Hemment) o Makedep fixes (Keith Owens) o Fix missing unlock_kernel on usb hub(Paul Mundt) o Fix smbfs+bigmem, buffer and listing bugs (Urban Widmark) o Merge tms380 isa token ring support (Jochen Friedrich) o Sigmatel change didnt help, removed (Jeff Garzik) 2.4.1-ac12 o Make tmpfs use link counts of 2 on directories (Christoph Rohland) o Update Documentation/sound/Introductions(Wade Hampton) o Fix bug in new tlb shootdown code (Ben LaHaise) o Add isa_* api to the Alpha (Richard Henderson) o Export down_trylock on Alpha(Richard Henderson) o Fix maestro3 build on ia64 (Bill Nottingham) 2.4.1-ac11 o Hack the setup code to do the right thing for (me) Cyrix processors. Cpuid on cyrix should now work o Change sigmatel codec inits (Jeff Garzik) o Revised TLB shootdown patch (Ben LaHaise) o Use pci quirks to handle the nonstandard irq(Andrey Panin) setup for VIA ACPI o If a user sets an io on the opl3sa2 assume they (me) mean it even if isapnp isnt turned off o Fix xmms cpu burn on i810 audio (Marcus Sundberg) o Fix pnic problems with tulip driver (Manfred Spraul) o Add pci skeleton driver (Jeff Garzik) o Fix vfat mishandling of 16bit characters(Kazuki Yasumatsu) o Fix syntax things found by his source code (Jean-Luc Leger) analyser o Fix pcmcia ixj build bug(Florian) o Remove dead via sound docs (Jeff Garzik) o add __dev_alloc_skb for drivers needing to force(Jeff Garzik) allocation types o Fix arcnet initializers (Jeff Garzik) o Fix various warnings(Keith Owens) o Further MPT fusion updates (Steve Ralston) o sock_alloc_send_skb fix (Manfred Spraul) o Fix signed/unsigned handling on 8139too (Jeff Garzik) o Document problem with old powertweak(Dave Jones) o s/controler/controller/ spelling fixes o S/390 build fixes (Neale Ferguson) 2.4.1-ac10 o Merge with Linus 2.4.2pre3 o More net driver clean up(Jeff Garzik) o Further maxiradio fix (Francois Romieu) o Lock reclaiming fixes (MCL) o Update ver_linux
Re: Manual SCSI bus reset?
German Gomez Garcia wrote: > I've got Plexwriter 12x10x32S attached to an onbard AIC7890 > (besides other things as three IBM UWSCSI harddisks, an SCSI ZIP and a > Pioneer DVD) and sometimes when recording a CD the Plexwriter fails at the > very end of the process (although the CD is recorded correctly) and it is > locked with no posibility to eject it (it seems that a failure while > reading from the DVD during on-the-fly recording is the cause). > > But if I reset the SCSI bus manually, that is trying to read from > a "reset-it CD", that is completely broken and makes the SCSI bus resets > itself, I can eject the CD from the Plexwriter. So I would like to know if > there is a way to do it without that trick. I've downloaded some utilities > for the SCSI generic driver, one of them should let you reset the bus (or > even just a single device) but it fails with "SCSI_RESET" not supported > and after reading through the docs it seems that the kernel (or should I > say the SCSI drivers) doesn't support this kind of reset. > > I would like to know if this is "kernel politics", "faulty > hardware", or just lazy programmers ;-), thanks and please CC the answer > to me as I'm not subscribed to this mailing list. Various distributions (e.g. RH 7.0) contain the SCSI mid-level patch that will permit the sg_reset utility to perform a scsi bus reset. [The same patch makes the scsi subsystem respect device reservations.] The patch originates from James Bottomley (see the linux-scsi list archive) and he has submitted a new version for the lk 2.4 tree recently. When first submitted, objections were raised to the concept of allowing users to do scsi bus resets (see same list archive). There is a chance that the required patch will go into main kernel tree soon. Doug Gilbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] oopsing in the reiser included in 2.4.2-pre2
Andres Salomon wrote: > I'm getting the following oopses, both apparently in the same place of > create_virtual_node(): > > Feb 15 16:03:32 infinity kernel: printing eip: > Feb 15 16:03:32 infinity kernel: c015aeaa > Feb 15 16:03:32 infinity kernel: Oops: > Feb 15 16:03:32 infinity kernel: CPU:0 > Feb 15 16:03:32 infinity kernel: EIP:0010:[create_virtual_node+698/1240] > Feb 15 16:03:32 infinity kernel: EFLAGS: 00010287 > Feb 15 16:03:32 infinity kernel: eax: ff3e ebx: ecx: c12efcc4 > edx: > Feb 15 16:03:32 infinity kernel: esi: c0c8f000 edi: 000b ebp: c0c8f124 > esp: c12efba0 > Feb 15 16:03:32 infinity kernel: ds: 0018 es: 0018 ss: 0018 > Feb 15 16:03:32 infinity kernel: Process rm (pid: 2756, stackpage=c12ef000) > Feb 15 16:03:32 infinity kernel: Stack: c0c8f000 c0c8f124 ff3e c12e > fcc4 03e8 0086 > Feb 15 16:03:32 infinity kernel:0016 000c c0a4b4a0 c0de > f018 c015d204 c12efcc4 > Feb 15 16:03:32 infinity kernel:c12efcc4 c12efcc4 > 0064 c12efcc4 > kFeb 15 16:03:32 infinity kernel: Call Trace: [dc_check_balance_leaf+84/344] [dc_ > check_balance+32/36] [check_balance+95/104] [fix_nodes+252/1064] [reiserfs_cut_f > rom_item+154/1120] [reiserfs_cut_from_item+481/1120] [reiserfs_do_truncate+780/1 > 052] > Feb 15 16:03:33 infinity kernel:[reiserfs_delete_object+35/56] [reiserfs > _delete_inode+72/148] [iput+167/340] [d_delete+76/104] [vfs_unlink+246/300] [sys > _unlink+167/284] [system_call+51/64] > Feb 15 16:03:33 infinity kernel: > Feb 15 16:03:33 infinity kernel: Code: 8b 42 14 ff d0 89 c2 03 16 89 16 8b 4c 24 > 38 83 c4 10 8b 81 > > Feb 15 17:23:47 infinity kernel: printing eip: > Feb 15 17:23:47 infinity kernel: c015aeaa > Feb 15 17:23:47 infinity kernel: Oops: > Feb 15 17:23:47 infinity kernel: CPU:0 > Feb 15 17:23:47 infinity kernel: EIP:0010:[create_virtual_node+698/1240] > Feb 15 17:23:47 infinity kernel: EFLAGS: 00010287 > Feb 15 17:23:47 infinity kernel: eax: 0038 ebx: ecx: c0c85cb0 > edx: > Feb 15 17:23:47 infinity kernel: esi: c0c59000 edi: 000d ebp: c0c59154 > esp: c0c85b00 > Feb 15 17:23:47 infinity kernel: ds: 0018 es: 0018 ss: 0018 > Feb 15 17:23:47 infinity kernel: Process BitchX (pid: 189, stackpage=c0c85000) > Feb 15 17:23:47 infinity kernel: Stack: c0c59000 c0c59154 0038 > 1008 c0c93ba0 c0c85c14 > Feb 15 17:23:47 infinity kernel:001a 000e c0c93ba0 c0cb > 0018 c015c4df c0c85cb0 > Feb 15 17:23:47 infinity kernel:c0c85ea0 0069 > 0101 1000 0282 > Feb 15 17:23:47 infinity kernel: Call Trace: [ip_check_balance+919/2816] [__allo > c_pages+219/720] [filemap_nopage+282/1032] [do_no_page+77/192] [check_balance+86 > /104] [fix_nodes+252/1064] [ide_set_handler+89/100] > Feb 15 17:23:47 infinity kernel:[reiserfs_insert_item+123/256] [reiserfs > _new_inode+855/1092] [reiserfs_mkdir+215/456] [vfs_mkdir+133/184] [sys_mkdir+114 > /180] [system_call+51/64] > Feb 15 17:23:47 infinity kernel: > Feb 15 17:23:47 infinity kernel: Code: 8b 42 14 ff d0 89 c2 03 16 89 16 8b 4c 24 > 38 83 c4 10 8b 81 > > This is w/ linux 2.4.2-pre2, Debian testing, and > ii reiserfsprogs 3.0.20001019-3 *PRE-RELEASE* Tools for ReiserFS filesystems > > Is this a known issue? What would you folks recommend I do? > -- > "... being a Linux user is sort of like living in a house inhabited > by a large family of carpenters and architects. Every morning when > you wake up, the house is a little different. Maybe there is a new > turret, or some walls have moved. Or perhaps someone has temporarily > removed the floor under your bed." - Unix for Dummies, 2nd Edition > -- found in the .sig of Rob Riggs, [EMAIL PROTECTED] do not reply this post please, if you know how to fix problem ( alan please help ) please email to him directly: [EMAIL PROTECTED] I just reply to kernel mail list :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
japanese keyboards
Recently I got some more detailed information on Japanese keyboards and their scancodes. Maybe there are Japanese readers here who can look at http://www.win.tue.nl/~aeb/linux/kbd/scancodes-3.html#ss3.3 and correct what is wrong? Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Samba seems to be broken in 2.4.1-ac14
> Samba appears to be broken in 2.4.1-ac14 > No odd dmesg, modules load fine just nothing is there. Umm thats not enough info to help. What file system are you serving, explain 'nothing there' - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Samba seems to be broken in 2.4.1-ac14
Samba appears to be broken in 2.4.1-ac14 No odd dmesg, modules load fine just nothing is there. Works in 2.4.1-ac7 just fine. Versions follow Samba version 2.0.7 If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux the-penguin 2.4.1-ac14 #4 Thu Feb 15 09:51:30 PST 2001 i686 unknown Gnu C 2.95.3 Gnu make 3.79.1 binutils 2.10.1.0.2 util-linux 2.10q modutils 2.4.1 e2fsprogs 1.19 PPP2.4.0 Linux C Library2.2.1 Dynamic linker (ldd) 2.2.1 Procps 2.0.7 Net-tools 1.57 Console-tools 0.2.3 Sh-utils 2.0.11 Modules Loaded nls_cp437 nls_iso8859-1 smbfs ipt_REJECT iptable_filter ip_tables mga ipx agpgart emu10k1 soundcore 3c59x -- *--* Mail: [EMAIL PROTECTED] *--* Voice: 425.739.4247 *--* Fax: 425.827.9577 *--* HTTP://www.otak-k.com/~lawrence/ -- - - - - - - O t a k i n c . - - - - - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.1,-ac9,-ac13: lockup after "now booting the kernel"
Hello, when trying to boot kernel 2.4.1, 2.4.1-ac9 or 2.4.1-ac13, I get lockups right after the message "now booting kernel". Kernel 2.4.0-test10 ist booting ok on the machine. Rik van Riel suspected on #kernelnewbies this might be a bug in the CPU detection routine. The system in question has an Intel 430HX chipset (Gigabyte 586HX2 board), 104 MB RAM und an AMD K6-III CPU, though the old BIOS detects is as an ordinary K6. Testing vanilla 2.4.1 with or withour MTRR support made no difference. Snippets of .config, 2.4.0-test10 dmesg, and /proc/cpuinfo are included below. Any ideas what might be wrong? Thanks in advance, Florian P.S.: Please Cc me in replies, as I am not subscribed to linux-kernel. --- .config --- ONFIG_MK6=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_ALIGNMENT_16=y CONFIG_X86_TSC=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_NOHIGHMEM=y --- --- --- --- /proc/cpuinfo --- processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 9 model name : AMD-K6(tm) 3D+ Processor stepping: 1 cpu MHz : 400.916 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow k6_mtrr bogomips: 799.53 --- - --- --- dmesg --- Linux version 2.4.0 ([EMAIL PROTECTED]) (gcc version 2.95.2 2220 (Debi an GNU/Linux)) #1 Thu Jan 18 20:48:28 CET 2001 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 0001 @ (reserved) BIOS-e820: 0670 @ 0010 (usable) On node 0 totalpages: 26624 zone(0): 4096 pages. zone(1): 22528 pages. zone(2): 0 pages. Kernel command line: BOOT_IMAGE=1 ro root=303 BOOT_FILE=/boot/vmlinuz-2.4.0 Initializing CPU#0 Detected 400.916 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 799.53 BogoMIPS Memory: 102512k/106496k available (1009k kernel code, 3596k reserved, 382k data, 196k init, 0k highmem) Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) CPU: Before vendor init, caps: 008021bf 808029bf , vendor = 2 Enabling new style K6 write allocation for 104 Mb CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line) CPU: L2 Cache: 256K (32 bytes/line) CPU: After vendor init, caps: 008021bf 808029bf 0002 CPU: After generic, caps: 008021bf 808029bf 0002 CPU: Common caps: 008021bf 808029bf 0002 CPU: AMD-K6(tm) 3D+ Processor stepping 01 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: AMD K6 - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
On Thu, 15 Feb 2001, Bill Wendling wrote: > With the horrid (pro-Microsoft) Aschroft in office, who knows what MS > can get away with. Not to mention all of the pro-business, anti-human > cronies in Washington running the Presidency (cause \/\/ just can't do > it). Most of the pro-business people in the Bush administration are also anti-regulation. I think the net effect on free software will be a wash. While there wouldn't be any Microsoft antitrust case, there probably wouldn't be any WIPO, either... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
Also sprach Alan Olsen: } I expect the next thing that will happen is that they will get patents on } key portions of their protocols and then start enforcing them. } Which protocols would that be? TCP/IP wasn't invented by them. } I wonder what kind of law they will try to push to outlaw Open Source? } With the horrid (pro-Microsoft) Aschroft in office, who knows what MS can get away with. Not to mention all of the pro-business, anti-human cronies in Washington running the Presidency (cause \/\/ just can't do it). -- || Bill Wendling[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] network driver updates
David Hinds wrote: > > On Thu, Feb 15, 2001 at 10:49:22PM +1100, Andrew Morton wrote: > > > > Now, the thing I don't understand about David's design is the > > final one. What 3c575_cb does is: > > > > CONFIG_HOTPLUG=y, MODULE=true > > If the hardware isn't there, register the driver and > > hang around. > > > > Why? > > Merely that I was trying to disassociate the concepts of module > loading and device probing, and I thought it was most consistent to > then allow people to load modules whenever they want, whether or not a > device was present. Fair enough. Thanks. Another scenario may be where (say) a network driver is modprobed from a hotpluggable disk controller. You want to be able to load the netdriver, pop out the disk controller and then insert the network card. Or vice-versa - load a parallel port driver across NFS then pull the network card and push the parallel port card. Could use local disks for this, of course. hmm.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ATA100 patch source code:
it's final version, but why it's not work ? diff -urN linux-2.4.1-p8-pristine/Documentation/Configure.help linux-2.4.1-p8/Documentation/Configure.help --- linux-2.4.1-p8-pristine/Documentation/Configure.helpThu Jan 18 01:20:48 2001 +++ linux-2.4.1-p8/Documentation/Configure.help Thu Jan 18 02:42:37 2001 @@ -673,6 +673,25 @@ If in doubt, say N. +PnP BIOS DMA Forced Enabled +CONFIG_BLK_DEV_IDEDMA_FORCED + If you say Y here, and your DMA original Triton I/II, VIA, ALI + fail to setup the DMA address space and it used to work in 2.0.34 + with the Jumbo Patch series or works in 2.0.39, then you should + consider enabling this option. + + If in doubt, say N. + +Attempt to HACK around Chipsets that TIMEOUT (EXPERIMENTAL) +CONFIG_BLK_DEV_IDEDMA_TIMEOUT + If you say Y here, this is a NASTY UGLY HACK! + + We have to issue an abort and requeue the request DMA engine got + turned off by a goofy ASIC, and we have to clean up the mess, and + here is as good as any. Do it globally for all chipsets. + + If in doubt, say N. + Boot off-board chipsets first support CONFIG_BLK_DEV_OFFBOARD Normally, IDE controllers built into the motherboard (on-board @@ -780,18 +799,18 @@ SAY NO! -AMD7409 chipset support -CONFIG_BLK_DEV_AMD7409 - This driver ensures (U)DMA support for the AMD756 Viper chipset. +AMD74XX chipset support +CONFIG_BLK_DEV_AMD74XX + This driver ensures (U)DMA support for the AMD756/765 Viper chipset. If you say Y here, you also need to say Y to "Use DMA by default when available", above. - Please read the comments at the top of drivers/ide/amd7409.c + Please read the comments at the top of drivers/ide/amd74xx.c If unsure, say N. AMD Viper ATA-66 Override support (WIP) -CONFIG_AMD7409_OVERRIDE +CONFIG_AMD74XX_OVERRIDE This option auto-forces the ata66 flag. This effect can be also invoked by calling "idex=ata66" If unsure, say N. diff -urN linux-2.4.1-p8-pristine/drivers/ide/Config.in linux-2.4.1-p8/drivers/ide/Config.in --- linux-2.4.1-p8-pristine/drivers/ide/Config.in Fri Dec 29 14:07:22 2000 +++ linux-2.4.1-p8/drivers/ide/Config.inThu Jan 18 02:42:37 2001 @@ -45,15 +45,18 @@ bool 'Generic PCI bus-master DMA support' CONFIG_BLK_DEV_IDEDMA_PCI bool 'Boot off-board chipsets first support' CONFIG_BLK_DEV_OFFBOARD dep_bool ' Use PCI DMA by default when available' CONFIG_IDEDMA_PCI_AUTO $CONFIG_BLK_DEV_IDEDMA_PCI + dep_bool ' PnP BIOS DMA Forced Enabled' CONFIG_BLK_DEV_IDEDMA_FORCED +$CONFIG_BLK_DEV_IDEDMA_PCI define_bool CONFIG_BLK_DEV_IDEDMA $CONFIG_BLK_DEV_IDEDMA_PCI dep_bool ' ATA Work(s) In Progress (EXPERIMENTAL)' CONFIG_IDEDMA_PCI_WIP $CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_EXPERIMENTAL dep_bool ' Good-Bad DMA Model-Firmware (WIP)' CONFIG_IDEDMA_NEW_DRIVE_LISTINGS $CONFIG_IDEDMA_PCI_WIP + dep_bool ' Attempt to HACK around Chipsets that TIMEOUT (WIP)' +CONFIG_BLK_DEV_IDEDMA_TIMEOUT $CONFIG_IDEDMA_PCI_WIP + dep_bool 'AEC62XX chipset support' CONFIG_BLK_DEV_AEC62XX $CONFIG_BLK_DEV_IDEDMA_PCI dep_mbool ' AEC62XX Tuning support' CONFIG_AEC62XX_TUNING $CONFIG_BLK_DEV_AEC62XX dep_bool 'ALI M15x3 chipset support' CONFIG_BLK_DEV_ALI15X3 $CONFIG_BLK_DEV_IDEDMA_PCI dep_mbool ' ALI M15x3 WDC support (DANGEROUS)' CONFIG_WDC_ALI15X3 $CONFIG_BLK_DEV_ALI15X3 - dep_bool 'AMD Viper support' CONFIG_BLK_DEV_AMD7409 $CONFIG_BLK_DEV_IDEDMA_PCI - dep_mbool ' AMD Viper ATA-66 Override (WIP)' CONFIG_AMD7409_OVERRIDE $CONFIG_BLK_DEV_AMD7409 $CONFIG_IDEDMA_PCI_WIP + dep_bool 'AMD Viper support' CONFIG_BLK_DEV_AMD74XX +$CONFIG_BLK_DEV_IDEDMA_PCI + dep_mbool ' AMD Viper ATA-66 Override (WIP)' CONFIG_AMD74XX_OVERRIDE +$CONFIG_BLK_DEV_AMD74XX $CONFIG_IDEDMA_PCI_WIP dep_bool 'CMD64X chipset support' CONFIG_BLK_DEV_CMD64X $CONFIG_BLK_DEV_IDEDMA_PCI dep_bool 'CY82C693 chipset support' CONFIG_BLK_DEV_CY82C693 $CONFIG_BLK_DEV_IDEDMA_PCI dep_bool 'Cyrix CS5530 MediaGX chipset support' CONFIG_BLK_DEV_CS5530 $CONFIG_BLK_DEV_IDEDMA_PCI @@ -147,7 +150,7 @@ if [ "$CONFIG_IDE_CHIPSETS" = "y" -o \ "$CONFIG_BLK_DEV_AEC62XX" = "y" -o \ "$CONFIG_BLK_DEV_ALI15X3" = "y" -o \ - "$CONFIG_BLK_DEV_AMD7409" = "y" -o \ + "$CONFIG_BLK_DEV_AMD74XX" = "y" -o \ "$CONFIG_BLK_DEV_CMD640" = "y" -o \ "$CONFIG_BLK_DEV_CMD64X" = "y" -o \ "$CONFIG_BLK_DEV_CS5530" = "y" -o \ diff -urN linux-2.4.1-p8-pristine/drivers/ide/Makefile linux-2.4.1-p8/drivers/ide/Makefile --- linux-2.4.1-p8-pristine/drivers/ide/MakefileFri Dec 29 14:07:22 2000 +++ linux-2.4.1-p8/drivers/ide/Makefile Thu Jan 18 02:42:37 2001 @@ -28,7 +28,7 @@ ide-obj-$(CONFIG_BLK_DEV_AEC62XX) += aec62xx.o ide-obj-$(CONFIG_BLK_DEV_ALI14XX) += ali14xx.o
Linux 2.2.19pre13
This is mostly again to make sure everyone is in sync across the various ports and those that are fully merged all compile. Alan 2.2.19pre13 o Fix up missing bits of Soohoon Lee's exec patch (Michael Jaegerman) | not sure where some bits of it escaped too... o Revert serial driver locking patch (me) | Seems to be causing crashes o PPC BUG(), and other compile fixes needed (Benjamin Herrenschmidt) o ide_pmac_init to fix IDE probe power off(Benjamin Herrenschmidt) o atyfb128 and serial for pmac(Benjamin Herrenschmidt) o Workaround early imac firmware bug (Benjamin Herrenschmidt) o Ensure task is running in mm faults (Roger Larsson) | from 2.4 o Fix nfs cache bug (Neil Brown) o Further config.in cleanups/fixing (Andrzej Krzysztofowicz) o Clean up tulip changes remove accidental fix(Jeff Garzik) reversions o Update defconfig(Jeff Garzik) o Update usb printer driver in 2.2 to match 2.4 (Randy Dunlap) o Fix posix compliance on sockopts 2.2.19pre12 o Update the DAC960 driver(Leonard Zubkoff) o Small PPC fixes (Benjamin Herrenschmidt) o Document irda options config(Steven Cole) o Small isdn fixes/obsolete code removal (Kai Germaschewski) o Fix alpha kernel builds (Michal Jaegermann) o Update ver_linux to match the 2.4 one (Steven Cole) o AVM isdn driver updates (Carsten Paeth) o ISDN capi/ppp fixes (Kai Germaschewski) 2.2.19pre11 o Corrected version of ipc/shm.c fix (Christoph Rohland) o Update/cleanup starfire (Ion Badulescu) o Update isdn makefiles (Kai Germaschewski) o Eicon driver updates/new driver (Armin Schindler) | code o Hysdn driver(Werner Cornelius) o Hisax updates (Kai Germaschewski) 2.2.19pre10 o Update aic7xxx driver to 5.1.33 (Doug Ledford) o Revert shm change - its unsafe (Richard Nelson) o Update sunrpc code, add rpc ping congestion (Trond Myklebust) checks o Fix wrong kfree in cosa driver (Jan Kasprzak) o NFS client fixes(Trond Myklebust) o Better dcache/inode hashes (Dave Miller) o Fix missing skb->protocol init in AX.25 (Thomas Osterried) o EEpro100 reporting fix as per 2.4 (Ion Badulescu) o Starfire ethernet driver(Don Becker, Ion Badulescu, Jeff Garzik, ...) o Memory handling fixes for ISDN core code(Kai Germaschewski) o ISDN module locking fixes (Kai Germaschewski) o Fix ISDN modem profile reading (Kai Germaschewski) o Fix missing mark_bh calls in isdn (Kai Germaschewski) o Fix problems make xconfig has with config (Andrzej Krzysztofowicz) o Clean up isdn to user new __init etc(Kai Germaschewski) 2.2.19pre9 o Merge all the pending NFS server fixes (Neil Brown) o Neil becomes NFS server maintainer (Neil Brown) o Update to aic7xxx 5.1.32(Doug Ledford) o Fix cs89x0 media selection (Frank Copeland) o Tidy APM stuff, make buggy bios selector tighter(Stephen Rothwell) o Fix i2o config typo (YOSHIMURA Keitaro) o Network updates, fix possible classifier hang (Dave Miller) o Sparc updates (nfs compat, syscalls)(Dave Miller) o Sparc watchdog driver (Eric Brower) o Remove experimental tag on QoS code (Dave Miller) o Move dumpable extra logic into binfmt avoiding (Solar Designer) other changes to arch code. Back out old stuff o Fix sysctl miscastings from signed/unsigned (Greg Kroah-Hartmann) o Alpha OSF syscall remove error printk o Don't trust IRQ routing on the ruffian ARC (Ivan Kokshaysky) 2.2.19pre8 o Add support for ICS1893 PHY to sis900 (L C Chang) o Fix typo in nautilus code (Tom Vier) o Clean up usb bandwidth messages (Randy Dunlap) o USB ACM loosen up end point rules (Randy Dunlap) o Fix tty module count corruptions(Maciej Rozycki) o i2o block
RE: finding Tekram SCSI dc395U linux patch driver:
Hi, On 15-Feb-01 Thomas Lau wrote: > hey, I found this driver on mandrake kernel sources, it's ac3, but I > need ac14 code, also, why still not port this driver into kernel? > the patch file already released 1 years ago Have you checked http://www.garloff.de/kurt/linux/dc395/index.html there ist a driver Version 1.32 (2000-12-02). Regards Juergen Schoew - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
How to optimize K6-2+ CPU in kernel?
anyone know how? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86 ptep_get_and_clear question
Manfred Spraul wrote: > > I just benchmarked a single flush_tlb_page(). > > Pentium II 350: ~ 2000 cpu ticks. > Pentium III 850: ~ 3000 cpu ticks. > I forgot the important part: SMP, including a smp_call_function() IPI. IIRC Ingo wrote that a local 'invplg' is around 100 ticks. -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86 ptep_get_and_clear question
Linus Torvalds wrote:
>
> In article <[EMAIL PROTECTED]>,
> Jamie Lokier <[EMAIL PROTECTED]> wrote:
> >> > << lock;
> >> > read pte
> >> > if (!present(pte))
> >> >do_page_fault();
> >> > pte |= dirty
> >> > write pte.
> >> > >> end lock;
> >>
> >> No, it is a little more complicated. You also have to include in the
> >> tlb state into this algorithm. Since that is what we are talking about.
> >> Specifically, what does the processor do when it has a tlb entry allowing
> >> RW, the processor has only done reads using the translation, and the
> >> in-memory pte is clear?
> >
> >Yes (no to the no): Manfred's pseudo-code is exactly the question you're
> >asking. Because when the TLB entry is non-dirty and you do a write, we
> >_know_ the processor will do a locked memory cycle to update the dirty
> >bit. A locked memory cycle implies read-modify-write, not "write TLB
> >entry + dirty" (which would be a plain write) or anything like that.
> >
> >Given you know it's a locked cycle, the only sensible design from Intel
> >is going to be one of Manfred's scenarios.
>
> Not necessarily, and this is NOT guaranteed by the docs I've seen.
>
> It _could_ be that the TLB data actually also contains the pointer to
> the place where it was fetched, and a "mark dirty" becomes
>
> read *ptr locked
> val |= D
> write *ptr unlock
>
Jamie wrote "one of my scenarios", that's the other option ;-)
> Now, I will agree that I suspect most x86 _implementations_ will not do
> this. TLB's are too timing-critical, and nobody tends to want to make
> them bigger than necessary - so saving off the source address is
> unlikely. Also, setting the D bit is not a very common operation, so
> it's easy enough to say that an internal D-bit-fault will just cause a
> TLB re-load, where the TLB re-load just sets the A and D bits as it
> fetches the entry (and then page fault handling is an automatic result
> of the reload).
>
But then the cpu would support setting the D bit in the page directory,
but it doesn't.
Probably Kanoj is right, the current code is not guaranteed by the
specs.
But if we change the interface, could we think about the poor s390
developers?
s390 only has a "clear the present bit in the pte and flush the tlb"
instruction.
>From your other post:
>pte = ptep_get_and_clear(page_table);
>flush_tlb_page(vma, address);
>+ pte = ptep_update_after_flush(page_table, pte);
What about one arch specific
pte = ptep_get_and_invalidate(vma, address, page_table);
On i386 SMP it would
{
pte = *page_table_entry;
if(!present(pte))
return pte;
lock; andl 0xfffe, *page_table_entry;
flush_tlb_page();
return *page_table_entry | 1;
}
>
> The "gather" operation could possibly be improved to make the other
> CPU's do useful work while being shot down (ie schedule away to another
> mm), but that has it's own pitfalls too.
>
IMHO scheduling away is the best long term solution.
Perhaps try to schedule away, just to improve the probability that
mm->cpu_vm_mask is clear.
I just benchmarked a single flush_tlb_page().
Pentium II 350: ~ 2000 cpu ticks.
Pentium III 850: ~ 3000 cpu ticks.
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Linux stifles innovation...
On Thu, 15 Feb 2001 [EMAIL PROTECTED] wrote: > > "I'm an American, I believe in the American Way, I worry if the > government encourages open source, and I don't think we've done > enough education of policy makers to understand the threat." > It is not American to steal. The first "Flight Simulator" was published on the PROGRAM EXCHANGE BBS System in the '70s. I know, with the help of some Turbo Pascal wizards for the graphics, and my state-machine, written in assembly, I did it. The original idea was started, and ran in text-mode under CP/M. The first flight simulator was also very difficult to fly. This is because I incorporated all the quirks of airplanes, spiral instability, long-mode oscillations, adverse yaw, etc. I had just gotten my Commercial Pilot's license at the time and joined AIAA. Every quirk I could find was built into that simulator. When M$ copied it, their first releases were also difficult to fly. Eventually, they understood enough about the code so that they were able to remove the instabilities and any kid could fly it. Their introduction into "games" brought them enough money to do anything they wanted, including continuing to steal. Again, this is not "American". This is Microsoft. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] to deal with bad dev->refcnt in unregister_netdevice()
Update on the "unregister_netdevice" bug ... Arnaldo Carvalho de Melo has been valiantly trying in his scarce free time to find the cause. I haven't been able to hunt effectively because I don't really understand the networking code; however I have been experimenting to see what are the exact conditions under which the failure occurs. I modified my kernel to print dev->refcnt in /proc/net/dev so that I could see what the refcnt of eth0 is at any given moment. One of the more interesting experiment logs is appended below. Experimentation seems to show 1) It happens when ipx is used, specifically when auto_interface=on and auto_primary=on 2) It happens only or especially when using DHCP 3) It happens only to PCMCIA ethernet cards Thomas Hood jdthood_AT_yahoo.co.uk Linux 2.4.1-ac10 /etc/pcmcia/network disabled with an 'exit 0' command refcnt message --- -- --- (boot) 0 (I inserted Xircom card) 1 ifconfig eth0 up 2 ipx_configure --auto_interface=on --auto_primary=on2 ifconfig eth0 down 0 "Freeing alive device c127ac8c, eth0" cardctl eject? "unregister_netdevice: waiting for eth0 to become free. Usage count = 0 Message from syslogd@thanatos at Wed Feb 14 12:51:26 2001 ... thanatos kernel: unregister_netdevice: waiting for eth0 to become free. Usage count = 0" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MTU and 2.4.x kernel
> > I ran DNS reliably over AX.25 networks. They have an MTU of 216. They work. > > 512 is maximal message size, which is transmitted without troubles, > hardwired to almost all the datagram protocols. Message size != MTU. DNS doesnt use DF. In fact DNS can even fall back to TCP. > > > B. Accoutning, classification, resource reervation does not work on > > >fragmented packets. > > Thats a bug in accounting classification and resource reservation. > Sorry? It is bug in client mtu selection. Functions above are impossible > on fragmented packet even in theory. And because of A, if client uses mtu > 296, it cannot use 100% of emerging and existing IP functions. Tragic. You are required to accept existing realities and degrade nicely. > > Over a 9600 mobile phone link mtu 296 makes measurable differences to the > > latency when mixing a mail fetch with typing. > > It is myth. Changing mtu until ~4K does not affect latency, it stays on 4K/bw. Please tell that to my phone. > > Over a radio link where > > error rate causes exponential increases in probability of packet loss as > > Another myth. All they do error correction and have so high latency, > that _increasing_ mtu only helps. And helps a lot. No. There is large amounts of real world hardware that this is not true for. You cannot do good FEC on a narrow band link. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.x/alpha/ALI chipset/IDE problems summary Re: 2.4.1 not fullysane on Alpha - file systems
On Thu, 15 Feb 2001, Michal Jaegermann wrote: > Like I wrote - I did not get to locks on fsck but then stuff was weird > and if I would press sufficiently long maybe I would. I still had some > use for my file systems so I did not try hard enough. Maybe we need > black hens on the top of the magic quoted above? You bring the black hens, I've got the goats, red silk ribbon, and candles ... > > I don't care about X on this system, all that much, honestly. > > "Technicolor" thingy seems to be side effect of your particular > graphics card, no? I gotta think that something Very Bad (tm) is happening at kernel level, like something getting overrun in the IDE subsystem, and overwriting into other areas of memory. *shrug* -- John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MTU and 2.4.x kernel
Rick Jones wrote: > > > Default of 536 is sadistic (and apaprently will be changed eventually > > to stop tears of poor people whose providers not only supply them > > with bogus mtu values sort of 552 or even 296, but also jailed them > > to some proxy or masquearding domain), but it is still right: IP > > with mtu lower 576 is not full functional. > > I thought that the specs said that 576 was the "minimum maximum" > reassemblable IP datagram size and not a minimum MTU. RFC 1191 (Path MTU Discovery as it happens): PlateauMTUComments Reference -- --- - 65535 Official maximum MTU RFC 791 65535 Hyperchannel RFC 1044 65535 32000 Just in case 17914 16Mb IBM Token Ring ref. [6] 17914 8166 IEEE 802.4RFC 1042 8166 4464 IEEE 802.5 (4Mb max) RFC 1042 4352 FDDI (Revised)RFC 1188 4352 (1%) 2048 Wideband Network RFC 907 2002 IEEE 802.5 (4Mb recommended) RFC 1042 2002 (2%) 1536 Exp. Ethernet NetsRFC 895 1500 Ethernet Networks RFC 894 1500 Point-to-Point (default) RFC 1134 1492 IEEE 802.3RFC 1042 1492 (3%) 1006 SLIP RFC 1055 1006 ARPANET BBN 1822 1006 576X.25 Networks RFC 877 544DEC IP Portal ref. [10] 512NETBIOS RFC 1088 508IEEE 802/Source-Rt Bridge RFC 1042 508ARCNETRFC 1051 508 (13%) 296Point-to-Point (low delay)RFC 1144 296 68Official minimum MTU RFC 791 Jordan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [drizzt.dourden@iname.com: USB mass storage and USB message]
On Thu, Feb 15, 2001, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I'm using the usb-uhci core with the 8200e storage drivers. I don't why > the kernel logs the next message: > > uhci.c: root-hub INT complete: port1: 495 port2: 58a data: 4 > uhci.c: root-hub INT complete: port1: 495 port2: 58a data: 4 > uhci.c: root-hub INT complete: port1: 495 port2: 58a data: 4 > uhci.c: root-hub INT complete: port1: 495 port2: 58a data: 4 > uhci.c: root-hub INT complete: port1: 495 port2: 58a data: 4 > uhci.c: root-hub INT complete: port1: 495 port2: 58a data: 4 > (well a lot of them) If it says, uhci.c, then it would be uhci.o. If it says usb-uhci.c, then it's usb-uhci.o. Your statement conflicts with the log you pasted. Which one is it? > The kernel is 2.4.1, the hardware a Celeron 566 with a VIA chipset, with the > next cat /proc/pci > > This doesn't hapeng with the uhci module. > > I was testing the cd writer with cdrecord at x1 speed( well, at least it can > finish th simulation, because with the pre series, it can finished). Did you get an oops? Is the khubd process zombied? JE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.x/alpha/ALI chipset/IDE problems summary Re: 2.4.1 not fully sane on Alpha - file systems
On Thu, Feb 15, 2001 at 03:15:01PM -0500, John Jasen wrote: > > I retried the mysticism and incantations (d -l 801feac d) at the srm > prompt, and the machine locked on fsck, under kernel 2.4.1-ac13. Like I wrote - I did not get to locks on fsck but then stuff was weird and if I would press sufficiently long maybe I would. I still had some use for my file systems so I did not try hard enough. Maybe we need black hens on the top of the magic quoted above? > I don't care about X on this system, all that much, honestly. "Technicolor" thingy seems to be side effect of your particular graphics card, no? Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OTP] RE: Linux stifles innovation...
On Thu, 15 Feb 2001, Alan Olsen wrote: > I expect the next thing that will happen is that they will get patents on > key portions of their protocols and then start enforcing them. > They can only patent their own creations. I'd like to see them try to get patents for their "extensions" to TCP or some other bastardization they've made to the various standard protocols. They'd be isolating themselves out of the market in a heartbeat. Who would be willing to pay for their breaking of standards? Their existing user base perhaps but not many more than that, save the few companies that decided it was in their best interests to pay the fee. More than likely they'll kill their own market they go that route. > With the various IP laws that have been passed in the last few years in > the US (and through WIPO) they will have a large brick to try and hit us > with. (IMHO these laws pretty much allow large entities to buy their > markets and are the biggest threat to innovation out there.) > OK, WIPO? Never heard of it. Got a URL? > Actually I am sending copies of his rant out to all of my friends who > still use Microsoft products. > hehe, already done that. Got some GOOD feedback off of that. So far 5 of the 10 I've emailed have responded in rage. Don't know too many humans that take kindly to being politely called an idiot in public, which is basically what M$ has been saying. "You're an idiot if you use Linux because Linux stifles inovation. Thus you are a pawn of the Linux movement which makes you part of the threat to intellectual property (Read this as you are a part of the threat to my bottom line. > If that is the attitude they have towards their customers and the > development community then it is time to get away while you still can. > Microsoft relies rather heavily on the belief that their business model has locked their client base in. What they don't understand is that, the "movement" of Opensource as they so call it, will start to cost them even MORE money than we do now. Why? because as more people get pissed off at the mindframe of M$ and realize that there are comparable OpenSource products out there, they'll be leaving M$. Admittedly this will start out as a small trickle, taking place over the next say 2 years. Microsoft needs to wake up to the understanding that the only way they will survive if the "Linux movement" (their words not mine) gets ticked off enough to truly start a concerted effort to make open source based replacements for Microsoft products, is to play nice with Linux and OpenSource products in general, they're dead in the water. > Of course, the reason I moved over all my development to Linux in the > first place what that I did not have to worry about being screwed over by > a "corporate strategy" or have the license terms changed on the next > release or have to pay for something over and over again in the vain > attempt to get something to work. > I started with Linux in 94 because I thought it was a replacement for Windows. Even back then, when Linux was still a dog of a kernel, it seemed to exude power and inovation. (My personal belief so no one flame me for that line.) > With Linux I can read the source. There are no hidden interfaces. No > mystical archane knowledge that you have to pay the company to learn get > the job done. It is all there and it all works. (Or if it does not, then > the tools exist to make it work.) > Microsoft relies HEAVILY on the changes they've made in their product lines to hide details from the consumer, some of whom NEED to know those changes. This is just a case of a company that's chosen a business model that can't compete with it's exact opposite. They know it, we know it, and their advantage right now is that the general public DOESN'T know it. I do feel kind of sorry for Microsoft. Their attornies and marketing force must have tons of ulcers trying to figure out how to beat (not just co-exist with) a product that has no clearly defined (read suable) human owner, and that changes on an hourly basis like the sea changes the layout of the sand on a beach. Severely tough to fight something like that. > I wonder what kind of law they will try to push to outlaw Open Source? > > If this is his idea of "The American Way" then he needs to take a basic > civics course. He obviously slept through the last one. > He wasn't sleeping. He was down the hall in Corporate Raiding 101. David D.W. Downey - RHCE Consulting Engineer Ensim Corporation - Sunnyvale, CA - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MTU and 2.4.x kernel
Hello! > I ran DNS reliably over AX.25 networks. They have an MTU of 216. They work. Please, Alan, distinguish two things: "works" and "works, until I ask X". The second is equal to "does not". 512 is maximal message size, which is transmitted without troubles, hardwired to almost all the datagram protocols. > > B. Accoutning, classification, resource reervation does not work on > >fragmented packets. > > Thats a bug in accounting classification and resource reservation. Sorry? It is bug in client mtu selection. Functions above are impossible on fragmented packet even in theory. And because of A, if client uses mtu 296, it cannot use 100% of emerging and existing IP functions. > Over a 9600 mobile phone link mtu 296 makes measurable differences to the > latency when mixing a mail fetch with typing. It is myth. Changing mtu until ~4K does not affect latency, it stays on 4K/bw. >Over a radio link where > error rate causes exponential increases in probability of packet loss as Another myth. All they do error correction and have so high latency, that _increasing_ mtu only helps. And helps a lot. When you have 22Kbit link and 2 second latency, mtu must be large. > NetROM is MTU 128. I wrote "<". 8) > If you want to argue that a MTU < 512 is hard to deal with by MTU discovery > you are right. So when you get a 'must fragment' below 512, just turn DF off > for that socket. It is exactly, which we make, Alan. 8) > I repeat my request. Cite the RFC number and line. I repeat my reply: it is sillogism of A and B. See above. You can write RFC yourself. 8) Alexey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux stifles innovation...
"I'm an American, I believe in the American Way, I worry if the government encourages open source, and I don't think we've done enough education of policy makers to understand the threat." He believes in the "Golden Rule" too... Can you say "NSA" or "Secure Linux"? I believe they are truly worried. It's all about money and control, both of which they are leaking badly. I have faith in the policy makers at large. A certain judge understood M$'s policy all to well. A lot of parallels can be drawn between this latest volley and their current legal predicament. I'm rambling, but this has got me a bit upset. -- Dave --- Dave Helton, KD0YU- [EMAIL PROTECTED] - http://www.kd0yu.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[drizzt.dourden@iname.com: USB mass storage and USB message]
- Forwarded message from [EMAIL PROTECTED] - Date: Thu, 15 Feb 2001 21:40:28 +0100 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: USB mass storage and USB message I'm using the usb-uhci core with the 8200e storage drivers. I don't why the kernel logs the next message: uhci.c: root-hub INT complete: port1: 495 port2: 58a data: 4 uhci.c: root-hub INT complete: port1: 495 port2: 58a data: 4 uhci.c: root-hub INT complete: port1: 495 port2: 58a data: 4 uhci.c: root-hub INT complete: port1: 495 port2: 58a data: 4 uhci.c: root-hub INT complete: port1: 495 port2: 58a data: 4 uhci.c: root-hub INT complete: port1: 495 port2: 58a data: 4 (well a lot of them) The kernel is 2.4.1, the hardware a Celeron 566 with a VIA chipset, with the next cat /proc/pci This doesn't hapeng with the uhci module. I was testing the cd writer with cdrecord at x1 speed( well, at least it can finish th simulation, because with the pre series, it can finished). > PCI devices found: > Bus 0, device 0, function 0: > Host bridge: VIA Technologies, Inc. VT8601 [Apollo ProMedia] (rev 5). > Prefetchable 32 bit memory at 0xf800 [0xfbff]. > Bus 0, device 1, function 0: > PCI bridge: VIA Technologies, Inc. VT8601 [Apollo ProMedia AGP] (rev 0). > Master Capable. No bursts. Min Gnt=12. > Bus 0, device 7, function 0: > ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 27). > Bus 0, device 7, function 1: > IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 6). > Master Capable. Latency=64. > I/O at 0x1420 [0x142f]. > Bus 0, device 7, function 2: > USB Controller: VIA Technologies, Inc. UHCI USB (rev 14). > IRQ 11. > Master Capable. Latency=64. > I/O at 0x1400 [0x141f]. > Bus 0, device 7, function 4: > ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 32). > Bus 0, device 7, function 5: > Multimedia audio controller: VIA Technologies, Inc. AC97 Audio Controller (rev >33). > IRQ 9. > I/O at 0x1000 [0x10ff]. > I/O at 0x1434 [0x1437]. > I/O at 0x1430 [0x1433]. > Bus 0, device 9, function 0: > Communication controller: CONEXANT HSP MicroModem 56K (rev 1). > IRQ 11. > Master Capable. Latency=64. > Non-prefetchable 32 bit memory at 0xf400 [0xf400]. > I/O at 0x1438 [0x143f]. > Bus 0, device 10, function 0: > CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 1). > IRQ 9. > Master Capable. Latency=168. Min Gnt=192.Max Lat=5. > Non-prefetchable 32 bit memory at 0x1000 [0x1fff]. > Bus 1, device 0, function 0: > VGA compatible controller: Trident Microsystems CyberBlade i1 (rev 106). > IRQ 9. > Master Capable. Latency=64. > Non-prefetchable 32 bit memory at 0xf500 [0xf57f]. > Non-prefetchable 32 bit memory at 0xf410 [0xf411]. > Non-prefetchable 32 bit memory at 0xf480 [0xf4ff]. > Saludos Carlos PD: It's possible don't use the DUL list to blackmail SPAM sites. I usually use my loca smtp, because a don't trust the smtp of my ISP ( and nethier in Spain, swith doesn't it a option :( ) -- ... Windows 95: Emulador de Spectrum para PII. Drizzt Do'UrdenThree rings for the Elves Kings under the Sky [EMAIL PROTECTED] Seven for the Dwarf_lords in their hall of stone Nine for the Mortal Men doomed to die - End forwarded message - -- ... Castillos no hay muchos, pero fantasmas por todas partes. Drizzt Do'UrdenThree rings for the Elves Kings under the Sky [EMAIL PROTECTED] Seven for the Dwarf_lords in their hall of stone Nine for the Mortal Men doomed to die - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MTU and 2.4.x kernel
> Default of 536 is sadistic (and apaprently will be changed eventually > to stop tears of poor people whose providers not only supply them > with bogus mtu values sort of 552 or even 296, but also jailed them > to some proxy or masquearding domain), but it is still right: IP > with mtu lower 576 is not full functional. I thought that the specs said that 576 was the "minimum maximum" reassemblable IP datagram size and not a minimum MTU. rick jones -- ftp://ftp.cup.hp.com/dist/networking/misc/rachel/ these opinions are mine, all mine; HP might not want them anyway... :) feel free to email, OR post, but please do NOT do BOTH... my email address is raj in the cup.hp.com domain... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
finding Tekram SCSI dc395U linux patch driver:
hey, I found this driver on mandrake kernel sources, it's ac3, but I need ac14 code, also, why still not port this driver into kernel? the patch file already released 1 years ago - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Ata100 drives
Hi all, How it's the support of ATA100 in the linux kernel? Do I need to use 2.4 to get full speed or is enough to configure the drive with hdparm? When i use hdparm several modes supported appear. Is udma5 equivalent to the standard ATA100 ? And sorry if my questions are maybe too simple for this list. TIA David Gómez "The question of whether computers can think is just like the question of whether submarines can swim." -- Edsger W. Dijkstra - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1ac13/14 problem
> I haven't tried 2.4.1-ac13 on that machine yet, but I did attempt to boot > 2.4.1-ac13 on an Winchip-C6 machine. It froze at the same place, i.e. > "Checking if this processor honours the WP bit even in supervisor > mode...". 2.4.1-ac12 works quite nicely on this machine, although I still Now thats interesting. And also useful because I've not touched the winchip code paths. Also I have an IDT winchip t frob with. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pcnet32.c: MAC address may be in CSR registers
Alan Cox wrote:
>
> > Peter pointed out that the contents of the CSR12-14 registers are
> > initialized from the EEPROM, so reading the EEPROM is superfluous--we
> > should just read the CSRs and not read the EEPROM. I think he has a
> > point, so I'll make that change and submit yet another patch pair.
>
> I'd rather keep the existing initialisation behaviour of using the eeprom
> for 2.2. There are also some power management cases where I am not sure
> the values are restored on the pcnet/pci.
>
> For 2.2 conservatism is the key. For 2.4 by all means default to CSR12-14 and
> print a warning if they dont match the eeprom value and we'll see what it
> shows
>
> > Alan, do you want me to put your inline version in
> > while I'm at it, or what?
>
> Sure
Ok, here is the 2.4.1 version. Note that it is slightly different from
the 2.2.18 version. This one uses the CSRs and complains if the PROM is
different (but uses the CSRs anyway since those can be overridden by a
bootloader, etc.).
I don't have a 2.4.x tree handy that I can compile at the moment, but I
tested this change in a 2.2.x kernel, so it should be ok.
Is this patch satisfactory?
Eli
. Rule of Accuracy: When working toward
Eli Carter | the solution of a problem, it always
[EMAIL PROTECTED] `- helps if you know the answer.
--- linux/drivers/net/pcnet32.c.2.4.1 Wed Feb 14 16:49:31 2001
+++ linux/drivers/net/pcnet32.c Thu Feb 15 13:48:05 2001
@@ -624,10 +624,35 @@
printk(KERN_INFO "%s: %s at %#3lx,", dev->name, chipname, ioaddr);
-/* There is a 16 byte station address PROM at the base address.
- The first six bytes are the station address. */
+/* In most chips, after a chip reset, the ethernet address is read from the
+ * station address PROM at the base address and programmed into the
+ * "Physical Address Registers" CSR12-14.
+ * As a precautionary measure, we read the PROM values and complain if
+ * they disagree with the CSRs. Either way, we use the CSR values, and
+ * double check that they are valid.
+ */
+for (i = 0; i < 3; i++) {
+ unsigned int val;
+ val = a->read_csr(ioaddr, i+12) & 0x0;
+ /* There may be endianness issues here. */
+ dev->dev_addr[2*i] = val & 0x0ff;
+ dev->dev_addr[2*i+1] = (val >> 8) & 0x0ff;
+}
+{
+ u8 promaddr[6];
+ for (i = 0; i < 6; i++) {
+ promaddr[i] = inb(ioaddr + i);
+ }
+ if( memcmp( promaddr, dev->dev_addr, 6) )
+ printk(" warning: PROM address does not match CSR address");
+}
+/* if the ethernet address is not valid, force to 00:00:00:00:00:00 */
+if( !is_valid_ether_addr(dev->dev_addr) )
+ for (i = 0; i < 6; i++)
+ dev->dev_addr[i]=0;
+
for (i = 0; i < 6; i++)
- printk(" %2.2x", dev->dev_addr[i] = inb(ioaddr + i));
+ printk(" %2.2x", dev->dev_addr[i] );
if (((chip_version + 1) & 0xfffe) == 0x2624) { /* Version 0x2623 or 0x2624 */
i = a->read_csr(ioaddr, 80) & 0x0C00; /* Check tx_start_pt */
@@ -774,6 +799,10 @@
lp->shared_irq ? SA_SHIRQ : 0, lp->name, (void *)dev)) {
return -EAGAIN;
}
+
+/* Check for a valid station address */
+if( !is_valid_ether_addr(dev->dev_addr) )
+ return -EINVAL;
/* Reset the PCNET32 */
lp->a.reset (ioaddr);
--- linux/include/linux/etherdevice.h.2.4.1 Thu Feb 15 11:25:46 2001
+++ linux/include/linux/etherdevice.h Thu Feb 15 13:18:20 2001
@@ -45,6 +45,14 @@
memcpy (dest->data, src, len);
}
+/* Check that the ethernet address (MAC) is not 00:00:00:00:00:00 and is not
+ * a multicast address. Return true if the address is valid.
+ */
+static __inline__ int is_valid_ether_addr( u8 *addr )
+{
+ return !(addr[0]&1) && memcmp( addr, "\0\0\0\0\0\0", 6);
+}
+
#endif
#endif /* _LINUX_ETHERDEVICE_H */
Re: x86 ptep_get_and_clear question
In article <[EMAIL PROTECTED]>, Jamie Lokier <[EMAIL PROTECTED]> wrote: >> > << lock; >> > read pte >> > if (!present(pte)) >> >do_page_fault(); >> > pte |= dirty >> > write pte. >> > >> end lock; >> >> No, it is a little more complicated. You also have to include in the >> tlb state into this algorithm. Since that is what we are talking about. >> Specifically, what does the processor do when it has a tlb entry allowing >> RW, the processor has only done reads using the translation, and the >> in-memory pte is clear? > >Yes (no to the no): Manfred's pseudo-code is exactly the question you're >asking. Because when the TLB entry is non-dirty and you do a write, we >_know_ the processor will do a locked memory cycle to update the dirty >bit. A locked memory cycle implies read-modify-write, not "write TLB >entry + dirty" (which would be a plain write) or anything like that. > >Given you know it's a locked cycle, the only sensible design from Intel >is going to be one of Manfred's scenarios. Not necessarily, and this is NOT guaranteed by the docs I've seen. It _could_ be that the TLB data actually also contains the pointer to the place where it was fetched, and a "mark dirty" becomes read *ptr locked val |= D write *ptr unlock Now, I will agree that I suspect most x86 _implementations_ will not do this. TLB's are too timing-critical, and nobody tends to want to make them bigger than necessary - so saving off the source address is unlikely. Also, setting the D bit is not a very common operation, so it's easy enough to say that an internal D-bit-fault will just cause a TLB re-load, where the TLB re-load just sets the A and D bits as it fetches the entry (and then page fault handling is an automatic result of the reload). However, the _implementation_ detail is not, as far as I can tell, explicitly defined by the architecture. And in anothe rpost I quote a book by the designers of the original 80386 that implies strongly that the "re-walk the page tables on D miss" assumption is not what they _meant_ for the architecture design, even if they probably happened to implement it that way. >An interesting thought experiment though is this: > ><< lock; >read pte >pte |= dirty >write pte >>> end lock; >if (!present(pte)) > do_page_fault(); > >It would have a mighty odd effect wouldn't it? Why do you insist on the !present() check at all? It's not implied by the architecture - a correctly functioning OS is not supposed to ever be able to cause it according to specs.. I tink Kanoj is right to be worried. I _do_ believe that the current Linux code works on "all current hardware". But I think Kanoj has a valid point in that it's not guaranteed to work in the future. That said, I think Intel tends to be fairly pragmatic in their design (that's the nice way of saying that Intel CPU's tend to dismiss the notion of "beautiful architecture" completely over the notion of "let's make it work"). And I would be extremely surprised indeed if especially MS Windows didn't do some really bad things with the TLB. In fact, I think I can say from personal experience that I pretty much _know_ windows has big bugs in TLB invalidation. And because of that, it may be that nobody can ever create a x86-compatible CPU that does anything but "re-walk the TLB tables on _anything_ fishy going on with the TLB". (Basically, it seems to be pretty much a fact of life that the x86 architecture will NOT raise a page protection fault directly from the TLB content - it will re-walk the page tables before it actually raises the fault, and only the act of walking the page tables and finding that it really _should_ fault will raise an x86-level fault. It all boils down to "never trust the TLB more than you absolutely have to"). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aic7xxx (and sym53c8xx) plans
According to J . A . Magallon: > Please, I think it would be much more useful a patch against the latest > 2.2.19-pre (if that one for 2.2.18 does not work, I have not tried) > and the latest 2.4.1-ac14, that is what people experiments with. There's no end of versions that people use. Might I suggest that Justin imitate the maintainers of lm_sensors, and create a program (shell script, Perl program, whatever) that *creates* a patch against any given Linux source tree? Obviously it could break in the face of weird trees, but even minimal flexibility would save him a lot of work ... -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1ac13/14 problem
On Thu, 15 Feb 2001, Alan Cox wrote: > > Calibrating delay loop... 466.94 BogoMIPS > > Memory: 62836k/65536k available (712k kernel code, 2312k reserved, 188k > > data, 56k init, 0k highmem) > > Checking if this processor honours the WP bit even in supervisor mode... > > > > Here it freezes forever... My cpu: > > > > vendor_id : CyrixInstead > > Ok I've been trying to fix the Cyrix/cpuid problems and it appears I > may have overdone it. I'll reread the code in detail. > > Alan Hello Alan, For your information, 2.4.1-ac12 works great on my Cyrix 6x86 P166+, and it properly recognizes the CPU as i586 class. I haven't tried 2.4.1-ac13 on that machine yet, but I did attempt to boot 2.4.1-ac13 on an Winchip-C6 machine. It froze at the same place, i.e. "Checking if this processor honours the WP bit even in supervisor mode...". 2.4.1-ac12 works quite nicely on this machine, although I still experience random crashes on this machine. (Don't know if it is the kernel or hardware problem... I have been having troubles with this computer with just about any kernels since 2.2.17...) One of these days, when I have time, I'll post the Oops or the Bug. Meanwhile, 2.4.x is rock solid on my Cyrix machine. :-) Thanks, Anthony -- Anthony Fok Tung-LingCivil and Environmental Engineering [EMAIL PROTECTED], [EMAIL PROTECTED]University of Alberta, Canada Debian GNU/Linux Chinese Project -- http://www.debian.org/intl/zh/ Come visit Our Lady of Victory Camp -- http://www.olvc.ab.ca/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MTU and 2.4.x kernel
> A. Datagram protocols do not work with mtus not allowing to send >512 byte frames (even DNS). I ran DNS reliably over AX.25 networks. They have an MTU of 216. They work. Please explain your claim in more detail. Please explain why the real world is violating your version of the laws of physics. > B. Accoutning, classification, resource reervation does not work on >fragmented packets. Thats a bug in accounting classification and resource reservation. We expect cisco to fix their ECN bugs I think its rather cheeky to refuse to deal with our own flaws. > mistake, I found some fun talking to people, which suffer of superstition > that "mtu 296 is good for..." (latency for example) 8)8)8) Over a 9600 mobile phone link mtu 296 makes measurable differences to the latency when mixing a mail fetch with typing. Over a radio link where error rate causes exponential increases in probability of packet loss as the frame length grows the issue is even more visible. > Right observation. It stops to work even earlier: at mtu<128. > It is strict limit. Pardon, discussing marginal cases is useless. > If someone has device with mtu of 128, let him to put it back to the place, > where he found it. NetROM is MTU 128. It is a neccessary but inconvenient limitation that would require ripping out tens of thousands of nodes to fix. > I would prefer that minimal MTU on internet stayed on 576, which > is already fact. Only in your mind. Not in the real world. If you wont fix the TCP/IP code to handle a 128 byte MTU properly then -ac will diverge from the main tree because some of us want Linux to work on real world tricky environments. If you want to argue that a MTU < 512 is hard to deal with by MTU discovery you are right. So when you get a 'must fragment' below 512, just turn DF off for that socket. Its not exactly a hard problem to solve properly. I repeat my request. Cite the RFC number and line. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aic7xxx (and sym53c8xx) plans
On 02.15 Justin T. Gibbs wrote: > >All of my boxes with that card are on 2.2.16. The rest are on 2.4.1, so I > >don't really have a need to test 2.2.18 as I would rather be on 2.4.x for > >all of my boxes. > > Well, I'll try and generate patches against 2.2.16 soon. I probably > need to support 2.2.14 too. There are already so many versions to > keep track of, the sooner the driver becomes embedded, the better. > Please, I think it would be much more useful a patch against the latest 2.2.19-pre (if that one for 2.2.18 does not work, I have not tried) and the latest 2.4.1-ac14, that is what people experiments with. People who has still a 2.2.14 or 16 looks like does not worry too much about updating and building kernels, and it they go into the work, they can just go to 2.2.18, compatible with 16 and 14 and much more stable. I think it is better to work for preX kernels than for eldely ones. -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.4.1-ac14 #1 SMP Thu Feb 15 16:05:52 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1ac13/14 problem
> Calibrating delay loop... 466.94 BogoMIPS > Memory: 62836k/65536k available (712k kernel code, 2312k reserved, 188k > data, 56k init, 0k highmem) > Checking if this processor honours the WP bit even in supervisor mode... > > Here it freezes forever... My cpu: > > vendor_id : CyrixInstead Ok I've been trying to fix the Cyrix/cpuid problems and it appears I may have overdone it. I'll reread the code in detail. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86 ptep_get_and_clear question
In article <[EMAIL PROTECTED]>, Kanoj Sarcar <[EMAIL PROTECTED]> wrote: >> >> Will you please go off and prove that this "problem" exists on some x86 >> processor before continuing this rant? None of the PII, PIII, Athlon, > >And will you please stop behaving like this is not an issue? This is documented in at least Programming the 80386 John Crawford & Patrick Gelsinger which is still the best book I've ever seen on the x86 architecture. See page 477, "Memory management, Protection, and Tasks", under "Multiple- Processor Considerations". And I quote: "Before changing a page table entry that may be used on another procesor , software should use a locked AND instruction to clear the P bit to 0 in an indivisible operation. Then the entry can be changed as required, and made available by later setting the P bit to 1. At some point in the modification of a page table entry, all processors in the system that may have had the entry cached must be notified (usually with an interrupt) to flush their page translation caches to remove any old copies of the entry. Until these old copies are flushed, the processors can continue to access the old page, and may also set the D bit in the entry being modified. If this may case the modification of the entry to fail, the paging caches should be flushed after the entry is marked not present, but before the entry is otherwise modified". Note the last sentence - that's the one that really matters to this discussion. And it does imply that the read-and-clear thing is not the right thing to do and is not guaranteed to fix the race (even if I personally suspect that all current x86 implementations will just re-walk the page tables and set the D bit the same way they set the A bit, and basically making the usage an "argument" to the page table walker logic). However, I suspect that we could extend it to just re-read the entry (which _should_ be zero, but could have the D bit set) after having invalidated the TLB on the other CPU's. But Gelsinger suggests just clearing the P bit - which is easily enough done, as the following modification would be needed anyway in mm/vmscan.c: pte = ptep_get_and_clear(page_table); flush_tlb_page(vma, address); + pte = ptep_update_after_flush(page_table, pte); where "ptep_update_after_flush()" would be a no-op on UP, and on SMP it would just or in the D bit (which should be practically always zero) from the page table entry into the pte. Just clearing the P bit actuall ymakes "out_unlock_restore:" simpler: it becomes a simple lock ; orl $1, page_table which makes the worry about overwriting the D bit at that point go away (although, considering where we invalidate the TLB's and that we should now have had the correct D bits anyway, the non-locked simple store should also work reliably). The case of munmap() is more worrisome, and has much worse performance issues. Ben's experimental shootdown patch would appear to not be good enough. The only simple solution is the "gather" operation that I've already suggested because of it's obvious correctness and simplicity. A potential alternative would be to walk the page tables twice, and make the page table zapping be a two-phase process. We'd only need to do this when the "mm->cpu_vm_mask" bits implied that other CPU's might have TLB entries, so we could avoid the double work for the normal case. HOWEVER, this is also the only case where a CPU "gather" operation would be necessary, so the thing basically boils down to the question of whether "gather" or "double walk" is the more expensive operation. The "gather" operation could possibly be improved to make the other CPU's do useful work while being shot down (ie schedule away to another mm), but that has it's own pitfalls too. >OS clears present bit, processors can keep using their TLBs and access >the page, no problems at all. That is why after clearing the present bit, >the processor must flush all tlbs before it can assume no one is using >the page. Hardware updated access bit could also be a problem, but an >error there does not destroy data, it just leads the os to choosing the >wrong page to evict during memory pressure. The bible (see above) explicitly mentions only the D bit here - the A bit is set at page table walk time, and is explicitly NOT set if the P bit is clear at walk time, so there is no apparent race on that. But as the A bit isn't very important anyway, the apparent lack of a race is not all that interesting. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.x/alpha/ALI chipset/IDE problems summary Re: 2.4.1 not fullysane on Alpha - file systems
On Thu, 15 Feb 2001, Michal Jaegermann wrote:
> > Well, the situation is improving, I suppose ...
> >
> > Under kernel 2.4.0 and 2.4.1, a dd of about 1 4k blocks would cause
> > the system to go technicolor and lock up.
>
> On UP1100 which I have here somehow this looks a bit different _after_
> I put on it the latest SRM and used this "magic incantation" from
> Hyung Min SEO ('d -l 801feac d' at SRM prompt to modify firmware).
> I copied from disk to disk directory tries with some 150 MB of data
> in these and no ill effects.
I retried the mysticism and incantations (d -l 801feac d) at the srm
prompt, and the machine locked on fsck, under kernel 2.4.1-ac13.
I don't care about X on this system, all that much, honestly.
-- John
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Linux stifles innovation...
On Thu, 15 Feb 2001, David D.W. Downey wrote: > Seriously though folks, look at who's doing this! > > They've already tried once to sue 'Linux', were told they couldn't because > Linux is a non-entity (or at least one that they can not effectively sue > due to the classification Linux holds), and now they can't use their > second favorite tactic for stifling NON-M$ product lines. > > How? They can't BUY the linux code base OR any GPL's software to the point > that they can bury it by buying and freezing the code from public use. > > We sort HAD to expect something like THIS to come. Though what DOES > concern me is how effective this current ploy may be if they get ANY sort > of backing from the government. (I doubt they will, but What If?) I expect the next thing that will happen is that they will get patents on key portions of their protocols and then start enforcing them. With the various IP laws that have been passed in the last few years in the US (and through WIPO) they will have a large brick to try and hit us with. (IMHO these laws pretty much allow large entities to buy their markets and are the biggest threat to innovation out there.) > Let's hope EFF and FSF stay on their toes for this one. M$ doesn't have to > win to really wipe our nose in stuff. They got the cash whereas we don't. > ALTHOUGH, spending money to fight an idea or concept has never proven > successful. And since the RESULTS of that idea or concept (in this case > source code) are not suable AFAIK. So we got the upper hand there. Actually I am sending copies of his rant out to all of my friends who still use Microsoft products. If that is the attitude they have towards their customers and the development community then it is time to get away while you still can. Of course, the reason I moved over all my development to Linux in the first place what that I did not have to worry about being screwed over by a "corporate strategy" or have the license terms changed on the next release or have to pay for something over and over again in the vain attempt to get something to work. With Linux I can read the source. There are no hidden interfaces. No mystical archane knowledge that you have to pay the company to learn get the job done. It is all there and it all works. (Or if it does not, then the tools exist to make it work.) I wonder what kind of law they will try to push to outlaw Open Source? If this is his idea of "The American Way" then he needs to take a basic civics course. He obviously slept through the last one. [EMAIL PROTECTED] | Note to AOL users: for a quick shortcut to reply Alan Olsen| to my mail, just hit the ctrl, alt and del keys. "In the future, everything will have its 15 minutes of blame." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: strange tcp errors
Hello! > Maybe someone want to say me what does it mean and how serious it is? It means that debugging messages are still not disabled in 2.4.x 8) > Any fixes? These ones can be ignored. Alexey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux stifles innovation...
Seriously though folks, look at who's doing this! They've already tried once to sue 'Linux', were told they couldn't because Linux is a non-entity (or at least one that they can not effectively sue due to the classification Linux holds), and now they can't use their second favorite tactic for stifling NON-M$ product lines. How? They can't BUY the linux code base OR any GPL's software to the point that they can bury it by buying and freezing the code from public use. We sort HAD to expect something like THIS to come. Though what DOES concern me is how effective this current ploy may be if they get ANY sort of backing from the government. (I doubt they will, but What If?) Let's hope EFF and FSF stay on their toes for this one. M$ doesn't have to win to really wipe our nose in stuff. They got the cash whereas we don't. ALTHOUGH, spending money to fight an idea or concept has never proven successful. And since the RESULTS of that idea or concept (in this case source code) are not suable AFAIK. So we got the upper hand there. -- David D.W. Downey - RHCE Consulting Engineer Ensim Corporation - Sunnyvale, CA - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.x/alpha/ALI chipset/IDE problems summary Re: 2.4.1 not fully sane on Alpha - file systems
On Thu, Feb 15, 2001 at 12:49:29PM -0500, John Jasen wrote:
>
> Well, the situation is improving, I suppose ...
>
> Under kernel 2.4.0 and 2.4.1, a dd of about 1 4k blocks would cause
> the system to go technicolor and lock up.
On UP1100 which I have here somehow this looks a bit different _after_
I put on it the latest SRM and used this "magic incantation" from
Hyung Min SEO ('d -l 801feac d' at SRM prompt to modify firmware).
I copied from disk to disk directory tries with some 150 MB of data
in these and no ill effects.
OTOH things are still wobbly. This shows up in this that trying to
run e2fsck on a dirty file system while booting one 2.4.1 is likely
to come up with all kind of errors in a file sytstem requiring manual
interactions. If one breaks this process and repeats an exercise
on the same file system, but booting this time 2.2.18, then things
check out without any incidents. Once clean file systems can be
used with 2.4.1 again and no problems are reported.
I really do not see any kernel problems with 2.2 series kernels and IDE
patches.
> Now, under 2.4.1-ac13, at about 11000 blocks, it goes technicolor, but
> doesn't lock up until somewhere between 13000 and 2.
I got various lockups but no "technicolor" on any occasion. Recently
I even got a picture with X and G450 Matrox card although one can
be very careful not to look at it a wrong angle or a power button will
be the only way out.
Michal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
patch for mini-pci ethernet card
Hi,
I have a HP Pavilon 5290 laptop. It has a a mini-pci modem/ethernet combo
integrated card.
Searching in the Internet I found a patch for the ethernet to work with the
tulip driver for kernel 2.2.x series, However, I found no patch for the 2.4.x
kernel series, so I made one.
Here is what /proc/pci detects as the ethernet card.
Bus 0, device 16, function 0:
Ethernet controller: PCI device 1113:1216 (Accton Technology Corporation)
(rev 17).
IRQ 11.
Master Capable. Latency=64. Min Gnt=255.Max Lat=255.
I/O at 0x1c00 [0x1cff].
Non-prefetchable 32 bit memory at 0xe800 [0xe80003ff].
This patch merely adds the configuration for that card in the tulip driver
tables.
I made this patch against kernel 2.4.1 and it works fine on my laptop.
Apply this patch against linux/drivers/net/tulip/tulip_core.c
Anyone with a similar laptop please test it and see if it works for you
My name is Paul Pacheco, email: [EMAIL PROTECTED]
So, Here is the patch:
--- tulip_core.c.orig Fri Feb 16 14:30:38 2001
+++ tulip_core.cFri Feb 16 14:47:54 2001
@@ -150,6 +150,9 @@
{ "Davicom DM9102/DM9102A", 128, 0x0001ebef,
HAS_MII | HAS_MEDIA_TABLE | CSR12_IN_SROM | HAS_ACPI,
tulip_timer },
+ { "EN2242 tulip work-alike", 128, 0x0801fbff,
+HAS_MII | HAS_MEDIA_TABLE | ALWAYS_CHECK_MII | HAS_ACPI | HAS_NWAY,
+t21142_timer },
{0},
};
@@ -177,6 +180,7 @@
{ 0x1282, 0x9100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
{ 0x1282, 0x9102, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
{ 0x1113, 0x1217, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MX98715 },
+{ 0x1113, 0x1216, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
{0, }
};
MODULE_DEVICE_TABLE(pci, tulip_pci_tbl);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: What does the linux kernel need?
http://linux24.sourceforge.net/ is a good place to start. > I am not subscribed to the list yet, please CC to me your reply. > Thank you very much, You should be. Also I suggest you read the lkml FAQ at http://www.tux.org/lkml/ . It should give quite a few starting points. -gabi > -Original Message- > From: Yuri Niyazov [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 15, 2001 7:13 PM > To: [EMAIL PROTECTED] > Subject: What does the linux kernel need? > > > Hello, respected Linux kernel developers, > I am currently a university student taking a "Advanced design of > Operating Systems" class at > New York University. We are reviewing some basic and studying a few > advanced issues with regards > to kernel design, mostly multithreading, scalability, performance > improvement - its webpage is http://www.scs.cs.nyu.edu/G22.3033-010/ > take a look if you please. The requirement of the class is a final > project proposal and > implementation of a student's own choosing - I would really > like to do > something useful for the > linux kernel, but I do not know what kinds of issues are most > imminent > at the linux kernel and > have to be worked on. I would greatly appreciate it if people would > send me ideas of what is > needed and what I can work on - it can be pretty much anything, any > topic or project, but it must > relate to kernel development, thus I am asking it here. > I am not subscribed to the list yet, please CC to me your reply. > Thank you very much, > Yuri Niyazov > > __ > Do You Yahoo!? > Get personalized email addresses from Yahoo! Mail - only $35 > a year! http://personal.mail.yahoo.com/ > - > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MTU and 2.4.x kernel
Hello! > Please cite an exact RFC reference. No need to cite RFC, this is plain sillogism. A. Datagram protocols do not work with mtus not allowing to send 512 byte frames (even DNS). B. Accoutning, classification, resource reervation does not work on fragmented packets. -> IP suite is not full functional with low MTUs and must be eliminated. Current setting of min_adv_mss to 536 is actually occasional. I tested pmtu discovery on local clients using mtu 296 and did not change the value to less fascist after this. I happened to be not mistake, I found some fun talking to people, which suffer of superstition that "mtu 296 is good for..." (latency for example) 8)8)8) > to put it back together. Our handling of DF on syn frames is also broken > due to that misassumption, but fortunately only for crazy mtus like 70. Right observation. It stops to work even earlier: at mtu<128. It is strict limit. Pardon, discussing marginal cases is useless. If someone has device with mtu of 128, let him to put it back to the place, where he found it. Preventing DoSes requires to block pmtu discovery at 576 or at least 552. More practical question is mtu=296. There exist old myth that this value is good for PPP. This is nothing but myth. 14% of overhead. I would prefer that minimal MTU on internet stayed on 576, which is already fact. Alexey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ONE-LINE PATCH](Silly?) bug in ext2/namei.c, 2.2.x, 2.4.x
Hi!
I think that this is a bug. The buffer is always released except in this
case.
Bye.
*** /usr/src/linux-2.4.1/fs/ext2/namei.cTue Dec 12 16:48:22 2000
--- namei.c.new Thu Feb 15 20:42:45 2001
***
*** 235,240
--- 235,241
return retval;
if (dir->i_size <= offset) {
if (dir->i_size == 0) {
+ brelse(bh);
return -ENOENT;
}
--
D. Juan Piernas Cánovas
Departamento de Ingeniería y Tecnología de Computadores
Facultad de Informática. Universidad de Murcia
Campus de Espinardo - 30080 Murcia (SPAIN)
Tel.: +34968367657Fax: +34968364151
email: [EMAIL PROTECTED]
PGP public key:
http://pgp.rediris.es:11371/pks/lookup?search=piernas%40ditec.um.es=index
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: x86 ptep_get_and_clear question
> > On Thu, 15 Feb 2001, Kanoj Sarcar wrote: > > > No. All architectures do not have this problem. For example, if the > > Linux "dirty" (not the pte dirty) bit is managed by software, a fault > > will actually be taken when processor 2 tries to do the write. The fault > > is solely to make sure that the Linux "dirty" bit can be tracked. As long > > as the fault handler grabs the right locks before updating the Linux "dirty" > > bit, things should be okay. This is the case with mips, for example. > > > > The problem with x86 is that we depend on automatic x86 dirty bit > > update to manage the Linux "dirty" bit (they are the same!). So appropriate > > locks are not grabbed. > > Will you please go off and prove that this "problem" exists on some x86 > processor before continuing this rant? None of the PII, PIII, Athlon, And will you please stop behaving like this is not an issue? > K6-2 or 486s I checked exhibited the worrisome behaviour you're And I maintain that this kind of race condition can not be tickled deterministically. There might be some piece of logic (or absence of it), that can show that your finding of a thousand runs is not relevant. > speculating about, plus it is logically consistent with the statements the > manual does make about updating ptes; otherwise how could an smp os Don't say this anymore, specially if you can not point me to the specs. > perform a reliable shootdown by doing an atomic bit clear on the present > bit of a pte? OS clears present bit, processors can keep using their TLBs and access the page, no problems at all. That is why after clearing the present bit, the processor must flush all tlbs before it can assume no one is using the page. Hardware updated access bit could also be a problem, but an error there does not destroy data, it just leads the os to choosing the wrong page to evict during memory pressure. Kanoj > > -ben > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to [EMAIL PROTECTED] For more info on Linux MM, > see: http://www.linux.eu.org/Linux-MM/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86 ptep_get_and_clear question
Kanoj Sarcar wrote: > > Is the sequence > > << lock; > > read pte > > pte |= dirty > > write pte > > >> end lock; > > or > > << lock; > > read pte > > if (!present(pte)) > > do_page_fault(); > > pte |= dirty > > write pte. > > >> end lock; > > No, it is a little more complicated. You also have to include in the > tlb state into this algorithm. Since that is what we are talking about. > Specifically, what does the processor do when it has a tlb entry allowing > RW, the processor has only done reads using the translation, and the > in-memory pte is clear? Yes (no to the no): Manfred's pseudo-code is exactly the question you're asking. Because when the TLB entry is non-dirty and you do a write, we _know_ the processor will do a locked memory cycle to update the dirty bit. A locked memory cycle implies read-modify-write, not "write TLB entry + dirty" (which would be a plain write) or anything like that. Given you know it's a locked cycle, the only sensible design from Intel is going to be one of Manfred's scenarios. An interesting thought experiment though is this: << lock; read pte pte |= dirty write pte >> end lock; if (!present(pte)) do_page_fault(); It would have a mighty odd effect wouldn't it? -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pcnet32.c: MAC address may be in CSR registers
Alan Cox wrote:
> I'd rather keep the existing initialisation behaviour of using the eeprom
> for 2.2. There are also some power management cases where I am not sure
> the values are restored on the pcnet/pci.
>
> For 2.2 conservatism is the key. For 2.4 by all means default to CSR12-14 and
> print a warning if they dont match the eeprom value and we'll see what it
> shows
>
> > Alan, do you want me to put your inline version in
> > while I'm at it, or what?
>
> Sure
Here is the 2.2.18 patch... I'll send the 2.4.1 patch shortly.
This one still uses the PROM since we are going for least change in
initialization.
is_valid_ether_addr() is static inline in
Is this one satisfactory?
Eli
. Rule of Accuracy: When working toward
Eli Carter | the solution of a problem, it always
[EMAIL PROTECTED] `- helps if you know the answer.
--- linux/drivers/net/pcnet32.c 2001/01/20 11:10:30 1.1.1.6
+++ linux/drivers/net/pcnet32.c 2001/02/15 19:08:55
@@ -648,10 +648,33 @@
printk(KERN_INFO "%s: %s at %#3lx,", dev->name, chipname, ioaddr);
-/* There is a 16 byte station address PROM at the base address.
- The first six bytes are the station address. */
-for (i = 0; i < 6; i++)
- printk(" %2.2x", dev->dev_addr[i] = inb(ioaddr + i));
+/* In most chips, there is a station address PROM at the base address.
+ * However, if that does not have a valid address, try the "Physical
+ * Address Registers" CSR12-CSR14
+ */
+{
+ /* There is a 16 byte station address PROM at the base address.
+The first six bytes are the station address. */
+ for (i = 0; i < 6; i++) {
+ dev->dev_addr[i] = inb(ioaddr + i);
+ }
+ if( !is_valid_ether_addr(dev->dev_addr) ) {
+ /* also double check this station address */
+ for (i = 0; i < 3; i++) {
+ unsigned int val;
+ val = a->read_csr(ioaddr, i+12) & 0x0;
+ /* There may be endianness issues here. */
+ dev->dev_addr[2*i] = val & 0x0ff;
+ dev->dev_addr[2*i+1] = (val >> 8) & 0x0ff;
+ }
+ /* if this is not valid either, force to 00:00:00:00:00:00 */
+ if( !is_valid_ether_addr(dev->dev_addr) )
+ for (i = 0; i < 6; i++)
+ dev->dev_addr[i]=0;
+ }
+ for (i = 0; i < 6; i++)
+ printk(" %2.2x", dev->dev_addr[i] );
+}
if (((chip_version + 1) & 0xfffe) == 0x2624) { /* Version 0x2623 or 0x2624 */
i = a->read_csr(ioaddr, 80) & 0x0C00; /* Check tx_start_pt */
@@ -796,6 +819,10 @@
lp->shared_irq ? SA_SHIRQ : 0, lp->name, (void *)dev)) {
return -EAGAIN;
}
+
+/* Check for a valid station address */
+if( !is_valid_ether_addr(dev->dev_addr) )
+ return -EINVAL;
/* Reset the PCNET32 */
lp->a.reset (ioaddr);
--- linux/include/linux/etherdevice.h 2001/01/19 19:25:31 1.1.1.1
+++ linux/include/linux/etherdevice.h 2001/02/15 19:08:55
@@ -51,6 +51,14 @@
unsigned char *src, int length, int base);
#endif
+/* Check that the ethernet address (MAC) is not 00:00:00:00:00:00 and is not
+ * a multicast address. Return true if the address is valid.
+ */
+static __inline__ int is_valid_ether_addr( u8 *addr )
+{
+return !(addr[0]&1) && memcmp( addr, "\0\0\0\0\0\0", 6);
+}
+
#endif
#endif /* _LINUX_ETHERDEVICE_H */
Re: x86 ptep_get_and_clear question
> > Kanoj Sarcar wrote: > > > > Okay, I will quote from Intel Architecture Software Developer's Manual > > Volume 3: System Programming Guide (1997 print), section 3.7, page 3-27: > > > > "Bus cycles to the page directory and page tables in memory are performed > > only when the TLBs do not contain the translation information for a > > requested page." > > > > And on the same page: > > > > "Whenever a page directory or page table entry is changed (including when > > the present flag is set to zero), the operating system must immediately > > invalidate the corresponding entry in the TLB so that it can be updated > > the next time the entry is referenced." > > > > But there is another paragraph that mentions that an OS may use lazy tlb > shootdowns. > [search for shootdown] > > You check the far too obvious chapters, remember that Intel wrote the > documentation ;-) :-) :-) The good part is, there are a lot of Intel folks now active on Linux, I can go off and ask one of them, if we are sufficiently confused. I am trying to see whether we are. > I searched for 'dirty' though Vol 3 and found > > Chapter 7.1.2.1 Automatic locking. > > .. the processor uses locked cycles to set the accessed and dirty flag > in the page-directory and page-table entries. > > But that obviously doesn't answer your question. > > Is the sequence > << lock; > read pte > pte |= dirty > write pte > >> end lock; > or > << lock; > read pte > if (!present(pte)) > do_page_fault(); > pte |= dirty > write pte. > >> end lock; No, it is a little more complicated. You also have to include in the tlb state into this algorithm. Since that is what we are talking about. Specifically, what does the processor do when it has a tlb entry allowing RW, the processor has only done reads using the translation, and the in-memory pte is clear? Kanoj > > -- > Manfred > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is this the ultimate stack-smash fix?
Manfred Spraul <[EMAIL PROTECTED]> writes:
> "Eric W. Biederman" wrote:
> >
> > But the gcc bounds checking work is the ultimate buffer overflow fix.
> > You can recompile all of your trusted applications, and libraries with
> > it and be safe from one source of bugs.
> >
>
> void main(int argc, char **argv[])
> {
> char local[128];
> if(argc > 2)
> strcpy(local,argv[1]);
> }
>
> Unless you modify the ABI and pass the array bounds around you won't
> catch such problems,
Of course. But this is linux and you have the source. And I did mention
you needed to recompile the libraries your trusted applications depended on.
> and I won't even mention unions and
>
> struct dyn_data {
> int len;
> char data[];
> }
Yep bounds checking is not an easy fix. But it is a good fix.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: x86 ptep_get_and_clear question
Manfred Spraul wrote: > Is the sequence > << lock; > read pte > pte |= dirty > write pte > >> end lock; > or > << lock; > read pte > if (!present(pte)) > do_page_fault(); > pte |= dirty > write pte. > >> end lock; or more generally << lock; read pte if (!present(pte) || !writable(pte)) do_page_fault(); pte |= dirty write pte. >> end lock; Not to mention, does it guarantee to use the newly read physical address, does it check the superviser permission again, does it use the new PAT/CD/WT attributes? I can vaguely imagine some COW optimisation where the pte is updated to be writable with the new page's address, and there is no need to flush other processor TLBs because they will do so when they first write to the page. (But of course you have to be careful synchronising with other uses of the shared page prior to the eventual TLB flush). -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86 ptep_get_and_clear question
On Thu, 15 Feb 2001, Kanoj Sarcar wrote: > No. All architectures do not have this problem. For example, if the > Linux "dirty" (not the pte dirty) bit is managed by software, a fault > will actually be taken when processor 2 tries to do the write. The fault > is solely to make sure that the Linux "dirty" bit can be tracked. As long > as the fault handler grabs the right locks before updating the Linux "dirty" > bit, things should be okay. This is the case with mips, for example. > > The problem with x86 is that we depend on automatic x86 dirty bit > update to manage the Linux "dirty" bit (they are the same!). So appropriate > locks are not grabbed. Will you please go off and prove that this "problem" exists on some x86 processor before continuing this rant? None of the PII, PIII, Athlon, K6-2 or 486s I checked exhibited the worrisome behaviour you're speculating about, plus it is logically consistent with the statements the manual does make about updating ptes; otherwise how could an smp os perform a reliable shootdown by doing an atomic bit clear on the present bit of a pte? -ben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.1ac13/14 problem
Hi
I have't seen any posts about this, maybe nobody haveing
problems? I can't boot ac13/ac14 on my machine. 2.4.1ac12 was ok.
Linux version 2.4.1-ac13 (root@singular) (gcc version 2.95.3 20010125
(prerelease)) #2 Thu Feb 15 02:23:31 CET 2001
BIOS-provided physical RAM map:
BIOS-e820: 0009fc00 @ (usable)
BIOS-e820: 0400 @ 0009fc00 (usable)
BIOS-e820: 0001 @ 000f (reserved)
BIOS-e820: 0001 @ (reserved)
BIOS-e820: 03f0 @ 0010 (usable)
On node 0 totalpages: 16384
zone(0): 4096 pages.
zone(1): 12288 pages.
zone(2): 0 pages.
Kernel command line: BOOT_IMAGE=o ro root=30a reboot=warm hdb=none
hdd=none
ide_setup: hdb=none
ide_setup: hdd=none
Initializing CPU#0
Detected 233.866 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 466.94 BogoMIPS
Memory: 62836k/65536k available (712k kernel code, 2312k reserved, 188k
data, 56k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode...
Here it freezes forever... My cpu:
processor : 0
vendor_id : CyrixInstead
cpu family : 6
model : 2
model name : M II 3.5x Core/Bus Clock
stepping: 8
cpu MHz : 233.866
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu de tsc msr cx8 pge cmov mmx cyrix_arr
bogomips: 466.94
I reality it`s an IBM 6x86 MX and have to run at 2.5x83, however I
overclockd it to 3.5x66 for a year now. (maybe this is why it seems to be
a M II?)
My other problem exists since 1999.okt. when I first installed Linux with
kernel 2.2.x. I get random floating point exceptions in every math
intensive program (at xmms it's really anoying). It's impossible to listen
to mp3 more than 5 minutes if I do not patch signal.c to re-execute
SIGFPE. (this has some sideeffects, like 1/0 is a forever loop...) This
does also accour if I run the processor at 2.5x66, so the problem is not
overclocking/heating. Should I buy a new processor+motherboard or is it
kernel related? (I did not had this problem before linux) I normally
compile the kernel for Pentium-Pro/Celeron/Pentium-II, but same happens
when compiled for 386.
I've made a little patch just for fun, maybe you could include it in
kernel (removes not compiled devices for root=/dev/x, and saves a few
bytes):
---
diff -u --recursive --new-file v2.4.1/linux/init/main.c linux/init/main.c
--- v2.4.1/linux/init/main.cThu Jan 4 05:45:26 2001
+++ linux/init/main.c Sat Jan 13 13:46:18 2001
@@ -148,7 +148,10 @@
const char *name;
const int num;
} root_dev_names[] __initdata = {
+#ifdef CONFIG_NFS_FS
{ "nfs", 0x00ff },
+#endif
+#ifdef CONFIG_IDE
{ "hda", 0x0300 },
{ "hdb", 0x0340 },
{ "hdc", 0x1600 },
@@ -169,6 +172,9 @@
{ "hdr", 0x5A40 },
{ "hds", 0x5B00 },
{ "hdt", 0x5B40 },
+#endif
+#ifdef CONFIG_SCSI
+ { "scd", 0x0b00 },
{ "sda", 0x0800 },
{ "sdb", 0x0810 },
{ "sdc", 0x0820 },
@@ -185,35 +191,69 @@
{ "sdn", 0x08d0 },
{ "sdo", 0x08e0 },
{ "sdp", 0x08f0 },
+#endif
+#ifdef CONFIG_ATARI_ACSI
{ "ada", 0x1c00 },
{ "adb", 0x1c10 },
{ "adc", 0x1c20 },
{ "add", 0x1c30 },
{ "ade", 0x1c40 },
+#endif
+#if defined(CONFIG_BLK_DEV_FD) || defined(CONFIG_AMIGA_FLOPPY) ||
+defined(CONFIG_ATARI_FLOPPY) || defined(CONFIG_BLK_DEV_SWIM_IOP)
{ "fd", 0x0200 },
- { "md", 0x0900 },
+#endif
+#ifdef CONFIG_MD
+ { "md", 0x0900 },
+#endif
+#ifdef CONFIG_BLK_DEV_XD
{ "xda", 0x0d00 },
{ "xdb", 0x0d40 },
+#endif
+#if defined(CONFIG_BLK_DEV_RAM) || defined(CONFIG_AMIGA_Z2RAM)
{ "ram", 0x0100 },
- { "scd", 0x0b00 },
+#endif
+#ifdef CONFIG_MCD
{ "mcd", 0x1700 },
+#endif
+#ifdef CONFIG_CDU535
{ "cdu535", 0x1800 },
+#endif
+#ifdef CONFIG_CDU31A
{ "sonycd", 0x1800 },
+#endif
+#ifdef CONFIG_AZTCD
{ "aztcd", 0x1d00 },
+#endif
+#ifdef CONFIG_CM206
{ "cm206cd", 0x2000 },
+#endif
+#ifdef CONFIG_GSCD
{ "gscd",0x1000 },
+#endif
+#ifdef CONFIG_SBPCD
{ "sbpcd", 0x1900 },
+#endif
+#ifdef CONFIG_BLK_DEV_PS2
{ "eda", 0x2400 },
{ "edb", 0x2440 },
+#endif
+#ifdef CONFIG_PARIDE
{ "pda",0x2d00 },
{ "pdb",0x2d10 },
{ "pdc",0x2d20 },
{ "pdd",0x2d30 },
{ "pcd",0x2e00 },
{ "pf", 0x2f00 },
+#endif
+#ifdef CONFIG_APBLOCK
{ "apblock", APBLOCK_MAJOR << 8},
+#endif
+#ifdef CONFIG_DDV
{ "ddv", DDV_MAJOR << 8},
+#endif
+#ifdef CONFIG_SUN_JSFLASH
{
hard lockup using 2.4.1ac-1, usb, uhci
Hey, just found this one out. I've got a sony vaio 505tx, running linux-2.4.1-ac1, and I've got all the good stuff turned. With APM turned, and using USB uhci-alt driver (all as modules), if you put the laptop to sleep with any (and I mean *any*) usb devices plugged in, it will hard lock upon resume. Only way out is to power cycle the poor thing.. I'm going to update to a newer version of the kernel, and see if the other uhci driver suffers from this fate.. -- +-- Thomas Davis| PDSF Project Leader [EMAIL PROTECTED] | (510) 486-4524 | "Only a petabyte of data this year?" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86 ptep_get_and_clear question
> > Kanoj Sarcar wrote: > > > Here's the important part: when processor 2 wants to set the pte's dirty > > > bit, it *rereads* the pte and *rechecks* the permission bits again. > > > Even though it has a non-dirty TLB entry for that pte. > > > > > > That is how I read Ben LaHaise's description, and his test program tests > > > exactly this. > > > > Okay, I will quote from Intel Architecture Software Developer's Manual > > Volume 3: System Programming Guide (1997 print), section 3.7, page 3-27: > > > > "Bus cycles to the page directory and page tables in memory are performed > > only when the TLBs do not contain the translation information for a > > requested page." > > > > And on the same page: > > > > "Whenever a page directory or page table entry is changed (including when > > the present flag is set to zero), the operating system must immediately > > invalidate the corresponding entry in the TLB so that it can be updated > > the next time the entry is referenced." > > > > So, it looks highly unlikely to me that the basic assumption about how > > x86 works wrt tlb/ptes in the ptep_get_and_clear() solution is correct. > > To me those quotes don't address the question we're asking. We know > that bus cycles _do_ occur when a TLB entry is switched from clean to > dirty, and furthermore they are locked cycles. (Don't ask me how I know > this though). > > Does that mean, in jargon, the TLB does not "contain > the translation information" for a write? > > The second quote: sure, if we want the TLB updated we have to flush it. > And eventually in mm/mprotect.c we do. But what before, it keeps on > using the old TLB entry? That's ok. If the entry was already dirty > then we don't mind if processor 2 continues with the old TLB entry for a > while, until we do the big TLB range flush. > > In other words I don't think those two quotes address our question at > all. Agreed. But these are the only relevant quotes I could come up with. And to me, these quotes make the ptep_get_and_clear() assumption look risky at best ... even though they do not give clear answers either way. > > What worries more is that this is quite a subtle requirement, and the > code in mm/mprotect.c is not specific to one architecture. Do all SMP > CPUs support by Linux do the same thing on converting TLB entries from > clean to dirty, or do they have a subtle, easily missed data integrity > problem? No. All architectures do not have this problem. For example, if the Linux "dirty" (not the pte dirty) bit is managed by software, a fault will actually be taken when processor 2 tries to do the write. The fault is solely to make sure that the Linux "dirty" bit can be tracked. As long as the fault handler grabs the right locks before updating the Linux "dirty" bit, things should be okay. This is the case with mips, for example. The problem with x86 is that we depend on automatic x86 dirty bit update to manage the Linux "dirty" bit (they are the same!). So appropriate locks are not grabbed. Kanoj > > -- Jamie > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86 ptep_get_and_clear question
Kanoj Sarcar wrote: > > Okay, I will quote from Intel Architecture Software Developer's Manual > Volume 3: System Programming Guide (1997 print), section 3.7, page 3-27: > > "Bus cycles to the page directory and page tables in memory are performed > only when the TLBs do not contain the translation information for a > requested page." > > And on the same page: > > "Whenever a page directory or page table entry is changed (including when > the present flag is set to zero), the operating system must immediately > invalidate the corresponding entry in the TLB so that it can be updated > the next time the entry is referenced." > But there is another paragraph that mentions that an OS may use lazy tlb shootdowns. [search for shootdown] You check the far too obvious chapters, remember that Intel wrote the documentation ;-) I searched for 'dirty' though Vol 3 and found Chapter 7.1.2.1 Automatic locking. .. the processor uses locked cycles to set the accessed and dirty flag in the page-directory and page-table entries. But that obviously doesn't answer your question. Is the sequence << lock; read pte pte |= dirty write pte >> end lock; or << lock; read pte if (!present(pte)) do_page_fault(); pte |= dirty write pte. >> end lock; -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel lock contention and scalability
To discover possible locking limitations to scalability, I have collected locking statistics on a 2-way, 4-way, and 8-way performing as networked database servers. I patched the [48]-way kernels with Kravetz's multiqueue patch in the hope that mitigating runqueue_lock contention might better reveal other lock contention. In the attached document, I describe my test environment and excerpt lockstat output to show the more contentious locks for a typical run on each of my server configurations. I'm interested in comparing these data to other lock contention data, so information regarding previous or ongoing lock contention work would be appreciated. I'm aware of timer scalability work ongoing at people.redhat.com/mingo/scalable-timers, but is anyone working on reducing sem_ids contention? -- Jonathan Lahr IBM Linux Technology Center Beaverton, Oregon [EMAIL PROTECTED] 503-578-3385 server configuration: hardware: memory: 2-way: .5 Gb 4-way: 1 Gb 8-way: 1 Gb cpus: 2-way: Pentium II, 300 MHz [48]-way: Pentium III, 700 MHz NICs: 100 Mbps ethernet (2) software: distribution: Redhat 7.0 kernel: 2-way: 2.4.0-test10 patched with lockmeter1.4.5-2.4.0 [48]-way: 2.4.0 patched with lockmeter1.4.5-2.4.0, 2.4.0.MQ1-sched.rt database: postgresql-7.0.2-17 client: pgbench (distributed with postgresql) lockstat excerpts: 2way: SPINLOCKS HOLD WAIT UTIL CONMEAN ( MAX ) MEAN ( MAX ) TOTAL NOWAIT SPIN REJECT NAME 4.04% 1.22%50us( 3344us) 5.2us( 2014us) 36515 36068 447 0 kernel_flag 0.01% 3.47%46us( 427us)17us( 2014us)144139 5 0do_coredump+0x24 0.00% 0.00% 960us( 960us) 0us1 1 0 0do_exit+0x94 0.00% 4.00% 2.0us( 4.2us)75us( 1876us) 25 24 1 0ext2_discard_prealloc+0x24 0.03% 0.70%11us( 1048us) 1.3us( 682us) 1144 1136 8 0ext2_get_block+0x50 1.78% 0.79% 455us( 3344us) 0.8us( 759us) 1766 1752 14 0ext2_sync_file+0x28 0.62% 0.84%12us( 1289us) 2.5us( 1717us) 23353 23157 196 0real_lookup+0x68 1.46% 1.29% 186us( 2980us) 5.4us( 1824us) 3553 3507 46 0schedule+0x490 0.01% 0.00% 456us( 596us) 0us9 9 0 0sync_old_buffers+0x20 0.01% 1.83% 9.4us(84us) 0.7us(92us)328322 6 0sys_fcntl64+0x44 0.00% 3.87% 8.0us( 329us) 6.7us( 1011us)155149 6 0sys_ioctl+0x48 0.02% 2.79% 1.9us( 805us)19us( 1986us) 5483 5330 153 0sys_lseek+0x70 0.00% 0.00%22us(22us) 0us1 1 0 0sys_sysctl+0x50 0.01% 3.23%17us(84us) 0.5us(25us)155150 5 0tty_read+0xbc 0.02% 2.35%39us( 110us) 0.2us(11us)213208 5 0tty_write+0x1dc 0.07% 1.09% 168us( 1442us) 0.7us( 116us)184182 2 0vfs_readdir+0x70 0.00% 0.00%31us(31us) 0us1 1 0 0vfs_statfs+0x54 24.38% 23.93%15us( 218us) 4.3us( 111us) 744475 566289 178186 0 runqueue_lock 0.06% 15.97% 4.5us(26us) 2.6us(67us) 5592 4699 893 0__wake_up+0xdc 0.00% 10.27% 0.4us( 1.3us) 1.5us(60us)146131 15 0deliver_signal+0x58 1.16% 8.59% 1.5us(27us) 2.3us( 111us) 360313 329373 30940 0process_timeout+0x14 0.00% 0.00% 0.6us( 0.6us) 0us1 1 0 0release+0x28 23.15% 38.78%28us( 218us) 6.2us( 108us) 376292 230381 145911 0schedule+0xe0 0.01% 45.34% 3.7us(24us)16us(82us)686375 311 0schedule+0x458 0.00% 0.00% 2.8us(70us) 0us 89 89 0 0schedule+0x504 0.01% 8.55% 3.0us(18us) 1.9us(68us) 1356 1240 116 0wake_up_process+0x14 0.11% 4.97%12us( 1113us) 1.0us( 1540us) 4041 3840 201 0 sem_ids+0x24 0.00% 1.32% 7.1us(88us) 0.1us(11us)303299 4 0semctl_main+0x4c 0.06% 3.85%11us( 281us) 0.5us(81us) 2392 2300 92 0
Re: MTU and 2.4.x kernel
> with bogus mtu values sort of 552 or even 296, but also jailed them > to some proxy or masquearding domain), but it is still right: IP > with mtu lower 576 is not full functional. Please cite an exact RFC reference. The 576 byte requirement is for reassembled packets handled by the host. That is if you send a 576 byte frame you know the other end will be able to put it back together. Our handling of DF on syn frames is also broken due to that misassumption, but fortunately only for crazy mtus like 70. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86 ptep_get_and_clear question
Kanoj Sarcar wrote: > > Here's the important part: when processor 2 wants to set the pte's dirty > > bit, it *rereads* the pte and *rechecks* the permission bits again. > > Even though it has a non-dirty TLB entry for that pte. > > > > That is how I read Ben LaHaise's description, and his test program tests > > exactly this. > > Okay, I will quote from Intel Architecture Software Developer's Manual > Volume 3: System Programming Guide (1997 print), section 3.7, page 3-27: > > "Bus cycles to the page directory and page tables in memory are performed > only when the TLBs do not contain the translation information for a > requested page." > > And on the same page: > > "Whenever a page directory or page table entry is changed (including when > the present flag is set to zero), the operating system must immediately > invalidate the corresponding entry in the TLB so that it can be updated > the next time the entry is referenced." > > So, it looks highly unlikely to me that the basic assumption about how > x86 works wrt tlb/ptes in the ptep_get_and_clear() solution is correct. To me those quotes don't address the question we're asking. We know that bus cycles _do_ occur when a TLB entry is switched from clean to dirty, and furthermore they are locked cycles. (Don't ask me how I know this though). Does that mean, in jargon, the TLB does not "contain the translation information" for a write? The second quote: sure, if we want the TLB updated we have to flush it. And eventually in mm/mprotect.c we do. But what before, it keeps on using the old TLB entry? That's ok. If the entry was already dirty then we don't mind if processor 2 continues with the old TLB entry for a while, until we do the big TLB range flush. In other words I don't think those two quotes address our question at all. What worries more is that this is quite a subtle requirement, and the code in mm/mprotect.c is not specific to one architecture. Do all SMP CPUs support by Linux do the same thing on converting TLB entries from clean to dirty, or do they have a subtle, easily missed data integrity problem? -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.1-ac14 tulip woes
Nathan Walp wrote: > > The fix in ac14 for the ac13 patch that killed the tulip driver doesn't > quite work either: > I need more details: does it immediately time out (after a few seconds), or a after a few minutes. Which network speed do you use? 100MBit half duplex? Could you please run the tulip-diag program I send you yesterday? #tulip-diag -mm -aa -f both before and after the hang. Thanks, Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA chipset problems with 2.2?
On Thu, Feb 15, 2001 at 06:33:36AM -0500, safemode wrote: > > What's the nature of the VIA chipset problems? I want to get a new system > > There are no problems with 2.2.x. I'm very glad to hear that because the AMD chips are the obvious choice for a lot of people(all?). > (classic), get the KA7 by abit. Duron and T-bird should get KT7 or > something like that .I'd use alan cox's latest patch. >From kernelnotes? Do you have a link so I'm sure? > They work great. > Awesome performance. As good as linux gets. That sounds favorable :~) Thanks, Mike -- signature pending - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86 ptep_get_and_clear question
> > [Added Linus and linux-kernel as I think it's of general interest] > > Kanoj Sarcar wrote: > > Whether Jamie was trying to illustrate a different problem, I am not > > sure. > > Yes, I was talking about pte_test_and_clear_dirty in the earlier post. > > > Look in mm/mprotect.c. Look at the call sequence change_protection() -> ... > > change_pte_range(). Specifically at the sequence: > > > > entry = ptep_get_and_clear(pte); > > set_pte(pte, pte_modify(entry, newprot)); > > > > Go ahead and pull your x86 specs, and prove to me that between the > > ptep_get_and_clear(), which zeroes out the pte (specifically, when the > > dirty bit is not set), processor 2 can not come in and set the dirty > > bit on the in-memory pte. Which immediately gets overwritten by the > > set_pte(). For an example of how this can happen, look at my previous > > postings. > > Let's see. We'll assume processor 2 does a write between the > ptep_get_and_clear and the set_pte, which are done on processor 1. > > Now, ptep_get_and_clear is atomic, so we can talk about "before" and > "after". Before it, either processor 2 has a TLB entry with the dirty > bit set, or it does not (it has either a clean TLB entry or no TLB entry > at all). > > After ptep_get_and_clear, processor 2 does a write. If it already has a > dirty TLB entry, then `entry' will also be dirty so the dirty bit is > preserved. If processor 2 does not have a dirty TLB entry, then it will > look up the pte. Processor 2 finds the pte is clear, so raises a page fault. > Spinlocks etc. sort everything out in the page fault. > > Here's the important part: when processor 2 wants to set the pte's dirty > bit, it *rereads* the pte and *rechecks* the permission bits again. > Even though it has a non-dirty TLB entry for that pte. > > That is how I read Ben LaHaise's description, and his test program tests > exactly this. Okay, I will quote from Intel Architecture Software Developer's Manual Volume 3: System Programming Guide (1997 print), section 3.7, page 3-27: "Bus cycles to the page directory and page tables in memory are performed only when the TLBs do not contain the translation information for a requested page." And on the same page: "Whenever a page directory or page table entry is changed (including when the present flag is set to zero), the operating system must immediately invalidate the corresponding entry in the TLB so that it can be updated the next time the entry is referenced." So, it looks highly unlikely to me that the basic assumption about how x86 works wrt tlb/ptes in the ptep_get_and_clear() solution is correct. Kanoj > > If the processor worked by atomically setting the dirty bit in the pte > without rechecking the permissions when it reads that pte bit, then this > scheme would fail and you'd be right about the lost dirty bits. I would > have thought it would be simpler to implement a CPU this way, but > clearly it is not as efficient for SMP OS design so perhaps CPU > designers thought about this. > > The only remaining question is: is the observed behaviour defined for > x86 CPUs in general, or are we depending on the results of testing a few > particular CPUs? > > -- Jamie > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MTU and 2.4.x kernel
Hello! > Kernel 2.4.x apparently disregards my ppp options MTU setting of 552 > and sets mss=536 (=> MTU=576). Yes, default configuration is not allowed to advertise mss<536. The limit is controlled via /proc/sys/net/ipv4/route/min_adv_mss, you can change it to 256. Default of 536 is sadistic (and apaprently will be changed eventually to stop tears of poor people whose providers not only supply them with bogus mtu values sort of 552 or even 296, but also jailed them to some proxy or masquearding domain), but it is still right: IP with mtu lower 576 is not full functional. Alexey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
strange tcp errors
Messages in my kernel log: node1 kernel: sending pkt_too_big to self node1 kernel: KERNEL: assertion (tp->lost_out == 0) failed at tcp_input.c(1202):tcp_remove_reno_sacks Kernel 2.4.1-ac13. Maybe someone want to say me what does it mean and how serious it is? Any fixes? Thanks. -- Andrius [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Crypto patches for losetup
I'm trying to update some patches of Harald's to work with the official 2.4.0 international patches. He had a very nice unofficial patch set that doesn't use a table, it just sees what is in /proc/crypto. I fixed a few bugs and it worked marvelously with unofficial test9 patches all the way up to t12. However the official patches have changed the data structure underlying the "files", ie /proc/crypto/cipher/twofish-ecb no longer has int t_id; it has int t_flags instead. And it isn't just a name change, it does something entirely different. Since Harald's code depended on predefined id's in the international patches, that broke it pretty thoroughly. I'm looking at them to see if I can excise that dependance entirely. I think I can, but I'd like someone who I could chat with about some of the underlying reasons for certain things being there. Harald is busy with other things and can't take time off to refresh himself on the contents of the patch-int's enough to help. I'm working on some mods now but I can see a couple ways to go and I'd rather pick the right one first time. Please contact me directly, [EMAIL PROTECTED]; since the LK-digest went away I've been finding I often (mostly?) miss things in the flood of thousands of itty bitty messages :-) -- -- Use Linux: A computerDale Amon, CEO/MD is a terrible thing Village Networking Ltd to waste.Belfast, Northern Ireland -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.1-ac14 tulip woes
The fix in ac14 for the ac13 patch that killed the tulip driver doesn't quite work either: Feb 15 13:04:16 patience kernel: LDT allocated for cloned task! Feb 15 13:04:55 patience kernel: NETDEV WATCHDOG: eth0: transmit timed out Feb 15 13:05:27 patience last message repeated 4 times Feb 15 13:06:31 patience last message repeated 8 times Feb 15 13:07:35 patience last message repeated 8 times Feb 15 13:07:59 patience last message repeated 3 times Feb 15 13:08:07 patience kernel: NETDEV WATCHDOG: eth0: transmit timed out Feb 15 13:08:39 patience last message repeated 4 times Feb 15 13:08:41 patience init: Switching to runlevel: 6 lspci -v from ac13 w/ ac12 tulip driver: 00:0a.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20) Subsystem: Netgear FA310TX Flags: bus master, medium devsel, latency 32, IRQ 5 I/O ports at 9800 [size=256] Memory at e000 (32-bit, non-prefetchable) [size=256] Expansion ROM at [disabled] [size=256K] dmesg snippet from ac13 w/ ac12 tulip driver: PCI: Found IRQ 5 for device 00:0a.0 eth0: Lite-On 82c168 PNIC rev 32 at 0x9800, 00:A0:CC:61:CC:D2, IRQ 5. eth0: MII transceiver #1 config 3000 status 7829 advertising 01e1. Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86 ptep_get_and_clear question
> > [Added Linus and linux-kernel as I think it's of general interest] > > Kanoj Sarcar wrote: > > Whether Jamie was trying to illustrate a different problem, I am not > > sure. > > Yes, I was talking about pte_test_and_clear_dirty in the earlier post. > > > Look in mm/mprotect.c. Look at the call sequence change_protection() -> ... > > change_pte_range(). Specifically at the sequence: > > > > entry = ptep_get_and_clear(pte); > > set_pte(pte, pte_modify(entry, newprot)); > > > > Go ahead and pull your x86 specs, and prove to me that between the > > ptep_get_and_clear(), which zeroes out the pte (specifically, when the > > dirty bit is not set), processor 2 can not come in and set the dirty > > bit on the in-memory pte. Which immediately gets overwritten by the > > set_pte(). For an example of how this can happen, look at my previous > > postings. > Now you are talking my language! > Let's see. We'll assume processor 2 does a write between the > ptep_get_and_clear and the set_pte, which are done on processor 1. > > Now, ptep_get_and_clear is atomic, so we can talk about "before" and > "after". Before it, either processor 2 has a TLB entry with the dirty > bit set, or it does not (it has either a clean TLB entry or no TLB entry > at all). > > After ptep_get_and_clear, processor 2 does a write. If it already has a > dirty TLB entry, then `entry' will also be dirty so the dirty bit is > preserved. If processor 2 does not have a dirty TLB entry, then it will > look up the pte. Processor 2 finds the pte is clear, so raises a page fault. > Spinlocks etc. sort everything out in the page fault. > > Here's the important part: when processor 2 wants to set the pte's dirty > bit, it *rereads* the pte and *rechecks* the permission bits again. > Even though it has a non-dirty TLB entry for that pte. > > That is how I read Ben LaHaise's description, and his test program tests > exactly this. > Okay, I asked Ben, he couldn't point me at specs and shut me up. > If the processor worked by atomically setting the dirty bit in the pte > without rechecking the permissions when it reads that pte bit, then this > scheme would fail and you'd be right about the lost dirty bits. I would Exactly. This is why I did not implement this scheme earlier when Alan and I talked about this scenario, almost a couple of years back. > have thought it would be simpler to implement a CPU this way, but > clearly it is not as efficient for SMP OS design so perhaps CPU > designers thought about this. > > The only remaining question is: is the observed behaviour defined for > x86 CPUs in general, or are we depending on the results of testing a few > particular CPUs? Exactly! So my claim still stands: ptep_get_and_clear() doesn't do what it claims to do. I would be more than happy if someone can give me logic to break this claim ... which would mean one longstanding data integrity problem on Linux has been fixed satisfactorily. Kanoj > > -- Jamie > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux stifles innovation...
>> repeated exposition to Linux... Hey isn't that _exposure_ to Linux? Or one of Dubya's words? Like strategery? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of fsnchzjr Sent: Thursday, February 15, 2001 12:49 PM To: '[EMAIL PROTECTED]' Subject: Linux stifles innovation... Watch Microsoft's Jim Allchin go Linux-bashing!!! Nice little article on how we're all going to die of herpes from our repeated exposition to Linux... http://news.cnet.com/investor/news/newsitem/0-9900-1028-4825719-RHAT.html?ta g=ltnc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux stifles innovation...
* fsnchzjr ([EMAIL PROTECTED]) wrote: > Watch Microsoft's Jim Allchin go Linux-bashing!!! > Nice little article on how we're all going to die of herpes from our > repeated exposition to Linux... > http://news.cnet.com/investor/news/newsitem/0-9900-1028-4825719-RHAT.html?tag=ltnc Just remember, the tag is 'ltnc' --> 'long-time, no clue'. Stephen PGP signature
Re: 2.4.x/alpha/ALI chipset/IDE problems summary Re: 2.4.1 not fullysane on Alpha - file systems
Well, the situation is improving, I suppose ... Under kernel 2.4.0 and 2.4.1, a dd of about 1 4k blocks would cause the system to go technicolor and lock up. Now, under 2.4.1-ac13, at about 11000 blocks, it goes technicolor, but doesn't lock up until somewhere between 13000 and 2. *wry shrug* - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux stifles innovation...
Watch Microsoft's Jim Allchin go Linux-bashing!!! Nice little article on how we're all going to die of herpes from our repeated exposition to Linux... http://news.cnet.com/investor/news/newsitem/0-9900-1028-4825719-RHAT.html?ta g=ltnc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Loopback status
What's the current status of the loop-# patch? Haven't seen anything since loop-4, which doesn't apply clean to 2.4.1-ac14 (one hunk is rejected in loop.c, many others apply with fuzz). I am waiting in anticipation of the folding of this patch into the mainline kernel. IIRC, Jens said he was working on a loop-5, but that was a week or two ago. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
