Re: [BUG] 2.4.[01] lockups
On Sun, 11 Feb 2001, Pavel Machek wrote:
> Login via network or serial cable, and see if /proc/interrupts entry
> for keyboard/mouse changes as you type. Attempt to blink keyboard leds
> with setleds.
> Pavel
On Mon, 12 Feb 2001, Ville Herva wrote:
> Also, try killing gpm.
> -- v --
Hello,
Thanks for the suggestions. Due to lack of a terminal or second computer
I've had no chance still to try the above suggestions. However, I have
tried many different versions of the 2.4.X series to no avail. I tried to
compile out APIC/IO-APIC stuff, I tried Alan's ac9 patches, etc.
However, I recently noticed that most times the console freezes when I am
doing a filename completion (which involves a beep when the completion is
not unique in KDE). I have changed the beep to be much shorter and with
much less annoying pitch from the KDE control panel.
I have found out that going in the control panel and just clicking the
"Test" button to test out the beep would freeze the console in less than
10-15 tries.
I got the sources for "kcontrol" and it seems the beeping is done from
some function of the keyboard driver, although I do not understand KDE
much and have no idea how to continue tracing the bug further.
Currently I have set the pitch to 0 Hz (no beeping) and have not had a
lockup yet. I will continue testing, however, if someone can give me a
suggestion how to go about tracing the code that actually does the
beeping (be it in KDE or the kernel) I'd be very grateful.
Cheers,
--Ivan
P.S. The relevant code from kdebase-2.0.1/kcontrol/bell/bell.cpp is:
void KBellConfig::ringBell()
{
// store the old state
XKeyboardState old_state;
XGetKeyboardControl(kapp->getDisplay(), _state);
// switch to the test state
XKeyboardControl kbd;
kbd.bell_percent = m_volume->value();
kbd.bell_pitch = m_pitch->value();
if (m_volume->value() > 0)
kbd.bell_duration = m_duration->value();
else
kbd.bell_duration = 0;
XChangeKeyboardControl(kapp->getDisplay(),
KBBellPercent | KBBellPitch | KBBellDuration,
);
// ring bell
XBell(kapp->getDisplay(),100);
// restore old state
kbd.bell_percent = old_state.bell_percent;
kbd.bell_pitch = old_state.bell_pitch;
kbd.bell_duration = old_state.bell_duration;
XChangeKeyboardControl(kapp->getDisplay(),
KBBellPercent | KBBellPitch | KBBellDuration,
);
}
--
Ivan Ganev 327236 Georgia Tech Station
College of Computing Atlanta, GA 30332
Georgia Institute of Technology1-(404)-365-8694
[EMAIL PROTECTED] http://www.cc.gatech.edu/~ganev
--
Learning is not compulsory. Neither is survival.
-- W. Edwards Deming
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: NFSD die with 2.4.1 (resend with ksymoops)
On Wednesday February 14, [EMAIL PROTECTED] wrote: > > Hi all, > I have a machine with kernel 2.4.1 + acls patch. It exports some volume via > NFS (installed with RedHat 7.0 + custom 2.4.1 kernel). The underlying > filesystem is ext2. I tried with NFS v2 and v3 and without ACLs in the > kernel. results are the same. > > Unable to handle kernel NULL pointer dereference at virtual address > > *pde = > Oops: > CPU:0 > EIP:0010:[acpi_exit+0/-1072693248] > EFLAGS: 00010286 > eax: ebx: c4f5c03c ecx: c091d040 edx: c0173710 > esi: c4f63424 edi: c4f5c03c ebp: c4f5c03c esp: c4f61f38 > ds: 0018 es: 0018 ss: 0018 > Process nfsd (pid: 2690, stackpage=c4f61000) > Stack: c0173774 c091d040 8000 c4f63000 c02f9220 c4f5c014 c4f63000 > c091d040 >a1ffc014 c016bdbb c4f63000 c4f5c01c c4f63400 c4f63138 c02f9220 > c4f63490 >c0273e38 c4f63000 c4f5c014 c4f6 0034fdbb c7f68560 c4f60550 > c4f63400 > Call Trace: [nfssvc_encode_diropres+100/520] [nfsd_dispatch+275/360] > [svc_process+684/1348] [nfsd+401/760] [kernel_thread+35/48] > Code: Bad EIP value. > Using defaults from ksymoops -t elf32-i386 -a i386 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 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. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
success NICs (disabled CONFIG_ISAPNP with 2.4.1-ac11)/otheroddments/Problem: NIC doesn't work
2.2.19pre11 works. Got 2.4.1-ac11 to work with these settings: # Plug and Play configuration # CONFIG_PNP=y # CONFIG_ISAPNP is not set eth0: Digital DC21041 Tulip rev 17 at 0xfc00, 21041 mode, 00:00:C0:5C:45:01, IRQ 10. eth1: 3c509 at 0x340, 10baseT port, address 00 10 5a 1c e5 fe, IRQ 7. 3c509.c:1.16 (2.2) 2/3/98 [EMAIL PROTECTED] eth2: 3c509 at 0x320, AUI port, address 00 20 af 0a 62 0d, IRQ 5. 3c509.c:1.16 (2.2) 2/3/98 [EMAIL PROTECTED] Oddments: [Can't show you since the machine locked up both times prior to logging information -- I need to break out the serial cable and capture boot messages] With CONFIG-ISAPNP off: 2.4.1-ac12 -- SCSI driver takes over and does not allow the IDE disk to boot. 2.4.1-ac11 -- The first time, root didn't remount properly from read-only to read-write and hung at trying to bring the system logger up. Was able to reboot using ALT-CTRL-DEL. Booting as single worked and then allowed it to follow through the remaining boot sequence. All seems well. Vitals on 2.4.1-ac11: Linux version 2.4.1-ac11 ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red Hat Linux 7.0)) #3 Wed Feb 14 22:55:19 EST 2001 BIOS-provided physical RAM map: BIOS-e820: 0009f800 @ (usable) BIOS-e820: 0800 @ 0009f800 (reserved) BIOS-e820: 0002 @ 000e (reserved) BIOS-e820: 03f0 @ 0010 (usable) BIOS-e820: 0008 @ fff8 (reserved) On node 0 totalpages: 16384 zone(0): 4096 pages. zone(1): 12288 pages. zone(2): 0 pages. Kernel command line: BOOT_IMAGE=2.4.1-ac11 ro root=301 BOOT_FILE=/boot/vmlinuz-2.4.1-ac11 hdc=ide-scsi hdd=ide-scsi single ide_setup: hdc=ide-scsi ide_setup: hdd=ide-scsi Initializing CPU#0 Detected 266.618 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 532.48 BogoMIPS Memory: 62464k/65536k available (893k kernel code, 2684k reserved, 307k data, 180k init, 0k highmem) Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) CPU: Before vendor init, caps: 0080f9ff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0080f9ff CPU: After generic, caps: 0080f9ff CPU: Common caps: 0080f9ff CPU: Intel Pentium II (Klamath) stepping 04 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX PCI: PCI BIOS revision 2.10 entry at 0xfd9cc, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 0: assuming transparent Unknown bridge resource 2: assuming transparent PCI: Using IRQ router PIIX [8086/7110] at 00:07.0 Limiting direct PCI/PCI transfers. Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 pty: 256 Unix98 ptys configured block: queued sectors max/low 41437kB/13812kB, 128 slots per queue RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PIIX4: IDE controller on PCI bus 00 dev 39 PIIX4: chipset revision 1 PIIX4: not 100% native mode: will probe irqs later hda: QUANTUM FIREBALL SE4.3A, ATA DISK drive hdc: SAF CD-RW4224A, ATAPI CD/DVD-ROM drive hdd: FX320S, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 8418816 sectors (4310 MB) w/80KiB Cache, CHS=524/255/63 Partition check: hda: hda1 hda2 < hda5 hda6 hda7 hda8 > Floppy drive(s): fd0 is 1.44M FDC 0 is a National Semiconductor PC87306 Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A Linux PCMCIA Card Services 3.1.22 options: [pci] [cardbus] [pm] NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 4096 bind 4096) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. ds: no socket drivers loaded! VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 180k freed Adding Swap: 136512k swap-space (priority -1) usb.c: registered new driver usbdevfs usb.c: registered new driver hub usb-uhci.c: $Revision: 1.251 $ time 23:17:30 Feb 14 2001 usb-uhci.c: High bandwidth mode enabled PCI: Enabling device 00:07.2 (0004 -> 0005) PCI: Found IRQ 11 for device 00:07.2 usb-uhci.c: USB UHCI at I/O 0xfcc0, IRQ 11 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found hub.c: 2 ports detected es1370: version v0.34 time 23:16:59 Feb
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? -- 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/
2.4.1/2.4.2-pre3 lockup unmounting usbdevfs
I'm getting an intermittent (but fairly reproducible) lockup under 2.4.1 and 2.4.2-pre3, which seems to be occurring when usbdevfs is unmounted. The system appears to freeze almost completely; I can still switch VCs (assuming I wasn't in X at the time) but little else. Sometimes (but not always) the console shows the message "VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day...". At least it's a very polite crash! (-: The sysreq-(b|p|t|m) combinations work, but sysreq-(s|u) don't... they display the appropriate console message, but there is no indication of any disk activity whatsoever. The 2.4.1 kernel had the crypto (patch-int-2.4.0.3) and Jens Axboe's loopback (loop-3) patches applied; 2.4.2-pre3 kernel had only the crypto patch. I've attached the output from two ksymoops runs... I had to copy them by hand, so hopefully I didn't miskey anything. Both are from the 2.4.1 kernel, as I was in X when I finally reproduced it under 2.4.2-pre3. As for the specific hardware, the system is a dual PIII-600MHz with 512MB, using the i840 chipset. It has an Adaptec 2940UW SCSI controller, and a Matrox G400. Comments and suggestions are, of course, quite welcome. ksymoops 2.3.7 on i686 2.4.1. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.1/ (default) -m /boot/System.map-2.4.1 (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. EIP: 0010:[] CPU: 0 EFLAGS: 0286 Using defaults from ksymoops -t elf32-i386 -a i386 EAX: db73f464 EBX: c023fcf4 ECX: db73f464 EDX: f33958e8 ESI: f33958e7 EDI: e0b21fe0 EBP: e0b22018 DS: 0018 ES: 0018 CR0: 8005003b CR2: 40116554 CR3: 1e4de000 CR4: 0690 Call Trace: [] [] [] [] [] [] [] [] [] [] [] Warning (Oops_read): Code line not seen, dumping what data is available >>EIP; c01ea703<= Trace; e0b21fe0 Trace; c0147688 Trace; e0b1c6fd Trace; e0b1cdc3 Trace; c0138186 Trace; c013747a Trace; c01385b2 Trace; c013869d Trace; c0124528 Trace; c013870c Trace; c0108f53 2 warnings issued. Results may not be reliable. ksymoops 2.3.7 on i686 2.4.1. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.1/ (default) -m /boot/System.map-2.4.1 (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. EIP: 0010:[] CPU: 0 EFLAGS: 0246 Using defaults from ksymoops -t elf32-i386 -a i386 EAX: f7cdc585 EBX: c023fcf4 ECX: cd4b0a64 EDX: f7cdc585 ESI: f7cdc584 EDI: e0b23fe0 EBP: e0b24018 DS: 0018 ES: 0018 CR0: 8005003b CR2: 40116554 CR3: 066e2000 CR4: 0690 Call Trace: [] [] [] [] [] [] [] [] [] [] [] Warning (Oops_read): Code line not seen, dumping what data is available >>EIP; c01ea709<= Trace; e0b23fe0 Trace; c0147688 Trace; e0b1e6fd Trace; e0b1edc3 Trace; c0138186 Trace; c013747a Trace; c01385b2 Trace; c013869d Trace; c0124528 Trace; c013870c Trace; c0108f53 2 warnings issued. Results may not be reliable. # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set CONFIG_MPENTIUMIII=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_TOSHIBA is not set CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y CONFIG_SMP=y CONFIG_HAVE_DEC_LOCK=y # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_X86_IO_APIC=y
Re: aic7xxx (and sym53c8xx) plans
On Wed, 14 Feb 2001, Chip Salzenberg wrote: > 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). "Justin" not "Jason" > > 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." Yes indeed. And he also support FreeBSD too. Very excellent. Maybe the two of *them* can convince Linus to take the !$*!)$*!)$*~$)* patch to scsi_syms.c that exports the add/del timer functions - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aic7xxx (and sym53c8xx) plans
According to 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/
Re: [patch] 2.4.2-pre3: parport_pc init_module bug
Philipp Rumpf wrote:
> On Wed, 14 Feb 2001, Grant Grundler wrote:
> > Having people look things up in the spec isn't very user friendly.
>
> Having the constants in some well-known header file should be sufficient,
> shouldn't it ?
I would hope anyone bothering to include the constants in a document would
spend a few minutes explaining them as well. Perhaps a bad assumption
on my part...
> It depends on the platform and maybe the exact PCI slot used, but I don't
> think it depends on the driver (unless MSI support is broken in which case
> you would want to fix it up in the driver).
correct.
> At least I can't find
> anything in the PCI 2.2 spec that would suggest we need to consult the
> driver before enabling MSIs with one message only.
I don't know how BIOS's treat this (if at all). Need to know this first.
If they manage this resource and pre-assign everything, ok.
That's how it goes.
But if generic PCI manages this, I prefer to avoid allocating resources
that may not get used. The host platform may have a limited pool of
usable MSI data values (think parisc EIRR bits) and some cards may want
to use more than one MSI.
grant
ps. seems this thread has gotten a bit far off from the original subject. :^/
Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253
-
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
See http://www.freebsd.org/~gibbs/linux. > Alan Cox wrote: > > > Are there any plans of switching the drivers ? I have tried to patch 2.4.1-acX, > > > but there are rejected hunks and had no time to patch manually and make a > > > diff. > > > > 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 > > 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. > > - 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
Alan Cox wrote: > > Are there any plans of switching the drivers ? I have tried to patch 2.4.1-acX, > > but there are rejected hunks and had no time to patch manually and make a > > diff. > > 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 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. -- Lab tests show that use of micro$oft causes cancer in lab animals - 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/
More (other) NIC info/Problem: NIC doesn't work anymore, SIOCIFADDR-errors
Jonathon, You and I might have the same problem. I have 2 3COM cards (ISA/PCI) and 1 Tulip card in a single PC and I loose functionality in one 3COM card using the 2.4. series; IRQ and IOBASE is wrong. Using stock Redhat built kernels, they operate fine. Feb 7 21:42:50 anole kernel: Linux version 2.2.16-22 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Tue Aug 22 16:49:06 EDT 2000 Feb 7 21:43:03 anole kernel: tulip.c:v0.91g-ppc 7/16/99 [EMAIL PROTECTED] Feb 7 21:43:03 anole kernel: eth0: Digital DC21041 Tulip rev 17 at 0xfc00, 00:00:C0:5C:45:01, IRQ 10. Feb 7 21:43:03 anole kernel: eth0: 21041 Media table, default media 0800 (Autosense ). Feb 7 21:43:03 anole kernel: eth1: 3c509 at 0x340 tag 1, 10baseT port, address 00 10 5a 1c e5 fe, IRQ 7. Feb 7 21:43:03 anole kernel: 3c509.c:1.16 (2.2) 2/3/98 [EMAIL PROTECTED] Feb 7 21:43:03 anole kernel: eth2: 3c509 at 0x320 tag 2, AUI port, address 00 20 a f 0a 62 0d, IRQ 5. Feb 7 21:43:03 anole kernel: 3c509.c:1.16 (2.2) 2/3/98 [EMAIL PROTECTED] 2.4.1-ac11 results (with isapnp stuff!): Feb 13 19:58:58 anole kernel: Linux version 2.4.1-ac11 ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red Hat Linux 7.0)) #1 Tue Feb 13 19:29:28 EST 2001 Feb 13 19:58:59 anole kernel: isapnp: Scanning for Pnp cards... Feb 13 19:58:59 anole kernel: isapnp: Card '3Com 3C509B EtherLink III' Feb 13 19:58:59 anole kernel: isapnp: 1 Plug & Play card detected total * my guess is this biloxes up resource somewhere... Feb 13 20:08:52 anole kernel: eth1: 3c509 at 0x340 tag 1, 10baseT port, address 00 10 5a 1c e5 fe, IRQ 7. Feb 13 20:08:52 anole kernel: 3c509.c:1.16 (2.2) 2/3/98 [EMAIL PROTECTED] Feb 13 20:08:52 anole kernel: eth2: 3c509 at 0x320 tag 2, AUI port, address 00 20 a f 0a 62 0d, IRQ 5. Feb 13 20:08:52 anole kernel: 3c509.c:1.16 (2.2) 2/3/98 [EMAIL PROTECTED] I'm building 2.2.19pre11 to see if things are still working out. I think I narrowed it down to the ISAPNP code entering the network drivers...I need to do more testing... Rob Cermak -- Subject : dual 3c509 cards break from 2.2.17-14 (Redhat versions) to 2.4.x through 2.4.1-ac11 - Message Text - Stock Redhat 7.x 2.2.16 and 2.2.17 kernels are able to correctly detect 3c509 cards with this result: Feb 13 20:14:44 anole kernel: eth1: 3c509 at 0x340 tag 1, 10baseT port, address 00 10 5a 1c e5 fe, IRQ 7. Feb 13 20:14:44 anole kernel: eth2: 3c509 at 0x320 tag 2, AUI port, address 00 20 af 0a 62 0d, IRQ 5. The printer port on the PC (x86) has been disabled through the BIOS. The above kernels operate as expected and I can ping and do normal network traffic. Any 2.4.x kernel causes both cards to appear on IRQ 5 and renders one of the cards useless. Stock unpatched 2.4.0: Feb 7 19:25:16 anole kernel: eth1: 3c509 at 0x220, 10baseT port, address 00 10 5a 1c e5 fe, IRQ 5. Feb 7 19:25:16 anole kernel: eth2: 3c509 at 0x320, AUI port, address 00 20 af 0a 62 0d, IRQ 5. Same result with the recent patched 2.4.1 with ac11. I'll continue checking other patched versions of the kernel and try and locate where things might have went awry and post a message; if someone else doesn't find it first. >From what I gather, it might have something do ISAPNP stuff. Rob -- Forwarded message -- Date: Wed, 14 Feb 2001 12:00:16 +0100 From: Jonathan Brugge <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Problem: NIC doesn't work anymore, SIOCIFADDR-errors I've got a problem with my network. I can't get the card running, though it worked perfectly before. Below what happens and the errors I get: --- odysseus:/# ifconfig // No active devices found. odysseus:/# ifconfig -a eth0 Link encap:Ethernet HWaddr 00:20:18:80:B0:95 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:9 Base address:0xde00 loLink encap:Local Loopback LOOPBACK MTU:16192 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) // It finds eth0 and the loopback, they aren't active. odysseus:/# ifdown eth0 ifdown: interface eth0 not configured // Just what should happen... odysseus:/# ifup eth0 SIOCSIFADDR: Bad file descriptor eth0: unknown interface: Bad file descriptor SIOCSIFNETMASK: Bad file descriptor eth0: unknown interface: Bad file descriptor odysseus:/# ifup lo SIOCSIFADDR: Bad file descriptor lo: unknown interface: Bad file descriptor lo: unknown interface: Bad file descriptor odysseus:/# // This is where I loose the track. These seem to be kernel-messages, but I can't find them in the kernel-source (looked in the kernel-subdirectory
crash 5/5 w/ memtest86
Hi, 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. I suspected a new PC133 memory stick, but the test failed at the same point without it. My system has run fine with this for at least five days, I only noticed a problem after an oops last night, after upgrading to the 2.4.2-pre3 kernel yesterday morning. Is there any other way to test whether this may be a memory problem or something else, besides gettig more ram or a different motherboard? I do have an strace of one SIGSEGV from a fetchmail run, if it might help. 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: modules_install target
You're forgetting it's using System.map from your build directory and not from /boot. "J . A . Magallon" wrote: > > I have recently noticed that 'make modules_install' tries as a last step > > if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.4.1-ac13; fi > > I depends on 'make install' doing the right symlinks in /boot. > Would not be better to do a: > > if [ -r System.map-2.4.1-ac13 ]; then /sbin/depmod -ae -F System.map-2.4.1-ac13 > 2.4.1-ac13; fi > > ??? -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [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/
Manual SCSI bus reset?
Hello, I've got Plexwriter 12x10x32S attached to an onbard AIC7890 (besides other things as three IBM UWSCSI harddisks, an SCSI ZIP and a Pioneer DVD) and sometimes when recording a CD the Plexwriter fails at the very end of the process (although the CD is recorded correctly) and it is locked with no posibility to eject it (it seems that a failure while reading from the DVD during on-the-fly recording is the cause). But if I reset the SCSI bus manually, that is trying to read from a "reset-it CD", that is completely broken and makes the SCSI bus resets itself, I can eject the CD from the Plexwriter. So I would like to know if there is a way to do it without that trick. I've downloaded some utilities for the SCSI generic driver, one of them should let you reset the bus (or even just a single device) but it fails with "SCSI_RESET" not supported and after reading through the docs it seems that the kernel (or should I say the SCSI drivers) doesn't support this kind of reset. I would like to know if this is "kernel politics", "faulty hardware", or just lazy programmers ;-), thanks and please CC the answer to me as I'm not subscribed to this mailing list. - german --- German Gomez Garcia | "This isn't right. This isn't even wrong." <[EMAIL PROTECTED]> | -- Wolfgang Pauli - 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: modules_install target
On Thu, 15 Feb 2001 01:38:46 +0100, "J . A . Magallon" <[EMAIL PROTECTED]> wrote: >I have recently noticed that 'make modules_install' tries as a last step > >if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.4.1-ac13; fi > >I depends on 'make install' doing the right symlinks in /boot. >Would not be better to do a: > >if [ -r System.map-2.4.1-ac13 ]; then /sbin/depmod -ae -F System.map-2.4.1-ac13 > 2.4.1-ac13; fi The System.map depmod uses is the one in the top level linux directory. It has nothing to do with where the distribution will copy that System.map to, nor does it depend on /boot. Leave it alone. - 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/
NFS mounting delays w/ 2.4.x kernel?
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 - Which pauses the boot process by about 3 minutes. Everything mounts fine but there is the pause. Doing a tcpump I see: 18:34:39.445211 192.168.2.18.931 > 192.168.2.26.827: udp 60 (DF) 18:34:39.445428 192.168.2.26.829 > 192.168.2.18.111: udp 56 (DF) 18:34:39.446396 192.168.2.18.111 > 192.168.2.26.829: udp 28 (DF) 18:34:39.446764 192.168.2.26.2114226 > 192.168.2.18.2049: 96 getattr [|nfs] (DF) 18:34:39.447682 192.168.2.18.2049 > 192.168.2.26.2114226: reply ok 96 getattr [|nfs] (DF) 18:34:39.447894 192.168.2.26.18891442 > 192.168.2.18.2049: 96 statfs [|nfs] (DF) 18:34:39.448528 192.168.2.18.2049 > 192.168.2.26.18891442: reply ok 48 statfs [|nfs] (DF) (192.168.2.18 - nfs exporter, 192.168.2.26 the system that was upgraded the one trying to mount the exported volume). When I don't change anything but boot the older 2.2.17 kernel the system starts right up. I don't see anything that would be causing this. Attached is the configuration for the kernel I'm running. I use menuconfig to configure the system (if that makes a difference) and compile kernels monolithic. Does anyone have any ideas? -- CONFIG_X86=y CONFIG_ISA=y CONFIG_UID16=y CONFIG_EXPERIMENTAL=y CONFIG_MPENTIUMIII=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_MICROCODE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_NOHIGHMEM=y CONFIG_MTRR=y CONFIG_SMP=y CONFIG_HAVE_DEC_LOCK=y CONFIG_NET=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_PCI=y CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y CONFIG_BINFMT_ELF=y CONFIG_PNP=y CONFIG_ISAPNP=y CONFIG_BLK_DEV_FD=y CONFIG_BLK_DEV_DAC960=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_RAID0=y CONFIG_MD_RAID1=y CONFIG_MD_RAID5=y CONFIG_BLK_DEV_LVM=y CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_NETLINK=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_SYN_COOKIES=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_SD_EXTRA_DEVS=40 CONFIG_CHR_DEV_ST=y CONFIG_BLK_DEV_SR=y CONFIG_SR_EXTRA_DEVS=2 CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y CONFIG_SCSI_BUSLOGIC=y CONFIG_SCSI_OMIT_FLASHPOINT=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_DE4X5=y CONFIG_EEPRO100=y CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y CONFIG_SERIAL_CONSOLE=y CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 CONFIG_NVRAM=y CONFIG_RTC=y CONFIG_QUOTA=y CONFIG_ISO9660_FS=y CONFIG_MINIX_FS=y CONFIG_PROC_FS=y CONFIG_DEVFS_FS=y CONFIG_DEVFS_MOUNT=y CONFIG_DEVPTS_FS=y CONFIG_EXT2_FS=y CONFIG_NFS_FS=y CONFIG_SUNRPC=y CONFIG_LOCKD=y CONFIG_MSDOS_PARTITION=y CONFIG_VGA_CONSOLE=y CONFIG_VIDEO_SELECT=y - 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: doing RAID 0 with HPT370
> do know I get the feeling they don't care to support Linux in any way > shape or form. Feels like a pawn off job. afaik, there's no hardware raid support in the chip - it's just another dual-channel controller, with some raid0 (perhaps raid1) software in bios. I think Andre has said that he has hopes of getting docs on HPT's on-disk raid layout - but this is a software thing, and all it would give us is interoperability with that other OS. - 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/
modules_install target
I have recently noticed that 'make modules_install' tries as a last step if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.4.1-ac13; fi I depends on 'make install' doing the right symlinks in /boot. Would not be better to do a: if [ -r System.map-2.4.1-ac13 ]; then /sbin/depmod -ae -F System.map-2.4.1-ac13 2.4.1-ac13; fi ??? -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.4.1-ac10 #1 SMP Sun Feb 11 23:36:46 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: doing RAID 0 with HPT370
On Thu, 15 Feb 2001, Bradley Kite wrote: > I found this message while searching for a solution to getting > linux to see a raid array on my HPT370: > > http://www.mailgate.org/linux/linux.dev.raid/msg00163.html > > Its got someone from highpoint saying that raid support will > be offered "in the near future", and that message was dated October 2000. > > I emailed highpoint to ask if they had got any where, but they dont seem to > reply. > I've emailed them myself as this is the 2nd board I have with the HPT370 controller on it. HighPoint has not returned any of the 4 messages I've sent to them in the last 3 months. I don't know what their plans are but I do know I get the feeling they don't care to support Linux in any way shape or form. Feels like a pawn off job. -- 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/
doing RAID 0 with HPT370
I'm new to this list so I'd like to say hi first :-) I found this message while searching for a solution to getting linux to see a raid array on my HPT370: http://www.mailgate.org/linux/linux.dev.raid/msg00163.html Its got someone from highpoint saying that raid support will be offered "in the near future", and that message was dated October 2000. I emailed highpoint to ask if they had got any where, but they dont seem to reply. Does any one know if highpoint are in fact developing a linux driver that supports the RAID functions of this chip? and if so, are we looking at weeks/months/years before it might be ready? ps: hedricks ide patch doesnt support the RAID functions of the chip, otherwise I would have been happy to use that! :-) Many thanks -- Brad. - 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] i2c 2.5.5
On 02.15 Alan Cox wrote: > > The rest are revision noise and incorrect reverts of include changes > > > #ifndef MODULE > > +#ifdef CONFIG_I2C_CHARDEV > > extern int i2c_dev_init(void); > > Also reverting a cleanup > And I manually deleted the #endif /* X */ (kernel) vs #endif X (i2c 2.5.5) diffs that I got... (do not know why the maintainer did not clone the change...) So I suppose the lm_sensors-2.5.5 package will have the same problems. Well, I will leave it for home use... -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.4.1-ac10 #1 SMP Sun Feb 11 23:36:46 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pcnet32.c: MAC address may be in CSR registers
> +int is_valid_ether_addr( char* address )
> +{
> +int i,isvalid=0;
> +for( i=0; i<6; i++)
> + isvalid |= address[i];
> +return isvalid && !(address[0]&1);
> +}
static and why not
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)
Looks ok to me, Im picking holes now
-
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
> Are there any plans of switching the drivers ? I have tried to patch 2.4.1-acX, > but there are rejected hunks and had no time to patch manually and make a > diff. 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 - 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/
2001-02-14 release of hotplug scripts
I've just packaged up the latest hotplug scripts into a release, and they can be found at: http://download.sourceforge.net/linux-hotplug/hotplug-2001_02_14.tar.gz http://download.sourceforge.net/linux-hotplug/hotplug-2001_02_14-1.noarch.rpm http://download.sourceforge.net/linux-hotplug/hotplug-2001_02_14-1.src.rpm depending on which format you prefer. Changes in this version from the last release are: - rpm makes the subsystem scripts executable - some logging fixes - insistence on having a writable /tmp so bash works properly - added support for pcimodules - Fixes some problems seen with Redhat 7 systems when the partial USB setup in /etc/rc.sysinit was not disabled. The failure mode was that all USB modules got loaded, rather than only modules for the devices that were connected. - In conjunction with the "usbmodules" and "pcimodules" patches to "usbutils-0.7" and "pciutils-2.1.8", devices that are connected at boot time will also be configured. If you don't have those utilities, you'll need to plug USB and CardBus devices in after the system is booted, otherwise they can't be properly configured. - other small fixes. If you haven't patched your version of usbutils and pciutils, you can get the patch at: http://marc.theaimsgroup.com/?l=linux-hotplug-devel=98141435915986=2 Hopefully updated versions of these two packages will be released with these changes in them soon. thanks, greg k-h -- greg@(kroah|wirex).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/
aic7xxx plans
Hi. I have read in the Doug Ledford www page that the drivers for the aic7xxx card are going to a more or less unmantained state, 'cause he has not the time. And also recommends to use the Justin Gibbs's ones from FreeBSD. They are now at version 6.1.1, no more beta. Are there any plans of switching the drivers ? I have tried to patch 2.4.1-acX, but there are rejected hunks and had no time to patch manually and make a diff. -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.4.1-ac10 #1 SMP Sun Feb 11 23:36:46 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pcnet32.c: MAC address may be in CSR registers
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.
Added Peter since he's given feedback on a past pcnet32 patch.
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,
Eli
. Rule of Accuracy: When working toward
Eli Carter | the solution of a problem, it always
[EMAIL PROTECTED] `- helps if you know the answer.
--- linux/drivers/net/pcnet32.c.2.4.1 Wed Feb 14 16:49:31 2001
+++ linux/drivers/net/pcnet32.c Wed Feb 14 17:37:23 2001
@@ -283,6 +283,7 @@
struct net_device *next;
};
+static int is_valid_ether_addr( char* );
static int pcnet32_probe_vlbus(int cards_found);
static int pcnet32_probe_pci(struct pci_dev *, const struct pci_device_id *);
static int pcnet32_probe1(unsigned long, unsigned char, int, int, struct pci_dev *);
@@ -437,6 +438,18 @@
+/* Check that the ethernet station address is not 00:00:00:00:00:00 and is also
+ * not a multicast address
+ * Return true if the address is valid.
+ */
+int is_valid_ether_addr( char* address )
+{
+int i,isvalid=0;
+for( i=0; i<6; i++)
+ isvalid |= address[i];
+return isvalid && !(address[0]&1);
+}
+
/* only probes for non-PCI devices, the rest are handled by pci_register_driver via
pcnet32_probe_pci*/
static int __init pcnet32_probe_vlbus(int cards_found)
{
@@ -624,10 +637,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 */
@@ -774,6 +810,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);
diff -u -r1.1.1.6 pcnet32.c
--- linux/drivers/net/pcnet32.c 2001/01/20 11:10:30 1.1.1.6
+++ linux/drivers/net/pcnet32.c 2001/02/14 23:30:51
@@ -281,6 +281,7 @@
#endif
};
+static int is_valid_ether_addr( char* );
int pcnet32_probe(struct device *);
static int pcnet32_probe1(struct device *, unsigned long, unsigned char, int, int);
static int pcnet32_open(struct device *);
@@ -442,6 +443,18 @@
+/* Check that the ethernet station address is not 00:00:00:00:00:00 and is also
+ * not a multicast address
+ * Return true if the address is valid.
+ */
+int is_valid_ether_addr( char* address )
+{
+int i,isvalid=0;
+for( i=0; i<6; i++)
+ isvalid |= address[i];
+return isvalid && !(address[0]&1);
+}
+
int __init pcnet32_probe (struct device *dev)
{
unsigned long ioaddr = dev ?
Re: [PATCH] i2c 2.5.5
> @@ -71,4 +71,7 @@ >} > > +IMPORTANT: because of the use of inline functions, you *have* to use > +'-O' or some variation when you compile your program! > + Considered too obvious to restate > > -This sends a single byte to the device, at the place of the Rd/Wr bit. > +This sends a single bit to the device, at the place of the Rd/Wr bit. > There is no equivalent Read Quick command. Ok valid The rest are revision noise and incorrect reverts of include changes > #ifndef MODULE > +#ifdef CONFIG_I2C_CHARDEV > extern int i2c_dev_init(void); Also reverting a cleanup - 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] i2c 2.5.5
Hi, everyone... Kernel 2.4 looks like including the updated i2c package. But the diff automatic generator from i25 2.5.5 still gives this diffs against 2.4.1-ac13. Think about them for inclussion...(I do not know if some of them are not valid, like the change of for , but the #ifdefs CONFIG_ perhaps matter) patch follows === --- linux-old/Documentation/i2c/dev-interface Thu Feb 15 00:26:02 CET 2001 +++ linux/Documentation/i2c/dev-interface Thu Feb 15 00:26:02 CET 2001 @@ -71,4 +71,7 @@ } +IMPORTANT: because of the use of inline functions, you *have* to use +'-O' or some variation when you compile your program! + Full interface description --- linux-old/Documentation/i2c/smbus-protocol Thu Feb 15 00:26:03 CET 2001 +++ linux/Documentation/i2c/smbus-protocol Thu Feb 15 00:26:03 CET 2001 @@ -32,5 +32,5 @@ = -This sends a single byte to the device, at the place of the Rd/Wr bit. +This sends a single bit to the device, at the place of the Rd/Wr bit. There is no equivalent Read Quick command. --- linux-old/drivers/i2c/i2c-algo-bit.cThu Feb 15 00:26:06 CET 2001 +++ linux/drivers/i2c/i2c-algo-bit.cThu Feb 15 00:26:06 CET 2001 @@ -22,10 +22,10 @@ Frodo Looijaard <[EMAIL PROTECTED]> */ -/* $Id: i2c-algo-bit.c,v 1.27 2000/07/09 15:16:16 frodo Exp $ */ +/* $Id: i2c-algo-bit.c,v 1.28 2001/01/09 20:10:57 frodo Exp $ */ #include #include #include -#include +#include #include #include --- linux-old/drivers/i2c/i2c-algo-pcf.cThu Feb 15 00:26:07 CET 2001 +++ linux/drivers/i2c/i2c-algo-pcf.cThu Feb 15 00:26:07 CET 2001 @@ -30,5 +30,5 @@ #include #include -#include +#include #include #include --- linux-old/drivers/i2c/i2c-core.cThu Feb 15 00:26:10 CET 2001 +++ linux/drivers/i2c/i2c-core.cThu Feb 15 00:26:10 CET 2001 @@ -26,5 +26,5 @@ #include #include -#include +#include #include #include @@ -1278,12 +1278,29 @@ #ifndef MODULE +#ifdef CONFIG_I2C_CHARDEV extern int i2c_dev_init(void); +#endif +#ifdef CONFIG_I2C_ALGOBIT extern int i2c_algo_bit_init(void); +#endif +#ifdef CONFIG_I2C_BITLP extern int i2c_bitlp_init(void); +#endif +#ifdef CONFIG_I2C_BITELV extern int i2c_bitelv_init(void); +#endif +#ifdef CONFIG_I2C_BITVELLE extern int i2c_bitvelle_init(void); +#endif +#ifdef CONFIG_I2C_BITVIA extern int i2c_bitvia_init(void); +#endif + +#ifdef CONFIG_I2C_ALGOPCF extern int i2c_algo_pcf_init(void); +#endif +#ifdef CONFIG_I2C_PCFISA extern int i2c_pcfisa_init(void); +#endif /* This is needed for automatic patch generation: sensors code starts here */ --- linux-old/drivers/i2c/i2c-dev.c Thu Feb 15 00:26:11 CET 2001 +++ linux/drivers/i2c/i2c-dev.c Thu Feb 15 00:26:11 CET 2001 @@ -29,5 +29,5 @@ <[EMAIL PROTECTED]> */ -/* $Id: i2c-dev.c,v 1.36 2000/09/22 02:19:35 mds Exp $ */ +/* $Id: i2c-dev.c,v 1.37 2001/01/09 20:10:57 frodo Exp $ */ #include @@ -35,5 +35,5 @@ #include #include -#include +#include #include #if LINUX_KERNEL_VERSION >= KERNEL_VERSION(2,4,0) --- linux-old/drivers/i2c/i2c-elektor.c Thu Feb 15 00:26:12 CET 2001 +++ linux/drivers/i2c/i2c-elektor.c Thu Feb 15 00:26:12 CET 2001 @@ -29,5 +29,5 @@ #include #include -#include +#include #include #include --- linux-old/drivers/i2c/i2c-elv.c Thu Feb 15 00:26:12 CET 2001 +++ linux/drivers/i2c/i2c-elv.c Thu Feb 15 00:26:12 CET 2001 @@ -27,5 +27,5 @@ #include #include -#include +#include #include #include --- linux-old/include/linux/i2c-id.hThu Feb 15 00:26:13 CET 2001 +++ linux/include/linux/i2c-id.hThu Feb 15 00:26:13 CET 2001 @@ -21,5 +21,5 @@ /* - */ -/* $Id: i2c-id.h,v 1.25 2000/10/12 07:27:29 simon Exp $ */ +/* $Id: i2c-id.h,v 1.27 2000/12/23 16:59:38 mds Exp $ */ #ifndef I2C_ID_H -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.4.1-ac10 #1 SMP Sun Feb 11 23:36:46 CET 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ECN for servers ?
Hi no they should not be effected the place that starts the connection eg send the first SYN has to ask to use ECN if it is not requested it will never be used in that connection In local.linux-kernel-list, you wrote: >Hello, > >What is the impact of enabling ECN on the server side ? I mean, will >any clients (with broken firewalls) be affected if a SMTP/HTTP server >has ECN enabled ? > >On the other hand, is there any advantage with ECN enabled on the server >side ? > >-- >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/ > -- - Check Out: http://stev.org E-Mail: [EMAIL PROTECTED] 8:10pm up 13 days, 3:55, 2 users, load average: 0.08, 0.28, 0.14 - 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/
/proc/stat missing disk_io info
Hi all, I was wondering why some of my disks don't show up in /proc/stat's disk_io line. Specifically, my line says: disk_io: (2,0):(144,144,288,0,0) (3,0):(35,35,140,0,0) This equates to my floppy and first cdrom. I also have a second cdrom (RW) and 2 hard disks. Looking at the code (kstat_read_proc in fs/proc/proc_misc.c) it is looping only up to DK_MAX_MAJOR which is defined as 16 in kernel_stat.h. The problem is that my 2 HDs have a major number of 22. I don't know enough to produce a patch, that is, what should DK_MAX_MAJOR be set to, but I believe the above is the problem. Thanks, --Rainer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Samba performance / zero-copy network I/O
Quoting "Gord R. Lamb" <[EMAIL PROTECTED]>: > On Wed, 14 Feb 2001, Jeremy Jackson wrote: > > > "Gord R. Lamb" wrote: > > > in etherchannel bond, running > linux-2.4.1+smptimers+zero-copy+lowlatency) Not related to network, but why would you have lowlatency patches on this box? My testing showed that the lowlatency patches abosolutely destroy a system thoughput under heavy disk IO. Sure, the box stays nice and responsive, but something has to give. On a file server I'll trade console responsivness for IO performance any day (might choose the opposite on my laptop). My testing wasn't very complete, but heavy dbench and multiple simultaneous file copies both showed significantly lower performance with lowlatency enabled, and returned to normal when disabled. Of course you may have had lowlatency disabled via sysctl but I was mainly curious if your results were different. Later, Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [beta patch] SSE copy_page() / clear_page()
I have another idea for sse, and this one is far safer:
only use sse prefetch, leave the string operations for the actual copy.
The prefetch operations only prefetch, don't touch the sse registers,
thus neither any reentency nor interrupt problems.
I tried the attached hack^H^H^H^Hpatch, and read(fd, buf, 400) from
user space got 7% faster (from 264768842 cycles to 246303748 cycles,
single cpu, noacpi, 'linux -b', fastest time from several thousand
runs).
The reason why this works is simple:
Intel Pentium III and P 4 have hardcoded "fast stringcopy" operations
that invalidate whole cachelines during write (documented in the most
obvious place: multiprocessor management, memory ordering)
The result is a very fast write, but the read is still slow.
--
Manfred
--- 2.4/mm/filemap.cWed Feb 14 10:51:42 2001
+++ build-2.4/mm/filemap.c Wed Feb 14 22:11:44 2001
@@ -1248,6 +1248,20 @@
size = count;
kaddr = kmap(page);
+ if (size > 128) {
+ int i;
+ __asm__ __volatile__(
+ "mov %1, %0\n\t"
+ : "=r" (i)
+ : "r" (kaddr+offset)); /* load tlb entry */
+ for(i=0;ibuf, kaddr + offset, size);
kunmap(page);
[ANNOUNCEMENT] High resolution timer mailing list/ project
An open source project is starting at: http://sourceforge.net/projects/high-res-timers/ Currently the project is collecting ideas, requirements, etc. A mailing list has been set up for the project. To join: http://lists.sourceforge.net/lists/listinfo/high-res-timers-discourse To mail to the list (member or not) mail to: [EMAIL PROTECTED] Come help us design and build high resolution timers for linux. George - 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-ac13 tulip problems
Alan Cox wrote: > > > I just booted to 2.4.1-ac13, and was fine for a couple minutes. Then > > all network connectivity went away, and I had this sitting in syslog: > > Hence, I'm back to 2.4.1-ac12, and sending this in. No other noticible > > problems in my short-lived uptime ;-) > > I guess the pnic fixes have a side effect we didnt want. What kind of tulip > do you have (lspci -v ?) oops, i guess that would have been helpful, eh? ;-) It's a Netgear FA310TX. Here's lspci output: patience:~# lspci -v 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02) Subsystem: Asustek Computer, Inc.: Unknown device 8033 Flags: bus master, medium devsel, latency 0 Memory at e400 (32-bit, prefetchable) [size=64M] Capabilities: [a0] AGP version 2.0 Capabilities: [c0] Power Management version 2 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (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: e080-e1df Prefetchable memory behind bridge: e1f0-e3ff Capabilities: [80] Power Management version 2 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22) Subsystem: Asustek Computer, Inc.: Unknown device 8033 Flags: bus master, stepping, medium devsel, latency 0 00:04.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (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:04.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) (prog-if 00 [UHCI]) Subsystem: Unknown device 0925:1234 Flags: bus master, medium devsel, latency 32, IRQ 9 I/O ports at d400 [size=32] Capabilities: [80] Power Management version 2 00:04.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) (prog-if 00 [UHCI]) Subsystem: Unknown device 0925:1234 Flags: bus master, medium devsel, latency 32, IRQ 9 I/O ports at d000 [size=32] Capabilities: [80] Power Management version 2 00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) Subsystem: Asustek Computer, Inc.: Unknown device 8033 Flags: medium devsel, IRQ 9 Capabilities: [68] Power Management version 2 00:09.0 Multimedia audio controller: Creative Labs SB Live! EMU1 (rev 05) Subsystem: Creative Labs CT4760 SBLive! Flags: bus master, medium devsel, latency 32, IRQ 9 I/O ports at a400 [size=32] Capabilities: [dc] Power Management version 1 00:09.1 Input device controller: Creative Labs SB Live! (rev 05) Subsystem: Creative Labs Gameport Joystick Flags: bus master, medium devsel, latency 32 I/O ports at a000 [size=8] Capabilities: [dc] Power Management version 1 00:0a.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20) Subsystem: Netgear FA310TX Flags: bus master, medium devsel, latency 32, IRQ 5 I/O ports at 9800 [size=256] Memory at e000 (32-bit, non-prefetchable) [size=256] Expansion ROM at [disabled] [size=256K] 00:0d.0 SCSI storage controller: Adaptec 7892A (rev 02) Subsystem: Adaptec: Unknown device 62a0 Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 9 BIST result: 00 I/O ports at 9400 [size=256] Memory at df80 (64-bit, non-prefetchable) [size=4K] Expansion ROM at [disabled] [size=128K] Capabilities: [dc] Power Management version 2 00:11.0 Unknown mass storage controller: Promise Technology, Inc. 20265 (rev 02) Subsystem: Promise Technology, Inc.: Unknown device 4d33 Flags: bus master, medium devsel, latency 32, IRQ 10 I/O ports at 9000 [size=8] I/O ports at 8800 [size=4] I/O ports at 8400 [size=8] I/O ports at 8000 [size=4] I/O ports at 7800 [size=64] Memory at df00 (32-bit, non-prefetchable) [size=128K] Expansion ROM at [disabled] [size=64K] Capabilities: [58] Power Management version 1 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 05) (prog-if 00 [VGA]) Subsystem: Matrox Graphics, Inc. Millennium G400 MAX/Dual Head 32Mb Flags: bus master, medium devsel, latency 64, IRQ 11 Memory at e200 (32-bit, prefetchable) [size=32M] Memory at e100 (32-bit, non-prefetchable) [size=16K] Memory at e080 (32-bit, non-prefetchable) [size=8M] Expansion ROM at e1ff [disabled] [size=64K] Capabilities: [dc] Power Management version 2 Capabilities: [f0] AGP version 2.0 Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of
Re: 2.4.1-ac13 tulip problems
Which tulip card do you use? -- 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: ECN for servers ?
"H. Peter Anvin" <[EMAIL PROTECTED]> writes: > Con: people behind broken firewalls can't connect. Are you sure that is correct? "Servers" normally listen for incoming connections from clients rather than establish them[1]. So, if the server implements ECN then it will respond appropriately to incoming SYN packets irrespective of whether the ECN bits are set. People, who use ECN, who are behind a broken firewall will have problems connecting irrespective of whether or not the server implements ECN. [1] Passive FTP being an exception. - 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-ac13 tulip problems
> I just booted to 2.4.1-ac13, and was fine for a couple minutes. Then > all network connectivity went away, and I had this sitting in syslog: > Hence, I'm back to 2.4.1-ac12, and sending this in. No other noticible > problems in my short-lived uptime ;-) I guess the pnic fixes have a side effect we didnt want. What kind of tulip do you have (lspci -v ?) - 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-ac13 tulip problems
I just booted to 2.4.1-ac13, and was fine for a couple minutes. Then all network connectivity went away, and I had this sitting in syslog: Feb 14 16:45:48 patience kernel: LDT allocated for cloned task! Feb 14 16:47:19 patience kernel: NETDEV WATCHDOG: eth0: transmit timed out Feb 14 16:47:51 patience last message repeated 4 times Feb 14 16:48:55 patience last message repeated 8 times Feb 14 16:49:59 patience last message repeated 8 times Feb 14 16:51:03 patience last message repeated 8 times Feb 14 16:51:51 patience last message repeated 6 times Feb 14 16:51:59 patience kernel: NETDEV WATCHDOG: eth0: transmit timed out Feb 14 16:52:31 patience last message repeated 4 times Feb 14 16:53:35 patience last message repeated 8 times Feb 14 16:54:39 patience last message repeated 8 times Feb 14 16:54:47 patience kernel: NETDEV WATCHDOG: eth0: transmit timed out Feb 14 16:54:49 patience kernel: inet6_ifa_finish_destroy Feb 14 16:54:49 patience kernel: inet6_ifa_finish_destroy Feb 14 16:54:57 patience kernel: eth0: Setting half-duplex based on MII#1 link partner capability of 0021. Feb 14 16:55:15 patience kernel: eth0: no IPv6 routers present Feb 14 16:55:15 patience kernel: eth0: no IPv6 routers present Hence, I'm back to 2.4.1-ac12, and sending this in. No other noticible problems in my short-lived uptime ;-) Nathan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Are the sysctl and ptrace bugs already fixed ?
> vulnerability in 2.2.18-pre9 (I suppose it was really 2.2.19-pre9). But > with respect to the other two vulnerabilities on 2.2.x and the whole th= > ree > in kernel series 2.4.x haven't been able to find any information in > neither Bugtraq, nor in the Linux kernel development archives. 2.2.19pre9 fixes the base ptrace attack, the sysctl bug. The PIII fpu bug doesnt apply to 2.2 unless you applied the PIII patches to it 2.4.0 didnt have the ptrace bug. The -ac tree has both sysctl and fpu fixed. I believe the current Linus 2.4.2pre has fpu but not sysctl fixed - 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] pcnet32.c: MAC address may be in CSR registers
All,
Thomas Bogendoerfer is listed as maintainer.
Richard, I know you've done some work with this driver so I thought you
might be interested.
Alan, I'd like to see this find its way into the official version(s), so
feedback would be appreciated if you don't apply it. (In your copious
spare time, of course. ;) )
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.
(The diff is against 2.2.18 and applies cleanly.)
If this is not acceptible or could be improved, please reply with
feedback.
TIA,
Eli
. Rule of Accuracy: When working toward
Eli Carter | the solution of a problem, it always
[EMAIL PROTECTED] `- helps if you know the answer.
diff -u -r1.1.1.6 pcnet32.c
--- linux/drivers/net/pcnet32.c 2001/01/20 11:10:30 1.1.1.6
+++ linux/drivers/net/pcnet32.c 2001/02/14 21:43:28
@@ -648,10 +648,32 @@
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
+ * Currently, we only check for 00:00:00:00:00:00 as invalid.
+ */
+{
+int valid_station=0;
+ /* 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++) {
+ unsigned int addr = inb(ioaddr + i);
+ valid_station |= addr;
+ dev->dev_addr[i] = addr;
+ }
+ if( !valid_station ) {
+ for (i = 0; i < 3; i++) {
+ unsigned int v;
+ v = a->read_csr(ioaddr, i+12);
+ /* There may be endianness issues here. */
+ dev->dev_addr[2*i] = v & 0x0ff;
+ dev->dev_addr[2*i+1] = (v >> 8) & 0x0ff;
+ }
+ }
+ 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 */
Are the sysctl and ptrace bugs already fixed ?
Hi everyone: Last week there was some advisories on the Bugtraq mailing list about three problems with respect to both kernel series 2.2.x and 2.4.x. They were about two possible local exploits trough sysctl and ptrace, and a minor bug about machines with Pentium III processors (any local user could potentially halt the CPU). At least RedHat and Caldera released patched kernel packages for their distributions. It seems that Alan Cox included a patch that fixes the sysctl() vulnerability in 2.2.18-pre9 (I suppose it was really 2.2.19-pre9). But with respect to the other two vulnerabilities on 2.2.x and the whole three in kernel series 2.4.x haven't been able to find any information in neither Bugtraq, nor in the Linux kernel development archives. Am I missing something here ?. PS: first message on the list. Don't be too cruel with me :) -- José Luis Domingo López Linux Registered User #189436 Debian GNU/Linux Potato (P166 64 MB RAM) jdomingo AT internautas DOT org => Spam at your own risk - 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: piix.c and tuning question
On Wed, Feb 14, 2001 at 02:51:03AM -0500, Shawn Starr wrote: > > hmmm this is my chipset: > > Which motherboard do you have? No clue, it's an old p166, and I'm not about to open up the case.. > > 00:00.0 Host bridge: Intel Corporation 430HX - 82439HX TXC [Triton II] (rev 03) > 00:07.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] (rev 01) > 00:07.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] > > i've had irq timeouts but they were due to a slow CD-ROM causing the two DMA drives >to timeout (don't > know why). > > ive never seen ide_dmaproc though. Me neither, which is why I initially couldn't figure out what was wrong.. Since setting -X34, however, I haven't had any more ide problems. > > This is my following hdparm config > > hdparm -d 1 -X34 -u1 -k 1 /dev/hdb > hdparm -d 1 -X34 -u1 -k 1 /dev/hda I don't use -k1, since I rely on the OS to set features if something is messed up. Has -u1 made much of a difference for you? > > for both drives, one of them us a UDMA66 but this Pentium 200Mhz cant do UDMA even ;/ > > I have a AP53/AX AcerOpen Motherboard. > > Shawn. > -- "... being a Linux user is sort of like living in a house inhabited by a large family of carpenters and architects. Every morning when you wake up, the house is a little different. Maybe there is a new turret, or some walls have moved. Or perhaps someone has temporarily removed the floor under your bed." - Unix for Dummies, 2nd Edition -- found in the .sig of Rob Riggs, [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE DMA Problems...system hangs
Alan Cox wrote:
>> Feb 13 05:23:27 bertha kernel: hdo: dma_intr: status=0x51 { DriveReady
>> SeekComplete Error }
>> Feb 13 05:23:27 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
>> BadCRC }
>
>You have inadequate cabling. CRC errors are indications of that. Make sure you
>are using sufficiently short cables for ATA33 and proper 80pin ATA66 cables.
I've had cases (on VIA chipsets) where, even or ATA33, a 40-pin cable
caused CRC errors for ATA33 and an 80-pin cable fixed things. (The same
40-pin cable does ATA33 without problems on an AMD 750 or an Intel BX,
though.)
IIRC, Andre Hedrick has said in the past that a marginal PSU or
motherboard can also cause CRC errors.
-Barry K. Nathan <[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: IDE DMA Problems...system hangs
Jasmeet Sidhu wrote: > > Hey guys, > > I am attaching my previous email for additional info. Now I am using > kernel 2.4.1-ac12 and these problems have not gone away. > > Anybody else having these problems with a ide raid 5? > > The Raid 5 performance should also be questioned..here are some number > returned by hdparam > > /dev/hda -IBM DLTA 20GB (ext2) > /dev/md0 - 8 IBM DLTA 45GB (Reiserfs) > > [root@bertha hdparm-3.9]# ./hdparm -t /dev/hda > /dev/hda: > Timing buffered disk reads: 64 MB in 2.36 seconds = 27.12 MB/sec > > [root@bertha hdparm-3.9]# ./hdparm -t /dev/md0 > /dev/md0: > Timing buffered disk reads: 64 MB in 22.16 seconds = 2.89 MB/sec > > Is this to be expected? This much performance loss? Anybody else using > IDE raid, I would really appreciate your input on this setup. md2 = RAID0 ext2 hda = hdb = IBM DTTA-351010 (10GB, 5400RPM, UDMA33) # hdparm -tT /dev/hda /dev/md2 /dev/hda: Timing buffered disk reads: 64 MB in 5.27 seconds = 12.14 MB/sec Timing buffer-cache reads: 128 MB in 0.82 seconds =156.10 MB/sec /dev/md2: Timing buffered disk reads: 64 MB in 3.34 seconds = 19.16 MB/sec Timing buffer-cache reads: 128 MB in 0.80 seconds =160.00 MB/sec On AMD K7 w/ 7409 (Viper) chipset, DMA66 mode w/ 80-pin cable. kernel = 2.4.1-ac8, no errors in kernel log. So I get a 58% increase. You should almost max out the bus. You probably have a bad cable. Try hdparam on each disk and see if any of them have errors/ cause the lockup. -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: MP-Table mappings
> In my dmesg I'm getting duplicate table reservations. Just a crap bios > OEM ID: OEM0 Product ID: PROD APIC at: 0xFEE0 I think the required OEM ID and product id speak volumes for the rest of the quality issues > Is this an issue? Once is correct, twice is fine, zero times would be bad. Its ok - 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.2-pre3: parport_pc init_module bug
On Wed, 14 Feb 2001, Grant Grundler wrote: > Philipp Rumpf wrote: > > Jeff Garzik wrote: > > > Looks ok, but I wonder if we should include this list in the docs. > > > These is stuff defined by the PCI spec, and this list could potentially > > > get longer... (opinions either way wanted...) > > Having people look things up in the spec isn't very user friendly. Having the constants in some well-known header file should be sufficient, shouldn't it ? > > I'm not sure whether the > > plan is to have drivers handle MSIs or do it in the generic PCI code. > > Grant ? > > Generic PCI code can d very little by itself with MSI since not all > platforms provide support for it - even within the same arch. It depends on the platform and maybe the exact PCI slot used, but I don't think it depends on the driver (unless MSI support is broken in which case you would want to fix it up in the driver). At least I can't find anything in the PCI 2.2 spec that would suggest we need to consult the driver before enabling MSIs with one message only. > It's also possible for the driver to just ignore MSI and not use it. > ie use regular PCI IRQ lines for interrupts. .. at least until someone comes out with a PCI board that supports MSI interrupts only. - 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/
Trying to fix 3dfx.o + question about char drivers..
So, I upgrade to 2.4.0 and it's cool, except that I can't do anything neat with my voodoo3 anymore. I've been looking for a solution for weeks but to no avail. 3dfx's web site looks like it's gone and nothing on lk about it. [ By all means, if someone has fixed this, do let me know ] Tracing the Glide test programs shows that ioctl() is returning -EPERM. Compiling the driver with 'make debug' shows: [ To aid in the confusion, my machine's hostname is 'mmap' ] [ insmod 3dfx.o ] Feb 14 15:08:14 mmap kernel: 3dfx: Entering init_module() Feb 14 15:08:14 mmap kernel: 3dfx: Successfully registered device 3dfx Feb 14 15:08:14 mmap kernel: 3dfx: board vendor 4634 type 5 located at de00/ [ ./test3Dfx ] Feb 14 15:08:29 mmap kernel: 3dfx: Entering mmap_3dfx Feb 14 15:08:29 mmap kernel: 3dfx: Couldn't match address 0 to a card Feb 14 15:08:29 mmap kernel: 3dfx: Entering release_3dfx mmap_3dfx is being called before ioctl_3dfx is ever reached. Looking to make heads of the "Couldn't match address 0 to a card" message, I stuck in some more debugging output: [ VM_OFFSET is #define VM_OFFSET(vma) (vma->vm_pgoff << PAGE_SHIFT) ] Feb 14 15:08:29 mmap kernel: 3dfx: Entering mmap_3dfx Feb 14 15:08:29 mmap kernel: 3dfx: Entering decode_vma: Feb 14 15:08:29 mmap kernel: 3dfx: start = c1270640, end = c5e40840 Feb 14 15:08:29 mmap kernel: 3dfx: offset = 0 (VM_OFFSET = 0) Feb 14 15:08:29 mmap kernel: 3dfx: Leaving decode_vma Feb 14 15:08:29 mmap kernel: 3dfx: compare de00 or e200 to 0 Feb 14 15:08:29 mmap kernel: 3dfx: Couldn't match address 0 to a card Feb 14 15:08:29 mmap kernel: 3dfx: Entering release_3dfx Sure stumped me. By my guess, it seems that mmap_3dfx is provided by the char driver so that a userland process can map a region of (video?) memory on the card. The process calls ioctl() after opening /dev/3dfx. That ioctl() triggers an mmap() call, the driver gets addresses it's totally not expecting, and it returns -EPERM. Why does mmap get called first?? Am I reading this right? -- Michael Bacarella <[EMAIL PROTECTED]> Technical Staff / System Development, New York Connect.Net, Ltd. - 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: File IO performance
Marcelo Tosatti wrote: > > On Wed, 14 Feb 2001, Steve Lord wrote: > > > > > A break in the on disk mapping of data could be used to stop readahead > > I suppose, especially if getting that readahead page is going to > > involve evicting other pages. I suspect that doing this time of thing > > is probably getting too complex for it's own good though. > > > > Try breaking the readahead loop apart, folding the page_cache_read into > > the loop, doing all the page allocates first, and then all the readpage > > calls. > > Its too dangerous it seems --- the amount of pages which are > allocated/locked/mapped/submitted together must be based on the number of > free pages otherwise you can run into an oom deadlock when you have a > relatively high number of pages allocated/locked. Which says that as you ask for pages to put the readahead in, you want to get a failure back under memory pressure, you push out what you allocated already and carry on. > > > I suspect you really need to go a bit further and get the mapping of > > all the pages fixed up before you do the actual reads. > > Hum, also think about a no-buffer-head deadlock when we're under a > critical number of buffer heads while having quite a few buffer heads > locked which are not going to be queued until all needed buffer heads are > allocated. All this is probably attempting to be too clever for its own good, there is probably a much simpler way to get more things happening in parallel. Plus, in reality, lots of apps will spend some time between read calls processing data, so there is overlap, a benchmark doing just reads is the end case of all of this. Steve - 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.
On Tue, 13 Feb 2001, Ion Badulescu wrote: > On Tue, 13 Feb 2001 12:29:16 -0800, Ion Badulescu <[EMAIL PROTECTED]> >wrote: > > On Tue, 13 Feb 2001 07:06:44 -0600 (CST), Jeff Garzik ><[EMAIL PROTECTED]> wrote: > > > >> On 12 Feb 2001, Jes Sorensen wrote: > >>> In fact one has to look out for this and disable the feature in some > >>> cases. On the acenic not disabling Memory Write and Invalidate costs > >>> ~20% on performance on some systems. > >> > >> And in another message, On Mon, 12 Feb 2001, David S. Miller wrote: > >>> 3) The acenic/gbit performance anomalies have been cured > >>>by reverting the PCI mem_inval tweaks. > >> > >> Just to be clear, acenic should or should not use MWI? > > With the zerocopy patch, acenic always disables MWI by default. > > >> And can a general rule be applied here? Newer Tulip hardware also > >> has the ability to enable/disable MWI usage, IIRC. > > > > And so do eepro100 and starfire. On the eepro100 we're enabling MWI > > unconditionally, and on the starfire we disable it unconditionally... > > > > I should probably take a look at acenic's use of PCI_COMMAND_INVALIDATE > > to see when it gets activated. Some benchmarking would probably help, > > too -- maybe later today. > > I did some testing with starfire, and the results are inconclusive -- > at least on my P-III is makes absolutely no difference. Does it make > a difference on other architectures? sparc64, ia64 maybe? > > I should probably rephrase this: MWI makes no difference on i386, but > it is claimed that using MWI *reduces* performance on some systems. > Are there any systems on which MWI *increases* performance? I have read several data sheets about Intel PCI-HOST bridges and they all were said to alias PCI MWI to normal PCI MEMORY WRITE transactions. This matches your observations just fine. Even when MWI is handled as MW, the PCI master is required to transfer entire cache lines and this cannot be bad for performances. But this should probably not make significant difference with normal MW. Btw, your rephrasing looks improper to me. The processor is not involved in the handling of MWI., especially when the MWI targets the memory. It is the PCI-HOST bridge that must be considered here. What about ServerWorks chipset ? Hmmm... I would be glad to have docs about these ones. :( The MWI is intended to allow optimizations based on cache lines invalidations rather than snooping. The target (or bridge) can perfectly elect to handle the MWI as a normal MW and so, performance should not be significantly lowered using MWI. But nothing is perfect, as we know. The MWI is interesting for PCI throughput optimization but the MEMORY READ LINE and MEMORY READ MULTIPLE transactions are a lot more interesting, in my opinion. WRITEs can be posted (buffered), but in order to stream data from memory (prefetchable) the bridge can do a better work when it knows the intention of the PCI MASTER. All bridges should take in considerations hints associated with MRL and MRM. IIRC, Intel bridges do. > I've added some code to the starfire driver that allows changing the > use of MWI at module load time, just in case. By default, it activates > it. You should also play with MRL and MRM, in my opinion. Gérard. - 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/
MP-Table mappings
In my dmesg I'm getting duplicate table reservations. found SMP MP-table at 000f5770 hm, page 000f5000 reserved twice. hm, page 000f6000 reserved twice. hm, page 000f1000 reserved twice. hm, page 000f2000 reserved twice. On node 0 totalpages: 262128 zone(0): 4096 pages. zone(1): 225280 pages. zone(2): 32752 pages. Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: OEM0 Product ID: PROD APIC at: 0xFEE0 Is this an issue? David - 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: ECN for servers ?
> > Con: people behind broken firewalls can't connect. > > Since you can use ICMP to tunnel data, a lot of security ppl are > reluctant to stop filtering ICMP :/ ICMP isnt the problem. Some of the load balancers and proxy setups didnt allow ECN frames through. ICMP blocking just breaks path mtu discovery and accessing the site via IPsec, via mobile ip and a few other things. And you can tunnel data over ack sequence spaces, IP over http is trivial. There are reasons proper proxy setups have passwords outgoing and do not let any control data/header info across untouched - 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/
PROBLEM: virtual console corruption (2.4.1/p4/radeon/XFree86 4.0.2)
[1.] virtual console corruption (2.4.1/p4/radeon/XFree86 4.0.2) [2.] Taking a redhat 7 install, upgrading it to currency, and then adding rawhide RPMS for the required extra pieces, I compiled a 2.4.1 kernel using kgcc. Everything actually works rather well, with the exception that when I've started XFree86 a few times, coupled with switching virtual consoles, I get irretrievably "corrupted" text virtual consoles. The screen becomes garbled, sometimes quite colorful, cursor goes to the wrong place, text appears in odd locations or is not visible at all. Interestingly, the scrollback buffer allows me to scroll through the garble perfectly. The problem can only be fixed by rebooting. X works great throughout, even when the text-mode console is messed up. It's just the text-mode console that has the problem. I have tried an alternate compile, omitting support for AGPART and Radeon DRI - no effect. The exact same setup, but replacing 2.4.1 with 2.2.17, works perfectly. [3.] kernel, console, vga, xwindows [4.] Linux version 2.4.1 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Wed Feb 14 14:28:33 EST 2001 [5.] No OOPS [6.] No script [7.] [7.1.] Software: Linux fox.templar.com 2.4.1 #1 Wed Feb 14 14:28:33 EST 2001 i686 unknown Kernel modules 2.4.2 Gnu C 2.96 Gnu Make 3.79.1 Binutils 2.10.0.18 Linux C Library> libc.2.2 Dynamic linker ldd (GNU libc) 2.2 Procps 2.0.7 Mount 2.10m Net-tools 1.56 Console-tools 0.3.3 Sh-utils 2.0 Modules Loaded emu10k1 soundcore [7.2.] processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 0 model name : Intel(R) Pentium(R) 4 CPU 1600MHz stepping: 5 cpu MHz : 1396.591 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss tm bogomips: 2785.28 [7.3.] emu10k144944 0 soundcore 3920 4 [emu10k1] [7.4.] ioports: -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 0376-0376 : ide1 03c0-03df : vga+ 03f6-03f6 : ide0 03f8-03ff : serial(auto) 0cf8-0cff : PCI conf1 c000-cfff : PCI Bus #01 c800-c8ff : PCI device 1002:5144 (ATI Technologies Inc) d000-dfff : PCI Bus #02 d800-d8ff : Adaptec AIC-7861 df00-df3f : Intel Corporation 82557 [Ethernet Pro 100] df00-df3f : eepro100 df80-df9f : Creative Labs SB Live! EMU1 df80-df9f : EMU10K1 dfe0-dfe7 : CONEXANT 56K Winmodem dff0-dff7 : Creative Labs SB Live! ef40-ef5f : Intel Corporation 82820 820 (Camino 2) Chipset USB (Hub A) ef40-ef5f : usb-uhci ef80-ef9f : Intel Corporation 82820 820 (Camino 2) Chipset USB (Hub B) ef80-ef9f : usb-uhci efa0-efaf : Intel Corporation 82820 820 (Camino 2) Chipset SMBus ffa0-ffaf : Intel Corporation 82820 820 (Camino 2) Chipset IDE U100 ffa0-ffa7 : ide0 ffa8-ffaf : ide1 iomem: -0009fbff : System RAM 0009fc00-0009 : reserved 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000c8000-000c87ff : Extension ROM 000c8800-000c9fff : Extension ROM 000f-000f : System ROM 0010-0ffb : System RAM 0010-00213ef7 : Kernel code 00213ef8-002734cf : Kernel data 0ffc-0ffd : ACPI Tables 0ffe-0fff7fff : ACPI Tables 0fff8000-0fff : ACPI Non-volatile Storage e690-f69f : PCI Bus #01 e800-efff : PCI device 1002:5144 (ATI Technologies Inc) f6a0-f6af : PCI Bus #02 f800-fbff : Intel Corporation 82850 850 (Tehama) Chipset Host Bridge (MCH) fec0-fec00fff : reserved fee0-fee00fff : reserved ff50-ff6f : PCI Bus #01 ff68-ff6f : PCI device 1002:5144 (ATI Technologies Inc) ff70-ff9f : PCI Bus #02 ff9a-ff9b : Intel Corporation 82557 [Ethernet Pro 100] ff9d-ff9d : CONEXANT 56K Winmodem ff9fe000-ff9fefff : Intel Corporation 82557 [Ethernet Pro 100] ff9fe000-ff9fefff : eepro100 ff9ff000-ff9f : Adaptec AIC-7861 ffb8-ffbf : reserved fff0- : reserved [7.5.] 00:00.0 Host bridge: Intel Corporation: Unknown device 2530 (rev 02) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 00:01.0 PCI bridge: Intel Corporation: Unknown device 2532 (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast
Re: ECN for servers ?
Jeff Garzik wrote: > > On 14 Feb 2001, H. Peter Anvin wrote: > > By author:Petru Paler <[EMAIL PROTECTED]> > > > What is the impact of enabling ECN on the server side ? I mean, will > > > any clients (with broken firewalls) be affected if a SMTP/HTTP server > > > has ECN enabled ? > > > Pro: better behaviour in presence of network congestion. > > > > Con: people behind broken firewalls can't connect. > > Since you can use ICMP to tunnel data, a lot of security ppl are > reluctant to stop filtering ICMP :/ > You can use DNS to tunnel data, too. As far as ICMP is concerned, perhaps they should consider sterilizing approaches instead. -hp -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Samba performance / zero-copy network I/O
On Wed, 14 Feb 2001, Jeremy Jackson wrote: > "Gord R. Lamb" wrote: > > > Hi everyone, > > > > I'm trying to optimize a box for samba file serving (just contiguous block > > I/O for the moment), and I've now got both CPUs maxxed out with system > > load. > > > > (For background info, the system is a 2x933 Intel, 1gb system memory, > > 133mhz FSB, 1gbit 64bit/66mhz FC card, 2x 1gbit 64/66 etherexpress boards > > in etherchannel bond, running linux-2.4.1+smptimers+zero-copy+lowlatency) > > > > CPU states typically look something like this: > > > > CPU states: 3.6% user, 94.5% system, 0.0% nice, 1.9% idle > > > > .. with the 3 smbd processes each drawing around 50-75% (according to > > top). > > > > When reading the profiler results, the largest consuming kernel (calls?) > > are file_read_actor and csum_partial_copy_generic, by a longshot (about > > 70% and 20% respectively). > > > > Presumably, the csum_partial_copy_generic should be eliminated (or at > > least reduced) by David Miller's zerocopy patch, right? Or am I > > misunderstanding this completely? :) > > I only know enough to be dangerous here, but I believe you will need to > be using one of the network cards whose driver actually uses the > zero-copy patches, and/or which can perform tcp checksum in hardware > (of the network card). Hmm. Yeah, I think that may be one of the problems (Intel's card isn't supported afaik; if I have to I'll switch to 3com, or hopelessly try to implement support). I'm looking for a patch to implement sendfile in Samba, as Alan suggested. That seems like a good first step. - 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: ECN for servers ?
On 14 Feb 2001, H. Peter Anvin wrote: > By author:Petru Paler <[EMAIL PROTECTED]> > > What is the impact of enabling ECN on the server side ? I mean, will > > any clients (with broken firewalls) be affected if a SMTP/HTTP server > > has ECN enabled ? > Pro: better behaviour in presence of network congestion. > > Con: people behind broken firewalls can't connect. Since you can use ICMP to tunnel data, a lot of security ppl are reluctant to stop filtering ICMP :/ Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE DMA Problems...system hangs
> >You will get horribly bad performance off raid5 if you have stripes on both > >hda/hdb or hdc/hdd etc. > > If I am reading this correctly, then by striping on both hda/hdb and > /hdc/hdd you mean that I have two drives per ide channel. In other words, > you think I have a Master and a Slave type of a setup? This is > incorrect. Each drive on the system is a master. I have 5 promise cards Ok then your performance should be fine (at least reasonably so, the lack of tagged queueing does hurt) > ide chanel, the penalty should not be much in terms of performance. Maybe > its just that the hdparam utility is not a good tool for benchamarking a > raid set? Its not a good raid benchmark tool but its a good indication of general problems. Bonnie is a good tool for accurate assessment. > disable DMA if its giving it a lot of problems, but it should not hang. I > have been experiencing this for quite a while with the newer > kernels. Should I try the latest ac13 patch? I glanced of the changes and > didnt seem like anything had changed regarding the ide subsystem. I've not changed anything related to DMA handling specifically. The current -ac does have a fix for a couple of cases where an IDE reset on the promise could hang the box dead. That may be the problem. > Is there anyway I can force the kernel to output more messages...maybe that > could help narrow down the problem? Ask [EMAIL PROTECTED] He may know the status of the promise support - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MTU and 2.4.x kernel
> Kernel 2.4.x apparently disregards my ppp options MTU setting of 552 > and sets mss=536 (=> MTU=576). Kernel 2.2.16 sets mss=512 correctly. > Is this a kernel bug or what? The kernel is entitled to set an MSS that may cause fragmentation. So no it isnt a bug. 536 + 40 = 576 Im not sure why it made that choice but it is allowed to. (cc'd to netdev to see if they know) > Description: Typically Netscape/Lynx will connect to a remote site but > will not download (it will hang indefinitely). When the browser is in Typically indicates your ISP has path mtu problems. > the browser is locked for almost all remote sites, I _am_ able to > connect to (the web page of) the proxy server itself. And after I do > this the browser is *unlocked*, and I can connect/download from any web > address. However this only lasts for 5 minutes or so, after which time That would be a cached pmtu for that connection. I suspect the connections via the proxy server are not sending back valid ICMP fragmentation required frames for path mtu discovery. That would suggest the problem is the ISP. 2.2 happened to cover this up for the case of a single host directly connected to a modem with a low mtu. 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: Video drivers and the kernel
On 14 Feb 2001 01:09:10 -0500, Albert D. Cahalan wrote: > > I was wondering why video drivers are not part of the kernel like every > > other piece of hardware. I would think if video drivers were part of the > > kernel and had a nice API for X or any other windowing system, would not > > only improve performance but would allow competing windowing systems > > without having to develop drivers for each. Has anyone thought or > > rejected this idea. > > Yes. > > So then what, split X, with only the hardware access in the kernel? > This can actually reduce performance, by a small or great amount > depending on how it is done. Stability would improve a bit, assuming > the new drivers have Linux quality rather than XFree86 quality. > The gain is tiny, while the difficulty is large. At least we'd get > a safe and reliable way to print an oops though. This isn't an x86 world. For most other architectures, there *must* be a kernel driver. Check out linux/drivers/video. But what X is doing at this point is taking over access to the video card and using it's own driver. So see, there needs to be no split of X. I could also argue that if video was moved into the kernel in that manner, stability would decrease, but performance could be dramatically increased. > Both options cause political troubles. Currently the X server is > shared with OS/2 and other crummy systems. If the Linux kernel had > serious video drivers for PC hardware, then driver support for the > other operating systems would mostly go away. Linux would become > a better desktop OS, at the expense of various crummy systems. I find this to be a flawed argument. > Both options cause more work for Linus. This totally kills the idea. > See his past postings flaming the GGI/KGI developers. I think GGI/KGI were overkill -- especially at the time. But with the advent of embedded systems, you simply just can't say "use X" anymore. I believe that there needs to be basic 2D acceleration available in kernel space. They already have to be there for non-BIOS architectures, so why not take advantage of them? > If you ever write this, go ahead and throw in the rest. I mean the > window manager, xterm, and a GDK system call even. My hardware can > spare the memory, but CPU cycles are way too scarce. Clean design > can go screw itself when it eats CPU time. Don't worry about being > accepted into the main kernel, because that won't happen no matter > what you do. Have fun hacking, and whip XFree86's ass. Check out GTKFb and Embedded QT. Whip XFree86's ass? But the author was talking about writing kernel drivers *for* Xfree86... You are correct in the fact that this will never happen. But as far as video in the kernel, you are wrong. Brad Douglas [EMAIL PROTECTED] http://www.linux-fbdev.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Samba performance / zero-copy network I/O
"Gord R. Lamb" wrote: > Hi everyone, > > I'm trying to optimize a box for samba file serving (just contiguous block > I/O for the moment), and I've now got both CPUs maxxed out with system > load. > > (For background info, the system is a 2x933 Intel, 1gb system memory, > 133mhz FSB, 1gbit 64bit/66mhz FC card, 2x 1gbit 64/66 etherexpress boards > in etherchannel bond, running linux-2.4.1+smptimers+zero-copy+lowlatency) > > CPU states typically look something like this: > > CPU states: 3.6% user, 94.5% system, 0.0% nice, 1.9% idle > > .. with the 3 smbd processes each drawing around 50-75% (according to > top). > > When reading the profiler results, the largest consuming kernel (calls?) > are file_read_actor and csum_partial_copy_generic, by a longshot (about > 70% and 20% respectively). > > Presumably, the csum_partial_copy_generic should be eliminated (or at > least reduced) by David Miller's zerocopy patch, right? Or am I > misunderstanding this completely? :) I only know enough to be dangerous here, but I believe you will need to be using one of the network cards whose driver actually uses the zero-copy patches, and/or which can perform tcp checksum in hardware (of the network card). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE DMA Problems...system hangs
At 08:28 PM 2/14/2001 +, Alan Cox wrote:
> > Anybody else having these problems with a ide raid 5?
> > The Raid 5 performance should also be questioned..here are some number
> > returned by hdparam
>
>You will get horribly bad performance off raid5 if you have stripes on both
>hda/hdb or hdc/hdd etc.
If I am reading this correctly, then by striping on both hda/hdb and
/hdc/hdd you mean that I have two drives per ide channel. In other words,
you think I have a Master and a Slave type of a setup? This is
incorrect. Each drive on the system is a master. I have 5 promise cards
in the system (4 PCI and 1 onboard AUS a7v mobo). This gives me the
ability to have 10 master drives. Since I am only striping on one drive per
ide chanel, the penalty should not be much in terms of performance. Maybe
its just that the hdparam utility is not a good tool for benchamarking a
raid set?
> > Feb 13 05:23:27 bertha kernel: hdo: dma_intr: status=0x51 { DriveReady
> > SeekComplete Error }
> > Feb 13 05:23:27 bertha kernel: hdo: dma_intr: error=0x84 {
> DriveStatusError
> > BadCRC }
>
>You have inadequate cabling. CRC errors are indications of that. Make sure you
>are using sufficiently short cables for ATA33 and proper 80pin ATA66 cables.
All the cables are ATA/100 capable. But I cannot think of another reason
as to why I might be getting CRC errors. I will invest in better cables
and see if it changes anything.
> > Feb 13 12:12:42 bertha kernel: hdg: irq timeout: status=0x50 { DriveReady
> > SeekComplete }
> > Feb 13 12:13:02 bertha kernel: hdg: timeout waiting for DMA
>
>This could be cabling too, cant be sure
>
> > Feb 13 12:13:12 bertha kernel: hdg: DMA disabled
>
>It gave up using DMA
agreed.
> > Feb 13 12:13:12 bertha kernel: ide3: reset: success <--- * SYSTEM
> HUNG
> > AT THIS POINT *
>
>Ok thats a reasonable behaviour, except it shouldnt have then hung.
This is also my main point of frustration. The system should be able to
disable DMA if its giving it a lot of problems, but it should not hang. I
have been experiencing this for quite a while with the newer
kernels. Should I try the latest ac13 patch? I glanced of the changes and
didnt seem like anything had changed regarding the ide subsystem.
Is there anyway I can force the kernel to output more messages...maybe that
could help narrow down the problem?
J.Sidhu
-
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: ECN for servers ?
Followup to: <[EMAIL PROTECTED]> By author:Petru Paler <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > Hello, > > What is the impact of enabling ECN on the server side ? I mean, will > any clients (with broken firewalls) be affected if a SMTP/HTTP server > has ECN enabled ? > > On the other hand, is there any advantage with ECN enabled on the server > side ? > Pro: better behaviour in presence of network congestion. Con: people behind broken firewalls can't connect. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - 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?
> Is there any documentation of the kernel's 'capabilities' functions? It > would be exceedingly cool if services (named, nfs, etc) > could be updated to use this; I think crackers would loose some motivation > if instead of "hey I can totally rule this box!" > they have to settle for "hey I can make the ident service report user 'CrAp' > for every port!". Named and proftpd are already updated to use this.. check the source for the best documentation ... Gerhard -- Gerhard Mack [EMAIL PROTECTED] <>< As a computer I find your faith in technology amusing. - 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/
MTU and 2.4.x kernel
Kernel 2.4.x apparently disregards my ppp options MTU setting of 552 and sets mss=536 (=> MTU=576). Kernel 2.2.16 sets mss=512 correctly. Is this a kernel bug or what? I ran a much broader inquiry recently concerning poor ppp performance under the 2.4.x kernel. But I got a disappointing response to my questions so I am narrowing the field to this one question. I include my original enquiry below. Thankyou, Roger Young. Topic: Problem with Netscape/Linux v.2.4.x [repeat] (MTU problem)? Symptoms: The browser (Netscape or Lynx) will not download from remote web sites (dynamic ppp connection via external modem). This is a second post. The problem is still not resolved, but can now be described in more detail, thanks to help given by David Woodhouse (and others) and my ISP. Description: Typically Netscape/Lynx will connect to a remote site but will not download (it will hang indefinitely). When the browser is in such a hung state I am still able to ping/telnet/ftp to the URL. I have no difficulty browsing with Linux 2.2.16. The problem only occurs with the 2.4.x kernels (2.4.0, 2.4.1). My ISP operates a "transparent proxy server". According to tcpdump TX packets from my machine are passed on by the proxy server to the remote site, and the response from the latter is also logged by the server and passed on to me. However at that point there is no further traffic from the proxy server. This looks to be a problem for my PC and the 2.4.x kernel, however the proxy server is also involved for the following reason: although the browser is locked for almost all remote sites, I _am_ able to connect to (the web page of) the proxy server itself. And after I do this the browser is *unlocked*, and I can connect/download from any web address. However this only lasts for 5 minutes or so, after which time I must reconnect to the ISP proxy server. It is as though some information has been cached and then lost after a time?? Now I include a note from my ISP: >Roger, as we discussed I think the problem is to do with the MTU being = >used for TCP connections in combination with the 2.4.1 kernel and PPP. > >At any rate, what we have found from the packet dumps are when you use = >kernel 2.2.16 and you set the MTU at 552 our cache receives SYN packets = >from your host with a "mss" option set at 512 (MTU =3D 552 - IP header = >(20) - TCP header (20)) (and here is a packet dump of that): > >19:29:33.146337 131.203.xxx.yyy.1028 > www.google.com.www: S = >1878153551:1878153551(0) win 15872 614080,nop,wscale 0> (DF) > >however, when your 2.4.1 kernel also set with an MTU of 552 does the = >same thing, we find a "mss" option set at 536 (MTU =3D 576 - IP header - = >TCP header) not 552! Here is the packet trace: > >19:34:17.559674 131.203.xxx.yyy.32771 > www.google.com.www: S = >2178626299:2178626299(0) win 2144 175390,nop,wscale 0> (DF) > >There is more in the trace that indicates packets with data segment = >sizes of 536 are not getting through, and when the data segment drops to = >468 it does get through, likewise with the 2.2.16 kernel packets only = >get as big as 512 and they all get through ok. > >This indicates that although the MTU is being set to 552, this is being = >ignored by the 2.4.1 kernel and it is using 576 instead. Kernel 2.2.16 = >correctly uses the 552 as specified. This is as far as my understanding of the situation reaches. There appear to be 3 interdependent elements: (1) the web browser (2) the 2.4.x kernel (3) the ISP transparent proxy server Can anyone throw further light on this problem and/or suggest how to fix it? I'll say straight away that it has nothing to do with ECN since this has not been selected as a kernel option. Our analysis seems to suggest that with 2.4.x the MTU is being incorrectly set, but I don't know whether this is the whole explanation. Thanks for any help you can provide... Roger Young. ([EMAIL PROTECTED]) ... Motherboard: GA-6VX7-4X with Via Apollo Pro AGP chipset CPU: P3/733 MHz Memory: 256 Mb SDRAM Modem: Dynalink 56K external modem. Serial port IRQ4, I/O 03F8-03FF Distribution: Slackware 7.1 Linux kernel(s): 2.4.1/2.4.0/2.2.16 PPP: 2.4.0. MTU 552 Netscape: 4.76 XFree86: 4.0.2 modutils: 2.4.1 binutils: 2.10.1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE DMA Problems...system hangs
> Anybody else having these problems with a ide raid 5?
> The Raid 5 performance should also be questioned..here are some number
> returned by hdparam
You will get horribly bad performance off raid5 if you have stripes on both
hda/hdb or hdc/hdd etc.
> Feb 13 05:23:27 bertha kernel: hdo: dma_intr: status=0x51 { DriveReady
> SeekComplete Error }
> Feb 13 05:23:27 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
> BadCRC }
You have inadequate cabling. CRC errors are indications of that. Make sure you
are using sufficiently short cables for ATA33 and proper 80pin ATA66 cables.
> Feb 13 12:12:42 bertha kernel: hdg: irq timeout: status=0x50 { DriveReady
> SeekComplete }
> Feb 13 12:13:02 bertha kernel: hdg: timeout waiting for DMA
This could be cabling too, cant be sure
> Feb 13 12:13:12 bertha kernel: hdg: DMA disabled
It gave up using DMA
> Feb 13 12:13:12 bertha kernel: ide3: reset: success <--- * SYSTEM HUNG
> AT THIS POINT *
Ok thats a reasonable behaviour, except it shouldnt have then hung.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Samba performance / zero-copy network I/O
> When reading the profiler results, the largest consuming kernel (calls?) > are file_read_actor and csum_partial_copy_generic, by a longshot (about > 70% and 20% respectively). > > Presumably, the csum_partial_copy_generic should be eliminated (or at > least reduced) by David Miller's zerocopy patch, right? Or am I > misunderstanding this completely? :) To an extent, providing you are using the samba sendfile() patches. SMB cant make great use of zero copy file I/O due to the fact its not really designed so much as mutated over time and isnt oriented for speed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Samba performance / zero-copy network I/O
Hi everyone, I'm trying to optimize a box for samba file serving (just contiguous block I/O for the moment), and I've now got both CPUs maxxed out with system load. (For background info, the system is a 2x933 Intel, 1gb system memory, 133mhz FSB, 1gbit 64bit/66mhz FC card, 2x 1gbit 64/66 etherexpress boards in etherchannel bond, running linux-2.4.1+smptimers+zero-copy+lowlatency) CPU states typically look something like this: CPU states: 3.6% user, 94.5% system, 0.0% nice, 1.9% idle .. with the 3 smbd processes each drawing around 50-75% (according to top). When reading the profiler results, the largest consuming kernel (calls?) are file_read_actor and csum_partial_copy_generic, by a longshot (about 70% and 20% respectively). Presumably, the csum_partial_copy_generic should be eliminated (or at least reduced) by David Miller's zerocopy patch, right? Or am I misunderstanding this completely? :) Regards, - Gord R. Lamb ([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: What does "device or resource busy" mean ?
Hi, For some unknown (to me) reason, this message has to do with X being active. Leaving X causes the module to be correctly loaded. I guess X should be using some resource that my module also wanted to use. Marcus. Marcus Ramos wrote: > Hello, > > When I try to load module ttime.o - "insmod ttime.o" - I get the > following message: "ttime.o: init_module: Device or resource busy". > "lsmod" shows that ttime.o was effectively not loaded. I am using RH7 > with kernel 2.2.16-22. Does anyone have a guess on a possible reason for > this and how to fix it, so the module can be normally loaded ? > > Thanks, > Marcus. - 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/
IDE DMA Problems...system hangs
Hey guys,
I am attaching my previous email for additional info. Now I am using
kernel 2.4.1-ac12 and these problems have not gone away.
Anybody else having these problems with a ide raid 5?
The Raid 5 performance should also be questioned..here are some number
returned by hdparam
/dev/hda -IBM DLTA 20GB (ext2)
/dev/md0 - 8 IBM DLTA 45GB (Reiserfs)
[root@bertha hdparm-3.9]# ./hdparm -t /dev/hda
/dev/hda:
Timing buffered disk reads: 64 MB in 2.36 seconds = 27.12 MB/sec
[root@bertha hdparm-3.9]# ./hdparm -t /dev/md0
/dev/md0:
Timing buffered disk reads: 64 MB in 22.16 seconds = 2.89 MB/sec
Is this to be expected? This much performance loss? Anybody else using
IDE raid, I would really appreciate your input on this setup.
Here is the log from syslog
Feb 13 05:23:27 bertha kernel: hdo: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Feb 13 05:23:27 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Feb 13 05:23:28 bertha kernel: hdo: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Feb 13 05:23:28 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Feb 13 05:23:28 bertha kernel: hdo: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Feb 13 05:23:28 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Feb 13 05:23:28 bertha kernel: hdo: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Feb 13 05:23:28 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Feb 13 05:23:33 bertha kernel: hdo: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Feb 13 05:23:33 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
BadCRC }
...
Feb 13 08:47:48 bertha kernel: hdo: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Feb 13 08:47:48 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
BadCRC }
...
Feb 13 09:54:07 bertha kernel: hdo: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Feb 13 09:54:07 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
BadCRC }
...
Feb 13 12:10:43 bertha kernel: hds: dma_intr: bad DMA status
Feb 13 12:10:43 bertha kernel: hds: dma_intr: status=0x50 { DriveReady
SeekComplete }
Feb 13 12:12:22 bertha kernel: hdg: timeout waiting for DMA
Feb 13 12:12:22 bertha kernel: ide_dmaproc: chipset supported
ide_dma_timeout func only: 14
Feb 13 12:12:22 bertha kernel: hdg: irq timeout: status=0x50 { DriveReady
SeekComplete }
Feb 13 12:12:42 bertha kernel: hdg: timeout waiting for DMA
Feb 13 12:12:42 bertha kernel: ide_dmaproc: chipset supported
ide_dma_timeout func only: 14
Feb 13 12:12:42 bertha kernel: hdg: irq timeout: status=0x50 { DriveReady
SeekComplete }
Feb 13 12:13:02 bertha kernel: hdg: timeout waiting for DMA
Feb 13 12:13:02 bertha kernel: ide_dmaproc: chipset supported
ide_dma_timeout func only: 14
Feb 13 12:13:02 bertha kernel: hdg: irq timeout: status=0x50 { DriveReady
SeekComplete }
Feb 13 12:13:12 bertha kernel: hdg: timeout waiting for DMA
Feb 13 12:13:12 bertha kernel: ide_dmaproc: chipset supported
ide_dma_timeout func only: 14
Feb 13 12:13:12 bertha kernel: hdg: irq timeout: status=0x50 { DriveReady
SeekComplete }
Feb 13 12:13:12 bertha kernel: hdg: DMA disabled
Feb 13 12:13:12 bertha kernel: ide3: reset: success <--- * SYSTEM HUNG
AT THIS POINT *
Feb 13 23:31:13 bertha syslogd 1.3-3: restart.
--
To: [EMAIL PROTECTED]
Subject: DMA blues... (Raid5 + Promise ATA/100)
I have a software raid setup using the latest kernel, but the system keeps
crashing.
Each drive is connected to the respective ide port via ATA100 capable
cables. Each drive is a master..no slaves. The configuration is that
/dev/hdc is a hot spare and /dev/hd[e,g,i,k,m,o,q,s] are all setup as raid
5. These are all 75GB drives and are recognized as such.
I have searched the linux-kernel archives and saw many posts addressing the
problems that I was experiencing, namely the freezing caused by the code in
the body of delay_50ms() in drivers/ide/ide.c. This was fixed in the
current patch and as discussed earlier on the linux-kernel mailing list by
using mdelay(50). This fixed the problems to some extent, the system
seemed very reliable and I did not get a single "DriveStatusError BadCRC"
or a "DriveReady SeekComplete Index Error" for a while. But after I had
copied a large amount of data to the raid, about 17GB, the system crashed
completely and could only be recovered by a cold reboot. Before using the
latest patches, the system would usually crash after about 4-6GB of data
had been moved. Here are the log entries...
Feb 12 06:41:12 bertha kernel: hdo: dma_intr: status=0x53 { DriveReady
SeekComplete Index Error }
Feb 12 06:41:12 bertha kernel: hdo: dma_intr: error=0x84 { DriveStatusError
BadCRC }
Feb 12 06:45:42 bertha kernel: hdo: timeout waiting for DMA
Feb 12 06:45:42 bertha kernel: hdo: ide_dma_timeout: Lets do it again!stat
= 0x50, dma_stat = 0x20
Feb 12
Re: Multicast on loopback?
> I read that multicast loopback is by default enabled, and I have witnessed > this, when having my application bind to my ethernet interface, but the > datagrams do not seem to be looped back when I bind to the 'lo' interface. I wouldnt expect them to be. The lo interface does not support multicasting. I dont think this is a bug - 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.2.19pre12
> > hosts.c:500: `AIC7XXX' undeclared here (not in a function) > > hosts.c:500: initializer element for `builtin_scsi_hosts[0]' is not constant > > I'm sure Alan will notice and pick up the proper fix. For a workaround > to get you going, you can change hosts.c to include aic7xxx/aic7xxx.h... It already does, and builds. - 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/
Oops from updatedb?
Sorry about the last message, somehow got just the plain oops there. ksymoops 2.3.7 on i686 2.4.2-pre3. Options used -V (default) -k /proc/ksyms (specified) -l /proc/modules (default) -o /lib/modules/2.4.2-pre3/ (default) -m /usr/src/linux/System.map (default) Feb 14 04:02:37 nic-31-c31-100 kernel: Unable to handle kernel NULL pointer dereference at virtual address 0004 Feb 14 04:02:37 nic-31-c31-100 kernel: c0132711 Feb 14 04:02:37 nic-31-c31-100 kernel: *pde = Feb 14 04:02:37 nic-31-c31-100 kernel: Oops: 0002 Feb 14 04:02:37 nic-31-c31-100 kernel: CPU:0 Feb 14 04:02:37 nic-31-c31-100 kernel: EIP:0010:[__remove_inode_queue+17/32] Feb 14 04:02:37 nic-31-c31-100 kernel: EFLAGS: 00010206 Feb 14 04:02:37 nic-31-c31-100 kernel: eax: ebx: c63228c0 ecx: edx: Feb 14 04:02:37 nic-31-c31-100 kernel: esi: c63228c0 edi: c63228c0 ebp: esp: c4cc7d64 Feb 14 04:02:37 nic-31-c31-100 kernel: ds: 0018 es: 0018 ss: 0018 Feb 14 04:02:37 nic-31-c31-100 kernel: Process updatedb (pid: 3773, stackpage=c4cc7000) Feb 14 04:02:37 nic-31-c31-100 kernel: Stack: c0134bf9 c63228c0 0003 c227e280 c015039c Feb 14 04:02:37 nic-31-c31-100 kernel:c10a666c 0007 c012b1b7 c10a666c Feb 14 04:02:37 nic-31-c31-100 kernel: 16bb 40c8 1000 000d 0303 00030ea9 Feb 14 04:02:37 nic-31-c31-100 kernel: Call Trace: [try_to_free_buffers+105/368] [ext2_get_block+44/1264] [page_launder+871/2208] [refill_freelist+31/48] [getblk+250/256] [ext2_getblk+106/224] [ext2_read_inode+258/976] Feb 14 04:02:37 nic-31-c31-100 kernel: Code: 89 50 04 89 02 c3 89 f6 8d bc 27 00 00 00 00 8b 54 24 04 31 Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol <_EIP>: Code; Before first symbol 0: 89 50 04 mov%edx,0x4(%eax) Code; 0003 Before first symbol 3: 89 02 mov%eax,(%edx) Code; 0005 Before first symbol 5: c3ret Code; 0006 Before first symbol 6: 89 f6 mov%esi,%esi Code; 0008 Before first symbol 8: 8d bc 27 00 00 00 00 lea0x0(%edi,1),%edi Code; 000f Before first symbol f: 8b 54 24 04 mov0x4(%esp,1),%edx Code; 0013 Before first symbol 13: 31 00 xor%eax,(%eax)
Re: dropcopyright script
Please dont do this. The copyright info at the top of the file is there for a reason. Not only does it give credit where credit is due, but it gives vital contact info for reporting problems back to the maintainer/authour. -- Brett G. Person 415-358-2656 [EMAIL PROTECTED] Penguin Computing - The World's Most Reliable Linux 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: longjmp problem
> I'm working with a C package written by other > on a linux machine with kernel version 2.2.14, > often in a calls of longjmp routine > the system crash with a SIGSEGV signal. > > Anyone can tell me if it can be a kernel problem ? Unlikely. If it was kernel related you would see an Oops. - 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/
No Subject
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? Feb 14 04:02:02 nic-31-c31-100 kernel: klogd 1.3-3, log source = /proc/kmsg started. Feb 14 04:02:02 nic-31-c31-100 kernel: Inspecting /boot/System.map-2.4.2-pre3 Feb 14 04:02:02 nic-31-c31-100 kernel: Loaded 12979 symbols from /boot/System.map-2.4.2-pre3. Feb 14 04:02:02 nic-31-c31-100 kernel: Symbols match kernel version 2.4.2. Feb 14 04:02:02 nic-31-c31-100 kernel: Loaded 58 symbols from 4 modules. Feb 14 04:02:37 nic-31-c31-100 kernel: Unable to handle kernel NULL pointer dereference at virtual address 0004 Feb 14 04:02:37 nic-31-c31-100 kernel: printing eip: Feb 14 04:02:37 nic-31-c31-100 kernel: c0132711 Feb 14 04:02:37 nic-31-c31-100 kernel: *pde = Feb 14 04:02:37 nic-31-c31-100 kernel: Oops: 0002 Feb 14 04:02:37 nic-31-c31-100 kernel: CPU:0 Feb 14 04:02:37 nic-31-c31-100 kernel: EIP:0010:[__remove_inode_queue+17/32] Feb 14 04:02:37 nic-31-c31-100 kernel: EFLAGS: 00010206 Feb 14 04:02:37 nic-31-c31-100 kernel: eax: ebx: c63228c0 ecx: edx: Feb 14 04:02:37 nic-31-c31-100 kernel: esi: c63228c0 edi: c63228c0 ebp: esp: c4cc7d64 Feb 14 04:02:37 nic-31-c31-100 kernel: ds: 0018 es: 0018 ss: 0018 Feb 14 04:02:37 nic-31-c31-100 kernel: Process updatedb (pid: 3773, stackpage=c4cc7000) Feb 14 04:02:37 nic-31-c31-100 kernel: Stack: c0134bf9 c63228c0 0003 c227e280 c015039c Feb 14 04:02:37 nic-31-c31-100 kernel:c10a666c 0007 c012b1b7 c10a666c Feb 14 04:02:37 nic-31-c31-100 kernel: 16bb 40c8 1000 000d 0303 00030ea9 Feb 14 04:02:37 nic-31-c31-100 kernel: Call Trace: [try_to_free_buffers+105/368] [ext2_get_block+44/1264] [page_launder+871/2208] [refill_freelist+31/48] [getblk+250/256] [ext2_getblk+106/224] [ext2_read_inode+258/976] Feb 14 04:02:37 nic-31-c31-100 kernel:[ext2_read_inode+836/976] [ext2_bread+35/288] [iget4+194/208] [ext2_readdir+155/1008] [cached_lookup+16/80] [real_lookup+79/192] [open_namei+831/1456] [vfs_readdir+90/128] Feb 14 04:02:37 nic-31-c31-100 kernel:[filldir64+0/320] [sys_getdents64+79/192] [filldir64+0/320] [sys_fchdir+224/240] [system_call+51/56] Feb 14 04:02:37 nic-31-c31-100 kernel: Feb 14 04:02:37 nic-31-c31-100 kernel: Code: 89 50 04 89 02 c3 89 f6 8d bc 27 00 00 00 00 8b 54 24 04 31 -- Versions installed: (if some fields are empty or look -- unusual then possibly you have very old versions) Linux nic-31-c31-100.mn.mediaone.net 2.4.2-pre3 #1 Tue Feb 13 09:25:14 CST 2001 i686 unknown Kernel modules 2.4.0 Gnu C 2.96 Gnu Make 3.79.1 Binutils 2.10.0.18 Linux C Library> libc.2.2 Dynamic linker ldd (GNU libc) 2.2 Procps 2.0.7 Mount 2.10r Net-tools 1.56 Console-tools 0.3.3 Sh-utils 2.0 Modules Loaded parport_pc lp parport tulip es1371 soundcore ac97_codec
test
sory again - 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: File IO performance
On Wed, 14 Feb 2001, Steve Lord wrote: > > However, we may still optimize readahead a bit on Linux 2.4 without too > > much efforts: an IO read command which fails (and returns an error code > > back to the caller) if merging with other requests fail. > > > > Using this command for readahead pages (and quitting the read loop if we > > fail) can "fix" the logically!=physically contiguous problem and it also > > fixes the case were we sleep and the previous IO commands have been > > already sent to disk when we wakeup. This fix ugly and not as good as the > > IO clustering one, but _much_ simpler and thats all we can do for 2.4, I > > suppose. > > We could break the loop apart somewhat and grab pages first, map them, > then submit all the I/Os together. > > This has other costs assoiated with it, the earlier pages in the > readahead - the ones likely to be used first, will be delayed by the > setup of the other pages. So the calling thread is less likely to find > the first of these pages in cache next time it somes around looking > for them. Of course, most of the time, the thread doing the setup of > readahead is the thread doing the reading, so it gets to wait anyway. > > I am not sure that the fact we do readahead on non contiguous data matters, > since that is the data the user will want anyway. Hum, yes. > A break in the on disk mapping of data could be used to stop readahead > I suppose, especially if getting that readahead page is going to > involve evicting other pages. I suspect that doing this time of thing > is probably getting too complex for it's own good though. > > Try breaking the readahead loop apart, folding the page_cache_read into > the loop, doing all the page allocates first, and then all the readpage > calls. Its too dangerous it seems --- the amount of pages which are allocated/locked/mapped/submitted together must be based on the number of free pages otherwise you can run into an oom deadlock when you have a relatively high number of pages allocated/locked. > I suspect you really need to go a bit further and get the mapping of > all the pages fixed up before you do the actual reads. Hum, also think about a no-buffer-head deadlock when we're under a critical number of buffer heads while having quite a few buffer heads locked which are not going to be queued until all needed buffer heads are allocated. - 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: block ioctl to read/write last sector
> "Michael" == Michael E Brown <[EMAIL PROTECTED]> writes: Michael, Michael> It looks like the numbers we picked for our respective IOCTLs Michael> conflict. I think I can change mine to the next higher since Michael> your patch seems to have been around longer. If you could pick another number that would be great. All the people out there using XFS rely on the BLKSETSIZE ioctl, and mkfs.xfs would break horribly with your patch. Michael> What is the general way to deal with these conflicts? Whoever applies the patch to the official tree deals with them :) -- Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc. [EMAIL PROTECTED], http://www.linuxcare.com/ SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/ - 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: > (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... I wonder if the root of the issue is the underlying security architechure ... anything that needs ANY privilege gets ALL privileges (ie root). chown named and such fixes this, but can't rebind to privileged port, must be restarted by root to do so. VMS / NT have more fine grained privileges. Is there any documentation of the kernel's 'capabilities' functions? It would be exceedingly cool if services (named, nfs, etc) could be updated to use this; I think crackers would loose some motivation if instead of "hey I can totally rule this box!" they have to settle for "hey I can make the ident service report user 'CrAp' for every port!". - 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: Multicast on loopback?
> > locally over the loopback interface. This does not work without adding a > > bogus route statement to get the kernel to hand up the packets from > > loopback to my waiting application. > > The multicast ABI includes the ability to toggle loopback of multicast > datagrams. Use the socket options instead I read that multicast loopback is by default enabled, and I have witnessed this, when having my application bind to my ethernet interface, but the datagrams do not seem to be looped back when I bind to the 'lo' interface. Could this possibly be a conflict with the inherently 'looped back' behavior of the loopback net driver? As far as toggling the flag, or even reading it, I cannot, as I am developing in Java. For developing, I can easily kludge it to work, by adding a fake route statement, forcing the packets back up to the application, but I want to make sure the differing behavior is not a bug in the kernel networking code. -Erik G. Burrows - 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.2.19pre12
On 14 Feb 2001, Andriy Korud wrote: > Hello Alan, > > Wednesday, February 14, 2001, 6:33:49 PM, you wrote: > > > Alan> 2.2.19pre12 > Alan> o Update the DAC960 driver(Leonard Zubkoff) > Alan> o Small PPC fixes (Benjamin >Herrenschmidt) > Alan> o Document irda options config(Steven Cole) > Alan> o Small isdn fixes/obsolete code removal (Kai Germaschewski) > Alan> o Fix alpha kernel builds (Michal Jaegermann) > Alan> o Update ver_linux to match the 2.4 one (Steven Cole) > Alan> o AVM isdn driver updates (Carsten Paeth) > Alan> o ISDN capi/ppp fixes (Kai Germaschewski) > > When trying to compile: > > rm -f scsi_n_syms.o > ld -m elf_i386 -r -o scsi_n_syms.o scsi.o > cc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-fr > ame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -m486 -malign-loops= > 2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -c -o hosts.o hosts.c > hosts.c:139: aic7xxx.h: No such file or directory > hosts.c:500: `AIC7XXX' undeclared here (not in a function) > hosts.c:500: initializer element for `builtin_scsi_hosts[0]' is not constant I'm sure Alan will notice and pick up the proper fix. For a workaround to get you going, you can change hosts.c to include aic7xxx/aic7xxx.h... Jeff - 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.2.19pre12
Hello Alan, Wednesday, February 14, 2001, 6:33:49 PM, you wrote: Alan> 2.2.19pre12 Alan> o Update the DAC960 driver(Leonard Zubkoff) Alan> o Small PPC fixes (Benjamin Herrenschmidt) Alan> o Document irda options config(Steven Cole) Alan> o Small isdn fixes/obsolete code removal (Kai Germaschewski) Alan> o Fix alpha kernel builds (Michal Jaegermann) Alan> o Update ver_linux to match the 2.4 one (Steven Cole) Alan> o AVM isdn driver updates (Carsten Paeth) Alan> o ISDN capi/ppp fixes (Kai Germaschewski) When trying to compile: rm -f scsi_n_syms.o ld -m elf_i386 -r -o scsi_n_syms.o scsi.o cc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-fr ame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -m486 -malign-loops= 2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -c -o hosts.o hosts.c hosts.c:139: aic7xxx.h: No such file or directory hosts.c:500: `AIC7XXX' undeclared here (not in a function) hosts.c:500: initializer element for `builtin_scsi_hosts[0]' is not constant make[3]: *** [hosts.o] Error 1 make[3]: Leaving directory `/usr/src/linux/drivers/scsi' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/usr/src/linux/drivers/scsi' make[1]: *** [_subdir_scsi] Error 2 make[1]: Leaving directory `/usr/src/linux/drivers' make: *** [_dir_drivers] Error 2 -- Best regards, Andriymailto:[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: [Xpert]Video drivers and the kernel
Please CC me if sending to xpert list. This is a big topic. I think I can contribute a whole two cents worth though... Interesting to note that NT's windowing system moved from being originally in userland to inside the kernel between V3.? and 4.0. Remember mom saying "If your friends all jump off a bridge..." The issue I understand is that context switching kernel<>user slows things down. And then there's trying to make an api... XFree just maps mmio/framebuffer and ioports into it's own address space and bangs the hardware, so it's fast and can do anything. DRI extends this to client 3D code in a sense. Bottom line for me, I don't care; as long as I still can use remote X apps, and Quake3 uses my 3D hardware, I'm happy to have people spend their time improving X how they see fit, and they're done an incredible job so far. My only complaint is when there's a problem with X: It's cool that I can just restart it rather than reboot like windows. (so you can play from console of a server right? :) This is a benefit of it being in userspace. But it would be nice if I didn't have to do it via telnet; sometimes I don't have a box on a network. (Aside, is this because X uses keyboard in raw mode? would be nice to still be able to ctrl-alt-del to rebood from console) Anyone know about using alt-sysrq to restore console? So, if the kernel had a card specific module that just knew enough to put the card back into text mode, or if it used the card's bios to do it like the int10.a module in XFree 4.0, we would lack for nothing. (hmm vesafb could be extended?) > On Tue, 13 Feb 2001, Louis Garcia wrote: > > > I was wondering why video drivers are not part of the kernel like every > > other piece of hardware. I would think if video drivers were part of the > > kernel and had a nice API for X or any other windowing system, would not > > only improve performance but would allow competing windowing systems > > without having to develop drivers for each. Has anyone thought or > > rejected this idea. - 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/
longjmp problem
I'm working with a C package written by other on a linux machine with kernel version 2.2.14, often in a calls of longjmp routine the system crash with a SIGSEGV signal. Anyone can tell me if it can be a kernel problem ? Elena Labruna. - 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 "device or resource busy" mean ?
Hello, When I try to load module ttime.o - "insmod ttime.o" - I get the following message: "ttime.o: init_module: Device or resource busy". "lsmod" shows that ttime.o was effectively not loaded. I am using RH7 with kernel 2.2.16-22. Does anyone have a guess on a possible reason for this and how to fix it, so the module can be normally loaded ? Thanks, Marcus. - 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] make file times work in tmpfs
Hi Alan,
here is a patch that makes the different file timestamps work on
tmpfs.
Greetings
Christoph
--- mac10/mm/shmem.c.orig Wed Feb 14 14:39:46 2001
+++ mac10/mm/shmem.cWed Feb 14 15:30:09 2001
@@ -160,6 +160,7 @@
swp_entry_t **base, **ptr, **last;
struct shmem_inode_info * info = >u.shmem_i;
+ inode->i_ctime = inode->i_mtime = CURRENT_TIME;
spin_lock (>lock);
index = (inode->i_size + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT;
if (index > info->max_index)
@@ -734,6 +735,7 @@
struct inode * inode = shmem_get_inode(dir->i_sb, mode, dev);
int error = -ENOSPC;
+ dir->i_ctime = dir->i_mtime = CURRENT_TIME;
if (inode) {
d_instantiate(dentry, inode);
dget(dentry); /* Extra count - pin the dentry in core */
@@ -767,6 +769,7 @@
if (S_ISDIR(inode->i_mode))
return -EPERM;
+ inode->i_ctime = dir->i_ctime = dir->i_mtime = CURRENT_TIME;
inode->i_nlink++;
atomic_inc(>i_count);/* New dentry reference */
dget(dentry); /* Extra pinning count for the created dentry */
@@ -809,7 +812,9 @@
static int shmem_unlink(struct inode * dir, struct dentry *dentry)
{
- dentry->d_inode->i_nlink--;
+ struct inode *inode = dentry->d_inode;
+ inode->i_ctime = dir->i_ctime = dir->i_mtime = CURRENT_TIME;
+ inode->i_nlink--;
dput(dentry); /* Undo the count from "create" - this does all the work */
return 0;
}
@@ -836,10 +841,12 @@
if (shmem_empty(new_dentry)) {
struct inode *inode = new_dentry->d_inode;
if (inode) {
+ inode->i_ctime = CURRENT_TIME;
inode->i_nlink--;
dput(new_dentry);
}
error = 0;
+ old_dentry->d_inode->i_ctime = old_dir->i_ctime = old_dir->i_mtime =
+CURRENT_TIME;
}
return error;
}
@@ -873,6 +880,7 @@
UnlockPage(page);
page_cache_release(page);
up(>i_sem);
+ dir->i_ctime = dir->i_mtime = CURRENT_TIME;
return 0;
fail:
up(>i_sem);
-
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: Reason (was: Re: dropcopyright script)
Mordechai Ovits wrote: > > > In newer file managers, the icon of a C file is a tiny image of the first > > > few lines of text. If all files startt with a copyright, it's not much > > > good. So running this on a local, personal, tree can be a good thing. > > > > Modifying the file manager to take care of that would > > be a proper solution I think... > > hard to imagine that working for any general solution. Better to let people > mess with their own files using a script like the one posted. According to GNU standards <;-)> all files should begin with a short description of the contents of the file, 1 or 2 lines long. The copyright notice comes next. Surely that's enough to identify an icon? -- 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: Reason (was: Re: dropcopyright script)
On Wed, Feb 14, 2001 at 12:52:36PM -0500, Gregory Maxwell wrote: > On Wed, Feb 14, 2001 at 10:00:25AM -0500, Mohammad A. Haque wrote: > > How big do you have your icons set that you can actually read stuff in > > it? > > On Wed, 14 Feb 2001, Mordechai Ovits wrote: > > > > > In newer file managers, the icon of a C file is a tiny image of the first > > > few lines of text. If all files startt with a copyright, it's not much > > > good. So running this on a local, personal, tree can be a good thing. > > It would probably be more useful to make a little picture of a tree of the Huh? Mordy > - > 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: 2.4.1-ac12 compile failure on sparc64
On Wed, Feb 14, 2001 at 10:41:48PM +1100, Anton Blanchard wrote: > > Hi - I am having compilation troubles on my sparc64 workstation (standard > > Ultra 5 machine), which is currently running stock 2.4.1 on Red Hat 6.2 quite > > happily. > > We arent tracking the -ac patches at the moment and alan can't be expected > to ensure it compiles on all architectures. Best bet is to stick with > Linus releases. You are right, of course, but then ASN Stephens is also right for reporting a problem in the -ac patches. Or do you expect people to ignore bugs in the -ac series and let bugs go unreported? How will the -ac series improve, and ultimately, how will the official Linux kernel improve? Granted, in this case, Alan already knew the problem. :-) Cheers, Anthony -- Anthony Fok Tung-LingCivil and Environmental Engineering [EMAIL PROTECTED], [EMAIL PROTECTED]University of Alberta, Canada Debian GNU/Linux Chinese Project -- http://www.debian.org/intl/zh/ Come visit Our Lady of Victory Camp -- http://www.olvc.ab.ca/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] network driver updates
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 :
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().
What about the attached patch?
--- 2.4/drivers/net/3c59x.c Wed Feb 14 10:50:50 2001
+++ build-2.4/drivers/net/3c59x.c Wed Feb 14 18:51:55 2001
@@ -2661,13 +2661,16 @@
rc = pci_module_init(_driver);
if (rc < 0) {
- rc = vortex_eisa_init();
- if (rc > 0)
- vortex_have_eisa = 1;
+ if (rc != -ENODEV)
+ return rc;
} else {
vortex_have_pci = 1;
}
+ if (vortex_eisa_init() > 0) {
+ vortex_have_eisa = 1;
+ rc = 0;
+ }
return rc;
}
Re: [PATCH] network driver updates
On Wed, 14 Feb 2001, David Hinds wrote: > On Thu, Feb 15, 2001 at 12:33:43AM +1100, Andrew Morton wrote: > > > > > * something is wrong in the vortex initialization: I don't have such a > > > card, but the driver didn't return an error message on insmod. I'm not > > > sure if my fix is correct. > > > > That was intentional - dhinds suggested that if the hardware > > isn't present the driver should float about in memory anyway. > > Say the driver is linked into the kernel. Hot plug drivers should not > all complain about not finding their hardware. Yes; that is the whole reason why pci_register_driver does not error out when it finds zero matching devices. Jeff - 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.1, 2.4.2-pre3: APIC lockups
On Wed, 14 Feb 2001, Roeland Th. Jansen wrote: > On Tue, Feb 13, 2001 at 09:13:10PM +0100, Maciej W. Rozycki wrote: > > Please test it extensively, as much as you can, before I submit it for > > inclusion. If you ever get "Aieee!!! Remote IRR still set after unlock!" > > message, please report it to me immediately -- it means the code failed. > > > ok, so far so good. > > > There is also an additional debugging/statistics counter provided in > > /proc/cpuinfo that counts interrupts which got delivered with its trigger > > mode mismatched. Check it out to find if you get any misdelivered > > interrupts at all. > > currently attacking the box with a flood ping. I used a pristine 2.4.1. > to be sure I didn't leave stuff and applied the patch. ping -l is a good test also... Jeff - 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-ac12 compile failure on sparc64
It's a quick change at arch/sparc64/kernel/sys_sparc32.c:907 from: struct dqblk d; to: struct disk_dqblk d; Compiles and works great on my ultra. On Wed, 14 Feb 2001, Anton Blanchard wrote: > > Hi - I am having compilation troubles on my sparc64 workstation (standard > > Ultra 5 machine), which is currently running stock 2.4.1 on Red Hat 6.2 quite > > happily. > > We arent tracking the -ac patches at the moment and alan can't be expected > to ensure it compiles on all architectures. Best bet is to stick with > Linus releases. > > Anton - 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: Reason (was: Re: dropcopyright script)
On Wed, Feb 14, 2001 at 10:00:25AM -0500, Mohammad A. Haque wrote: > How big do you have your icons set that you can actually read stuff in > it? > On Wed, 14 Feb 2001, Mordechai Ovits wrote: > > > In newer file managers, the icon of a C file is a tiny image of the first > > few lines of text. If all files startt with a copyright, it's not much > > good. So running this on a local, personal, tree can be a good thing. It would probably be more useful to make a little picture of a tree of the - 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: Alpha: bad unaligned access handling
On Wed, Feb 14, 2001 at 03:38:33PM -0200, Carlos Carvalho wrote: > Sean Hunter ([EMAIL PROTECTED]) wrote on 14 February 2001 17:26: > >This is an application problem, not a kernel one. You need to upgrade your > >netkit. > > Yes, I was quite confident of this. However, unaligned traps are a > frequent problem with alphas. For a looong time we had zsh produce > lots of it, to the point of making it unusable. Strangely, the problem > disappeared without changing anything in zsh. It was either a library > or kernel problem. Definitely library, I'd think. > > >P.S. I wrote a small wrapper to aid in the debugging of unaligned > >traps, which I'll send to anyone who's interested. > > I'd like it! > OK, my alpha is a sick bunny at the moment, so I'll have to wait until I get home (so I can see why I can't ssh to it). What the wrapper does is set some settings so your program gets sigbus when it generates an unaligned trap, and then runs your program in gdb so gdb helpfully stops at the line which generated the trap. It goes without saying you need to build the program in question with debugging symbols so that you see the code. You then need to fix the unaligned access. This sometimes requires real alpha guruhood (Which I do not possess, but Richard Henderson or Michal Jagerman do, if you need advice), but sometimes simply requires adding __attribute__ ((__unaligned__)) to a struct member in a c file. Sean - 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.1, 2.4.2-pre3: APIC lockups
On Wed, Feb 14, 2001 at 05:30:57PM +, Roeland Th. Jansen wrote: > other observations -- approx 6000 ints from the ne2k card/sec. > MIS shows approx 1% that goes wrong with a ping flood. oops. had to count both CPU0 and CPU1's interrupts. after 23 minutes : CPU0 CPU1 19:38241143823371 IO-APIC-level eth0 MIS: 29025 makes approx 0.3%.. -- Grobbebol's Home | Don't give in to spammers. -o) http://www.xs4all.nl/~bengel | Use your real e-mail address /\ Linux 2.2.16 SMP 2x466MHz / 256 MB |on Usenet. _\_v - 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: File IO performance
>
> On Wed, 14 Feb 2001, wrote:
>
> > I have been performing some IO tests under Linux on SCSI disks.
>
> ext2 filesystem?
>
> > I noticed gaps between the commands and decided to investigate.
> > I am new to the kernel and do not profess to underatand what
> > actually happens. My observations suggest that the file
> > structured part of the io consists of the following file phases
> > which mainly reside in mm/filemap.c . The user read call ends up in
> > a generic file read routine.
> >
> > If the requested buffer is not in the file cache then the data is
> > requested from disk via the disk readahead routine.
> >
> > When this routine completes the data is copied to user space. I have
> > been looking at these phases on an analyzer and it seems that none of
> > them overlap for a single user process.
> >
> > This creates gaps in the scsi commands which significantly reduce
> > bandwidth, particularly at todays disk speeds.
> >
> > I am interested in making changes to the readahead routine. In this
> > routine there is a loop
> >
> > /* Try to read ahead pages.
> > * We hope that ll_rw_blk() plug/unplug, coalescence, requests sort
> > * and the scheduler, will work enough for us to avoid too bad
> > * actuals IO requests.
> > */
> >
> > while (ahead < max_ahead) {
> > ahead ++;
> > if ((raend + ahead) >= end_index)
> >break;
> > if (page_cache_read(filp, raend + ahead) < 0)
> > }
> >
> >
> > this whole loop completes before the disk command starts. If the
> > commands are large and it is for a maximum read ahead this loops
> > takes some time and is followed by disk commands.
>
> Well in reality its worse than you think ;)
>
> > It seems that the performance could be improved if the disk commands
> > were overlapped in some way with the time taken in this loop.
> > I have not traced page_cache_read so I have no idea what is happening
> > but I guess this is some page location and entry onto the specific
> > device buffer queues ?
>
> page_cache_read searches for the given page in the page cache and returns
> it in case its found.
>
> If the page is not already in cache, a new page is allocated.
>
> This allocation can block if we're running out of free memory. To free
> more memory, the allocation routines may try to sync dirty pages and/or
> swap out pages.
>
> After the page is allocated, the mapping->readpage() function is called to
> read the page. The ->readpage() job is to map the page to its correct
> on-disk block (which may involve reading indirect blocks).
>
> Finally, the page is queued to IO which again may block in case the
> request queue is full.
>
> Another issue is that we do readahead of logically contiguous pages, which
> means we may be queuing pages for readahead which are not physically
> contiguous. In this case, we are generating disk seeks.
>
> > I am really looking for some help in underatanding what is happening
> > here and suggestions in ways which operations may be overlapped.
>
> I have some ideas...
>
> The main problem of file readahead, IMHO, is its completly "per page"
> behaviour --- allocation, mapping, and queuing are done separately for
> each page and each of these three steps can block multiple times. This is
> bad because we can loose the chance for queuing the IOs together while
> we're blocked, resulting in several smaller reads which suck.
>
> The nicest solution for that, IMHO, is to make the IO clustering at
> generic_file_read() context and send big requests to the IO layer instead
> "cluster if we're lucky", which is more or less what happens today.
>
> Unfortunately stock Linux 2.4 maximum request size is one page.
>
> SGI's XFS CVS tree contains a different kind of IO mechanism which can
> make bigger requests. We will probably have the current IO mechanism
> support bigger request sizes as well sometime in the future. However,
> both are 2.5 only things.
>
> Additionaly, the way Linux caches on-disk physical block information is
> not very efficient and can be optimized, resulting in less reads of fs
> data to map pages and/or know if pages are physically contiguous (the
> latter is very welcome for write clustering, too).
>
> However, we may still optimize readahead a bit on Linux 2.4 without too
> much efforts: an IO read command which fails (and returns an error code
> back to the caller) if merging with other requests fail.
>
> Using this command for readahead pages (and quitting the read loop if we
> fail) can "fix" the logically!=physically contiguous problem and it also
> fixes the case were we sleep and the previous IO commands have been
> already sent to disk when we wakeup. This fix ugly and not as good as the
> IO clustering one, but _much_ simpler and thats all we can do for 2.4, I
> suppose.
We could break the loop apart somewhat and grab pages first, map them,
then submit all the I/Os together. This has other costs assoiated with
it, the earlier pages in the readahead -
Re: Alpha: bad unaligned access handling
Sean Hunter ([EMAIL PROTECTED]) wrote on 14 February 2001 17:26: >This is an application problem, not a kernel one. You need to upgrade your >netkit. Yes, I was quite confident of this. However, unaligned traps are a frequent problem with alphas. For a looong time we had zsh produce lots of it, to the point of making it unusable. Strangely, the problem disappeared without changing anything in zsh. It was either a library or kernel problem. >P.S. I wrote a small wrapper to aid in the debugging of unaligned >traps, which I'll send to anyone who's interested. I'd like it! - 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 12:33:43AM +1100, Andrew Morton wrote: > > > * something is wrong in the vortex initialization: I don't have such a > > card, but the driver didn't return an error message on insmod. I'm not > > sure if my fix is correct. > > That was intentional - dhinds suggested that if the hardware > isn't present the driver should float about in memory anyway. Say the driver is linked into the kernel. Hot plug drivers should not all complain about not finding their hardware. -- 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/
Re: [patch] 2.4.1, 2.4.2-pre3: APIC lockups
On Tue, Feb 13, 2001 at 09:13:10PM +0100, Maciej W. Rozycki wrote: > Please test it extensively, as much as you can, before I submit it for > inclusion. If you ever get "Aieee!!! Remote IRR still set after unlock!" > message, please report it to me immediately -- it means the code failed. ok, so far so good. > There is also an additional debugging/statistics counter provided in > /proc/cpuinfo that counts interrupts which got delivered with its trigger > mode mismatched. Check it out to find if you get any misdelivered > interrupts at all. currently attacking the box with a flood ping. I used a pristine 2.4.1. to be sure I didn't leave stuff and applied the patch. observations -- system doesn't crash; usually I had to use disable focus processor -- else it fails. other observations -- approx 6000 ints from the ne2k card/sec. MIS shows approx 1% that goes wrong with a ping flood. CPU0 CPU1 0: 35345 36195IO-APIC-edge timer 1: 1632 1534IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 3:826832IO-APIC-edge serial 4: 4 4IO-APIC-edge serial 5: 12213 12201IO-APIC-edge soundblaster 8: 0 1IO-APIC-edge rtc 14: 3079 2906IO-APIC-edge ide0 15: 3 3IO-APIC-edge ide1 18: 69 85 IO-APIC-level BusLogic BT-930 19:17582801758266 IO-APIC-level eth0 NMI: 71480 71480 LOC: 71459 71456 ERR: 3 MIS: 15814 good work ! -- Grobbebol's Home | Don't give in to spammers. -o) http://www.xs4all.nl/~bengel | Use your real e-mail address /\ Linux 2.2.16 SMP 2x466MHz / 256 MB |on Usenet. _\_v - 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: Memory performance significantly improved w/ 2.4.1ac11
Mark Hahn skrev: > first, are you sure your clock is write? the changes appear > to be tiny ~2 MB/s, and might be explained by the fact that > 2.2 and 2.4 have different implementations of gettimeofday. The change I was happy about was the one between 2.4.0ac10 and 2.4.1ac11. I think that it's a good thing that a few percent more memory bandwidth appears from nowhere... Well, but that's just me I guess. > (I'm assuming you're using gtod (second_wall.c) rather than > a times-based measure. the latter will be far less accurate.) *Scratching my head* I have no idea of what your're talking about. Sorry. Im using stream_whatever.cpp and whatever might be in it. > > are you also aware that more modern compilers (2.95.2, I think) > have more specific CPU tunings than just -mpentium? I just used the suggested optimizations. > > by "cycle length = 2", do you mean "tCAS latency = 2"? Not quite sure, that the BIOS says "sdram cycle length=2" is all I know. > finally (and don't take offense), those are astonishingly low > Stream scores. it's been a while since I ran Stream on a p5-class > machine, but jeeze! my dirt-cheap duron/600/kt133/pc133 sustains > 600 MB/s! Oh-well, I guess I just have a even dirt-cheaper machine than you. I haven't got any idea of how machines similar to mine perform. /Arvid - 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/
