Re: crash 5/5 w/ memtest86
After getting several segfaults running fetchmail, I tried memtest86 for the first time on my PC (Celeron 500, i810m/b from e-machines). Five out of five tries from two different floppy disks crashed at 6% into test 1. Does the machine in question have 256 MB of RAM, perchance? I ask because 6% or 256Mb it about 15MB or so and some motherboards have a BIOS setting for a "memory hole at 15MB" (or something like that), which might be the cause. Then again, it might not. -Daz. - 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/
VIA chipset problems with 2.2?
Hello, What's the nature of the VIA chipset problems? I want to get a new system this weekend but I read on kernel traffic that VIA has problems? I wan't to use Hendrick's ide patches on 2.2.18. What board should I get? Help, I've searched through usenet and asked on #linux without anything conclusive. Thanks, Mike From KT: David Riley [*] reported tremendous slowdowns in 2.4.1-pre11 and -pre12 on his Athlon 900 with a KT133 chipset. Mark Hahn [*] replied, "this is known: Linus decreed that, since two people reported disk corruption on VIA, any machine with a VIA southbridge must boot in stupid 1992 mode (PIO). (yes, it might be possible to boot with ide=autodma or something, but who would guess?)" He added to Linus Torvalds [*], "I hope you don't consider this a releasable state! VIA now owns 40% of the chipset market..." Linus replied: So find somebody who can figure out why the corruption happens, and I'll be really happy with a patch that fixes it. In the meantime, "releaseable" very much means that we did _everything_ possible to make sure that people don't screw their disks over. You have to realize that stability takes precedence over EVERYTHING. -- 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: [LK] Re: lkml subject line
On Tue, 13 Feb 2001, Mike A. Harris wrote: If the above procmail filter doesn't work (untested) let me know and I will MAKE it work. Windows users - tough luck - procmail is open source - hire someone to port it... and even windows users can filter properly. netscape allows you to add custom headers to filter on. So absolutely no problems for netscape users. Those tied to outlook (as i was when i worked at compaq, until i found an exchange server that did imap) also have no need to complain as i managed to get it to filter l-k without problems - use the outlook "Ru1eZ W1z4Rd" to setup a filter to catch anything "sent from linux-kernel@..." and then another filter to look for the l-k list info text included at the bottom of every mail. (this rule should be last.) hey presto, l-k neatly filtered away with Outlook. if you use an MUA that can't do filtering, well then there's something wrong with you --paulj - 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: NFS mounting delays w/ 2.4.x kernel?
" " == List User [EMAIL PROTECTED] writes: I've seen reference to this before (I think on this list) but didn't pay attention to them at the time. I am now running into this problem myself. I've just upgraded one of my NFS servers here from 2.2.17 - 2.4.1 ). I'm running the user-space server nfs-server-2.2beta48 (tried beta47 as well). Current versions of mount, et al. When booting I get the following errors: --- Mounted devfs on /dev Trying to unmount old root ... okay Freeing unused kernel memory: 228k freed Adding Swap: 1048568k swap-space (priority -1) portmap: server localhost not responding, timed out portmap: server localhost not responding, timed out lockd_up: makesock failed, error=-5 portmap: server localhost not responding, timed out - You need to add 'nolock' to your mount options. Unfsd doesn't support NLM locking, and it's causing the lockd daemon to be started (which again requires the portmapper to be installed etc.). Cheers, Trond - 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: More (other) NIC info/Problem: NIC doesn't work anymore, SIOCIFADDR-errors
Rob Cermak wrote: Anyone who can tell me what's going on here? Perhaps it's the 'dev-memstart==~0' bug I found yesterday? Could you go into line 450 of 3c509.c and replace - dev-if_port = (dev-mem_start 0x1f) ?dev-mem_start 3: if_port; + printk(KERN_WARNING "%s: mem_start is %lxh.\n",dev-name, dev-mem_start); + dev-if_port = if_port; -- 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/
[ANNONCE] Kernel Autoconfiguration utility v.0.9.1.2
Hello! I just release a new verion of kernel autoconfig. The kernel autoconfiguration utility will help user to detect and configure the kernel. The detection is soft, thus no hangs! It is still in test phase, thus now it prints only the proposed configuration. To change real configurations, I'm still waiting for a working CML2. On my hardware database there are: 1007 pci cards 111 devices (block and char) 37 file systems 7 console drivers 8 net protocols 511 resources strings. + some extra special detection. Project homepage: http://sourceforge.net/projects/kautoconfigure/ How to use: (now, testing phase) unpack the files (better: in a new directory) bash autoconfigure.sh | less check the output. no super user privileges required! I need some help: - Some drivers detect pci in a strange way, I could not check every files. Please check if your cards are included. - Check, add extra detections I will do: - updates to the database when a new official kernel version is released - interface with CML2 (partially done, but CML2-9.0.1 has still bugs) - better 'CONFIG_*=N' handling (e.g. I will check is a drivers depends on PCI. If this PCI card is not found, I can safely tell you that the device is not in the box). - generate inverse dependences. Comments? giacomo PS. I have done the autodetection reading the source and not using real hardware, thus ... no warranty. PPS: This tools is designed mainly for newbies (in kernel compiling...), thus I don't expect to have a real autodetection on very special machines. [But I expect in the future to do this :-) ] - 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/
Netmos PCI parallel card
Hi,
Attached is a patch to make a Netmos PCI parallal port card working.
Card is a PCI card with a Netmos 9705 controller and an Atmel serial
eeprom.
Regards,
Igmar
--
--
Igmar Palsenberg
JDI Media Solutions
Jansplaats 11
6811 GB Arnhem
The Netherlands
mailto: [EMAIL PROTECTED]
PGP/GPG key : http://www.jdimedia.nl/formulier/pgp/igmar
00:00.0 Class 0600: 8086:7122 (rev 03)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort-
MAbort+ SERR- PERR-
Latency: 0 set
00:01.0 Class 0300: 8086:7123 (rev 03)
Subsystem: 8086:0200
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort-
MAbort- SERR- PERR-
Latency: 0 set
Interrupt: pin A routed to IRQ 11
Region 0: Memory at ec00 (32-bit, prefetchable)
Region 1: Memory at ffe8 (32-bit, non-prefetchable)
Capabilities: [dc] Power Management version 1
Flags: PMEClk- AuxPwr- DSI+ D1- D2- PME-
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:1e.0 Class 0604: 8086:2418 (rev 01)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort-
MAbort- SERR- PERR-
Latency: 0 set
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
I/O behind bridge: d000-dfff
Memory behind bridge: ffc0-ffcf
Prefetchable memory behind bridge: e7e0-e7ef
BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- Reset- FastB2B-
00:1f.0 Class 0601: 8086:2410 (rev 01)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping-
SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort-
MAbort- SERR- PERR-
Latency: 0 set
00:1f.1 Class 0101: 8086:2411 (rev 01) (prog-if 80 [Master])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort-
MAbort- SERR- PERR-
Latency: 0 set
Region 4: I/O ports at ffa0
00:1f.2 Class 0c03: 8086:2412 (rev 01)
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort-
MAbort- SERR- PERR-
Latency: 0 set
Interrupt: pin D routed to IRQ 5
Region 4: I/O ports at ef80
00:1f.3 Class 0c05: 8086:2413 (rev 01)
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort-
MAbort- SERR- PERR-
Interrupt: pin B routed to IRQ 10
Region 4: I/O ports at efa0
01:05.0 Class 0200: 10ec:8029
Subsystem: 10ec:8029
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort-
MAbort- SERR- PERR-
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at df80
01:0b.0 Class 0701: 9710:9705 (rev 01) (prog-if 02)
Subsystem: 1000:0010
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort-
MAbort- SERR- PERR-
Interrupt: pin A routed to IRQ 5
Region 0: I/O ports at df00
--- linux/include/linux/pci.h.orig Thu Feb 15 11:18:43 2001
+++ linux/include/linux/pci.h Thu Feb 15 11:52:27 2001
@@ -1268,6 +1268,9 @@
#define PCI_DEVICE_ID_INTERPHASE_5526 0x0004
#define PCI_DEVICE_ID_INTERPHASE_55x6 0x0005
+#define PCI_VENDOR_ID_NETMOS 0x9710
+#define PCI_VENDOR_ID_NETMOS_9705 0x9705
+
/*
* The PCI interface treats multi-function devices as independent
* devices. The slot/function address of each device is encoded
--- linux/drivers/misc/parport_pc.c.origThu Feb 15 11:49:00 2001
+++ linux/drivers/misc/parport_pc.c Thu Feb 15 11:53:21 2001
@@ -910,6 +910,8 @@
{ { 0, -1 }, } },
{ PCI_VENDOR_ID_OXSEMI, PCI_DEVICE_ID_OXSEMI_12PCI840, 1,
{ { 0, 1 }, } },
+ { PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9705, 1,
+ { { 0, -1 }, } },
{ 0, }
};
--- linux/drivers/pci/oldproc.c.origThu Feb 15 11:30:36 2001
+++ linux/drivers/pci/oldproc.c Thu Feb 15 11:30:06 2001
@@ -947,6 +947,7 @@
case PCI_VENDOR_ID_TIGERJET: return
RE: NFSD die with 2.4.1 (resend with ksymoops)
Here I am again! NFSD died at 11h23, ~12 hours after the last reboot, a record :-) 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. I have tried without them, with exactly the same behaviour. Thanks -jec Dump of assembler code for function nfssvc_encode_diropres: 0xc0173710 nfssvc_encode_diropres:sub$0x8,%esp 0xc0173713 nfssvc_encode_diropres+3: push %ebp 0xc0173714 nfssvc_encode_diropres+4: push %edi 0xc0173715 nfssvc_encode_diropres+5: push %esi 0xc0173716 nfssvc_encode_diropres+6: push %ebx 0xc0173717 nfssvc_encode_diropres+7: mov$0x8,%ecx 0xc017371c nfssvc_encode_diropres+12: mov0x20(%esp,1),%ebx 0xc0173720 nfssvc_encode_diropres+16: mov0x24(%esp,1),%eax 0xc0173724 nfssvc_encode_diropres+20: lea0x4(%eax),%esi 0xc0173727 nfssvc_encode_diropres+23: mov%ebx,%edi 0xc0173729 nfssvc_encode_diropres+25: repz movsl %ds:(%esi),%es:(%edi) 0xc017372b nfssvc_encode_diropres+27: add$0x20,%ebx 0xc017372e nfssvc_encode_diropres+30: mov%ebx,%ebp 0xc0173730 nfssvc_encode_diropres+32: test %ebp,%ebp 0xc0173732 nfssvc_encode_diropres+34: je 0xc01738bb nfssvc_encode_diropres+427 0xc0173738 nfssvc_encode_diropres+40: mov0x44(%eax),%eax 0xc017373b nfssvc_encode_diropres+43: mov0x8(%eax),%eax 0xc017373e nfssvc_encode_diropres+46: mov%eax,0x10(%esp,1) 0xc0173742 nfssvc_encode_diropres+50: mov0x10(%esp,1),%ecx 0xc0173746 nfssvc_encode_diropres+54: movzwl 0x2a(%eax),%eax 0xc017374a nfssvc_encode_diropres+58: mov%ax,0x16(%esp,1) 0xc017374f nfssvc_encode_diropres+63: mov0x8c(%ecx),%eax 0xc0173755 nfssvc_encode_diropres+69: test %eax,%eax 0xc0173757 nfssvc_encode_diropres+71: je 0xc017379f nfssvc_encode_diropres+143 0xc0173759 nfssvc_encode_diropres+73: testb $0x4,0x24(%eax) 0xc017375d nfssvc_encode_diropres+77: je 0xc017379f nfssvc_encode_diropres+143 0xc017375f nfssvc_encode_diropres+79: mov0x84(%ecx),%eax 0xc0173765 nfssvc_encode_diropres+85: test %eax,%eax 0xc0173767 nfssvc_encode_diropres+87: je 0xc017379f nfssvc_encode_diropres+143 0xc0173769 nfssvc_encode_diropres+89: push $0x8000 0xc017376e nfssvc_encode_diropres+94: push %ecx 0xc017376f nfssvc_encode_diropres+95: mov0x48(%eax),%eax 0xc0173772 nfssvc_encode_diropres+98: call *%eax 0xc0173774 nfssvc_encode_diropres+100:mov%eax,%ebx 0xc0173776 nfssvc_encode_diropres+102:add$0x8,%esp 0xc0173779 nfssvc_encode_diropres+105:cmp$0xfc18,%ebx 0xc017377f nfssvc_encode_diropres+111:ja 0xc01737a6 nfssvc_encode_diropres+150 0xc0173781 nfssvc_encode_diropres+113:test %ebx,%ebx 0xc0173783 nfssvc_encode_diropres+115:je 0xc017379f nfssvc_encode_diropres+143 0xc0173785 nfssvc_encode_diropres+117:lea0x16(%esp,1),%eax 0xc0173789 nfssvc_encode_diropres+121:push %eax 0xc017378a nfssvc_encode_diropres+122:push %ebx 0xc017378b nfssvc_encode_diropres+123:call 0xc01498e4 posix_acl_masq_nfs_v2_mode 0xc0173790 nfssvc_encode_diropres+128:mov%eax,%esi 0xc0173792 nfssvc_encode_diropres+130:push %ebx 0xc0173793 nfssvc_encode_diropres+131:call 0xc0149474 posix_acl_release 0xc0173798 nfssvc_encode_diropres+136:add$0xc,%esp 0xc017379b nfssvc_encode_diropres+139:test %esi,%esi 0xc017379d nfssvc_encode_diropres+141:jne0xc01737a6 nfssvc_encode_diropres+150 0xc017379f nfssvc_encode_diropres+143:cmpl $0x0,0x10(%esp,1) 0xc01737a4 nfssvc_encode_diropres+148:jne0xc01737b0 nfssvc_encode_diropres+160 0xc01737a6 nfssvc_encode_diropres+150:xor%edx,%edx 0xc01737a8 nfssvc_encode_diropres+152:jmp0xc01738bb nfssvc_encode_diropres+427 0xc01737ad nfssvc_encode_diropres+157:lea0x0(%esi),%esi 0xc01737b0 nfssvc_encode_diropres+160:mov0x10(%esp,1),%edi 0xc01737b4 nfssvc_encode_diropres+164:movzwl 0x2a(%edi),%eax 0xc01737b8 nfssvc_encode_diropres+168:shr$0xc,%ax 0xc01737bc nfssvc_encode_diropres+172:and$0x,%eax 0xc01737c1 nfssvc_encode_diropres+177:lea0x14(%ebp),%esi 0xc01737c4
Re: Aic7xxx troubles with 2.4.1ac6
On Thu, Feb 08, 2001 at 06:16:01PM +0200, you [Ville Herva] claimed: On Thu, Feb 08, 2001 at 07:53:55AM -0500, you [Doug Ledford] claimed: Ville Herva wrote: It looks like ac6 (which I believe includes the patch you posted) is still a no-go with 7892. The boot halts and it just prints this once a second: (SCSI0:0:3:1) Synchronous at 160 Mbyte/sec offset 31 (SCSI0:0:3:1) CRC error during data in phase (SCSI0:0:3:1) CRC error in intermediate CRC packet Check your cables, especially the connector on the card and the drive. Look for any possible bent pins. The message you are seeing is *usually*, but not always, a legitimate data corruption issue. It doesn't show up under the 5.2.1 driver because it limits your Quantum drive to 80MByte/s and that particular speed doesn't include CRC checking. On this driver you have to be running at 160MByte/s before CRC checking is enabled. I checked the cables. I think HP didn't supply proper 160 MB/S capable cables (aren't those the ones with wattlings?). When I forced the drive to 80MB/s from bios, not only did aic7xxx/ac6 work like charm, but the BIOS also found the "missing" MBR. Stupid problem ;). Umm, I think I said that too early. I begun to have problem even during boot; the scsi bios did recognize the drive, but the bios didn't find the boot record. This was completely cured by forcing the drive to 80MB/s mode. So I think the cable wasn't Ultra160 capable. However, the 2.4.1ac6, 2.4.1ac2 and 2.19pre6 aic7xxx.c still had trouble with the drive. I went back to 80MB/s, 40MB/s and even 20MB/s, but that still didn't help. 2.4.1* reported time out while waiting for a command and would go into an endless loop resetting the bus. 2.2.19pre6 said there was an error during the data in phase, but after some coughing it booted up and seemed to work quite alright. NT4 booted up without and visible problems. The HP service guy changed the motherboard (integrated scsi) the cable (to another (80MB/s one), and the drive logics, but that didn't help. The problems first started after the motherboard was first changed (due to separate problem.) The new one had newer bios and scsi bios. Anyhow, I just compiled 2.4.1ac13 with Justin Gibbs's aic7xxx, and it does not suffer of any problem at 80MB/s. -- v -- [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: IRQ (routing ?) problem [was Re: epic100 in current -ac kernels]
Sorry for the delay, I could not get physical access to the machine for the last days. I was able to do some more testing today and found this: - The problem is not the IRQ /sharing/, after getting rid of all the other PCI cards, the problem was still there. - The only thing that seems to have any effect on the symptoms is the presence of the USB driver, either usb-uhci or uhci. I am not using USB at all. As described before, the system behaves is either of those ways: * epic100 driver without DMA mapping (e.g. 2.4.0-ac9): normal operation * driver with DMA mapping+USB driver loaded: lots of interrupts - slow * driver with DMA mapping, USB driver not loaded: hang after ~2 seconds - I sometimes get 'spurious interrupt: IRQ7', even though no device is connected there. Probably not important. On Sat, 10 Feb 2001, Francois Romieu wrote: The following informations may help: - motherboard type Asus A7V, onboard USB hub and Promise ATA/100 chip - bios revision Can't see right now, system was bought in October 2000 I think it was 1.004, but I am not sure. - lspci -x see attachment, this was when I ripped out sound, tv and scsi - 2.4.2pre3 + whatever recent ac epic100 = ? Still no improvement until latest -ac (2.4.1-ac13) Arnd 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02) Subsystem: Asustek Computer, Inc.: Unknown device 8033 Flags: bus master, medium devsel, latency 0 Memory at e700 (32-bit, prefetchable) [size=16M] Capabilities: [a0] AGP version 2.0 Capabilities: [c0] Power Management version 2 00: 06 11 05 03 06 00 10 22 02 00 00 06 00 00 00 00 10: 08 00 00 e7 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 33 80 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305 (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Memory behind bridge: e280-e3df Prefetchable memory behind bridge: e3f0-e6ff Capabilities: [80] Power Management version 2 00: 06 11 05 83 07 00 30 22 00 00 04 06 00 00 01 00 10: 00 00 00 00 00 00 00 00 00 01 01 00 e0 d0 00 00 20: 80 e2 d0 e3 f0 e3 f0 e6 00 00 00 00 00 00 00 00 30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 08 00 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22) Subsystem: Asustek Computer, Inc.: Unknown device 8033 Flags: bus master, stepping, medium devsel, latency 0 00: 06 11 86 06 87 00 10 02 22 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 33 80 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 32 I/O ports at d800 [size=16] Capabilities: [c0] Power Management version 2 00: 06 11 71 05 07 00 90 02 10 8a 01 01 00 20 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 d8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 c0 00 00 00 00 00 00 00 ff 00 00 00 00:04.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10) (prog-if 00 [UHCI]) Subsystem: Unknown device 0925:1234 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at d400 [size=32] Capabilities: [80] Power Management version 2 00: 06 11 38 30 17 00 10 02 10 00 03 0c 08 20 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 d4 00 00 00 00 00 00 00 00 00 00 25 09 34 12 30: 00 00 00 00 80 00 00 00 00 00 00 00 0b 04 00 00 00:04.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10) (prog-if 00 [UHCI]) Subsystem: Unknown device 0925:1234 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at d000 [size=32] Capabilities: [80] Power Management version 2 00: 06 11 38 30 17 00 10 02 10 00 03 0c 08 20 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 d0 00 00 00 00 00 00 00 00 00 00 25 09 34 12 30: 00 00 00 00 80 00 00 00 00 00 00 00 0b 04 00 00 00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) Flags: medium devsel, IRQ 9 Capabilities: [68] Power Management version 2 00: 06 11 57 30 00 00 90 02 30 00 00 06 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 68 00 00 00 00 00 00 00 00 00 00 00 00:0c.0 Ethernet controller: Standard Microsystems Corp [SMC] 83C170QF (rev 08) Subsystem: Standard Microsystems Corp [SMC]: Unknown device a020 Flags: bus master, fast devsel, latency 32, IRQ 10 I/O ports at a400 [size=256]
Re: Aic7xxx troubles with 2.4.1ac6
Ville Herva wrote: On Thu, Feb 08, 2001 at 06:16:01PM +0200, you [Ville Herva] claimed: On Thu, Feb 08, 2001 at 07:53:55AM -0500, you [Doug Ledford] claimed: Ville Herva wrote: It looks like ac6 (which I believe includes the patch you posted) is still a no-go with 7892. The boot halts and it just prints this once a second: (SCSI0:0:3:1) Synchronous at 160 Mbyte/sec offset 31 (SCSI0:0:3:1) CRC error during data in phase (SCSI0:0:3:1) CRC error in intermediate CRC packet Check your cables, especially the connector on the card and the drive. Look for any possible bent pins. The message you are seeing is *usually*, but not always, a legitimate data corruption issue. It doesn't show up under the 5.2.1 driver because it limits your Quantum drive to 80MByte/s and that particular speed doesn't include CRC checking. On this driver you have to be running at 160MByte/s before CRC checking is enabled. I checked the cables. I think HP didn't supply proper 160 MB/S capable cables (aren't those the ones with wattlings?). When I forced the drive to 80MB/s from bios, not only did aic7xxx/ac6 work like charm, but the BIOS also found the "missing" MBR. Stupid problem ;). Umm, I think I said that too early. I begun to have problem even during boot; the scsi bios did recognize the drive, but the bios didn't find the boot record. This was completely cured by forcing the drive to 80MB/s mode. So I think the cable wasn't Ultra160 capable. However, the 2.4.1ac6, 2.4.1ac2 and 2.19pre6 aic7xxx.c still had trouble with the drive. I went back to 80MB/s, 40MB/s and even 20MB/s, but that still didn't help. 2.4.1* reported time out while waiting for a command and would go into an endless loop resetting the bus. 2.2.19pre6 said there was an error during the data in phase, but after some coughing it booted up and seemed to work quite alright. NT4 booted up without and visible problems. The HP service guy changed the motherboard (integrated scsi) the cable (to another (80MB/s one), and the drive logics, but that didn't help. The problems first started after the motherboard was first changed (due to separate problem.) The new one had newer bios and scsi bios. Anyhow, I just compiled 2.4.1ac13 with Justin Gibbs's aic7xxx, and it does not suffer of any problem at 80MB/s. There was a new aic7xxx driver (version 5.2.3) that went into the 2.4.1ac kernel series around 2.4.1-ac7. I would be curious to know if it worked on your machine properly. -- Doug Ledford [EMAIL PROTECTED] http://people.redhat.com/dledford Please check my web site for aic7xxx updates/answers before e-mailing me about problems - 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/
Netmos patch
Hi,
Wrong patch. Attached is the (hopefully) correct one. Or replace the
PCI_VENDOR_ID_NETMOS_9705 with PCI_DEVICE_ID_NETMOS_9705
Regards,
Igmar
--
--
Igmar Palsenberg
JDI Media Solutions
Jansplaats 11
6811 GB Arnhem
The Netherlands
mailto: [EMAIL PROTECTED]
PGP/GPG key : http://www.jdimedia.nl/formulier/pgp/igmar
--- linux/include/linux/pci.h.orig Thu Feb 15 11:18:43 2001
+++ linux/include/linux/pci.h Thu Feb 15 11:52:27 2001
@@ -1268,6 +1268,9 @@
#define PCI_DEVICE_ID_INTERPHASE_5526 0x0004
#define PCI_DEVICE_ID_INTERPHASE_55x6 0x0005
+#define PCI_VENDOR_ID_NETMOS 0x9710
+#define PCI_DEVICE_ID_NETMOS_9705 0x9705
+
/*
* The PCI interface treats multi-function devices as independent
* devices. The slot/function address of each device is encoded
--- linux/drivers/misc/parport_pc.c.origThu Feb 15 11:49:00 2001
+++ linux/drivers/misc/parport_pc.c Thu Feb 15 11:53:21 2001
@@ -910,6 +910,8 @@
{ { 0, -1 }, } },
{ PCI_VENDOR_ID_OXSEMI, PCI_DEVICE_ID_OXSEMI_12PCI840, 1,
{ { 0, 1 }, } },
+ { PCI_VENDOR_ID_NETMOS, PCI_DEVICE_ID_NETMOS_9705, 1,
+ { { 0, -1 }, } },
{ 0, }
};
--- linux/drivers/pci/oldproc.c.origThu Feb 15 11:30:36 2001
+++ linux/drivers/pci/oldproc.c Thu Feb 15 11:30:06 2001
@@ -947,6 +947,7 @@
case PCI_VENDOR_ID_TIGERJET: return "TigerJet";
case PCI_VENDOR_ID_ARK: return "ARK Logic";
case PCI_VENDOR_ID_SYSKONNECT:return "SysKonnect";
+ case PCI_VENDOR_ID_NETMOS:return "Netmos";
default: return "Unknown vendor";
}
}
Re: Aic7xxx troubles with 2.4.1ac6
On Thu, Feb 15, 2001 at 06:08:12AM -0500, you [Doug Ledford] claimed: There was a new aic7xxx driver (version 5.2.3) that went into the 2.4.1ac kernel series around 2.4.1-ac7. I would be curious to know if it worked on your machine properly. Ok. Will try. Are there any changes that could affect? -- v -- [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: VIA chipset problems with 2.2?
"Michael B. Allen" wrote: Hello, What's the nature of the VIA chipset problems? I want to get a new system this weekend but I read on kernel traffic that VIA has problems? I wan't to use Hendrick's ide patches on 2.2.18. What board should I get? Help, I've searched through usenet and asked on #linux without anything conclusive. There are no problems with 2.2.x. What motherboard you get depends on how much you want to spend and on what type of athlon cpu you want to get. K7-2 (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. They work great. Awesome performance. As good as linux gets. Thanks, Mike From KT: David Riley [*] reported tremendous slowdowns in 2.4.1-pre11 and -pre12 on his Athlon 900 with a KT133 chipset. Mark Hahn [*] replied, "this is known: Linus decreed that, since two people reported disk corruption on VIA, any machine with a VIA southbridge must boot in stupid 1992 mode (PIO). (yes, it might be possible to boot with ide=autodma or something, but who would guess?)" He added to Linus Torvalds [*], "I hope you don't consider this a releasable state! VIA now owns 40% of the chipset market..." Linus replied: So find somebody who can figure out why the corruption happens, and I'll be really happy with a patch that fixes it. In the meantime, "releaseable" very much means that we did _everything_ possible to make sure that people don't screw their disks over. You have to realize that stability takes precedence over EVERYTHING. -- 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: [PATCH] network driver updates
Manfred Spraul wrote:
David Hinds wrote:
Say the driver is linked into the kernel. Hot plug drivers should not
all complain about not finding their hardware.
That's handled by pci_module_init(), check linux/pci.h:
if CONFIG_HOTPLUG is enabled, then pci_module_init() never returns with
-ENODEV.
Which means that eisa cards will never be probed in a hotplug enabled
kernel.
And loading the current 3c59x.c into a non CONFIG_HOTPLUG non EISA
kernel results in a disconnected driver:
it's _not_ registered as a pci driver, pci_module_init() calls
pci_unregister_driver().
That's what we want to happen, isn't it? If it's not a hotplug
kernel and the hardware isn't there at boot time, don't register
the PCI driver. But still scan for EISA devices. That's what
the patch I sent yesterday does. Here it is:
static int __init vortex_init (void)
{
int pci_rc, eisa_rc;
pci_rc = pci_module_init(vortex_driver);
eisa_rc = vortex_eisa_init();
if (pci_rc == 0)
vortex_have_pci = 1;
if (eisa_rc 0)
vortex_have_eisa = 1;
return (vortex_have_pci + vortex_have_eisa) ? 0 : -ENODEV;
}
Really, vortex_have_pci should be called
vortex_have_pci_or_hotplug_and_dont_have_pci.
Look. When the driver's init_module() method is called
there are four combinations which must be catered for
(ignoring EISA):
CONFIG_HOTPLUG=n, MODULE=false
If the hardware isn't there, don't register
the pci_driver. It can't _do_ anything.
CONFIG_HOTPLUG=n, MODULE=true
If the hardware isn't there, barf. modprobe will
remove the driver again.
CONFIG_HOTPLUG=y, MODULE=false
If the hardware isn't there, register the pci
driver, because the hardware may appear later
CONFIG_HOTPLUG=y, MODULE=true
If the hardware isn't there, barf. modprobe will remove
the driver. Later, when the hardware is inserted, another
modprobe will succeed.
This is what yesterday's patch implements.
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?
BTW: How come CONFIG_PCMCIA requires CONFIG_HOTPLUG? Doesn't
it make sense to be able to have glued-in Cardbus devices?
-
-
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 plans
I forget the location, where can I get this patch? I'm running 2.4.1 on an alpha which has nothing but problems with the aha-2940uw card I have installed. You would do. The AIC7xxx driver in 2.4 2.4.1ac10 or so is not 64bit clean Give 2.4.1ac12 a spin or try Justins driver (dont have the URL handy) - 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
Maybe the two of *them* can convince Linus to take the !$*!)$*!)$*~$)* patch to scsi_syms.c that exports the add/del timer functions Umm Eric Youngdale is Mr SCSI - 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 plans
I dont plan to switch them yet a while, and never for 2.2. For 2.5 its a total nobrainer that we move to Justins driver or move to Justins driver post crudfixing that may be needed to make it clean and Linuxish Can you be more specific about your complaints? Im not complaining ? - 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 troubles with 2.4.1ac6
On Thu, Feb 15, 2001 at 01:22:31PM +0200, you [Ville Herva] claimed: On Thu, Feb 15, 2001 at 06:08:12AM -0500, you [Doug Ledford] claimed: There was a new aic7xxx driver (version 5.2.3) that went into the 2.4.1ac kernel series around 2.4.1-ac7. I would be curious to know if it worked on your machine properly. Ok. Will try. Tried 2.4.1ac13 vanilla. Still a no-go: SCSI host 0 abort (pid 0) timed out - resetting SCSI bus is neing reset for host 0 channel 0 (scsi0:0:0:0) Synchronous at 40.0MBytes/s offset 31 SCSI host 0 abort (pid 0) timed out - trying harder SCSI bus is being reset for host 0 channel 0 (scsi0:0:0:0) Synchronous at 40.0MBytes/s offset 31 scsi: aborting command due to timeout pid 0 scsi 0 channel 0 id 0 lun 0 Read (10) 00 00 00 00 00 00 00 02 00 SCSI SIGI 0x14 SEDADDR 0x77 SSTAT 0x0 SSTAT 0x2 SG_CACHEPTR 0x6 SSTAT2 0xC0 ST 0x0F0 (copied by hand, so please excuse the typos.) Although 2.4.1ac13+Gibbs's aic7xxx seems to work perfectly, I still wouldn't count out the possibility a hardware fault of some kind, since the box already begun failing to find the boot record at 80MB/sec as well. -- v -- [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/
Compaq Alpha: missing i-cache invalidates in ptrace (2.2.18, 2.4.0) ?
I've been seeing some peculiar effects on Alpha boxes (particularly on SMPs) where threads run right past breakpoints planted by a debugger. (This on 2.2 series kernels). Looking at the code in arch/alpha/kernel/ptrace.c there appears to be nowhere where flush_icache_range is called. According to the Alpha architecture manual you must execute a "call_pal imb" (which is what flush_icache_range turns into) after changing the I-stream. So :- 1) Anyone agree with me that flush_icache_range ought to be called after any ptrace write which modifies an executable page ? (Or have I missed something which has this effect ?) 2) If so, would patches be accepted ? The same problem also appears to exist in 2.4... Thanks -- Jim James Cownie[EMAIL PROTECTED] Etnus, LLC. +44 117 9071438 http://www.etnus.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/
Re: Netmos PCI parallel card
On Thu, Feb 15, 2001 at 11:52:46AM +0100, Igmar Palsenberg wrote: Attached is a patch to make a Netmos PCI parallal port card working. Please try the following patch instead. That card _should_ have a working ECR. URL:ftp://people.redhat.com/twaugh/patches/linux24/linux-netmos.patch Tim. */ PGP signature
typo in 2.4.1/fs/dquot.c
Hi The attached is a fix for typo in 2.4.1/fs/dquot.c. It is not fixed yet in 2.4.2pre3. This typo causes quotactl (Q_GETQUOTA GRPQUOTA, ..) to return EPERM. Jan Kara ([EMAIL PROTECTED]) confirmed that this is really a typo and that the fix is a right one. Thanks, vs --- dquot.c.origWed Feb 14 04:08:26 2001 +++ dquot.c Wed Feb 14 04:09:00 2001 @@ -1536,7 +1536,7 @@ break; case Q_GETQUOTA: if (((type == USRQUOTA current-euid != id) || -(type == GRPQUOTA in_egroup_p(id))) +(type == GRPQUOTA !in_egroup_p(id))) !capable(CAP_SYS_RESOURCE)) goto out; break;
eth0: Something Wicked happened! 2008.
Hello, yesterday i successfully set up Linux-2.2.18 on a new machine (Pentium-III-667, D-Link 530TX (via-rhine) network-card, 256MB Ram). The system is now running for about 1 day, and now i get lot's of these messages : eth0: Something Wicked happened! 2008. This happened on another machine a few months ago (never appeared again for months now). What does this mean?? Is my NIC damaged?? Thanx a lot, Thomas - 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: eth0: Something Wicked happened! 2008.
Check out http://www.scyld.com/network/ethercard.html look under errata - Via Rhine. It seems your link either went down or had too many collisions. This caused the driver to yell "something wicked happened". -Gabi -Original Message- From: Thomas Foerster [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 15, 2001 2:37 PM To: [EMAIL PROTECTED] Subject: eth0: Something Wicked happened! 2008. Hello, yesterday i successfully set up Linux-2.2.18 on a new machine (Pentium-III-667, D-Link 530TX (via-rhine) network-card, 256MB Ram). The system is now running for about 1 day, and now i get lot's of these messages : eth0: Something Wicked happened! 2008. This happened on another machine a few months ago (never appeared again for months now). What does this mean?? Is my NIC damaged?? Thanx a lot, Thomas - 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: Compaq Alpha: missing i-cache invalidates in ptrace (2.2.18, 2.4.0) ?
Jeff Garzik asked :-
Does the same Alpha problem exist in 2.4.1-AC patches? (Alan Cox's
patchkit)
It looks as if there's a very suitable fix in kernel/ptrace.c .
In access_one_page we have
if (write) {
maddr = kmap(page);
memcpy(maddr + (addr ~PAGE_MASK), buf, len);
flush_page_to_ram(page);
flush_icache_page(vma, page);
kunmap(page);
}
which looks ideal to me...
That still leaves 2.2 broken, though :-(
-- Jim
James Cownie[EMAIL PROTECTED]
Etnus, LLC. +44 117 9071438
http://www.etnus.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/
Re: [PATCH] pcnet32.c: MAC address may be in CSR registers
On Wed, 14 Feb 2001, Eli Carter wrote: Eli Carter wrote: I'm dealing with an AMD chip that does not have the station address in the PROM at the base address, but resides in the "Physical Address Registers" in the chip (thanks to the bootloader in my case). This patch makes the driver try those registers if the station address read from the PROM is 00:00:00:00:00:00. I think others dealing with similar setups may find this helpful. The other lance-derived drivers might benefit from a similar patch, but I don't have that hardware for testing. aside Added Peter since he's given feedback on a past pcnet32 patch. /aside Two patches, one for 2.2.18 (patch-pcnet32-mac22), and one for 2.4.1 (patch-pcnet32-mac24) which should each apply cleanly. Changes: - Moved address validity check to a function. (Should this go somewhere other drivers can call it?) - Check the second address and set the address to 00:00:00:00:00:00 if it fails - Check the address at open time as well, failing with -EINVAL. I think that should address Alan's initial feedback. What else? TIA, Thanks for copying me on this. If, in the future, it seems reasonable, I will supply a patch for the new read/write SEEPROM stuff needed for embedded systems. If you need to check if this device has a SEEPROM. If it doesn't, you need to set up about 15 registers that would have been set upon hard-reset, by the contents of the SEEPROM. Otherwise you have a very dumb poorly performing chip. 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/
Allocating lots of DMA RAM?
Hi all. Is the following loop (from drivers/sound/i810_audio.c among others) still the best way to allocate a large amount of DMA RAM for audio? ie. for audio devices that do not support scatter-gather. Thanks, Jeff /* alloc as big a chunk as we can, FIXME: is this necessary ?? */ for (order = DMABUF_DEFAULTORDER; order = DMABUF_MINORDER; order--) if ((rawbuf = pci_alloc_consistent(state-card-pci_dev, PAGE_SIZE order, dmabuf-dma_handle))) break; if (!rawbuf) return -ENOMEM; - 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: *grin* Windows 2000 HPC: Scalable, Inexpensive
On Wed, Feb 14, 2001 at 09:21:24AM -0500, Mike Harrold wrote: At 9:10 am + 14/2/2001, David Howells wrote: How this for a laugh: http://www.microsoft.com/WINDOWS2000/hpc/indstand.asp Can anybody say "Beowulf cluster"? I bet you need a W2K license for every box you hook up, too. The sad thing is, 3/4 of the page is an outright lie. It isn't a first, W2k is not the de facto standard OS, and the TCO is significantly higher than any cluster running Linux. That's right, extreme linux has been around for years, and now they've changed the name to Scyld Linux at www.scyld.com .. I managed to pick up a couple of cds of scyld linux at lwe a couple of weeks ago.. I have yet to install it but i did boot it up all i can say is SHWEEET!! found my ata66 stuff right off the bat... it's based on redhat 6.2 but they've made some VERY nice changes to the installation procedure... on top of that, you only really need to install it on the master node... just boot the cd in all of the slave nodes for each to become a node. no hard drives required. :) -- .oO Gnea [gnea at rochester dot rr dot com] Oo. .oO url: http://garson.org/~gnea Oo. "You can tune a filesystem, but you can't tuna fish." -unknown - 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: MP-Table mappings
On Wed, 14 Feb 2001, Alan Cox wrote: In my dmesg I'm getting duplicate table reservations. Just a crap bios That's unrelated -- duplicate reservations are due to the MP table being located in memory areas marked as "reserved" (ROM, ususally) in the map. Thus the area is never freed in the first place and when smp_scan_config() calls reserve_bootmem() for the pages a warning is issued. Harmless, indeed. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - 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.2-pre3 segfaults and Oops
On Wed, 14 Feb 2001, Scott M. Hoffman wrote: Hello, See the attached Oops passed through ksymoops 2.3.7(the i386 rpm from kernel.org). Not sure who should see this... Is it generally a good idea to reboot the machine after getting one of these? I've been trying to see if this was a hardware problem (see my post about memtest86 crashing on me five out of five times at the same point). Even after rebooting from this Oops, I was still getting Segfaults from several programs. Going back to 2.4.1, it seems fine. I ran several tests with bonnie++, first without dma, or irq_unmask enabled for both /dev/hda and /dev/hdb. Then with dma, then with dma and irq_unmask enabled(as usually have it). No Segfaults, no Ooops...yet :) I didn't do any of the above tests in 2.4.2-pre3, as my system just seemed unstable. If there is an indication that it's not my machine being flaky, I'd be glad to test further, in hope of being able to use 2.4.2. Thanks, Scott - 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: MP-Table mappings
Just a crap bios That's unrelated -- duplicate reservations are due to the MP table being located in memory areas marked as "reserved" (ROM, ususally) in the map. Ah. Ok I'd not seen that specific case Thus the area is never freed in the first place and when smp_scan_config() calls reserve_bootmem() for the pages a warning is issued. Harmless, indeed. Umm probably worth cleaning up. - 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.1ac14
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ 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(Steven Cole) o Add support for the Socket LP-E CF+ ethernet(Nicolas Pitre) o Fix microtek scanner abort handling (Oliver Neukum) o Fix very dumb bug in my dma.c changes that (me) Linus noticed o Clean up AGP alloc/destroy a little (me) | Again a Linus request o Remove dead 8129 config help(Dave Jones) o Clean up extra unneeded check in setup.c(Dave Jones) o Improve mkdep, remove acpi special case (Keith Owens) o Fix bogus dead comment in fs.h (Jens Axboe) o Clean up config.in syntax errors(Christoph Hellwig) o Offer Duron in CPU option list for
Re: [ANNONCE] Kernel Autoconfiguration utility v.0.9.1.2
Hi Giacomo, one small remark, presence of the Philips SAA7146 doesn't mean presence of the Stradis video capture card. This multimedia bridge chip is very multipurpose device and can be used on very different cards (for example satellite DVB receivers). Best regards. -- Andrey Panin| Embedded systems software engineer [EMAIL PROTECTED]| PGP key: http://www.orbita1.ru/~pazke/AndreyPanin.asc PGP signature
[pre PATCH] freezes
Hi, I have had occasional freezes (complete NumLock won't work) for some time. I blamed HW, irq conflicts, temperature problems, ... But suddenly with 2.4.2-pre1 the problems disappeared! Since 2.4.2-pre1 was rather short I took the time to try to find out what could be the fix. I found one candidate, the setting of TASK_RUNNING in handle_mm_fault. Since the problem had appeared on both 2.4 and 2.2.18 I started to try to reproduce the problem in an unpatched 2.2 - it took some time, got the freeze today. During this time I have tried to collect information of the freezes on KDE mailing lists - I do now have three additional reports (one running 2.2.17) Hardware has varied. I have now compiled and installed this patch but since it can't be proven to fix the problem I submit it now. /RogerL -- Home page: none currently --- linux/mm/memory.c.orig Wed Feb 14 00:58:59 2001 +++ linux/mm/memory.c Wed Feb 14 00:59:16 2001 @@ -935,6 +935,7 @@ pte_t * pte; int ret; + current-state = TASK_RUNNING; pgd = pgd_offset(vma-vm_mm, address); pmd = pmd_alloc(pgd, address); if (!pmd)
loop races broke big time in 2.4.2-pre3
So I assume we wait on baited breathe for 2.4.2-pre4 or branch off soon to 2.5 blah? Frank - 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
Here is a complete trace of the Oops I have. I have a new compiled kernel with NFSD in the kernel with vmlinux available for it. I attached the ksymoops and the gdb stuff oops.orig : as found in /var/log/messages oops.ksyms : output of ksymoops oops.disassemble : output of "echo disassemble nfssvc_encode_diropres | gdb -batch -x /dev/stdin vmlinux" Thanks to give an eye -jec oops.orig oops.ksyms oops.disassemble
Re: Problem: NIC doesn't work anymore, SIOCIFADDR-errors
Yes, I do... Thanks for the hints, I've installed the older version, then upgraded to the fixed version. Everything works now as before. Jonathan Brugge From: David Raufeisen [EMAIL PROTECTED] Reply-To: David Raufeisen [EMAIL PROTECTED] To: Jonathan Brugge [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: Problem: NIC doesn't work anymore, SIOCIFADDR-errors Date: Wed, 14 Feb 2001 06:36:20 -0800 Are you using the net-tools from debian? There was a broken one causing these errors the last few days, is fixed now. On Wednesday, 14 February 2001, at 15:17:09 (+0100), Jonathan Brugge wrote: Here's the output from dmesg, after deleting some unimportant stuff like sound and graphics-init. I don't see any errors that have something to do with my NIC, the detected type (Winbond 89C940) is the right one. Linux version 2.4.0-prerelease (root@odysseus) (gcc version 2.95.3 20010125 (prerelease)) #2 Tue Feb 13 20:27:53 CET 2001 -- David Raufeisen [EMAIL PROTECTED] Cell: (604) 818-3596 - 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/ _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.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/
Re: [LK] Re: lkml subject line
if you use an MUA that can't do filtering, well then there's something wrong with you I really don't believe there is any need for this kind of attitude. /Mike - 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?
Jeremy Jackson [EMAIL PROTECTED] writes: "Eric W. Biederman" wrote: Jeremy Jackson [EMAIL PROTECTED] writes: (about non-executable stack) There is another much more effective solution in the works. The C standard allows bounds checking of arrays. So it is quite possible for the compiler itself to check this in a combination of run-time and compile-time checks. I haven't followed up but not too long ago there was an effort to add this as an option to gcc. If you really want this fixed that is the direction to go. Then buffer overflow exploits become virtually impossible. I've thought some more, and yes someone else has already done this. Problems are with compilers that put code on stack (g++ trampolines for local functions i think). There is the gcc-mod (Stack-guard?) that checks for corrupt stack frame using magic number containing zeros before returning... this will take away some performance though... No. I'm not talking about stack-guard patches. I'm talking about bounds checking. The difference here is that if correct code is generated you won't overflow any buffer at all period. The compiler will either prove at compile time that it can't happen (The efficient case). Or it will generate pointers as start,length,offset tuples into chunks of memory. And it will do runtime checks that will that will kill your program if it overflows the stack. I think the gcc options is -fcheck or something like that. I haven't had a chance to follow up, since I saw that someone was actually working on it. Since compilers bugs happen buffer overflow exploits are still possible but it means two separate programmers must mess up in complimentary ways. As for fine grain privileges they can help, but the real fix is to keep the programs that need raised privileges down to one function. Letting you look at the program and see if it is obviously correct with no security bugs. 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. 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/
2.4.1: TCP assertion failed
Moderately-high (couple hundred thousand hits a day) loaded web server running 2.4.1 (no other patches). I got this twice in the syslog after 15 days uptime: KERNEL: assertion (tp-lost_out == 0) failed at tcp_input.c(1202):tcp_remove_reno_sacks (between lots of "TCP: peer shrinks window :xxx:xx. Bad, what else can I say?" which I understand are harmless) Let me know if anyone needs more info/tests/etc. -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - 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 crashes every two days, oopses included
My last bug report did not seem to attract to much attention. But I'm back and I have a even longer oops list. Last night our system crashed (again). (Again) right after arkeia had started the nightly backup. But this time the kernel oopses went through syslog. Here they are ran through ksymoops (which issued many warnings). For now we have switched back to 2.2.18 which stays up for about a week before it crashes because of the VM too. (with trying to free unused pages..). The System is a Athlohn K7, 600Mhz with 512MB of RAM. aage, wrong page on list. aage, wrong page on list. VM: reclaim_page, wrong page on list. VM: reclaim_page, wrong page on list. VM: reclaim_page, wrong page on list. VM: reclaim_page, wrong page on list. VM: reclaim_page, wrong page on list. VM: reclaim_page, wrong page on list. VM: recVM: reclaim_page, wrong page on list. VM: recVM: reclaim_page, wrong page on list. VM: reclaim_page, wrong page on list. VM: reclaim_page, wrong page on list. VM: refill_inactive, wrong page on list. VM: refill_inactive, wrong page on list. VM: refill_inactive, wrong page on list. Unable to handle kernel paging request at virtual address 2208 VM: refill_inactive, wrong page on list. Unable to handle kernel paging request at virtual address 2208 printing eip: printing eip: ksymoops 2.3.7 on i686 2.2.18. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.2.18/ (default) -m /usr/src/linux/System.map (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. -- missing error messages -- Unable to handle kernel paging request at virtual address 2208 Unable to handle kernel paging request at virtual address 2208 c0123b9f c0123b9f *pde = *pde = Oops: Oops: CPU:0 CPU:0 EIP:0010:[__set_page_dirty+19/60] EIP:0010:[__set_page_dirty+19/60] EFLAGS: 00010246 EFLAGS: 00010246 eax: c115ec74 ebx: c02379e0 ecx: 2200 edx: c13c0400 eax: c115ec74 ebx: c02379e0 ecx: 2200 edx: c13c0400 esi: c9f216d4 edi: 05289047 ebp: c9f216d4 esp: dfffded8 esi: c9f216d4 edi: 05289047 ebp: c9f216d4 esp: dfffded8 ds: 0018 es: 0018 ss: 0018 ds: 0018 es: 0018 ss: 0018 Process kswapd (pid: 3, stackpage=dfffd000) Process kswapd (pid: 3, stackpage=dfffd000) Stack: c115ec74 c9f216d4 c012a10c c115ec74 c115ec74 c9f216d4 40db5000 02f4 Stack: c115ec74 c9f216d4 c012a10c c115ec74 c115ec74 c9f216d4 40db5000 02f4 05289047 00d5a900 c012a26d d0352ac0 d9deada0 40db5000 c9f216d4 c115ec74 05289047 00d5a900 c012a26d d0352ac0 d9deada0 40db5000 c9f216d4 c115ec74 40c1b000 4100 c222a40c 40c1b000 c012a347 d0352ac0 d9deada0 c222a40c 40c1b000 4100 c222a40c 40c1b000 c012a347 d0352ac0 d9deada0 c222a40c Call Trace: [try_to_swap_out+316/436] [swap_out_pmd+233/260] [swap_out_vma+191/228] [swap_out_mm+54/92] [swap_out+151/180] [refill_inactive+146/180] [do_try_to_free_pages+73/128] Call Trace: [try_to_swap_out+316/436] [swap_out_pmd+233/260] [swap_out_vma+191/228] [swap_out_mm+54/92] [swap_out+151/180] [refill_inactive+146/180] [do_try_to_free_pages+73/128] Code: 8b 51 08 89 42 04 8d 71 08 89 10 89 70 04 89 41 08 8b 41 20 Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol _EIP: Code; Before first symbol 0: 8b 51 08 mov0x8(%ecx),%edx Code; 0003 Before first symbol 3: 89 42 04 mov%eax,0x4(%edx) Code; 0006 Before first symbol 6: 8d 71 08 lea0x8(%ecx),%esi Code; 0009 Before first symbol 9: 89 10 mov%edx,(%eax) Code; 000b Before first symbol b: 89 70 04 mov%esi,0x4(%eax) Code; 000e Before first symbol e: 89 41 08 mov%eax,0x8(%ecx) Code; 0011 Before first symbol 11: 8b 41 20 mov0x20(%ecx),%eax Code: 8b 51 08 89 42 04 8d 71 08 89 10 89 70 04 89 41 08 8b 41 20 Code; Before first symbol _EIP: Code; Before first symbol 0: 8b 51 08 mov0x8(%ecx),%edx Code; 0003 Before first symbol 3: 89 42 04 mov%eax,0x4(%edx) Code; 0006 Before first symbol 6: 8d 71 08 lea0x8(%ecx),%esi Code; 0009 Before first symbol 9: 89 10 mov%edx,(%eax) Code; 000b Before first symbol b: 89 70
Re: Is this the ultimate stack-smash fix?
"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, and I won't even mention unions and
struct dyn_data {
int len;
char data[];
}
--
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: 2.4.1 - can't read root fs (devfs maybe?)
David Ford writes: "Michael J. Dikkema" wrote: I went from 2.4.0 to 2.4.1 and was surprised that either the root filesystem wasn't mounted, or it couldn't be read. I'm using devfs.. I'm thinking there might have been a change with regards to the devfs tree.. is the legacy /dev/hda1 still /dev/discs/disc0/part1? This symlink doesn't exist/isn't usable for boot. Use the qualified pathname. Actually, the /dev/ide/hd/... name is available for the root device. Also, the kernel has special init code to parse /dev/hda1 and similar names, so they should work too (as long as you don't have "devfs=only" on your boot line). That's actually very old code (predates devfs). Regards, Richard Permanent: [EMAIL PROTECTED] Current: [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: Is this the ultimate stack-smash fix?
"Eric W. Biederman" wrote: Jeremy Jackson [EMAIL PROTECTED] writes: "Eric W. Biederman" wrote No. I'm not talking about stack-guard patches. I'm talking about bounds checking. Sorry, I was quite incoherent. Many others have pointed out that there exist patches for non-executatble stack, and the problems with it. That's what I meant to comment on. But I'm glad to find out about bounds checking as an option. 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. That's why I was wondering of limiting privileged addresses security at a more fundamental level... as you say above, this fixes *ONE* source of bugs(security threats)... but itn't it inevitable that there will be others? But if services are each put in a separate box, that doesn't have a door leading to the inner sanctum, things would be more secure in spite of "bugs". Well I thank everyone for their responses in this thread, I think It's been beaten into the ground (my original idea), and I'm left with some food for thought. - 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/
Bug in FAT reading
Dear Kernel People, Recently I experienced a dos formatted floppy which, after mounting it vfat and issuing the df command produced the kernel messages below. The original part is several hundreds line long. The message stream persisted after a shutdown. If one waits long enough, it will stop. I consider this behavior a bug. It appeared in 2.2.14-5.0 (RH6.2), 2.2.16, 2.2.18 and 2.4.1 kernels (all from kernel.org). The mount, unmount and ls commands worked fine. [ ... deleted repeated lines, during normal system operation Feb 13 15:47:37 gaudi kernel: floppy0: sector not found: track 0, head 0, sector 5, size 2 Feb 13 15:47:37 gaudi kernel: floppy0: sector not found: track 0, head 0, sector 5, size 2 Feb 13 15:47:37 gaudi kernel: end_request: I/O error, dev 02:00 (floppy), sector 4 Feb 13 15:47:37 gaudi kernel: bread in fat_access failed Feb 13 15:47:38 gaudi kernel: floppy0: sector not found: track 0, head 0, sector 5, size 2 Feb 13 15:47:38 gaudi kernel: floppy0: sector not found: track 0, head 0, sector 5, size 2 Feb 13 15:47:38 gaudi kernel: end_request: I/O error, dev 02:00 (floppy), sector 4 Feb 13 15:47:38 gaudi kernel: bread in fat_access failed Feb 13 15:47:38 gaudi kernel: floppy0: sector not found: track 0, head 0, sector 5, size 2 Feb 13 15:47:39 gaudi kernel: floppy0: sector not found: track 0, head 0, sector 5, size 2 Feb 13 15:47:39 gaudi kernel: end_request: I/O error, dev 02:00 (floppy), sector 4 Feb 13 15:47:39 gaudi kernel: bread in fat_access failed ... and now we issue a shutdown ... Feb 13 15:47:39 gaudi PAM_pwdb[685]: (xdm) session closed for user hp Feb 13 15:47:39 gaudi gnome-name-server[1177]: input condition is: 0x10, exiting Feb 13 15:47:39 gaudi kernel: floppy0: sector not found: track 0, head 0, sector 5, size 2 Feb 13 15:47:39 gaudi kernel: floppy0: sector not found: track 0, head 0, sector 5, size 2 Feb 13 15:47:39 gaudi kernel: end_request: I/O error, dev 02:00 (floppy), sector 4 Feb 13 15:47:39 gaudi kernel: bread in fat_access failed Feb 13 15:47:40 gaudi kernel: floppy0: sector not found: track 0, head 0, sector 5, size 2 Feb 13 15:47:40 gaudi kernel: floppy0: sector not found: track 0, head 0, sector 5, size 2 Feb 13 15:47:40 gaudi kernel: end_request: I/O error, dev 02:00 (floppy), sector 4 Feb 13 15:47:40 gaudi kernel: bread in fat_access failed Feb 13 15:47:41 gaudi rc: Stopping keytable succeeded Feb 13 15:47:41 gaudi kernel: floppy0: sector not found: track 0, head 0, sector 5, size 2 Feb 13 15:47:41 gaudi Font Server[627]: terminating Feb 13 15:47:41 gaudi kernel: floppy0: sector not found: track 0, head 0, sector 5, size 2 Feb 13 15:47:41 gaudi kernel: end_request: I/O error, dev 02:00 (floppy), sector 4 Feb 13 15:47:41 gaudi kernel: bread in fat_access failed Feb 13 15:47:42 gaudi kernel: floppy0: sector not found: track 0, head 0, sector 5, size 2 Feb 13 15:47:42 gaudi kernel: floppy0: sector not found: track 0, head 0, sector 5, size 2 Feb 13 15:47:42 gaudi kernel: end_request: I/O error, dev 02:00 (floppy), sector 4 Feb 13 15:47:42 gaudi kernel: bread in fat_access failed ... ] deleted repeated lines, during and after shutdown The mdir output is: plain_io: Input/output error Error reading fat number 0 and proceeds with the normally expected dir listing. The messages file contains then just two of the above blocks and not this almost never ending junk. I think if the fourth or so read attempt on the FAT is unsuccesfull the kernel should proceed to the alternate FAT, as the mtools obviously do. With best regards, Herbert [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: 2.4.1 crashes every two days, oopses included
On Thu, 15 Feb 2001, Martin Rode wrote: My last bug report did not seem to attract to much attention. For now we have switched back to 2.2.18 which stays up for about a week before it crashes because of the VM too. [snip] VM: reclaim_page, wrong page on list. VM: refill_inactive, wrong page on list. Unable to handle kernel paging request at virtual address 2208 Since: 1. you see this kind of bug with both 2.2 and the completely changed 2.4 VM code and 2. this bug usually only happens when people have RAM problems, could you try running memtest86 on that machine to see if it indeed has memory errors or if the problem is coming from somewhere else ? thanks, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - 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:
+int is_valid_ether_addr( char* address )
+{
+int i,isvalid=0;
+for( i=0; i6; i++)
+ isvalid |= address[i];
+return isvalid !(address[0]1);
+}
static and why not
oops, I *meant* static... doesn't gcc do mind reading? ;) (I had
static in the declaration, but forgot it on the definition.)
static inline int is_valid_ea(u8 *addr)
{
return memcmp(addr, "\000\000\000\000\000\000", 6) !(addr[0]1);
}
That all assembles to nice inline code 8)
Hmm... well, if we're going for _those_ optimizations, shouldn't it be:
return !(addr[0]1) memcmp(addr, "\000\000\000\000\000\000", 6);
so we do the cheaper test first and thus possibly avoid needing to do
the more expensive test? :)
Tell ya what, put that in linux/etherdevice.h (if that's the right
place) and then everyone can use it. ;) (I'd rather keep the longer
function name... "ea" isn't very helpful to the newer hackers among
us...)
Looks ok to me, Im picking holes now
:) That's encouraging. I still feel like I'm scaling the learning
curve, and I'm feeling rather "green".
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.
Alan, do you want me to put your inline version in linux/etherdevice.h
while I'm at it, or what?
Comments?
Eli
. Rule of Accuracy: When working toward
Eli Carter | the solution of a problem, it always
[EMAIL PROTECTED] `- helps if you know the answer.
-
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] starfire reads irq before pci_enable_device.
"Petr" == Petr Vandrovec [EMAIL PROTECTED] writes: Petr On 14 Feb 01 at 16:35, Jes Sorensen wrote: What else is sending out 802.3 frames these days? I really don't care about IPX when it comes to performance. I am just advocating that we optimize for the common case which is DIX frames and not 802.3. Petr Pardon me, but IPX in 802.3 and IPX in DIX are exactly same Petr frames on wire, except that IPX/802.3 contains frame length in Petr bytes 0x0C/0x0D, while IPX/DIX contains 0x8137 here. They have Petr same length, and same length of media header, so I really do not Petr understand. Petr If you are talking about encapsulation which is known as Petr `ethernet_802.2' in IPX world, then it is true, it has odd bytes Petr in header. But nobody sane except Appletalk uses 802.2 Petr now... Our Suns already died due to this couple of years ago ;-) My point is that you rarely see Ethernet frames with 802.3 except for places running IPX. Jes - 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: Documentation required for TCP / IP stack implementation
Diwakar Sharma wrote: I require linux tcp/ip stack implementation details for a project i am involved in . can somebody please point out an online documentation site for the same. Not online, but "LINUX IP Stacks" by Satchell Clifford from CoriolisOpen Press may be helpful to you. Eli . Rule of Accuracy: When working toward Eli Carter | the solution of a problem, it always [EMAIL PROTECTED] `- helps if you know the answer. - 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/
[ANNOUNCE] Adaptive Domain Environment for Operating Systems
I've put up the following (white) papers out for general discussion: -Adaptive Domain Environment for Operating Systems (Adeos) -Building a Real-Time Operating System on top of the Adeos The first paper discusses the design and implementation of a nano-kernel- like facility that may be used to take control away from an unmodified running linux on ix86 for further uses including (but not limited to): -patch-less kernel debuggers/probers -running multiple general purpose OSes on the same hardware, -OS development -etc. As the first item suggests, this may be of interest to some on this list as kernel debuggers have been a rather pointy subject... The second document discusses a special case usage of Adeos that enables a real-time-bound kernel to co-exist with Linux on top of Adeos. The documents can be found here: http://www.opersys.com/adeos/index.html I've requested a project entry for Adeos on sourceforge and will update the project's home page as soon as everything is set up. In the mean time, anyone interested to participate in the project or that has pertinent information regarding the implementation, or its feasibility or lack of, as described in the Adeos document is welcomed to contact me. KEEP IN MIND that the documents are only a suggested method of doing things designed to stimulate discussion. There isn't one line of functionnal code out there (yet). Best regards, Karim === Karim Yaghmour [EMAIL PROTECTED] Operating System Consultant (Linux kernel, real-time and distributed systems) === - 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: [ANNONCE] Kernel Autoconfiguration utility v.0.9.1.2
Good day, Giacomo,
On Thu, 15 Feb 2001, Giacomo Catenazzi wrote:
How to use: (now, testing phase)
unpack the files (better: in a new directory)
bash autoconfigure.sh | less
check the output.
no super user privileges required!
Nice work - that's a neat way to do it.
One detail; you appear to assume that bash2 is being used. If
bash1 is /bin/bash, one gets syntax errors. The following patch allows
the script to run under bash1 and bash2, with no noticeable problems.
--- autoconfigure.sh-0.9.1.2.orig Wed Feb 14 15:37:30 2001
+++ autoconfigure.shThu Feb 15 10:59:45 2001
@@ -109,7 +109,7 @@
}
function found () {
local conf=CONFIG_$1
-if [ "${!conf}" != "y" ]; then
+if [ "${conf}" != "y" ]; then
define $1 y
else
debug "$1=y"
@@ -117,7 +117,7 @@
}
function found_y () {
local conf=CONFIG_$1
-if [ "${!conf}" != "y" ]; then
+if [ "${conf}" != "y" ]; then
define $1 y
else
debug "$1=y"
@@ -125,7 +125,7 @@
}
function found_m () {
local conf=CONFIG_$1
-if [ "${!conf}" != "y" -a "${!1}" != "m" ]; then
+if [ "${conf}" != "y" -a "${1}" != "m" ]; then
define $1 m
else
debug "$1=m"
@@ -133,7 +133,7 @@
}
function found_n () {
local conf=CONFIG_$1
-if [ -z "${!conf}" ]; then
+if [ -z "${conf}" ]; then
define $1 n
else
debug "$1=n"
@@ -142,7 +142,7 @@
}
function provide () {
local prov=PROVIDE_$1
-if [ "${!prov}" != "y" ]; then
+if [ "${prov}" != "y" ]; then
eval "PROVIDE_$1=y"
debug "PROVIDE_$1"
fi
@@ -188,7 +188,7 @@
set `od -An -tx1 -v $f`
x0=$1; shift # make variables zero-based
echo -n "${1}${x0},${3}${2}"
-if [ "${14}" == "00" ]; then
+if [ "${14}" = "00" ]; then
echo -n ",${45}${44},${47}${46}"
fi
echo ",${8};Class:${11}${10},${9}"
I'm sure I'm missing the real reasons why the "${!" and "=="
syntaxes were used (I don't know what they do, as I stick to bash1 for
portability), so my apologies in advance.
Cheers,
- Bill
---
"Mouse movement detected. Please reboot for changes to take
effect."
--
William Stearns ([EMAIL PROTECTED]). Mason, Buildkernel, named2hosts,
and ipfwadm2ipchains are at:http://www.pobox.com/~wstearns
LinuxMonth; articles for Linux Enthusiasts! http://www.linuxmonth.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/
Re: [PATCH] 2.4.1ac12 mkdep -I support - take 2
Hello, Keith! You patch has been applied to 2.4.1ac13, but it doesn't help: $ HPATH=. ../../scripts/mkdep -- names.c names.o: names.c \ $(wildcard /home/proski/src/linux/drivers/pci/config/pci/names.h) \ /home/proski/src/linux/drivers/pci/devlist.h \ /home/proski/src/linux/drivers/pci/devlist.h \ /home/proski/src/linux/drivers/pci/devlist.h $ ls Config.in compat.o names.c pci.o quirks.o setup-res.c Makefile devlist.h pci.cproc.csetup-bus.c syscall.c compat.c gen-devlist.c pci.ids quirks.c setup-irq.c devlist.h is in the current directory, but the full path is used. Regards, Pavel Roskin - 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 2.4.1ac14
After building/playing around with some java apps on this version, something seems to have gone weird with X or the kernel.. david@prototype:~$ ps aux | grep X root 267 0.9 99.9 167640 4294965764 ? S 06:50 1:11 /usr/bin/X11/X vt7 -auth /var/lib/gdm/:0.Xauth :0 System seems mostly fine, a bit slow.. Nothing special in logs prototype:~# free total used free sharedbuffers cached Mem:126708 123856 2852 0 27836 71568 -/+ buffers/cache: 24452 102256 Swap: 554232 66596 487636 Would having the huge swap have anything to do with it? Needed it to install oracle, but the blasted thing won't install anyway (Debian Sid). On Thursday, 15 February 2001, at 14:30:15 (+), Alan Cox wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ 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) - 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
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 linux/etherdevice.h while I'm at it, or what? Sure - 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: [ANNONCE] Kernel Autoconfiguration utility v.0.9.1.2
William Stearns [EMAIL PROTECTED] writes:
| Good day, Giacomo,
|
| On Thu, 15 Feb 2001, Giacomo Catenazzi wrote:
|
| How to use: (now, testing phase)
|unpack the files (better: in a new directory)
| bash autoconfigure.sh | less
|check the output.
|no super user privileges required!
|
| Nice work - that's a neat way to do it.
| One detail; you appear to assume that bash2 is being used. If
| bash1 is /bin/bash, one gets syntax errors. The following patch allows
| the script to run under bash1 and bash2, with no noticeable problems.
|
| --- autoconfigure.sh-0.9.1.2.origWed Feb 14 15:37:30 2001
| +++ autoconfigure.sh Thu Feb 15 10:59:45 2001
| @@ -109,7 +109,7 @@
| }
| function found () {
| local conf=CONFIG_$1
| -if [ "${!conf}" != "y" ]; then
| +if [ "${conf}" != "y" ]; then
| define $1 y
| else
| debug "$1=y"
This is plain wrong. ${!conf} and ${conf} are completely different
things.
Andreas.
--
Andreas Schwab "And now for something
SuSE Labscompletely different."
[EMAIL PROTECTED]
SuSE GmbH, Schanzckerstr. 10, D-90443 Nrnberg
-
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 2.4.1ac14
After building/playing around with some java apps on this version, something seems to have gone weird with X or the kernel.. david@prototype:~$ ps aux | grep X root 267 0.9 99.9 167640 4294965764 ? S 06:50 1:11 /usr/bin/X11/X vt7 -auth /var/lib/gdm/:0.Xauth :0 System seems mostly fine, a bit slow.. Yeah folks were wondering if our rss accounting was atomically safe. I guess the answer from this one is 'probably not' Would having the huge swap have anything to do with it? Needed it to install oracle, but the blasted thing won't install anyway (Debian Sid). It actually looks like the system is working fine other than miscounting the resident size of the X process. Rik, 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/
Re: [PATCH] network driver updates
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. BTW: How come CONFIG_PCMCIA requires CONFIG_HOTPLUG? Doesn't it make sense to be able to have glued-in Cardbus devices? I suppose it makes sense but I don't know if it is something worth the trouble of supporting. -- Dave - 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/
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/
RE: aic7xxx (and sym53c8xx) plans
I must say, after I saw this post, I tried out the latest driver for my own purposes. This really improved the performance of my dual PIII-866 w/512MB Ram and AIC7899 scsi. I have a couple of cheetah drives that I am writing data that I get off of an ATM card.(about 12-14 MB/sec rate). This has significantly lowered the number of dropped packets on the ATM read. I would suggest, if at all possible, putting this in the 2.4.2 kernel. Nathan -Original Message- From: Chip Salzenberg [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 14, 2001 9:20 PM To: Matthew Jacob Cc: Wakko Warner; Alan Cox; J . A . Magallon; linux-kernel Subject: Re: aic7xxx (and sym53c8xx) plans According to Matthew Jacob: See http://www.freebsd.org/~gibbs/linux. Here at VA we're already using Jason's driver -- it works on the Intel STL2 motherboard, while Doug's driver doesn't (or didn't, a month ago). While we're discussing SCSI drivers, I'd also like to put in a good word for the Sym-2 Symbios/NCR drivers from Gerard Roudier: ftp://ftp.tux.org/roudier/drivers/portable/sym-2.1.x/ Joe-Bob says: "Check it out." -- Chip Salzenberg- a.k.a. -[EMAIL PROTECTED] "Give me immortality, or give me death!" // Firesign Theatre - 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: aic7xxx (and sym53c8xx) plans
I am still stuck on 2.2 because of this issue. I would really like to see this driver in 2.4.2. -Matt -Original Message- From: Nathan Black [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 15, 2001 9:20 AM To: [EMAIL PROTECTED] Subject: RE: aic7xxx (and sym53c8xx) plans I must say, after I saw this post, I tried out the latest driver for my own purposes. This really improved the performance of my dual PIII-866 w/512MB Ram and AIC7899 scsi. I have a couple of cheetah drives that I am writing data that I get off of an ATM card.(about 12-14 MB/sec rate). This has significantly lowered the number of dropped packets on the ATM read. I would suggest, if at all possible, putting this in the 2.4.2 kernel. Nathan -Original Message- From: Chip Salzenberg [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 14, 2001 9:20 PM To: Matthew Jacob Cc: Wakko Warner; Alan Cox; J . A . Magallon; linux-kernel Subject: Re: aic7xxx (and sym53c8xx) plans According to Matthew Jacob: See http://www.freebsd.org/~gibbs/linux. Here at VA we're already using Jason's driver -- it works on the Intel STL2 motherboard, while Doug's driver doesn't (or didn't, a month ago). While we're discussing SCSI drivers, I'd also like to put in a good word for the Sym-2 Symbios/NCR drivers from Gerard Roudier: ftp://ftp.tux.org/roudier/drivers/portable/sym-2.1.x/ Joe-Bob says: "Check it out." -- Chip Salzenberg- a.k.a. -[EMAIL PROTECTED] "Give me immortality, or give me death!" // Firesign Theatre - 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/ - 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
I am still stuck on 2.2 because of this issue. I would really like to see this driver in 2.4.2. Have you tested the 2.2.18 version of the new driver? The patches should work on most 2.2.X kernels, I just haven't gotten around to verifying that. The more testers, the merrier! :-) -- Justin - 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
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. -Matt -Original Message- From: Justin T. Gibbs [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 15, 2001 9:36 AM To: Matt Liotta Cc: [EMAIL PROTECTED] Subject: Re: aic7xxx (and sym53c8xx) plans I am still stuck on 2.2 because of this issue. I would really like to see this driver in 2.4.2. Have you tested the 2.2.18 version of the new driver? The patches should work on most 2.2.X kernels, I just haven't gotten around to verifying that. The more testers, the merrier! :-) -- Justin - 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 2.4.1ac14
After building/playing around with some java apps on this version, something seems to have gone weird with X or the kernel.. david@prototype:~$ ps aux | grep X root 267 0.9 99.9 167640 4294965764 ? S 06:50 1:11 /usr/bin/X11/X vt7 -auth /var/lib/gdm/:0.Xauth :0 System seems mostly fine, a bit slow.. Yeah folks were wondering if our rss accounting was atomically safe. I guess the answer from this one is 'probably not' Would having the huge swap have anything to do with it? Needed it to install oracle, but the blasted thing won't install anyway (Debian Sid). It actually looks like the system is working fine other than miscounting the resident size of the X process. Rik, Ben ? I noticed that these accounting values were a little weird last night (when using top) when it said that X was using something like 205% of my memory. So there definately is something strange going on... Laramie - 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] 2.4.1ac12 mkdep -I support - take 2
On Thu, 15 Feb 2001, Pavel Roskin wrote: Hello, Keith! You patch has been applied to 2.4.1ac13, but it doesn't help: It's fixed in ac14. I ran twice make depend make clean make bzImage make modules and it worked both times. Thanks! Regards, Pavel Roskin - 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
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. -- Justin - 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/
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. 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/
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/
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/
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: 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: 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/
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 unassigned [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/
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/
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 mss536. 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/
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: 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: 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: 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: 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: 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: 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/
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
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/
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
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: [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 linux/etherdevice.h
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 linux/etherdevice.h
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
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: 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 mtu128. 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 Cnovas
Departamento de Ingeniera y Tecnologa de Computadores
Facultad de Informtica. 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.esop=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: 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/
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: 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/
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/
