Re: Newby help. Tons and tons of Oops
Trying to track down a hardware conflict since the memtest went fine. Does this look normal or can you recommend a place where I can get help tracking this down? Is it normal to have so many devices on IRQ 9? PCI devices found: Bus 0, device 0, function 0: Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 3). Master Capable. Latency=64. Prefetchable 32 bit memory at 0xe400 [0xe7ff]. Bus 0, device 1, function 0: PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 3). Master Capable. Latency=64. Min Gnt=136. Bus 0, device 4, function 0: ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 2). Bus 0, device 4, function 1: IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 1). Master Capable. Latency=32. I/O at 0xd800 [0xd80f]. Bus 0, device 4, function 2: USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 1). IRQ 9. Master Capable. Latency=32. I/O at 0xd400 [0xd41f]. Bus 0, device 4, function 3: Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 2). Bus 0, device 9, function 0: Multimedia video controller: Brooktree Corporation Bt878 (rev 2). IRQ 9. Master Capable. Latency=32. Min Gnt=16.Max Lat=40. Prefetchable 32 bit memory at 0xe100 [0xe1000fff]. Bus 0, device 9, function 1: Multimedia controller: Brooktree Corporation Bt878 (rev 2). IRQ 9. Master Capable. Latency=32. Min Gnt=4.Max Lat=255. Prefetchable 32 bit memory at 0xe080 [0xe0800fff]. Bus 0, device 10, function 0: SCSI storage controller: Adaptec AHA-7850 (rev 1). IRQ 5. Master Capable. Latency=32. Min Gnt=4.Max Lat=4. I/O at 0xd000 [0xd0ff]. Non-prefetchable 32 bit memory at 0xdf00 [0xdf000fff]. Bus 0, device 13, function 0: Multimedia audio controller: Creative Labs SB Live! EMU1 (rev 7). IRQ 9. Master Capable. Latency=32. Min Gnt=2.Max Lat=20. I/O at 0xb800 [0xb81f]. Bus 0, device 13, function 1: Input device controller: Creative Labs SB Live! (rev 7). Master Capable. Latency=32. I/O at 0xb400 [0xb407]. Bus 1, device 0, function 0: VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 4). IRQ 10. Master Capable. Latency=64. Min Gnt=16.Max Lat=32. Prefetchable 32 bit memory at 0xe200 [0xe3ff]. Non-prefetchable 32 bit memory at 0xe000 [0xe0003fff]. Non-prefetchable 32 bit memory at 0xdf80 [0xdfff]. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test10 truncate() change broke `dd'
On Thu, 16 Nov 2000, Mikael Pettersson wrote: > I noticed because I needed to build a boot floppy with an > initial ram disk under 2.4.0-test11pre5. The standard recipe > (Documentation/ramdisk.txt) basically goes: > - dd if=bzImage of=/dev/fd0 bs=1k > notice how many blocks dd reported (NNN) > - dd if=ram_image of=/dev/fd0 bs=1k seek=NNN > dd implements the seek=NNN option by calling ftruncate() before > starting the write. This is where 2.4.0-test10 breaks, since > ftruncate on a block device now provokes an EACCES error. And what kind of meaning would you assign to truncate on floppy? > Maybe `dd' is buggy and should use lseek() instead, but this has > apparently worked for a long time. Use conv=notrunc. > Does anyone know the reason for the S_ISDIR -> !S_ISREG change in test10? For one thing, you really don't want it working on pipes. For another - it's just damn meaningless on devices, symlinks and sockets. Which leaves regular files. OTOH, -EACCES looks wrong - for directories we must return -EISDIR and for sockets ftruncate() should return -EINVAL. Adopting -EINVAL for devices and pipes may be a good idea... Andries, could you comment on that? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Newby help. Tons and tons of Oops
I just noticed these errors in my log as well. Something is weird with my swapping I think. If I get Oops that say "Unable to handle kernel paging request at virtual address ff7f1014" would that not be swap since it is virtual? The errors that make me think it may be with my swapper are as follows. Nov 12 21:12:51 phlegmish kernel: swap_free: Trying to free nonexistent swap-page Nov 12 21:12:51 phlegmish kernel: swap_free: Trying to free nonexistent swap-page Nov 14 02:57:28 phlegmish rc.sysinit: Enabling swap space: succeeded Nov 14 03:01:51 phlegmish kernel: swap_free: offset exceeds max Nov 14 03:01:51 phlegmish kernel: swap_free: offset exceeds max Nov 14 03:17:37 phlegmish kernel: swap_free: Trying to free nonexistent swap-page Nov 14 03:17:37 phlegmish kernel: swap_free: Trying to free nonexistent swap-page And so on.. I tried deleting my swap partiton and recreating it but that made no difference. Any ideas or things to try? Thanks for the help so far Dave On Monday 13 November 2000 10:22, Arnaud S . Launay wrote: > Le Mon, Nov 13, 2000 at 07:59:24AM -0500, David Won a écrit: > > I'm running 2.4.0test11pre3. but the kernel shipped with Redhat 7 doesn't > > work either. When I was running 2.2.15 and RedHat 6.2 before upgrading it > > worked great. Never had an oops ever. > > I ran a memory checker under dos as well and it didn't find anything. Any > > tips? > > Could you please check: > 1/ if memtest really worked, as I had problems with 2.4 (in fact, it wasn't > launched, I had to downgrade to 2.3 for having a test) (have you seen a > scrolling bar of '#' ?) (anyway, i'm sending 2.3 binary privatly) > 2/ your hardware internal temperature (put your hand into the box) > 3/ if every cable is correctly plugged in > > It looks to me like an hardware failure, not a software one. > > Arnaud. > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > 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] Please read the FAQ at http://www.tux.org/lkml/
Large File Support
We need to handle files which are about 10GB large. Is there any way to do this with Linux? Some pointers would be nice. Andreas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Q: Linux rebooting directly into linux.
Erik Andersen <[EMAIL PROTECTED]> writes: > On Tue Nov 14, 2000 at 07:59:18AM -0700, Eric W. Biederman wrote: > > > > All mkelfImage does is the pasting of initrd's, command lines, > > and just a touch of argument conversion code. > > You can link in an initrd using linker magic, i.e. > $(OBJCOPY) --add-section=image=kernel --add-section=initrd=initrd.gz Hmm this is certainly possible. My impression is that this doesn't currently work on x86. I would love to be wrong. > This is done in ppc/boot/Makefile for example. It might be a nice thing > to add a .config option to optionally specify an initrd to link into > the kernel image. Similarly, several architectures have a CONFIG_CMDLINE > which could also do the job (see arch/ppc/config.in for example). > > Presumably, by doing such things you could avoid needing to use mkelfImage. Agreed. And I would like to see that. With the 2.4 code freeze it is too late to do that today. Also mkelfImage gives me backwards compatibility for now. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Modprobe local root exploit
Keith Owens wrote: > > On 15 Nov 2000 22:04:47 -0800, > "H. Peter Anvin" <[EMAIL PROTECTED]> wrote: > >No, it's correct, actually, but probably not what you want. It will > >include all letters [A-Za-z], but if a module named "ärlig"... > > Trying to sanitise the module name in request_module is the wrong fix > anyway, the kernel can ask for any module name it likes. What it must > not do is treat user supplied input _unchanged_ as a module name. > > modutils 2.3.20 (just released) fixes all the known local root > exploits, without kernel changes. However 2.3.20 does nothing about > this problem: "ping6 -I module_name" which lets any user load any > module. That problem exists because the kernel passes user supplied > data unchanged to request_module. The only fix is to add a prefix to > user supplied input (say 'user-interface-') before passing the text to > request_module. This has to be fixed in the higher layers of the > kernel, it cannot be fixed in request_module or modprobe. > Sure, but if you have to change the kernel anyway you ought to pass the "--" option so modprobe knows that regardless what the string is, it's a module name and not an option. -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] Please read the FAQ at http://www.tux.org/lkml/
Re: Modprobe local root exploit
On 15 Nov 2000 22:04:47 -0800, "H. Peter Anvin" <[EMAIL PROTECTED]> wrote: >No, it's correct, actually, but probably not what you want. It will >include all letters [A-Za-z], but if a module named "ärlig"... Trying to sanitise the module name in request_module is the wrong fix anyway, the kernel can ask for any module name it likes. What it must not do is treat user supplied input _unchanged_ as a module name. modutils 2.3.20 (just released) fixes all the known local root exploits, without kernel changes. However 2.3.20 does nothing about this problem: "ping6 -I module_name" which lets any user load any module. That problem exists because the kernel passes user supplied data unchanged to request_module. The only fix is to add a prefix to user supplied input (say 'user-interface-') before passing the text to request_module. This has to be fixed in the higher layers of the kernel, it cannot be fixed in request_module or modprobe. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Modprobe local root exploit
Followup to: <[EMAIL PROTECTED]> By author:Alan Cox <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > > >> + if ((*p & 0xdf) >= 'a' && (*p & 0xdf) <= 'z') continue; > > > > Francis> Just in case... Some modules have uppercase letters too :) > > > > That's what the &0xdf is intended for... > > That looks wrong for UTF8 which is technically what the kernel uses 8) > No, it's correct, actually, but probably not what you want. It will include all letters [A-Za-z], but if a module named "ärlig"... -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] Please read the FAQ at http://www.tux.org/lkml/
Announce: modutils 2.3.20 is available
Due to the recent modutils 2.3 local root exploits, anybody using modutils 2.3 should upgrade to 2.3.20. That means everybody using 2.4 kernels. The security patch to modutils 2.3.19 only closed part of the exploit, this version should close all known exploits. modutils still supports meta expansion, including back quoted commands, but only for data read from the configuration file. This assumes that when modutils is run as root out of the kernel, normal users cannot specify their own configuration files. ftp://ftp..kernel.org/pub/linux/utils/kernel/modutils/v2.3 patch-modutils-2.3.20.bz2 Patch from modutils 2.3.19 to 2.3.20 modutils-2.3.20.tar.bz2 Source tarball, includes RPM spec file modutils-2.3.20-1.src.rpm As above, in SRPM format modutils-2.3.20-1.i386.rpm Compiled with egcs-2.91.66, glibc 2.1.2 modutils-2.3.20-1.sparc.rpm My first sparc rpm, handle with care. Changelog extract * Rewrite table generation code to make it easier to add new tables. * usbmap uses zero vendor as wildcard, test more fields to find end of table. Adam J. Richter. * Off by one error in relocations. Jean-Francois Moine. * Use tgt_long to handle different sizes in combined 32/64 bit systems. Original patch by Dave Miller. * Include module type in headers of generated files. Randy Dunlap. * Add insmod -S (force kallsyms), clean up insmod parameters, man page. * Clean up messages. * Verify MODULE_PARM strings. * Check for multiple well known symbols to get prefix. * Security cleanup. Triggered by Bugtraq exploits by Michal Zalewski, Sebastian Krahmer, Chris Evans. It is still the kernel's fault for passing user data unchanged to a program running as root. * Add missing s/390 arch_finalize_section_address. Roger Luethi. * depmod -F supports strange sparc __export_priv_. Dave Miller. * Sparc64 relocation patch. Redhat (not that they bothered to tell me). * Sparc64 compile and link fixes. Me, with thanks to Dave Miller for making a machine available. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: NatSemi CS5530 Sound Support
> Are there any plans to develop kernel sound driver support for the > Cyrix/NatSemi CS5530 chipset? I noticed PCI and IDE support for this None whatsoever. Use the sb16 driver. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Modprobe local root exploit
> >> + if ((*p & 0xdf) >= 'a' && (*p & 0xdf) <= 'z') continue; > > Francis> Just in case... Some modules have uppercase letters too :) > > That's what the &0xdf is intended for... That looks wrong for UTF8 which is technically what the kernel uses 8) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: BUG Report 2.4.0-test11-pre3: NMI Watchdoch detected LOCKUP atCPU[01]
Gert Wollny wrote:
>
> Hello,
>
> i think it got it nailed, please try the attached patch (it is against
> 11-pre4, but it should work against all test11).
>
> Explanation:
> with test7-pre6 in the imm-module the new scsi - code was enabled (see
> imm.h).
> This causes the locking of the io_request_lock in scsi_register_host
> (scsi.c) during detection of the ZIP drive. Seems, that the request_module
> call for the parport_pc doesn't like this.
> The patch does, what the comment in scsi.c suggests: Enable the new code
> only, after the drive is detected.
>
> Have a nice day
Thank you Gert. I turned off Winbond support as before and it truly is
"safe to say no" now. Your patch seems to work. Good Job.
Still outstanding:
If (mode=SPP && Zip100) Log_msg("Spp is godawful slow, set for EPP in
bios");
// I don't know off top of my head if Zip250 can use ECP or not
// Zip100 is EPP at best
Imm driver reports Zip100 at 101 MB
ECP/EPP setting in Bios yields SPP for Zip100. 1284 spec says you should
be able to set mode 100 to get EPP and even tho it's a M$ extension most
chipsets should support it.
Speed Sucks: Hdparm reports 496k/sec for EPP on a 64 MB buffered disk
read. 1284 spec says 500k/2 MB for EPP and Iomega says it can do 1.4 MB
sustained for Zip100. Not that it matters but SPP runs 96k/sec.
I'm coding up a parport-poker to get familiar then I'll take a stab at
these if someone doesn't beat me to it.
>
> Gert
>
>
>
>
> Name: imm-lockup.patch
>imm-lockup.patch Type: Plain Text (TEXT/PLAIN)
> Encoding: BASE64
>Description: the patch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
unexpected busfree problem
Occasionally I am getting the follow error on my system: (scsi0:0:0:-1) Unexpected busfree, LASTPHASE = 0x40, SEQADDR = 0x66 Read : (10) 00 4f a0 07 00 00 20 00 scsi0 channel 0 : resetting for second half of retries. SCSI bus is being reset for host 0 channel 0. SCSI host 0 channel 0 reset (pid 0) timer out - trying harder. SCSI bus is being reset for host 0 channel 0. SCSI host 0 reset (pid 0) timed out again - probably an unrecoverable SCSI bus or device hang. (scsi0:0:0:0) Synchronous at 160.0 Mbytes/sec, offset 63. Device 804 not ready I/O error: dev 08:04, sector 1621936 ...etc I typed in the above since it was not saved in my log file, so it might be missing some stuff, but nothing that seemed to be needed. After that I get a bunch of I/O errors and the system remounts read-only. Also, after this error has occurred it always happens until I reboot the system, and sometime I even have to go into the adaptec bios and do nothing to get it back to working order (I don't change anything in the bios). I don't think it is the drive, this is the second drive I have tried. It might be and controller or cable problem, but it happen so randomly I can't pin it down. The adapter is an Adaptec 29160 and I use the internal LVD cable that came with the card. My kernel version is 2.4.0-test8. Could this be a kernel problem? I've seen it mentioned a couple of time in the past. Any suggestions? Andy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4. continues after Aieee...
At 05:30 PM 11/15/2000 +0100, Rogier Wolff wrote: > > network card driver) and leave the system running make linux unusable in > > unattended environments as the machine is functionally dead. > >Which doesn't help in this case, as your network card COULD be dead, >while the system simply hasn't crashed Yeah, but it doesn't matter. The system is no more useful running with a network card than it is rebooting itself. Just make sure that it doesn't reboot itself more than N times in M hours, and you'll be fine... The network admin needs to be paged in any case. The network card COULD be dead, in which case the administrator needs to replace it. Otherwise, a reboot could solve the problem. -- This message has been brought to you by the letter alpha and the number pi. Open Source: Think locally, act globally. David Feuer [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: net mods installed under misc in 2.2.18-pre21
On Wed, 15 Nov 2000 11:52:50 +0100, "J . A . Magallon" <[EMAIL PROTECTED]> wrote: >I have noticed that some kernel modules are installed under >/lib/modules/XXX/misc, >instead of /net. I have been checking the drivers/net/Makefile (little knowledge Known problem. Fixed with a new make modules_install algorithm in 2.4 kernels. Back porting that change to 2.2 would force all 2.2 users to upgrade to modutils 2.3. AC does not want forced user space upgrades in the stable kernel (and I agree). So you are stuck with the broken modutles install. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: More modutils: It's probably worse.
On Wed, 15 Nov 2000 11:43:54 +0100, >Why is there any reason that a shell should be invoked anywhere in the >request_module->modprobe->insmod chain? >If implemented correctly, this attack should have the same result as >insmod ';chmod o+w .' (and it should not matter if it gets renamed so >that the actual command executed is insmod 'netdevice-;chmod o+w .') You are confusing two different problems. The meta expansion problem means ;chmod o+w .' does nasty things to your system. The other problem is that any user can load any module by ping6 -I module_name. >> plus the >> modprobe meta expansion algorithm. > >and I see no reason why modprobe should do any such thing, apart from >configurations dealt with in modules.conf anyway. modutils 2.3.20 only does meta expansion for entries in the config file, not for input from the command line. That fixes the first problem but does nothing about the second. The only way to fix the second problem is by always adding a prefix to the user input before passing it to modprobe, that fix has to be in the kernel, not modutils. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test11-pre5/drivers/net/sunhme.c compile failure on x86
Date: Thu, 16 Nov 2000 02:16:32 +0100 (CET)
From: willy tarreau <[EMAIL PROTECTED]>
I also had to move the #include
out of the #ifdef __sparc__/#endif because
copy_{from|to}_user were left undefined (see
simple patch below).
Applied, thanks.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.2.17: TCP keepalive oops
Got this oops (captured by kmsgdump) today. The machine was completely stuck. Phil. ksymoops 2.3.4 on i686 2.2.17. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.2.17/ (default) -m /boot/System.map-2.2.17 (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. <1>Unable to handle kernel NULL pointer dereference at virtual address 0022 <1>current->tss.cr3 = 00101000, %cr3 = 00101000 <1>*pde = <6>Oops: <6>CPU:0 <6>EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 <6>EFLAGS: 00010202 <6>eax: cfd0 ebx: 0002 ecx: edx: <6>esi: 0369af3b edi: 70a2 ebp: 0010 esp: cfffbe8c <6>ds: 0018 es: 0018 ss: 0018 <6>Process swapper (pid: 0, process nr: 1, stackpage=cfffb000) <6>Stack: 0001 0010 cf782ec0 0001 cfffbf54 cfff1000 <6> c0203700 c0169ce9 c0203f70 cfffbf54 cfffbedc c0115d42 c0203f34 c0169cb0 <6> 0001 cfffbf1c cfffbf1c c011614d 0001 <6>Call Trace: [] [] [] [] [] [] [] <6> [] [] [] [] [] [] [] [] <6> [] <6>Code: 8b 43 20 89 44 24 18 8b 43 30 85 c0 0f 85 09 01 00 00 8a 43 >>EIP; c016988c<= Trace; c0169ce9 Trace; c0115d42 Trace; c0169cb0 Trace; c011614d Trace; c0111b14 Trace; c0111ac6 Trace; c011d451 Trace; c010ce39 Trace; c010ce50 Trace; c010b8a8 Trace; c0108ac9 Trace; c011d451 Trace; c0106000 Trace; c010ce39 Trace; c010ce50 Trace; c01cf660 Code; c016988c <_EIP>: Code; c016988c<= 0: 8b 43 20 mov0x20(%ebx),%eax <= Code; c016988f 3: 89 44 24 18 mov%eax,0x18(%esp,1) Code; c0169893 7: 8b 43 30 mov0x30(%ebx),%eax Code; c0169896 a: 85 c0 test %eax,%eax Code; c0169898 c: 0f 85 09 01 00 00 jne11b <_EIP+0x11b> c01699a7 Code; c016989e 12: 8a 43 00 mov0x0(%ebx),%al <6>Aiee, killing interrupt handler <0>Kernel panic: Attempted to kill the idle task! 1 warning issued. Results may not be reliable. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: BUG Report 2.4.0-test11-pre3: NMI Watchdoch detected LOCKUP atCPU[01]
Hello,
i think it got it nailed, please try the attached patch (it is against
11-pre4, but it should work against all test11).
Explanation:
with test7-pre6 in the imm-module the new scsi - code was enabled (see
imm.h).
This causes the locking of the io_request_lock in scsi_register_host
(scsi.c) during detection of the ZIP drive. Seems, that the request_module
call for the parport_pc doesn't like this.
The patch does, what the comment in scsi.c suggests: Enable the new code
only, after the drive is detected.
Have a nice day
Gert
diff -ru 2.4.0-test11-pre4/drivers/scsi/imm.c 2.4.0-test11-pre4-my/drivers/scsi/imm.c
--- 2.4.0-test11-pre4/drivers/scsi/imm.cWed Nov 15 19:39:41 2000
+++ 2.4.0-test11-pre4-my/drivers/scsi/imm.c Wed Nov 15 19:44:56 2000
@@ -212,8 +212,11 @@
return 0;
try_again = 1;
goto retry_entry;
-} else
- return 1; /* return number of hosts detected */
+} else {
+/* now enable the new code */
+host->use_new_eh_code = 1;
+return 1; /* return number of hosts detected */
+}
}
/* This is to give the imm driver a way to modify the timings (and other
diff -ru 2.4.0-test11-pre4/drivers/scsi/imm.h 2.4.0-test11-pre4-my/drivers/scsi/imm.h
--- 2.4.0-test11-pre4/drivers/scsi/imm.hWed Nov 15 19:40:44 2000
+++ 2.4.0-test11-pre4-my/drivers/scsi/imm.h Wed Nov 15 20:01:11 2000
@@ -10,7 +10,7 @@
#ifndef _IMM_H
#define _IMM_H
-#define IMM_VERSION "2.04 (for Linux 2.4.0)"
+#define IMM_VERSION "2.05 (for Linux 2.4.0)"
/*
* 10 Apr 1998 (Good Friday) - Received EN144302 by email from Iomega.
@@ -60,6 +60,9 @@
*added CONFIG_SCSI_IZIP_SLOW_CTR option
* [2.03]
* Fix kernel panic on scsi timeout. 20Aug00 [2.04]
+ *
+ * Fix a lockup during detection of drive 14Nov00 [2.05]
+ * <[EMAIL PROTECTED]>
*/
/* -- END OF USER CONFIGURABLE PARAMETERS - */
@@ -172,7 +175,7 @@
eh_device_reset_handler:NULL, \
eh_bus_reset_handler: imm_reset, \
eh_host_reset_handler: imm_reset, \
- use_new_eh_code:1, \
+ use_new_eh_code:0, \
bios_param: imm_biosparam, \
this_id:7, \
sg_tablesize: SG_ALL, \
Re: [BUG] knfsd causes file system corruption when files are locked.
> On Wednesday November 15, [EMAIL PROTECTED] wrote: Ivan> [1.] knfsd causes file system corruption when files are locked. Ivan> Ivan> [2.] Lock down a file using the NLM_SHARE sharing Ivan> mechanism. Remove the file. Unlock the file using Ivan> NLM_UNSHARE. The filesystem does not recover the file space. I Ivan> am running this on ext2fs. Fsck-ing the filesystem does not Ivan> help. The only way to recover the space is to reformat the Ivan> partition. Ivan> Ivan> [3.] knfsd, lock, NLM_SHARE, NLM_UNSHARE Ivan> Ivan> [4.] Linux version 2.2.16 (root@jedi) (gcc version 2.7.2.3) > "Neil" == Neil Brown <[EMAIL PROTECTED]> writes: Neil> Lots of changes have gone into knfsd since 2.2.16. Could Neil> you please try again with either a later 2.2.18pre kernel, Neil> or 2.2.16 with patches from Neil>http://nfs.sourceforge.net/ Neil> applied? Thanks. Neil> Quick guide is: Neil> 2.2.16 Neil> plus Neil> http://www.fys.uio.no/~trondmy/src/nfsv3-old/linux-2.2.16-nfsv3-0.22.0.dif.bz2 Neil> plus Neil> http://download.sourceforge.net/nfs/kernel-nfs-dhiggen_merge-2.0.gz Neil> NeilBrown I can reproduce the bug using: Linux version 2.2.18pre21 (root@jedi) (gcc version 2.7.2.3) I don't have to type vers=2 to mount a linux nfs share on Solaris (yeah!) Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: isofs broken (2.2 and 2.4)
On Thu, 16 Nov 2000 [EMAIL PROTECTED] wrote: > > If noone else does, I suppose I can. Thanks. > > (> .. gets ENOENT .. > and that is not because it only is a partial image?) I don't think so, but I obviously have no way of actually confirming my suspicion. If the stat information was wrong due to the partial image, the lookup should still have succeeded (the directory entries certainly were there - otherwise they'd not have shown up in readdir), and we would just have gotten garbage inode information etc. I think. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: isofs broken (2.2 and 2.4)
> Anybody else willing to finish this one off? If noone else does, I suppose I can. (> .. gets ENOENT .. and that is not because it only is a partial image?) Andries PS - Yesterday I complained that 2.4.0test9 was fine but 2.4.0test11pre5 dies as soon as it has to forward a ping. The effect is reproducible, and 2.4.0test10 is also fine. I see no changes in the netfilter code. Will look some more into this tomorrow. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: NatSemi CS5530 Sound Support
Matthew Carlisle wrote: > Are there any plans to develop kernel sound driver support for the > Cyrix/NatSemi CS5530 chipset? I noticed PCI and IDE support for this > chipset in the kernel source, but nothing for the sound. I have a NatSemi > Geode GXLV processor, NatSemi Geode CS5530 chipset, and the AC97 codec that > NatSemi recommends (although I'm sure any one will do). So I can act as an > alpha/beta/gamma/zappa tester! :) Go register as a developer on National Semiconductor's website and you can download the source to the native audio support for CS5530. However, my understanding is that this driver will only work on system with BIOS that support VSA2, so you may need to upgrade your BIOS first. Regards, T J -- Chng Tiak-Jung [EMAIL PROTECTED] Cyberlab Singapore, Ericsson ResearchTel: +65-880-8649 510 Thomson Road, #18-00 Fax: +65-256-2403 SLF Building, Singapore 298135http://www.ericsson.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: isofs broken (2.2 and 2.4)
On Wed, 15 Nov 2000, Linus Torvalds wrote: > > Does this patch fix it for you? > > Warning: TOTALLY UNTESTED!!! Please test carefully. Ok, I tested it with the broken image. It looks like "readdir()" is ok now (but not really knowing what the right output should be I cannot guarantee that). HOWEVER, doing an "ls -l" on some of the files gets ENOENT, implying that "lookup()" still has some problems with the image. I suspect the code to handle split entries in isofs_find_entry() has some simple bug, but I'm too lazy to check it out right now. Anybody else willing to finish this one off? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Patch: linux-2.4.0-test11-pre5/drivers/net/hamradio compile problems
linux-2.4.0-test11-pre5/drivers/net/hamradio/baycomm_epp.c and
linux-2.4.0-test11-pre5/drivers/net/hamradio/soundmodem.h refer to
current_cpu.x86_capability, which has changed from an integer to
an array, causing compile errors in these files. Here is a proposed
patch. Thomas, will you handle feeding these patches to Linus if
they look good, or do you want me to?
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
--- linux-2.4.0-test11-pre5/drivers/net/hamradio/baycom_epp.c Fri Oct 27 10:55:01
2000
+++ linux/drivers/net/hamradio/baycom_epp.c Wed Nov 15 17:20:16 2000
@@ -814,7 +814,7 @@
#ifdef __i386__
#define GETTICK(x)\
({\
- if (current_cpu_data.x86_capability & X86_FEATURE_TSC)\
+ if (test_bit(X86_FEATURE_TSC, _cpu_data.x86_capability))\
__asm__ __volatile__("rdtsc" : "=a" (x) : : "dx");\
})
#else /* __i386__ */
--- linux-2.4.0-test11-pre5/drivers/net/hamradio/soundmodem/sm.hWed Aug 18
11:38:50 1999
+++ linux/drivers/net/hamradio/soundmodem/sm.h Wed Nov 15 16:46:57 2000
@@ -299,7 +299,7 @@
#ifdef __i386__
-#define HAS_RDTSC (current_cpu_data.x86_capability & X86_FEATURE_TSC)
+#define HAS_RDTSC (test_bit(X86_FEATURE_TSC, _cpu_data.x86_capability))
/*
* only do 32bit cycle counter arithmetic; we hope we won't overflow.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test11-pre5/drivers/net/sunhme.c compile failure on x86
Hello !
(thanks Dave for the quick patch)
I also had to move the #include
out of the #ifdef __sparc__/#endif because
copy_{from|to}_user were left undefined (see
simple patch below).
Regards,
Willy
--- drivers/net/sunhme.c-orig Wed Nov 15 12:56:33
2000
+++ drivers/net/sunhme.cWed Nov 15 12:59:35
2000
@@ -48,8 +48,8 @@
#ifndef __sparc_v9__
#include
#endif
-#include
#endif
+#include
#include
#include
___
Do You Yahoo!? -- Pour dialoguer en direct avec vos amis,
Yahoo! Messenger : http://fr.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: isofs broken (2.2 and 2.4)
Does this patch fix it for you?
Warning: TOTALLY UNTESTED!!! Please test carefully.
Also, I'd be interested to know whether somebody really knows if the zero
length handling is correct. Should we really round up to 2048, or should
we perhaps round up only to the next bufsize?
Linus
-
--- v2.4.0-test10/linux/fs/isofs/dir.c Fri Aug 11 14:29:01 2000
+++ linux/fs/isofs/dir.cWed Nov 15 17:14:26 2000
@@ -94,6 +94,14 @@
return retnamlen;
}
+static struct buffer_head *isofs_bread(struct inode *inode, unsigned int bufsize,
+unsigned int block)
+{
+ unsigned int blknr = isofs_bmap(inode, block);
+ if (!blknr)
+ return NULL;
+ return bread(inode->i_dev, blknr, bufsize);
+}
+
/*
* This should _really_ be cleaned up some day..
*/
@@ -105,7 +113,7 @@
unsigned char bufbits = ISOFS_BUFFER_BITS(inode);
unsigned int block, offset;
int inode_number = 0; /* Quiet GCC */
- struct buffer_head *bh;
+ struct buffer_head *bh = NULL;
int len;
int map;
int high_sierra;
@@ -117,46 +125,25 @@
return 0;
offset = filp->f_pos & (bufsize - 1);
- block = isofs_bmap(inode, filp->f_pos >> bufbits);
+ block = filp->f_pos >> bufbits;
high_sierra = inode->i_sb->u.isofs_sb.s_high_sierra;
- if (!block)
- return 0;
-
- if (!(bh = breada(inode->i_dev, block, bufsize, filp->f_pos, inode->i_size)))
- return 0;
-
while (filp->f_pos < inode->i_size) {
int de_len;
-#ifdef DEBUG
- printk("Block, offset, f_pos: %x %x %x\n",
- block, offset, filp->f_pos);
- printk("inode->i_size = %x\n",inode->i_size);
-#endif
- /* Next directory_record on next CDROM sector */
- if (offset >= bufsize) {
-#ifdef DEBUG
- printk("offset >= bufsize\n");
-#endif
- brelse(bh);
- offset = 0;
- block = isofs_bmap(inode, (filp->f_pos) >> bufbits);
- if (!block)
- return 0;
- bh = breada(inode->i_dev, block, bufsize, filp->f_pos,
inode->i_size);
+
+ if (!bh) {
+ bh = isofs_bread(inode, bufsize, block);
if (!bh)
return 0;
- continue;
}
de = (struct iso_directory_record *) (bh->b_data + offset);
- if(first_de) inode_number = (block << bufbits) + (offset & (bufsize -
1));
+ if (first_de) inode_number = (block << bufbits) + (offset & (bufsize -
+1));
de_len = *(unsigned char *) de;
#ifdef DEBUG
printk("de_len = %d\n", de_len);
-#endif
-
+#endif
/* If the length byte is zero, we should move on to the next
CDROM sector. If we are at the end of the directory, we
@@ -164,36 +151,36 @@
if (de_len == 0) {
brelse(bh);
- filp->f_pos = ((filp->f_pos & ~(ISOFS_BLOCK_SIZE - 1))
- + ISOFS_BLOCK_SIZE);
+ bh = NULL;
+ filp->f_pos = ((filp->f_pos & ~(ISOFS_BLOCK_SIZE - 1)) +
+ISOFS_BLOCK_SIZE);
+ block = filp->f_pos >> bufbits;
offset = 0;
-
- if (filp->f_pos >= inode->i_size)
- return 0;
-
- block = isofs_bmap(inode, (filp->f_pos) >> bufbits);
- if (!block)
- return 0;
- bh = breada(inode->i_dev, block, bufsize, filp->f_pos,
inode->i_size);
- if (!bh)
- return 0;
continue;
}
- offset += de_len;
+ offset += de_len;
+ if (offset == bufsize) {
+ offset = 0;
+ block++;
+ brelse(bh);
+ bh = NULL;
+ }
+
+ /* Make sure we have a full directory entry */
if (offset > bufsize) {
- /*
-* This would only normally happen if we had
-* a buggy cdrom image. All directory
-* entries should terminate with a null size
-* or end exactly at the end of the sector.
-*/
- printk("next_offset (%x) > bufsize (%lx)\n",
- offset,bufsize);
- break;
+ int slop = bufsize - offset + de_len;
+ memcpy(tmpde, de, slop);
+
NatSemi CS5530 Sound Support
Hi all, Are there any plans to develop kernel sound driver support for the Cyrix/NatSemi CS5530 chipset? I noticed PCI and IDE support for this chipset in the kernel source, but nothing for the sound. I have a NatSemi Geode GXLV processor, NatSemi Geode CS5530 chipset, and the AC97 codec that NatSemi recommends (although I'm sure any one will do). So I can act as an alpha/beta/gamma/zappa tester! :) Thanks, Matthew - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test10 truncate() change broke `dd'
2.4.0-test10 broke `dd' for block devices, due to the following change to do_sys_truncate & do_sys_ftruncate: diff -u --recursive --new-file v2.4.0-test9/linux/fs/open.c linux/fs/open.c --- v2.4.0-test9/linux/fs/open.cSun Oct 8 10:50:33 2000 +++ linux/fs/open.c Thu Oct 26 08:11:21 2000 @@ -103,7 +103,7 @@ inode = nd.dentry->d_inode; error = -EACCES; - if (S_ISDIR(inode->i_mode)) + if (!S_ISREG(inode->i_mode)) goto dput_and_out; error = permission(inode,MAY_WRITE); @@ -164,7 +164,7 @@ dentry = file->f_dentry; inode = dentry->d_inode; error = -EACCES; - if (S_ISDIR(inode->i_mode) || !(file->f_mode & FMODE_WRITE)) + if (!S_ISREG(inode->i_mode) || !(file->f_mode & FMODE_WRITE)) goto out_putf; error = -EPERM; if (IS_IMMUTABLE(inode) || IS_APPEND(inode)) I noticed because I needed to build a boot floppy with an initial ram disk under 2.4.0-test11pre5. The standard recipe (Documentation/ramdisk.txt) basically goes: - dd if=bzImage of=/dev/fd0 bs=1k notice how many blocks dd reported (NNN) - dd if=ram_image of=/dev/fd0 bs=1k seek=NNN dd implements the seek=NNN option by calling ftruncate() before starting the write. This is where 2.4.0-test10 breaks, since ftruncate on a block device now provokes an EACCES error. Maybe `dd' is buggy and should use lseek() instead, but this has apparently worked for a long time. Does anyone know the reason for the S_ISDIR -> !S_ISREG change in test10? /Mikael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New bluesmoke patch available, implements MCE-without-MCA support
On 15 Nov 2000, H. Peter Anvin wrote: >This implements support for MCE on chips which don't support MCA (in >addition to enabling MCA for non-Intel chips, like Athlon, which >supports MCA.) > >I would appreciate it if people who have chips with MCE but no MCA -- >this includes older AMD chips and some Cyrix chips at the very least >-- would please be so kind and try this out. I have a K6-III which announces MCE but not MCA, so I was going to test this on that machine. However, both the K6-III manual and the K6 BIOS guide state quite clearly that the K6 family only has a "stub" MCE implementation. The MCE capability is announced, there are two MCE-related MSRs, and there is a CR4.MCE flag, but none of it actually _does_ anything. The new CPU detection code should probably clear FEATURE_MCE for K6 CPUs. (We might consider it an AMD bug, but in their defense, they do state that the stub implementation was done for "compatibility" reasons.) /Mikael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VIA IDE bug with WD drive?
On Wednesday 15 November 2000 19:30, Karnik, Rahul wrote:
| I get the following error if I try to enable DMA on my Abit KT7
| motherboard with a VIA2C686 chipset:
|
| hdb: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest
| } hdb: timeout waiting for DMA
| hda: DMA disabled
| hdb: DMA disabled
| ide0: reset: success
i get the same thing, along with a crc error, over and over on a
20-gig WD IDE drive. alternately puzzling and frightening.
apparently, wd uses some nonstandard goofball error checking thing
that just doesn't work with linux at present. it *seems* to do no
harm.
--
dep
--
Everyone is entitled to his own opinion but not his own facts.
-- Daniel Patrick Moynahan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: isofs broken (2.2 and 2.4)
On Thu, 16 Nov 2000, Andries Brouwer wrote: > > Has there been a kernel version that could read these? > It looks like it proclaims blocksize 512 and uses blocksize 2048 or so. The (de_len == 0) check in do_isofs_readdir() seems to imply that the blocksize is always 2048. So at the very least something is inconsistent. We use ISOFS_BUFFER_SIZE(inode) (512 in this case) for some sector sizes, and then ISOFS_BLOCK_SIZE (2048) for others. But the way isofs_bmap() works, we need to work with ISOFS_BUFFER_SIZE(inode). And I don't know if directories are always _aligned_ at 2048 bytes even if they should be blocked at 2k. Looking at the isofs lookup() logic, it will actually handle split entries, instead of complaining about them. And I suspect readdir() did too at some point, and the code was just removed (probably due to excessive confusion) when one of the many readdir() reorganizations was done. readdir() probably worked a long time ago. Is the thing documented somewhere? It looks like we should just allow entries that are split and not complain about them. We have the temporary buffer for it already.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test11-pre5/drivers/net/sunhme.c compile failure on x86
This is a better fix:
--- drivers/net/sunhme.c.~1~Sun Nov 12 02:23:30 2000
+++ drivers/net/sunhme.cWed Nov 15 16:34:44 2000
@@ -1600,6 +1600,10 @@
HMD(("happy_meal_init: old[%08x] bursts<",
hme_read32(hp, gregs + GREG_CFG)));
+#ifndef __sparc__
+ /* It is always PCI and can handle 64byte bursts. */
+ hme_write32(hp, gregs + GREG_CFG, GREG_CFG_BURST64);
+#else
if ((hp->happy_bursts & DMA_BURST64) &&
((hp->happy_flags & HFLAG_PCI) != 0
#ifdef CONFIG_SBUS
@@ -1633,6 +1637,7 @@
HMD(("XXX>"));
hme_write32(hp, gregs + GREG_CFG, 0);
}
+#endif /* __sparc__ */
/* Turn off interrupts we do not want to hear. */
HMD((", enable global interrupts, "));
@@ -2887,8 +2892,10 @@
/* And of course, indicate this is PCI. */
hp->happy_flags |= HFLAG_PCI;
+#ifdef __sparc__
/* Assume PCI happy meals can handle all burst sizes. */
hp->happy_bursts = DMA_BURSTBITS;
+#endif
hp->happy_block = (struct hmeal_init_block *)
pci_alloc_consistent(pdev, PAGE_SIZE, >hblock_dvma);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test11-pre5/drivers/net/sunhme.c compile failure on x86
linux-2.4.0-test11-pre5/drivers/net/sunhme.c fails to compile
on x86 because it uses the undefined symbols DMA_BURST{BITS,8,16,32,64},
which are not defined anywhere in include/asm-i386/*.h. For sparc,
these symbols are defined in include/asm-sparc/dma.h, so I copied them
in sunhme.c and bracketted them if #ifndef DMA_BURSTBITS...#endif, which
made the code compile. However, that is probably not exactly the cleanest
change (it should give correct behavior, however, since the PCI bus
behavior is just to set the mask in question to all ones, so that the
tests for different DMA types all succeed, if I understand correctly).
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
VIA IDE bug with WD drive?
Hi all,
I get the following error if I try to enable DMA on my Abit KT7 motherboard
with a VIA2C686 chipset:
hdb: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hdb: timeout waiting for DMA
hda: DMA disabled
hdb: DMA disabled
ide0: reset: success
hdb is a Western Digital 136BA 13,6 GB drive and hda is a Maxtor 20GB drive.
I do not get the error when enabling DMA on the Maxtor drive (hda).
I have tried kernel versions 2.2.16-3 (stock RH7), 2.2.17 and 2.4.0-testx.
Is this a known bug? Is it solved by the IDE backport patch?
TIA,
Rahul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: test11-pre5 breaks vmware
>> Actually, I know of at least one other shipping commercial >> product (Sitraka's JProbe Java Profiler) that will require >> patching because of this change. It seems unwise to be >> changing field names in commonly used /proc files like >> cpuinfo at this point in time. > > The problem with "flags" is that it no longer contains quite > the same information. Since the semantics of the field changed > slightly, changing the field name is sometimes more correct. The data sure looks like flags to me. If "flags" referred to some specific Intel register, it could be just hex. Anyway, breaking apps to make /proc pretty is just bad. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] show_task() and thread_saved_pc() fix for x86
On Tue, Nov 14, 2000 at 10:19:32AM +0100, Jean Wolter wrote: > > > OTOH, the value is used only by Alt-SysRq-T, so... Hell knows. > > > > No, it's also used by 'ps -l'. See wchan. > > ps -l uses get_wchan() (an architecture specific function from > arch/*/kernel/process.c) to get the return address from > schedule(). And now thread_saved_pc() seems to do the same (at least > on x86). Is there any reason to have two architecture specific > functions doing the same or do I miss something? > > Jean > > PS: Architectures other then x86 use thread_saved_pc() to implement > get_wchan(). If the debug output of Alt-SysRq-T is supposed to show > the waiting channel we should use get_wchan() instead of thread_saved_pc(). Probably historic reasons, it's been that way as long as I can think back. Yet the use of thread_saved_pc() in kernel/sched.c should imho be considered a buglet and be replaced by get_wchan to get more meaningful debugging information. Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: isofs broken (2.2 and 2.4)
On Wed, Nov 15, 2000 at 08:23:44PM +0100, Harald Koenig wrote: > both 2.2.x and 2.4.x kernels can't read `real sky' CDs from the > Space Telescope Science Institute containing lotsof directories (~100) > which each contain lots of small files (~700 files/dir). > only ~10 directories with ~10 files each are displayed, > all the other files/diretories can't be accessed. > the kernel gives the following message: > > next_offset (212) > bufsize (200) Has there been a kernel version that could read these? It looks like it proclaims blocksize 512 and uses blocksize 2048 or so. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Microcode ....
On Wed, 15 Nov 2000 16:10:08 +0100, Fabrice Peix wrote: > > > Yop, > Just a newbie question : > What do exactly Intel P6 Microcode. > It executes Intel P6 instructions. That's what microcode does. regards, Per Jessen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: (iptables) ip_conntrack bug?
> > > I have also seen this happen on a box which ran test9. Apparently because of > > > it's long uptime, because the logs should no signs of an attack. > > > > > > I guess conntrack forgets to flush some entries? Or maybe there is no way it can > > > recover from a full conntrack table? Is it maybe necessary to make the maximum > > > size a configurable option? Or a userspace conntrack daemon like the arpd? > > > > From reading the sources I got the impression that the use count of > > the ip_conntrack struct isn't decremented properly. This causes > > destroy_conntrack() not to free ip_conntrack's - which results allocation > > until the maximum (ip_conntrack_max), and failing to allocate new ones. > > I think I got something, icmp_error_track() increases the use count > (calling ip_conntrack_find_get()) when it returns with no error (not NULL). > Whoever calls icmp_error_track() and gets a valid pointer to ip_conntrack, > must call ip_conntrack_put() - look at ip_conntrack_in(), line 685, the > pointer is just used in a boolean expression without calling > ip_conntrack_put(). I'm not sure if other places needed fixing, but anyway > try this patch: I'm not sure this works, since the use count also counts for skb's, icmp_error_track(), makes the skb refer to this conntrack in case of success, intentually not calling ip_conntrack_put(). So now I'm clueless, although I'm almost certain it's a use count problem. I'd be happy to hear from Rusty or someone on the netfilter mailing list about this. -- Dan Aloni [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] knfsd causes file system corruption when files are locked.
On Wednesday November 15, [EMAIL PROTECTED] wrote:
> [1.] knfsd causes file system corruption when files are locked.
>
> [2.] Lock down a file using the NLM_SHARE sharing mechanism. Remove
> the file. Unlock the file using NLM_UNSHARE. The filesystem does not
> recover the file space. I am running this on ext2fs. Fsck-ing the
> filesystem does not help. The only way to recover the space is to
> reformat the partition.
>
> [3.] knfsd, lock, NLM_SHARE, NLM_UNSHARE
>
> [4.] Linux version 2.2.16 (root@jedi) (gcc version 2.7.2.3)
Lots of changes have gone into knfsd since 2.2.16. Could you please
try again with either a later 2.2.18pre kernel, or 2.2.16 with patches
from
http://nfs.sourceforge.net/
applied? Thanks.
Quick guide is:
2.2.16
plus
http://www.fys.uio.no/~trondmy/src/nfsv3-old/linux-2.2.16-nfsv3-0.22.0.dif.bz2
plus
http://download.sourceforge.net/nfs/kernel-nfs-dhiggen_merge-2.0.gz
NeilBrown
>
> [5.] N/A
>
> [6.] This test.c program will reproduce the problem. You need to compile it
> on a Solaris machine because Linux fcntl does not support NLM_SHARE.
>
> -start here
> #include
> #include
> #include
>
> int main (int argc, char *argv[])
> {
> struct fshare lck;
> int fd, ret;
> if (argc != 2) {
> printf ("Usage: %s file to lock\n", argv[0]);
> return 1;
> }
> fd = open (argv[1], O_WRONLY);
> memset (, 0, sizeof (struct flock));
> lck.f_access = F_WRACC;
> lck.f_deny = F_NODNY;
> ret = fcntl (fd, F_SHARE, );
> unlink (argv[1]);
> ret = fcntl (fd, F_UNSHARE, );
>
> return 0;
> }
> -end here
>
> Step to reproduce the problem
>
> - Compile the program:
> gcc test.c -o test
>
> - Mount a Linux nfs partition on Solaris: (Remember the partition will
> get corrupted, use a partition that you don't care about.)
> mount -o vers=2 jedi:/sandbox /mnt
>
> - Create a chunk of data on /mnt
> dd if=/dev/zero of=/mnt/chunk count=1
>
> - Do a df before running the program
>
> - Run the test program
> ./test /mnt/chunk
>
> - Run df again. The free space reamains the same. The space is gone
> till you reformat the partition.
>
>
> [7.] This bug was seen on a Debian 2.2 machine. We have seen the same
> thing happens on systems running Red Hat 6.2 and TurboLinux 6.0 distributions.
>
> [7.1] Environment:
> Kernel modules found
> Gnu C 2.95.2
> Binutils 2.9.5.0.37
> Linux C Library..
> Dynamic Linker (ld.so) 1.9.11
> ls: /usr/lib/libg++.so: No such file or directory
> Procps 2.0.6
> Mount 2.10f
> Net-tools (1999-04-20)
> Kbd0.99
> Sh-utils 2.0
> Sh-utils Parker.
> Sh-utils
> Sh-utils Inc.
> Sh-utils NO
> Sh-utils PURPOSE.
>
> [7.2] Processor information
>
> processor : 0
> vendor_id : GenuineIntel
> cpu family: 6
> model : 5
> model name: Pentium II (Deschutes)
> stepping : 2
> cpu MHz : 447.700
> cache size: 512 KB
> fdiv_bug : no
> hlt_bug : no
> sep_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 mmx fxsr
> bogomips : 891.29
>
> [7.3] Module information
>
> aic7xxx 124328 1
> nfsd 140436 8 (autoclean)
> snd-pcm-oss16840 1 (autoclean)
> snd-pcm-plugin 13000 0 (autoclean) [snd-pcm-oss]
> snd-mixer-oss 4308 1 (autoclean) [snd-pcm-oss]
> snd-card-cs4236 5224 2
> snd-mpu401-uart 2356 0 [snd-card-cs4236]
> snd-rawmidi 9752 0 [snd-mpu401-uart]
> snd-seq-device 3476 0 [snd-rawmidi]
> isapnp 27572 0 [snd-card-cs4236]
> snd-cs4236 20580 0 [snd-card-cs4236]
> snd-cs4231 19008 0 [snd-card-cs4236 snd-cs4236]
> snd-mixer 23536 0 [snd-mixer-oss snd-cs4236 snd-cs4231]
> snd-pcm29784 0 [snd-pcm-oss snd-pcm-plugin snd-cs4231]
> snd-opl34328 0 [snd-card-cs4236]
> snd-timer 8224 0 [snd-cs4231 snd-pcm snd-opl3]
> snd-hwdep 3052 0 [snd-opl3]
> snd36300 1 [snd-pcm-oss snd-pcm-plugin snd-mixer-oss
>snd-card-cs4236 snd-mpu401-uart snd-rawmidi snd-seq-device snd-cs4236 snd-cs4231
>snd-mixer snd-pcm snd-opl3 snd-timer snd-hwdep]
> soundcore 2448 3 [snd]
> 3c59x 18212 1
>
> [7.4] SCSI Information
>
> Attached devices:
> Host: scsi0 Channel: 00 Id: 05 Lun: 00
> Vendor: NEC Model: CD-ROM DRIVE:465 Rev: 1.03
> Type: CD-ROM ANSI SCSI revision: 02
>
> [7.5] N/A
>
> [8.] Here is a trace from the Solaris snoop program while the test
>
Re: Documentation/proc.txt update
Jorge Nerin wrote: > > Jorge Nerin wrote: > > > > Jorge Nerin wrote: > > > > > > Hello, this is a patch with some updates to the Documetation/proc.txt > > > file, basically it contains updates to the new files in /proc/, new > > > files in /proc, and a paragraph about /proc/sys/net/ipv4/tcp_ecn. It's > > > far from complete, but it's a start point. > > > > > > > Well, netscape seems to wrap long lines, as Peter Samuelson noticed me, > > so I send it again as an attachment. > > > > -- > > Jorge Nerin > > <[EMAIL PROTECTED]> > > Another little update to the patch, this time with bits from Philipp > Matthias Hahn, and a little formating change to break a very long line > in the middle of a paragraph. > > -- > Jorge Nerin > <[EMAIL PROTECTED]> > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ I have to be more careful, I don't know if I forgot to attach the file or if the majordomo has dropped it?, probably the first one. So again, the update: (let's hope it doesn't wrap) --- old/proc.txtMon Oct 23 15:20:00 2000 +++ new/proc.txtWed Nov 15 00:04:48 2000 @@ -3,8 +3,11 @@ -- /proc/sys Terrehon Bowden <[EMAIL PROTECTED]>October 7 1999 Bodo Bauer <[EMAIL PROTECTED]> + +2.4.x update Jorge Nerin <[EMAIL PROTECTED]> November 14 2000 -- -Version 1.2 Kernel version 2.2.12 +Version 1.3 Kernel version 2.2.12 + Kernel version 2.4.0-test11-pre4 -- Table of Contents @@ -42,17 +45,18 @@ 0.1 Introduction/Credits -This documentation is part of a soon (or so we hope) to be released book on -the SuSE Linux distribution. As there is no complete documentation for the -/proc file system and we've used many freely available sources to write these -chapters, it seems only fair to give the work back to the Linux community. -This work is based on the 2.2.* kernel version. I'm afraid it's still far from -complete, but we hope it will be useful. As far as we know, it is the first -'all-in-one' document about the /proc file system. It is focused on the Intel -x86 hardware, so if you are looking for PPC, ARM, SPARC, APX, etc., features, -you probably won't find what you are looking for. It also only covers IPv4 -networking, not IPv6 nor other protocols - sorry. But additions and patches -are welcome and will be added to this document if you mail them to Bodo. +This documentation is part of a soon (or so we hope) to be released book on +the SuSE Linux distribution. As there is no complete documentation for the +/proc file system and we've used many freely available sources to write these +chapters, it seems only fair to give the work back to the Linux community. +This work is based on the 2.2.* kernel version and the upcomming 2.4.*. I'm +afraid it's still far from complete, but we hope it will be useful. As far as +we know, it is the first 'all-in-one' document about the /proc file system. It +is focused on the Intel x86 hardware, so if you are looking for PPC, ARM, +SPARC, APX, etc., features, you probably won't find what you are looking for. +It also only covers IPv4 networking, not IPv6 nor other protocols - sorry. But +additions and patches are welcome and will be added to this document if you +mail them to Bodo. We'd like to thank Alan Cox, Rik van Riel, and Alexey Kuznetsov and a lot of other people for help compiling this documentation. We'd also like to extend a @@ -65,9 +69,13 @@ contact Bodo Bauer at [EMAIL PROTECTED] We'll be happy to add them to this document. -The latest version of this document is available online at +The latest versionof this document isavailable online at http://skaro.nightcrawler.com/~bb/Docs/Proc as HTML version. +If the above direction does not works for you, ypu could try the kernel +mailing list at [EMAIL PROTECTED] and/or try to reach me at [EMAIL PROTECTED] + 0.2 Legal Stuff --- @@ -92,7 +100,7 @@ The proc file system acts as an interface to internal data structures in the kernel. It can be used to obtain information about the system and to change -certain kernel parameters at runtime. +certain kernel parameters at runtime (sysctl). First, we'll take a look at the read-only parts of /proc. In Chapter 2, we show you how you can use /proc/sys to change settings. @@ -111,16 +119,17 @@ .. FileContent
Re: (iptables) ip_conntrack bug?
vegae:/usr/src/linux# grep -r ./* --regexp="IPS_CON" | grep "define" ./include/linux/elf.h:#define DT_MIPS_CONFLICT 0x7008 ./include/linux/elf.h:#define DT_MIPS_CONFLICTNO0x700b ./include/linux/elf.h:#define SHT_MIPS_CONFLICT 0x7002 vegae:/usr/src/linux# hmmm... looks like theriz no IPS_CONFIRMED definition in test9... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: (iptables) ip_conntrack bug?
On Thu, 16 Nov 2000, Dan Aloni wrote:
> On Wed, 15 Nov 2000, Guus Sliepen wrote:
>
> > > I was DDoS'd today while away and came home to find the firewall unable to
> > > do anything network related (although my connection to irc was still
> > > working oddly). a quick dmesg showed the problem.
> > > ip_conntrack: maximum limit of 2048 entries exceeded
> > [...]
> >
> > I have also seen this happen on a box which ran test9. Apparently because of
> > it's long uptime, because the logs should no signs of an attack.
> >
> > I guess conntrack forgets to flush some entries? Or maybe there is no way it can
> > recover from a full conntrack table? Is it maybe necessary to make the maximum
> > size a configurable option? Or a userspace conntrack daemon like the arpd?
>
> >From reading the sources I got the impression that the use count of
> the ip_conntrack struct isn't decremented properly. This causes
> destroy_conntrack() not to free ip_conntrack's - which results allocation
> until the maximum (ip_conntrack_max), and failing to allocate new ones.
I think I got something, icmp_error_track() increases the use count
(calling ip_conntrack_find_get()) when it returns with no error (not NULL).
Whoever calls icmp_error_track() and gets a valid pointer to ip_conntrack,
must call ip_conntrack_put() - look at ip_conntrack_in(), line 685, the
pointer is just used in a boolean expression without calling
ip_conntrack_put(). I'm not sure if other places needed fixing, but anyway
try this patch:
--- linux-2.4.0-test11-pre5/net/ipv4/netfilter/ip_conntrack_core.c Tue Nov 14
09:56:16 2000
+++ linux/net/ipv4/netfilter/ip_conntrack_core.cThu Nov 16 01:35:13 2000
@@ -682,8 +682,10 @@
/* It may be an icmp error... */
if ((*pskb)->nh.iph->protocol == IPPROTO_ICMP
- && icmp_error_track(*pskb, , hooknum))
+ && (ct = icmp_error_track(*pskb, , hooknum))) {
+ ip_conntrack_put(ct);
return NF_ACCEPT;
+ }
if (!(ct = resolve_normal_ct(*pskb, proto,_reply,hooknum,)))
/* Not valid part of a connection */
--
Dan Aloni
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[BUG] knfsd causes file system corruption when files are locked.
[1.] knfsd causes file system corruption when files are locked.
[2.] Lock down a file using the NLM_SHARE sharing mechanism. Remove
the file. Unlock the file using NLM_UNSHARE. The filesystem does not
recover the file space. I am running this on ext2fs. Fsck-ing the
filesystem does not help. The only way to recover the space is to
reformat the partition.
[3.] knfsd, lock, NLM_SHARE, NLM_UNSHARE
[4.] Linux version 2.2.16 (root@jedi) (gcc version 2.7.2.3)
[5.] N/A
[6.] This test.c program will reproduce the problem. You need to compile it
on a Solaris machine because Linux fcntl does not support NLM_SHARE.
-start here
#include
#include
#include
int main (int argc, char *argv[])
{
struct fshare lck;
int fd, ret;
if (argc != 2) {
printf ("Usage: %s file to lock\n", argv[0]);
return 1;
}
fd = open (argv[1], O_WRONLY);
memset (, 0, sizeof (struct flock));
lck.f_access = F_WRACC;
lck.f_deny = F_NODNY;
ret = fcntl (fd, F_SHARE, );
unlink (argv[1]);
ret = fcntl (fd, F_UNSHARE, );
return 0;
}
-end here
Step to reproduce the problem
- Compile the program:
gcc test.c -o test
- Mount a Linux nfs partition on Solaris: (Remember the partition will
get corrupted, use a partition that you don't care about.)
mount -o vers=2 jedi:/sandbox /mnt
- Create a chunk of data on /mnt
dd if=/dev/zero of=/mnt/chunk count=1
- Do a df before running the program
- Run the test program
./test /mnt/chunk
- Run df again. The free space reamains the same. The space is gone
till you reformat the partition.
[7.] This bug was seen on a Debian 2.2 machine. We have seen the same
thing happens on systems running Red Hat 6.2 and TurboLinux 6.0 distributions.
[7.1] Environment:
Kernel modules found
Gnu C 2.95.2
Binutils 2.9.5.0.37
Linux C Library..
Dynamic Linker (ld.so) 1.9.11
ls: /usr/lib/libg++.so: No such file or directory
Procps 2.0.6
Mount 2.10f
Net-tools (1999-04-20)
Kbd0.99
Sh-utils 2.0
Sh-utils Parker.
Sh-utils
Sh-utils Inc.
Sh-utils NO
Sh-utils PURPOSE.
[7.2] Processor information
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 5
model name : Pentium II (Deschutes)
stepping: 2
cpu MHz : 447.700
cache size : 512 KB
fdiv_bug: no
hlt_bug : no
sep_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 mmx fxsr
bogomips: 891.29
[7.3] Module information
aic7xxx 124328 1
nfsd 140436 8 (autoclean)
snd-pcm-oss16840 1 (autoclean)
snd-pcm-plugin 13000 0 (autoclean) [snd-pcm-oss]
snd-mixer-oss 4308 1 (autoclean) [snd-pcm-oss]
snd-card-cs4236 5224 2
snd-mpu401-uart 2356 0 [snd-card-cs4236]
snd-rawmidi 9752 0 [snd-mpu401-uart]
snd-seq-device 3476 0 [snd-rawmidi]
isapnp 27572 0 [snd-card-cs4236]
snd-cs4236 20580 0 [snd-card-cs4236]
snd-cs4231 19008 0 [snd-card-cs4236 snd-cs4236]
snd-mixer 23536 0 [snd-mixer-oss snd-cs4236 snd-cs4231]
snd-pcm29784 0 [snd-pcm-oss snd-pcm-plugin snd-cs4231]
snd-opl34328 0 [snd-card-cs4236]
snd-timer 8224 0 [snd-cs4231 snd-pcm snd-opl3]
snd-hwdep 3052 0 [snd-opl3]
snd36300 1 [snd-pcm-oss snd-pcm-plugin snd-mixer-oss
snd-card-cs4236 snd-mpu401-uart snd-rawmidi snd-seq-device snd-cs4236 snd-cs4231
snd-mixer snd-pcm snd-opl3 snd-timer snd-hwdep]
soundcore 2448 3 [snd]
3c59x 18212 1
[7.4] SCSI Information
Attached devices:
Host: scsi0 Channel: 00 Id: 05 Lun: 00
Vendor: NEC Model: CD-ROM DRIVE:465 Rev: 1.03
Type: CD-ROM ANSI SCSI revision: 02
[7.5] N/A
[8.] Here is a trace from the Solaris snoop program while the test
program mentioned above is running:
sun -> jedi.wrq.com NFS C LOOKUP2 FH=2344 chunk
jedi.wrq.com -> sun NFS R LOOKUP2 OK FH=D308
sun -> jedi.wrq.com NLM C SHARE3 OH=0009 FH=D308 Mode=0 Access=2
jedi.wrq.com -> sun NLM R SHARE3 OH=0009 granted 0
sun -> jedi.wrq.com NLM C UNSHARE3 OH=000A FH=D308 Mode=0 Access=2
jedi.wrq.com -> sun NLM R UNSHARE3 OH=000A granted 0
sun -> jedi.wrq.com NFS C GETATTR2 FH=2344
jedi.wrq.com -> sun NFS R GETATTR2 OK
sun -> jedi.wrq.com NFS C LOOKUP2 FH=2344 chunk
jedi.wrq.com -> sun NFS R LOOKUP2 OK FH=D308
sun -> jedi.wrq.com NFS C LOOKUP2 FH=2344 .nfs5FC7
jedi.wrq.com -> sun
A question about capabilities. fI and fE
Hello. I read the Linux Capabilities FAQ 2.0 and looked at the source in /usr/src/linux/fs/exec.c. In function prepare_binprm() I see that fE is always cleared and set only if EUID == 0 and fI is always cleared and set only if UID == 0 or EUID == 0. Is there a reason for this behaviour? I think that the default value for fE should always be ~0, because every program should be assumed to be capability dumb and fI by default should be ~0 because every capability dump program must be able to run with all capabilities it inherits from user that exec's it. The reason for this question is that I want to run apache in a chrooted environment. I want to run it as some user != root, so he cannot break out of chroot jail, but I must give apache CAP_NET_BIND_SERVICE. I have written a simple wrapper that optionally chroots, optinally sets its privileges, optionally sets its UID and GID and then executes a specified program, but the privileges that I set cannot survive the execve() call because of the default fE = 0 and fI = 0. So I want to know if I modify my kernel and make fE = 0~ and fI = ~0 by default, will this damage the security of my system? vesselin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Q: Linux rebooting directly into linux.
On Tue Nov 14, 2000 at 07:59:18AM -0700, Eric W. Biederman wrote: > > All mkelfImage does is the pasting of initrd's, command lines, > and just a touch of argument conversion code. You can link in an initrd using linker magic, i.e. $(OBJCOPY) --add-section=image=kernel --add-section=initrd=initrd.gz This is done in ppc/boot/Makefile for example. It might be a nice thing to add a .config option to optionally specify an initrd to link into the kernel image. Similarly, several architectures have a CONFIG_CMDLINE which could also do the job (see arch/ppc/config.in for example). Presumably, by doing such things you could avoid needing to use mkelfImage. -Erik -- Erik B. Andersen email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: (iptables) ip_conntrack bug?
On Wed, 15 Nov 2000, Guus Sliepen wrote: > > I was DDoS'd today while away and came home to find the firewall unable to > > do anything network related (although my connection to irc was still > > working oddly). a quick dmesg showed the problem. > > ip_conntrack: maximum limit of 2048 entries exceeded > [...] > > I have also seen this happen on a box which ran test9. Apparently because of > it's long uptime, because the logs should no signs of an attack. > > I guess conntrack forgets to flush some entries? Or maybe there is no way it can > recover from a full conntrack table? Is it maybe necessary to make the maximum > size a configurable option? Or a userspace conntrack daemon like the arpd? >From reading the sources I got the impression that the use count of the ip_conntrack struct isn't decremented properly. This causes destroy_conntrack() not to free ip_conntrack's - which results allocation until the maximum (ip_conntrack_max), and failing to allocate new ones. p.s. Get a popcorn when you're reading netfilter's sources - bumping into a label like 'i_see_dead_people' is quite amusing... -- Dan Aloni [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: (iptables) ip_conntrack bug?
On Wed, Nov 15, 2000 at 04:34:50PM -0500, safemode wrote: > On Wed, 15 Nov 2000 16:19:23 Guus Sliepen wrote: > > On Wed, Nov 15, 2000 at 03:46:03PM -0500, safemode wrote: > > > > > I was DDoS'd today while away and came home to find the firewall unable > > to > > > do anything network related (although my connection to irc was still > > > working oddly). a quick dmesg showed the problem. > > > ip_conntrack: maximum limit of 2048 entries exceeded > > [...] > > > > I have also seen this happen on a box which ran test9. Apparently because > > of > > it's long uptime, because the logs should no signs of an attack. safemode and I discussed this and we tried to find an answer in the kernel source. However, the chain of called functions is too long to determine where exactly the problem is. But most likely, because init_conntrack() can fail (because it cannot free an entry, which is either because netfilter does not dare to throw out entries with large timeouts (tcp connections have ridiculous long timeouts btw, almost 2.3 days?!) or because IPS_CONFIRMED is not set), and this failure is propagating back all the way to the tcp code, so that no new sockets can be opened. From our point of view, the conntrack stuff should be totally transparent to the tcp/ip stack. Since this allows for a DoS attack, might be wise to fix this before 2.4 comes out... --- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> --- See also: http://tinc.nl.linux.org/ http://www.kernelbench.org/ --- PGP signature
Re: EJECT ioctl fails on empty SCSI CD-ROM
On Wed, 15 Nov 2000, Richard B. Johnson wrote:
> On Wed, 15 Nov 2000, James Stevenson wrote:
>
> >
> > Hi
> >
> > this is what i get on 2.2.17
> >
> > open("/dev/scd1", O_RDONLY|O_NONBLOCK) = 3
> > ioctl(3, CDROMEJECT, 0xbc78)= 0
> > close(3)= 0
> >
> >
> > >
> > >Is this the expected behavior? If so, I am curious to hear the rationale
> > >behind it.
> >
>
> Well the open fails with ENOMEDIUM (errno 123). This is hardly appropriate
> since you can't insert any "media" on some machines without a paperclip.
>
> readlink("/dev/cdrom", "", 256) = 9
> open("/dev/scd0", O_RDONLY) = -1 ERRNO_123 (errno 123)
>
Well, here is another 'eject'.
#include
#include
#include
#include
#include
int main(int arg, char *argv[])
{
int fd;
if(((fd = open("/dev/cdrom", O_RDONLY|O_NONBLOCK)) > 0) ||
(arg > 1) && ((fd = open(argv[1], O_RDONLY|O_NONBLOCK)) > 0))
{
if(ioctl(fd, CDROMEJECT, NULL)) /* If it failed */
{
(void)ioctl(fd, CDROMRESET, NULL); /* Reset it */
(void)ioctl(fd, CDROMEJECT, NULL);
}
(void)close(fd);
exit(EXIT_SUCCESS);
}
perror("open");
exit(EXIT_FAILURE);
}
If there is no media in the drive, it fails to eject (open the tray).
open("/dev/cdrom", O_RDONLY|O_NONBLOCK) = 3
ioctl(3, CDROMEJECT, 0) = 671088642 -> error = 0
ioctl(3, 0x5312, 0) = 0 CDROMRESET
ioctl(3, CDROMEJECT, 0) = 671088642
close(3)= 0
_exit(0)= ?
I don't see an ioctl for CDROMOPENTRAY so I suppose CDROMEJECT
is the correct ioctl.
The last time I used CDROMEJECT, (Linux 2.2.17), it worked if there
was no media.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] misc fixes to 11-pre5
* baycom_epp: yet another missed x86_capability instance.
* soundmodem/sm.h: ditto.
* wan/comx.c: fixed typo in call of remove_proc_entry() (the second
argument is proc_dir_entry *, not **)
* scsi/gdth.c::gdth_flush() had a path with use of uninitialized
variable:
/* bar is not initialized */
if (foo)
bar = baz();
if (foo && bar) {
/* code that doesn't change foo or bar */
}
/* If foo was NULL we have random junk in bar */
if (bar)
quux(bar);
if (foo)
barf(foo);
return;
Fixed variant:
if (!foo)
return;
bar = baz();
if (bar) {
/* same code */
quux(bar);
}
barf(foo);
return;
- same, except that we don't do bogus if (bar) quux(bar); in case if bar
had never been initialized.
Please, apply. And yes, it really passes compile ;-/
Cheers,
Al
diff -urN rc11-pre5/drivers/net/hamradio/baycom_epp.c
linux-test/drivers/net/hamradio/baycom_epp.c
--- rc11-pre5/drivers/net/hamradio/baycom_epp.c Thu Nov 2 22:38:36 2000
+++ linux-test/drivers/net/hamradio/baycom_epp.cWed Nov 15 04:26:44 2000
@@ -814,7 +814,7 @@
#ifdef __i386__
#define GETTICK(x)\
({\
- if (current_cpu_data.x86_capability & X86_FEATURE_TSC)\
+ if (test_bit(X86_FEATURE_TSC, _cpu_data.x86_capability))\
__asm__ __volatile__("rdtsc" : "=a" (x) : : "dx");\
})
#else /* __i386__ */
diff -urN rc11-pre5/drivers/net/hamradio/soundmodem/sm.h
linux-test/drivers/net/hamradio/soundmodem/sm.h
--- rc11-pre5/drivers/net/hamradio/soundmodem/sm.h Sun Sep 12 20:43:29 1999
+++ linux-test/drivers/net/hamradio/soundmodem/sm.h Wed Nov 15 04:35:00 2000
@@ -299,7 +299,7 @@
#ifdef __i386__
-#define HAS_RDTSC (current_cpu_data.x86_capability & X86_FEATURE_TSC)
+#define HAS_RDTSC (test_bit(X86_FEATURE_TSC, _cpu_data.x86_capability))
/*
* only do 32bit cycle counter arithmetic; we hope we won't overflow.
diff -urN rc11-pre5/drivers/net/wan/comx.c linux-test/drivers/net/wan/comx.c
--- rc11-pre5/drivers/net/wan/comx.cTue Nov 14 20:26:21 2000
+++ linux-test/drivers/net/wan/comx.c Wed Nov 15 07:36:03 2000
@@ -855,7 +855,7 @@
cleanup_filename_hardware:
remove_proc_entry(FILENAME_HARDWARE, new_dir);
cleanup_new_dir:
- remove_proc_entry(dentry->d_name.name, _root_dir);
+ remove_proc_entry(dentry->d_name.name, comx_root_dir);
cleanup_dev:
kfree(dev);
return ret;
diff -urN rc11-pre5/drivers/scsi/gdth.c linux-test/drivers/scsi/gdth.c
--- rc11-pre5/drivers/scsi/gdth.c Tue Nov 14 20:26:25 2000
+++ linux-test/drivers/scsi/gdth.c Wed Nov 15 07:38:23 2000
@@ -3577,11 +3577,12 @@
ha = HADATA(gdth_ctr_tab[hanum]);
sdev = scsi_get_host_dev(gdth_ctr_tab[hanum]);
-if(sdev)
- scp = scsi_allocate_device(sdev, 1, FALSE);
-
-if(sdev!= NULL && scp != NULL)
-{
+if (!sdev)
+ return;
+
+scp = scsi_allocate_device(sdev, 1, FALSE);
+
+if (scp) {
scp->cmd_len = 12;
scp->use_sg = 0;
@@ -3597,11 +3598,9 @@
gdth_do_cmd(scp, , 30);
}
}
-}
-if(scp!=NULL)
scsi_release_command(scp);
-if(sdev!=NULL)
-scsi_free_host_dev(sdev);
+}
+scsi_free_host_dev(sdev);
}
/* shutdown routine */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: In line ASM magic? What is this?
Timur Tabi wrote:
>
> ** Reply to message from George Anzinger <[EMAIL PROTECTED]> on Wed, 15 Nov
> 2000 12:55:46 -0800
>
> > I am trying to understand what is going on in the following code. The
> > reference for %2, i.e. "m"(*__xg(ptr)) seems like magic (from
> > .../include/i386/system.h). At the same time, the code "m" (*mem) from
> > the second __asm__ below (my code) seems to generate the required asm
> > code. Before I go with the simple version, could someone tell me why?
> > Inquiring minds want to know.
> >
> > struct __xchg_dummy { unsigned long a[100]; };
> > #define __xg(x) ((struct __xchg_dummy *)(x))
> >
> > __asm__ __volatile__(LOCK_PREFIX "cmpxchgl %b1,%2"
> >: "=a"(prev)
> >: "q"(new), "m"(*__xg(ptr)), "0"(old)
> >: "memory");
> >
> >
> > __asm__ __volatile__(
> > LOCK "cmpxchgl %1,%2\n\t"
> > :"=a" (result)
> > :"r" (new),
> > "m" (*mem),
> > "a0" (test)
> > : "memory");
>
> I've been a lot of gcc inline asm recently, and I still consider it a black
> art. There are times when I just throw in what I think makes sense, and then
> look at the code the compiler generated. If it's wrong, I try something else.
>
> Both versions look correct to me. The "m" simply tells the compiler that
> __xg(ptr) is a memory location, and the contents of that memory location should
> NOT be copied to a register. The confusion occurs because its unintuitive that
> the "*" is required. Otherwise, it would have been "r", which basically tells
> the compiler to copy the contents to a register first.
>
I know the feeling. I am currently strugling with "inconsistant
constraints". Still, I must assume that form 1 was used instead of 2
for some reason
George
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [CFT] dmfe.c network driver update for 2.4
Tobias Ringstrom wrote: > > I have updated the dmfe.c network driver for 2.4.0-test by adding proper > locking (I hope), and also made transmission much efficient. > > I would appreciate any feedback from people using this driver, to confirm > that I did not break it. > > It would also be great if someone could take a look at the lock handling, > to confirm that is is correct and sufficient. Would you mind creating a separate patch that -just- correcting the SMP safety? That makes it much easier to review and apply, and then we can consider the other changes... Thanks, Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: mp3 problems on nfs mount
I don't have the asnwer to your particular problem, but I can provide a data point: I play mp3s regularly from an nfs server running 2.4.0.testx (currently test11-pre5), with client also running 2.4.0-testx. The mp3 directory is automounted on demand. xmms plays these nfs-mounted mp3s for hours with no problem. This same nfs server takes backups via tarfiles on nfs exported volumes to a mixed bag of 2.2 and 2.4 clients. The server is of course running the kernel-based nfsd, and HJ Lu's nfs-utils package. (currently 0.2.1-1) Regards, jjs [EMAIL PROTECTED] wrote: > summary: can't play mp3 files on nfs mounted partition. the music starts > to play and then hangs after about 5 seconds. using xmms on the nfs > client. > > leeloo (2.2.17) is the NFS server: > > [root@leeloo /root]# exportfs > /usr/local/mp3 rush > > rush (2.4.10-test10) is the NFS client: > > [root@rush mp3]# mount -t nfs > 192.168.1.50:/usr/local/mp3 on /mnt/mp3 type nfs (rw,addr=192.168.1.50) > > i've tried mounting with different rsize,wsize values, but no luck. i've > also tried mounting via SMB and have the same problems. > > any ideas? > > - brett > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > 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] Please read the FAQ at http://www.tux.org/lkml/
Re: CONFIG_USB_HOTPLUG (was Patch(?): linux-2.4.0-test11-pre4/drivers/sound/yss225.c compile failure)
Jeff Garzik wrote:
>"Adam J. Richter" wrote:
>> You were right: the
>> __devinitdata being used in the USB drivers will probably crash the
>> kernel if CONFIG_HOTPLUG is not defined and the USB code attempts to
>> recover from an error by faking disconnect/reconnect.
>[...]
>> Until there is __usbdev{init,exit}{,data}, the incorrect
>> __devinitdata qualifiers should be removed from the USB device
>> drivers (but not from the host controller drivers, which are PCI drivers).
>If a user hotplugs a device into a kernel which does not support
>CONFIG_HOTPLUG, they are shooting themselves in the foot.
I have always agreed with that (ultimately, I would have the
non-hot-plug kernel simply ignore hot insert events, which would
make it a bit smaller anyhow). That was not the scenario I was
warning about. Please reread this section of the message you
were resonding to:
| __devinitdata being used in the USB drivers will probably crash the
| kernel if CONFIG_HOTPLUG is not defined and the USB code attempts to
| recover from an error by faking disconnect/reconnect.
It has nothing to do with the user physically trying
to do hot plugging.
>I don't see that __devinitdata should be removed.
The reason that __devinitdata should be removed from
the USB drivers (or replaced with __usbdevinitdata) is that
under the status quo, USB storage error recovery code and the
usbdevfs reset code will crash on any non-CONFIG_HOTPLUG kernel
without the user doing anything wrong.
>*plonk*
I expect an apology for that.
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: RAID modules and CONFIG_AUTODETECT_RAID
On Wednesday November 15, [EMAIL PROTECTED] wrote:
>
> [Ian Grant <[EMAIL PROTECTED]>]
> > Of course we need an initrd with the raid modules on it before we can
> > boot from a RAID root partition.
>
> raidtools can't run from an initrd?
>
> Peter
There is a realy issue here.
raidstart currently does not reliably start an array in the face of
drive failure or device renaming. So it could be used in an initrd
setup, but it might not be as reliable as autodetect.
2.4 has appropriate ioctls to allow for a more reliable raidstart, but
that raidstart hasn't been written yet. I have some patches for the
standard raidstart that improve the situation a bit, but I would
prefer a very different looking config file.
So while I would prefer that autodetection were done by user-space,
especially if initrd were being used, I can see that that isn't going
to happen just now, and that it shouldn't be too hard to do in the
kernel, and it is not really unreasonable to do it there.
Ian, could you please try the attached patch?
It looks ok to me, and compiles, but I am not in a good position to
test it at the moment.
Hopefully it will do an auto-detect when you load md.o, and will
automatically load raidX.o as required.
Let me know how it goes, and if there are no problems I will see what
Linus thinks of it.
NeilBrown
--- ./drivers/md/md.c 2000/11/14 21:36:22 1.2
+++ ./drivers/md/md.c 2000/11/15 21:46:28 1.3
@@ -3806,7 +3806,11 @@
#ifdef MODULE
int init_module (void)
{
- return md_init();
+ int rv = md_init();
+#ifdef CONFIG_AUTODETECT_RAID
+ if (rv==0) rv=md_run_setup();
+#endif
+ return rv;
}
static void free_device_names(void)
--- ./drivers/md/Config.in 2000/11/15 20:51:53 1.1
+++ ./drivers/md/Config.in 2000/11/15 21:46:29 1.2
@@ -13,6 +13,8 @@
dep_tristate ' RAID-4/RAID-5 mode' CONFIG_MD_RAID5 $CONFIG_BLK_DEV_MD
if [ "$CONFIG_MD_LINEAR" = "y" -o "$CONFIG_MD_RAID0" = "y" -o "$CONFIG_MD_RAID1" =
"y" -o "$CONFIG_MD_RAID5" = "y" ]; then
bool ' Boot support' CONFIG_MD_BOOT
+fi
+if [ "$CONFIG_MD_LINEAR" = "y" -o "$CONFIG_MD_RAID0" = "y" -o "$CONFIG_MD_RAID1" =
+"y" -o "$CONFIG_MD_RAID5" = "y" -o "$CONFIG_BLK_DEV_MD" = "m" ]; then
bool ' Auto Detect support' CONFIG_AUTODETECT_RAID
fi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
New bluesmoke patch available, implements MCE-without-MCA support
Hi everyone, I have just released a second bluesmoke patch: ftp://ftp.kernel.org/pub/linux/kernel/people/hpa/bluesmoke-2.4.0-test11-pre5-2.diff This implements support for MCE on chips which don't support MCA (in addition to enabling MCA for non-Intel chips, like Athlon, which supports MCA.) I would appreciate it if people who have chips with MCE but no MCA -- this includes older AMD chips and some Cyrix chips at the very least -- would please be so kind and try this out. -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] Please read the FAQ at http://www.tux.org/lkml/
Re: test11-pre5 breaks vmware
On 15 Nov 00 at 12:12, H. Peter Anvin wrote: > Also, if a piece of software needs raw CPUID information (unlike the > "cooked" one provided by recent kernels) it should use > /dev/cpu/*/cpuid. There are two problems, first breaking procfs field name for no good reason (you can name x86 features as 'flags' and amd/cyrix/... as you named... There is certainly fewer apps which search 'flags' for AMD feature than apps which search 'flags' for x86 feature; you can also emulate old flags field by merging all features together, but I'm not asking for this). Second problem is that I know no system which has /dev/cpu/*/* file. Maybe it is just my problem... But if you could modify cpuid/msr registration interface so that they'll appear on my /devfs, it would be much nicer. Currently there is only 'microcode' and 'mtrr' in /devfs/cpu, and no 0,1 subdirectories... Thanks, Petr Vandrovec [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
vfat problems
I recently installed Winlinux2000 on my Win98 machine. When I removed a file from within the WinLinux environment from my mail folder (Eudora for Windows), it screwed up the file permissions on all of the files in that folder. It set the Read Only flag on for all of them. It was actually a relief to see that all of the files were still intact though.. Eric Reischer "You can't depend on your eyes [EMAIL PROTECTED] if your imagination is out of focus." [EMAIL PROTECTED]-- Mark Twain
Re: (iptables) ip_conntrack bug?
On Wed, 15 Nov 2000 16:19:23 Guus Sliepen wrote: > On Wed, Nov 15, 2000 at 03:46:03PM -0500, safemode wrote: > > > I was DDoS'd today while away and came home to find the firewall unable > to > > do anything network related (although my connection to irc was still > > working oddly). a quick dmesg showed the problem. > > ip_conntrack: maximum limit of 2048 entries exceeded > [...] > > I have also seen this happen on a box which ran test9. Apparently because > of > it's long uptime, because the logs should no signs of an attack. > > I guess conntrack forgets to flush some entries? Or maybe there is no way > it can > recover from a full conntrack table? Is it maybe necessary to make the > maximum > size a configurable option? Or a userspace conntrack daemon like the > arpd? I think something is wrong if the ip_conntrack module does not flush it's table after the connections and all that stop. I understand why it does this during the attack...but it doesn't make sense why these tables are kept long after. A userspace tool is not something i think is needed, this piece of code should be in the module, it is either not correctly coded or missing entirely. > I also see a lot of messages like this (on all 2.4 test kernels): > > NAT: 0 dropping untracked packet c00643f0 1 131.211.122.89 -> 224.0.0.2 > NAT: 0 dropping untracked packet c05468e0 1 131.211.122.89 -> 224.0.0.2 > NAT: 0 dropping untracked packet c0064760 1 131.211.122.31 -> 224.0.0.2 > > Turning of multicast on the respective network interface does not stop > these > messages, but anyway they seem rather annoying to me :) Everyone has seen that :) ... that's not exactly what i was talking about the main error message i was worried about was the "ip_conntrack: maximum limit of 2048 entries exceeded" when there was absolutely not traffic coming in and the attack was long since over. I think this is a fairly major bug with the module since it made the firewall inoperable until i reloaded the module.. this DDoS could be repeated on any linux box that is not babysat 24/7 it seems. My firewall drops everything so all the attacker needs to do is get a bunch of sources to send packets (specific? not sure) rapidly enough to fill the ip_conntrack table and your site becomes offline. any other ideas? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test11-pre5, Athlon, and Machine Check Architecture
Followup to: <[EMAIL PROTECTED]> By author:[EMAIL PROTECTED] In newsgroup: linux.dev.kernel > > > > However, since at least AMD Athlon actually advertises MCA, I would > > like to verify that the code works on these processors before > > submitting it to Linus. > > The Athlon MCA is basically the same architecture-wise as Pentium Pro/II > But there are some differences.. Until AMD make document 21656 (BIOS > writers guide) public (or even a subset of it), we'll not be able to take > advantage of these extra features. > > I'd suggest that until this happens, we leave bluesmoke.c Intel only. > That's completely the wrong way to look at it. AMD are certainly free to add features, what they aren't free to do is making code that expects the documented behaviour fail -- and if so, it's their bug. I have so far gotten no indication that that is the case; the only thing I have gotten so far is a positive report that it at least doesn't do the wrong thing in the no-#MF case. -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] Please read the FAQ at http://www.tux.org/lkml/
Re: test11-pre5, Athlon, and Machine Check Architecture
Followup to: <[EMAIL PROTECTED]> By author:[EMAIL PROTECTED] (Rogier Wolff) In newsgroup: linux.dev.kernel > > H. Peter Anvin wrote: > > crash; I don't expect anyone to actually see an #MF exception in real > > life. I'm trying to get confirmation from AMD that the code should > > be correct even for Athlon. > > Peter, > > Would it be an idea to invite people to lower the voltage on their > CPUs a bit, to try and trigger #MF's? > > (I started thinking about slowly overclocking the CPUs, to try and > trigger them, but that's not neccesary. At lower voltages, you'll also > get errors, but shouldn't risk smoking your CPU ) > If they wouldn't mind, I certainly would appreciate it... but on the other hand, once you have gotten an #MF you have no guarantee of proper operation anyway... after all, the code itself could be corrupt. -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] Please read the FAQ at http://www.tux.org/lkml/
Re: Question on SCSI Tape Changer Status
On Wed, Nov 15, 2000 at 10:32:19AM -0600, George R. Kasica wrote: > I've got an HP 4mm DAT Autochanger here (Scsi detection shown below > >from boot)...what I'm wondering is this: Is there a way to tell WHICH > ONE of the 6 tapes is in the actual tape drive from the OS? And if so, > a way to make it load a specific tape (1-6 or maybe 0-5 I'm not sure There's a kernel patch along with userspace ustils at http://www.in-berlin.de/User/kraxel/linux.html (scsi-changer) that exactly does what you want. I use it with 2.2.18pre_something at work but a 2.4 patch is also provided. It works great with our DLT-loader. I wonder why this still isn't in the mainline kernel though > Oct 26 22:20:27 eagle kernel: Vendor: HPModel: C1553A > Rev:NS01 > Oct 26 22:20:27 eagle kernel: Type: Medium Changer ^^ The patch makes this /dev/sch0 > ANSI SCSI revision: 02 > Oct 26 22:20:27 eagle kernel: Detected scsi generic sg2 at scsi0, > channel 0, id 3, lun 1 Bye, Thorsten -- | Thorsten KranzkowskiInternet: [EMAIL PROTECTED]| | Mobile: ++49 170 1876134 Snail: Niemannsweg 30, 49201 Dissen, Germany | | Ampr: dl8bcu@db0lj.#rpl.deu.eu, [EMAIL PROTECTED] [44.130.8.19] | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: (iptables) ip_conntrack bug?
On Wed, Nov 15, 2000 at 03:46:03PM -0500, safemode wrote: > I was DDoS'd today while away and came home to find the firewall unable to > do anything network related (although my connection to irc was still > working oddly). a quick dmesg showed the problem. > ip_conntrack: maximum limit of 2048 entries exceeded [...] I have also seen this happen on a box which ran test9. Apparently because of it's long uptime, because the logs should no signs of an attack. I guess conntrack forgets to flush some entries? Or maybe there is no way it can recover from a full conntrack table? Is it maybe necessary to make the maximum size a configurable option? Or a userspace conntrack daemon like the arpd? I also see a lot of messages like this (on all 2.4 test kernels): NAT: 0 dropping untracked packet c00643f0 1 131.211.122.89 -> 224.0.0.2 NAT: 0 dropping untracked packet c05468e0 1 131.211.122.89 -> 224.0.0.2 NAT: 0 dropping untracked packet c0064760 1 131.211.122.31 -> 224.0.0.2 Turning of multicast on the respective network interface does not stop these messages, but anyway they seem rather annoying to me :) --- Met vriendelijke groet / with kind regards, Guus Sliepen <[EMAIL PROTECTED]> --- See also: http://tinc.nl.linux.org/ http://www.kernelbench.org/ --- PGP signature
Re: test11-pre5, Athlon, and Machine Check Architecture
H. Peter Anvin wrote: > crash; I don't expect anyone to actually see an #MF exception in real > life. I'm trying to get confirmation from AMD that the code should > be correct even for Athlon. Peter, Would it be an idea to invite people to lower the voltage on their CPUs a bit, to try and trigger #MF's? (I started thinking about slowly overclocking the CPUs, to try and trigger them, but that's not neccesary. At lower voltages, you'll also get errors, but shouldn't risk smoking your CPU ) Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * Common sense is the collection of* ** prejudices acquired by age eighteen. -- Albert Einstein - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test11-pre5, Athlon, and Machine Check Architecture
> However, since at least AMD Athlon actually advertises MCA, I would > like to verify that the code works on these processors before > submitting it to Linus. The Athlon MCA is basically the same architecture-wise as Pentium Pro/II But there are some differences.. Until AMD make document 21656 (BIOS writers guide) public (or even a subset of it), we'll not be able to take advantage of these extra features. I'd suggest that until this happens, we leave bluesmoke.c Intel only. regards, Davej. -- | Dave Jones <[EMAIL PROTECTED]> http://www.suse.de/~davej | SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: In line ASM magic? What is this?
** Reply to message from George Anzinger <[EMAIL PROTECTED]> on Wed, 15 Nov
2000 12:55:46 -0800
> I am trying to understand what is going on in the following code. The
> reference for %2, i.e. "m"(*__xg(ptr)) seems like magic (from
> .../include/i386/system.h). At the same time, the code "m" (*mem) from
> the second __asm__ below (my code) seems to generate the required asm
> code. Before I go with the simple version, could someone tell me why?
> Inquiring minds want to know.
>
> struct __xchg_dummy { unsigned long a[100]; };
> #define __xg(x) ((struct __xchg_dummy *)(x))
>
> __asm__ __volatile__(LOCK_PREFIX "cmpxchgl %b1,%2"
>: "=a"(prev)
>: "q"(new), "m"(*__xg(ptr)), "0"(old)
>: "memory");
>
>
> __asm__ __volatile__(
> LOCK "cmpxchgl %1,%2\n\t"
> :"=a" (result)
> :"r" (new),
> "m" (*mem),
> "a0" (test)
> : "memory");
I've been a lot of gcc inline asm recently, and I still consider it a black
art. There are times when I just throw in what I think makes sense, and then
look at the code the compiler generated. If it's wrong, I try something else.
Both versions look correct to me. The "m" simply tells the compiler that
__xg(ptr) is a memory location, and the contents of that memory location should
NOT be copied to a register. The confusion occurs because its unintuitive that
the "*" is required. Otherwise, it would have been "r", which basically tells
the compiler to copy the contents to a register first.
--
Timur Tabi - [EMAIL PROTECTED]
Interactive Silicon - http://www.interactivesi.com
When replying to a mailing-list message, please direct the reply to the mailing list
only. Don't send another copy to me.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
RE: KPATCH] Reserve VM for root (was: Re: Looking for better VM)
Hi!
>I've also never said OOM killer should be disabled. In theory the
>non-overcommitting systems deadlock, Linux survives. Ironically
>usually it's just the opposite in practice. Any user can
>deadlock/crash Linux [default install, no quotas] but not an
>non-overcommitting system [root can clean up]. Here is an example code
>"simulating" a leaking daemon that will "deadlock" Linux even with
>your OOM killer patch [that is anyway *MUCH* better than the actually
>non-existing one in 2.2.x kernels]:
>
>main() { while(1) if (fork()) malloc(1); }
>
>With the patch below I could ssh to the host and killall the offending
>processes. To enable reserving VM space for root do
what about main() { while(1) system("ftp localhost &"); }
This. or so,ething similar should allow you to kill your machine even with your
patch from normal user account
Pavel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: shm swapping in 2.4 again
On 15 Nov 2000, Christoph Rohland wrote: > On Wed, 15 Nov 2000, Rik van Riel wrote: > > On 15 Nov 2000, Christoph Rohland wrote: > >> 2) Integrating it into the global lru lists and/or the page cache. > >> > >> I think the second approach is the way to go but I do not > >> understand the global lru list handling enough to do this and I > >> do not know if we can do this in the short time. > > > > Indeed, this is the way to go. However, for 2.4 ANY change > > that makes the system work would be a good one ;) > > That's what I think. But from my observations I get the impression > that balancing the vm for big shm loads will not work. So the second > approach is perhaps what we have to do to get it working. > > Actually I would appreciate some hints, where I could hook into > the vm if I implement a swap_shm_page() which could be called > from the vm. Can I simply call add_to_lru_cache or do I need to > add it to the page cache... You really want to have it in the swap cache, so we have a place for it allocated in cache, etc... Basically, when we unmap it in try_to_swap_out(), we should add the page to the swap cache, and when the last user stops using the page, we should push the page out to swap. [I'll code up the same thing for normal swap pages] regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: rdtsc to mili secs?
Pavel Machek wrote: > > > > Intel PIIX-based systems will do duty-cycle throttling, for example. > > Don't think so. My toshiba is PIIX-based, AFAIC: > Interesting. Some will, definitely. Didn't know that wasn't universal. Clearly, on a machine like that, there is no hope for RDTSC, at least unless the CPU (and OS!) gets notification that the TSC needs to be recalibrated whenever it switches. > root@bug:~# cat /proc/pci > Bus 0, device 5, function 0: > Bridge: Intel Corporation 82371AB PIIX4 ISA (rev 2). > Bus 0, device 5, function 1: > IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 1). > Master Capable. Latency=64. > I/O at 0x1000 [0x100f]. > Bus 0, device 5, function 2: > USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 1). > IRQ 11. > Master Capable. Latency=64. > I/O at 0xffe0 [0x]. > Bus 0, device 5, function 3: > Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 2). > > Still, it is willing to run with RDTSC at 300MHz, 150MHz, and > 40MHz. (The last one in _extreme_ cases when CPU fan fails -- running > at 40MHz is better than cooking cpu). > > -- > I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." > Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] -- <[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] Please read the FAQ at http://www.tux.org/lkml/
Re: rdtsc to mili secs?
Hi! > > > Sensibly configured power saving/speed throttle systems do not change the > > > frequency at all. The duty cycle is changed and this controls the cpu > > > performance but the tsc is constant > > > > Do you have an example of notebook that does powersaving like that? > > I have 2 examples of notebooks with changing TSC speed... > > > > Intel PIIX-based systems will do duty-cycle throttling, for example. Don't think so. My toshiba is PIIX-based, AFAIC: root@bug:~# cat /proc/pci Bus 0, device 5, function 0: Bridge: Intel Corporation 82371AB PIIX4 ISA (rev 2). Bus 0, device 5, function 1: IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 1). Master Capable. Latency=64. I/O at 0x1000 [0x100f]. Bus 0, device 5, function 2: USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 1). IRQ 11. Master Capable. Latency=64. I/O at 0xffe0 [0x]. Bus 0, device 5, function 3: Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 2). Still, it is willing to run with RDTSC at 300MHz, 150MHz, and 40MHz. (The last one in _extreme_ cases when CPU fan fails -- running at 40MHz is better than cooking cpu). -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
mp3 problems on nfs mount
summary: can't play mp3 files on nfs mounted partition. the music starts to play and then hangs after about 5 seconds. using xmms on the nfs client. leeloo (2.2.17) is the NFS server: [root@leeloo /root]# exportfs /usr/local/mp3 rush rush (2.4.10-test10) is the NFS client: [root@rush mp3]# mount -t nfs 192.168.1.50:/usr/local/mp3 on /mnt/mp3 type nfs (rw,addr=192.168.1.50) i've tried mounting with different rsize,wsize values, but no luck. i've also tried mounting via SMB and have the same problems. any ideas? - brett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Swapping over NFS in Linux 2.4?
Rik van Riel wrote: > > On Wed, 15 Nov 2000, Andreas Osterburg wrote: > > > Because I set up a diskless Linux-workstation, I want to swap > > over NFS. For this purpose I found only patches for "older" > > Linux-versions (2.0, 2.1, 2.2?). > > > Does anyone know wheter there are patches for 2.4 or does anyone > > know another solution for this problem? > > 1. you can swap over NBD > 2. if you point me to the swap-over-nfs patches you >have found, I can try to make them work on 2.4 ;) > > [I have some interest in making swap-over-nfs work and > most of the other VM things in 2.4 are already pretty > stable ... at the moment stability is more important > than extra performance tricks to me] There was a patch recently posted on the nfs mailing list by Tom Dyas from VAlinux. It is against 2.2.17 with the nfs patches by Trond Myklebust and Dave Higgen. The post (including the patch) can be found here: http://marc.theaimsgroup.com/?l=linux-nfs=97157102825580=2 Juri - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: shm swapping in 2.4 again
Hi Rik, On Wed, 15 Nov 2000, Rik van Riel wrote: > On 15 Nov 2000, Christoph Rohland wrote: > >> - shm_swap is called from swap_out. Actually on my machine after a >>while it only gets called without __GFP_IO set, which means it >>will not do anything which again leads to deadlock. > > Only _without_ __GFP_IO ? That's not quite right since > that way the system will never get around to swapping out > dirty pages... Yes :-( >> - If I call this from page_launder it will work much better, but >>after a while it gets stuck on prepare_highmem_swapout and will >>again lock up under heavy load. > > So calling it from page_launder() is just a workaround to > make the deadlock more difficult to trigger and not a fix? It does solve the __GFP_IO issue but triggers another lockup later. >> 2) Integrating it into the global lru lists and/or the page cache. >> >> I think the second approach is the way to go but I do not >> understand the global lru list handling enough to do this and I >> do not know if we can do this in the short time. > > Indeed, this is the way to go. However, for 2.4 ANY change > that makes the system work would be a good one ;) That's what I think. But from my observations I get the impression that balancing the vm for big shm loads will not work. So the second approach is perhaps what we have to do to get it working. Actually I would appreciate some hints, where I could hook into the vm if I implement a swap_shm_page() which could be called from the vm. Can I simply call add_to_lru_cache or do I need to add it to the page cache... Greetings Christoph - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
In line ASM magic? What is this?
I am trying to understand what is going on in the following code. The
reference for %2, i.e. "m"(*__xg(ptr)) seems like magic (from
.../include/i386/system.h). At the same time, the code "m" (*mem) from
the second __asm__ below (my code) seems to generate the required asm
code. Before I go with the simple version, could someone tell me why?
Inquiring minds want to know.
struct __xchg_dummy { unsigned long a[100]; };
#define __xg(x) ((struct __xchg_dummy *)(x))
__asm__ __volatile__(LOCK_PREFIX "cmpxchgl %b1,%2"
: "=a"(prev)
: "q"(new), "m"(*__xg(ptr)), "0"(old)
: "memory");
__asm__ __volatile__(
LOCK "cmpxchgl %1,%2\n\t"
:"=a" (result)
:"r" (new),
"m" (*mem),
"a0" (test)
: "memory");
George
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: test11-pre5 breaks vmware
Michel LESPINASSE wrote: > > On Wed, Nov 15, 2000 at 12:12:15PM -0800, H. Peter Anvin wrote: > > Also, if a piece of software needs raw CPUID information (unlike the > > "cooked" one provided by recent kernels) it should use > > /dev/cpu/*/cpuid. > > Is it also OK to use the cpuid opcode in userspace ? (after checking > for its presence with the 0x20 eflags bit) > Only on single-CPU systems. What /dev/cpu/*/cpuid gives you is the ability to direct the CPUID request to a particular CPU. -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] Please read the FAQ at http://www.tux.org/lkml/
Re: test11-pre5 breaks vmware
On Wed, Nov 15, 2000 at 12:12:15PM -0800, H. Peter Anvin wrote: > Also, if a piece of software needs raw CPUID information (unlike the > "cooked" one provided by recent kernels) it should use > /dev/cpu/*/cpuid. Is it also OK to use the cpuid opcode in userspace ? (after checking for its presence with the 0x20 eflags bit) -- Michel "Walken" LESPINASSE Of course I think I'm right. If I thought I was wrong, I'd change my mind. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: CONFIG_USB_HOTPLUG (was Patch(?): linux-2.4.0-test11-pre4/drivers/sound/yss225.c compile failure)
Hi Adam,
> From: Adam J. Richter [mailto:[EMAIL PROTECTED]]
>
> >From [EMAIL PROTECTED] Wed Nov 15 09:04:36 2000
> >> From: Jeff Garzik [mailto:[EMAIL PROTECTED]]
> >>
> >> Greg KH wrote:
> >> > On Wed, Nov 15, 2000 at 12:29:15AM -0500, Jeff Garzik wrote:
> >> > > If we are going to create CONFIG_USB_HOTPLUG, we must
> -eliminate-
> >> > > CONFIG_HOTPLUG, and create CONFIG_PCI_HOTPLUG, and
> >> > > CONFIG_ANOTHERBUS_HOTPLUG and so on, for each hotplug bus.
> >> >
> >> > Argh!
> >> > I thought the whole point of this was to make there be only
> >> one hotplug
> >> > strategy, due to the fact that this is a real need.
> >> >
> >> > Please let's not go down this path. It was all starting
> to look so
> >> > nice...
> >>
> >> I -want- there to be only one hotplug strategy, but Adam
> seemed to be
> >> talking about the opposite, with his CONFIG_USB_HOTPLUG suggestion.
>
> >I told Adam that I didn't want that patch, but it's not
> >up to me now.
>
> You said you wanted to "hold of on CONFIG_USB_HOTPLUG for now",
> which I take to mean up to 2.4.0.
OK, I stand corrected.
Actually I don't recall what that meant. You could be right,
but it could have meant that it should be re-evaluated later.
> I have not asked that CONFIG_USB_HOTPLUG be put in
> 2.4.0, although
> I would not mind. I am just agreeing with you (Randy) when you
> identified the problem and wrote in linux-usb-devel "[Why] is
> it safe to
> use __devinitdata on the usb_device_id table? It's used
> during any new
> device connect, after driver init, right ...?" You were right: the
> __devinitdata being used in the USB drivers will probably crash the
> kernel if CONFIG_HOTPLUG is not defined and the USB code attempts to
> recover from an error by faking disconnect/reconnect.
>
> The statements about how we might address this issue more
> fully have been about in the context of after 2.4.0. To refresh your
> memory, in my first message on this thread I wrote:
>
> |After 2.4.0, and after the fake disconnect/reconnect code in
> ^^^
> | drivers/usb/{devio,storage/scsiglue}.c is designed out, then we may
> | want to explore adding __usbdevinit{,data} defines in
> include/linux/init.h
> | that would be controlled by a new CONFIG_USB_HOTPLUG option, as in
> | the patches that I posted for this to linux-usb-devel.
>
> Until there is __usbdev{init,exit}{,data}, the incorrect
> __devinitdata qualifiers should be removed from the USB device
> drivers (but not from the host controller drivers, which are
> PCI drivers).
I agreed with you that the __dev qualifiers should be
removed for now, until there is a better solution.
I didn't agree that we should add __usbdev qualifiers.
I think that we should have a unified hotplug strategy,
whatever it is/becomes.
Like Greg and Jeff have said, I'd prefer not to see
CONFIG_whateverbuses_HOTPLUG, but I'm saying that based
on style and KISS, not on technical evaluation,
so I could be wrong. What you are proposing could be
the right thing to do. Maybe you are way ahead of my
thinking on this.
> Would you like to propose a different solution, Randy?
No thanks, I think that we have enough [good] cooks in the
kitchen for now. If I find that I have some time to
contribute to it, I would like to, but not now.
Obviously I may miss the window of time to contribute
to this if I don't do it now, but c'est la vie.
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [CFT] dmfe.c network driver update for 2.4
Hello,
I'll double check the locking later today, but not sure about the
transmission changes.
Regards,
Frank
([EMAIL PROTECTED])
--On Wednesday, November 15, 2000 9:34 PM +0100 Tobias Ringstrom
<[EMAIL PROTECTED]> wrote:
> I have updated the dmfe.c network driver for 2.4.0-test by adding proper
> locking (I hope), and also made transmission much efficient.
>
> I would appreciate any feedback from people using this driver, to confirm
> that I did not break it.
>
> It would also be great if someone could take a look at the lock handling,
> to confirm that is is correct and sufficient.
>
> /Tobias
>
>
> --- dmfe.c.orig Wed Nov 15 19:53:48 2000
> +++ dmfe.cWed Nov 15 21:35:24 2000
> @@ -57,6 +57,11 @@
> Resource usage cleanups.
> Report driver version to user.
>
> + Tobias Ringström <[EMAIL PROTECTED]> :
> + Added proper locking.
> + Rewrote the transmit code to actually use the ring buffer,
> + and to generate a lot fewer interrupts.
> +
> TODO
>
> Implement pci_driver::suspend() and pci_driver::resume()
> @@ -108,6 +113,7 @@
> #define TX_MAX_SEND_CNT 0x1 /* Maximum tx packet per time */
> #define TX_DESC_CNT 0x10 /* Allocated Tx descriptors */
> #define RX_DESC_CNT 0x10 /* Allocated Rx descriptors */
> +#define TX_IRQ_THR 12
> #define DESC_ALL_CNTTX_DESC_CNT+RX_DESC_CNT
> #define TX_BUF_ALLOC0x600
> #define RX_ALLOC_SIZE 0x620
> @@ -188,6 +194,8 @@
>u32 cr7_data;
>u32 cr15_data;
>
> + spinlock_t lock;
> +
>/* descriptor pointer */
>unsigned char *buf_pool_ptr; /* Tx buffer pool memory */
>unsigned char *buf_pool_start; /* Tx buffer pool align dword */
> @@ -198,8 +206,7 @@
>struct rx_desc *first_rx_desc;
>struct rx_desc *rx_insert_ptr;
>struct rx_desc *rx_ready_ptr; /* packet come pointer */
> - u32 tx_packet_cnt; /* transmitted packet count */
> - u32 tx_queue_cnt; /* wait to send packet count */
> + u32 tx_live_cnt;/* number of used/live tx slots */
>u32 rx_avail_cnt; /* available rx descriptor count */
>u32 interval_rx_cnt; /* rx packet count a callback time */
>
> @@ -490,8 +497,6 @@
>
>/* system variable init */
>db->cr6_data = CR6_DEFAULT | dmfe_cr6_user_set;
> - db->tx_packet_cnt = 0;
> - db->tx_queue_cnt = 0;
>db->rx_avail_cnt = 0;
>db->link_failed = 0;
>db->wait_reset = 0;
> @@ -595,46 +600,42 @@
> {
>struct dmfe_board_info *db = dev->priv;
>struct tx_desc *txptr;
> + static unsigned pkt_num = TX_IRQ_THR;
>
>DMFE_DBUG(0, "dmfe_start_xmit", 0);
> -
> - netif_stop_queue(dev);
> -
> - /* Too large packet check */
> - if (skb->len > MAX_PACKET_SIZE) {
> - printk(KERN_ERR "%s: oversized frame (%d bytes) for transmit.\n",
> dev->name, (u16) skb->len); - dev_kfree_skb(skb);
> - return 0;
> - }
> - /* No Tx resource check, it never happen nromally */
> - if (db->tx_packet_cnt >= TX_FREE_DESC_CNT) {
> - return 1;
> - }
> +
> + spin_lock_irq(>lock);
>
>/* transmit this packet */
>txptr = db->tx_insert_ptr;
>memcpy((char *) txptr->tx_buf_ptr, (char *) skb->data, skb->len);
> - txptr->tdes1 = 0xe100 | skb->len;
> + if (--pkt_num == 0)
> + {
> + txptr->tdes1 = 0xe100 | skb->len;
> + pkt_num = TX_IRQ_THR;
> + }
> + else
> + txptr->tdes1 = 0x6100 | skb->len;
> +
> + /* Transmit Packet Process */
> + txptr->tdes0 = 0x8000; /* set owner bit to DM910X */
> + outl(0x1, dev->base_addr + DCR1); /* Issue Tx polling comand */
> + dev->trans_start = jiffies; /* saved the time stamp */
>
>/* Point to next transmit free descriptor */
> - db->tx_insert_ptr = (struct tx_desc *) txptr->next_tx_desc;
> + txptr = (struct tx_desc *)txptr->next_tx_desc;
>
> - /* Transmit Packet Process */
> - if (db->tx_packet_cnt < TX_MAX_SEND_CNT) {
> - txptr->tdes0 = 0x8000; /* set owner bit to DM910X */
> - db->tx_packet_cnt++;/* Ready to send count */
> - outl(0x1, dev->base_addr + DCR1); /* Issue Tx polling comand */
> - } else {
> - db->tx_queue_cnt++; /* queue the tx packet */
> - outl(0x1, dev->base_addr + DCR1); /* Issue Tx polling comand */
> - }
> + if (txptr->tdes0 & 0x8000)
> + netif_stop_queue(dev);
>
> - /* Tx resource check */
> - if (db->tx_packet_cnt < TX_FREE_DESC_CNT)
> - netif_wake_queue(dev);
> + db->tx_insert_ptr = txptr;
> + db->tx_live_cnt++;
> +
> + spin_unlock_irq(>lock);
>
>/* free this SKB */
>dev_kfree_skb(skb);
> +
>return 0;
> }
>
> @@ -713,12 +714,14 @@
>outl(0, ioaddr + DCR7);/* disable all interrupt */
>
(iptables) ip_conntrack bug?
I was DDoS'd today while away and came home to find the firewall unable to do anything network related (although my connection to irc was still working oddly). a quick dmesg showed the problem. ip_conntrack: maximum limit of 2048 entries exceeded NET: 1 messages suppressed. ip_conntrack: maximum limit of 2048 entries exceeded NET: 3 messages suppressed. ip_conntrack: maximum limit of 2048 entries exceeded NAT: 0 dropping untracked packet c1e69980 6 192.168.1.2 -> 206.251.7.30 ip_conntrack: maximum limit of 2048 entries exceeded NAT: 0 dropping untracked packet c1e69b60 6 192.168.1.2 -> 206.251.7.30 ip_conntrack: maximum limit of 2048 entries exceeded That is a very small snippet of dmesg. It seems that ip_conntrack did not flush or reset after the attack, even though everything was fine when i got home. Keep in mind, this was a somewhat massive attack on my network here but is only connected via a DSL line, it seems the attackers sent hundreds or thousands of very small packets resulting in 21000 connection attempts in a short amount of time. Is this a bug with ip_conntrack? this is kernel version 2.4.0-test5, it's been up for 74 days. I had to reload ip_conntrack to flush it and everything worked fine after that.Thanks for any info. ps. If this is a previously discovered bug, is it fixed in the latest kernels? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: CONFIG_USB_HOTPLUG (was Patch(?): linux-2.4.0-test11-pre4/drivers/sound/yss225.c compile failure)
"Adam J. Richter" wrote:
> You were right: the
> __devinitdata being used in the USB drivers will probably crash the
> kernel if CONFIG_HOTPLUG is not defined and the USB code attempts to
> recover from an error by faking disconnect/reconnect.
[...]
> Until there is __usbdev{init,exit}{,data}, the incorrect
> __devinitdata qualifiers should be removed from the USB device
> drivers (but not from the host controller drivers, which are PCI drivers).
If a user hotplugs a device into a kernel which does not support
CONFIG_HOTPLUG, they are shooting themselves in the foot.
I don't see that __devinitdata should be removed.
*plonk*
--
Jeff Garzik |
Building 1024 | The chief enemy of creativity is "good" sense
MandrakeSoft| -- Picasso
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[CFT] dmfe.c network driver update for 2.4
I have updated the dmfe.c network driver for 2.4.0-test by adding proper
locking (I hope), and also made transmission much efficient.
I would appreciate any feedback from people using this driver, to confirm
that I did not break it.
It would also be great if someone could take a look at the lock handling,
to confirm that is is correct and sufficient.
/Tobias
--- dmfe.c.orig Wed Nov 15 19:53:48 2000
+++ dmfe.c Wed Nov 15 21:35:24 2000
@@ -57,6 +57,11 @@
Resource usage cleanups.
Report driver version to user.
+ Tobias Ringström <[EMAIL PROTECTED]> :
+ Added proper locking.
+ Rewrote the transmit code to actually use the ring buffer,
+ and to generate a lot fewer interrupts.
+
TODO
Implement pci_driver::suspend() and pci_driver::resume()
@@ -108,6 +113,7 @@
#define TX_MAX_SEND_CNT 0x1/* Maximum tx packet per time */
#define TX_DESC_CNT 0x10 /* Allocated Tx descriptors */
#define RX_DESC_CNT 0x10 /* Allocated Rx descriptors */
+#define TX_IRQ_THR 12
#define DESC_ALL_CNTTX_DESC_CNT+RX_DESC_CNT
#define TX_BUF_ALLOC0x600
#define RX_ALLOC_SIZE 0x620
@@ -188,6 +194,8 @@
u32 cr7_data;
u32 cr15_data;
+ spinlock_t lock;
+
/* descriptor pointer */
unsigned char *buf_pool_ptr;/* Tx buffer pool memory */
unsigned char *buf_pool_start; /* Tx buffer pool align dword */
@@ -198,8 +206,7 @@
struct rx_desc *first_rx_desc;
struct rx_desc *rx_insert_ptr;
struct rx_desc *rx_ready_ptr; /* packet come pointer */
- u32 tx_packet_cnt; /* transmitted packet count */
- u32 tx_queue_cnt; /* wait to send packet count */
+ u32 tx_live_cnt;/* number of used/live tx slots */
u32 rx_avail_cnt; /* available rx descriptor count */
u32 interval_rx_cnt;/* rx packet count a callback time */
@@ -490,8 +497,6 @@
/* system variable init */
db->cr6_data = CR6_DEFAULT | dmfe_cr6_user_set;
- db->tx_packet_cnt = 0;
- db->tx_queue_cnt = 0;
db->rx_avail_cnt = 0;
db->link_failed = 0;
db->wait_reset = 0;
@@ -595,46 +600,42 @@
{
struct dmfe_board_info *db = dev->priv;
struct tx_desc *txptr;
+ static unsigned pkt_num = TX_IRQ_THR;
DMFE_DBUG(0, "dmfe_start_xmit", 0);
-
- netif_stop_queue(dev);
-
- /* Too large packet check */
- if (skb->len > MAX_PACKET_SIZE) {
- printk(KERN_ERR "%s: oversized frame (%d bytes) for transmit.\n",
dev->name, (u16) skb->len);
- dev_kfree_skb(skb);
- return 0;
- }
- /* No Tx resource check, it never happen nromally */
- if (db->tx_packet_cnt >= TX_FREE_DESC_CNT) {
- return 1;
- }
+
+ spin_lock_irq(>lock);
/* transmit this packet */
txptr = db->tx_insert_ptr;
memcpy((char *) txptr->tx_buf_ptr, (char *) skb->data, skb->len);
- txptr->tdes1 = 0xe100 | skb->len;
+ if (--pkt_num == 0)
+ {
+ txptr->tdes1 = 0xe100 | skb->len;
+ pkt_num = TX_IRQ_THR;
+ }
+ else
+ txptr->tdes1 = 0x6100 | skb->len;
+
+ /* Transmit Packet Process */
+ txptr->tdes0 = 0x8000; /* set owner bit to DM910X */
+ outl(0x1, dev->base_addr + DCR1); /* Issue Tx polling comand */
+ dev->trans_start = jiffies; /* saved the time stamp */
/* Point to next transmit free descriptor */
- db->tx_insert_ptr = (struct tx_desc *) txptr->next_tx_desc;
+ txptr = (struct tx_desc *)txptr->next_tx_desc;
- /* Transmit Packet Process */
- if (db->tx_packet_cnt < TX_MAX_SEND_CNT) {
- txptr->tdes0 = 0x8000; /* set owner bit to DM910X */
- db->tx_packet_cnt++;/* Ready to send count */
- outl(0x1, dev->base_addr + DCR1); /* Issue Tx polling comand */
- } else {
- db->tx_queue_cnt++; /* queue the tx packet */
- outl(0x1, dev->base_addr + DCR1); /* Issue Tx polling comand */
- }
+ if (txptr->tdes0 & 0x8000)
+ netif_stop_queue(dev);
- /* Tx resource check */
- if (db->tx_packet_cnt < TX_FREE_DESC_CNT)
- netif_wake_queue(dev);
+ db->tx_insert_ptr = txptr;
+ db->tx_live_cnt++;
+
+ spin_unlock_irq(>lock);
/* free this SKB */
dev_kfree_skb(skb);
+
return 0;
}
@@ -713,12 +714,14 @@
outl(0, ioaddr + DCR7); /* disable all interrupt */
return;
}
+
+ spin_lock(>lock);
+
/* Free the transmitted descriptor */
txptr = db->tx_remove_ptr;
- while (db->tx_packet_cnt) {
+ while (db->tx_live_cnt > 0 && (txptr->tdes0 & 0x8000) == 0)
+ {
/* printk("tdes0=%x\n", txptr->tdes0); */
-
Re: EJECT ioctl fails on empty SCSI CD-ROM
On Wed, 15 Nov 2000, James Stevenson wrote:
>
> Hi
>
> this is what i get on 2.2.17
>
> open("/dev/scd1", O_RDONLY|O_NONBLOCK) = 3
> ioctl(3, CDROMEJECT, 0xbc78)= 0
> close(3)= 0
>
>
>
> In local.linux-kernel-list, you wrote:
> >Apparently using the CDROMEJECT ioctl with kernel 2.4-testX fails on
> >a SCSI CD-ROM that does not have a disc in it. The errno returned
> >corresponds to the string ``No such file or directory.''
> >
> >The Linux CD-ROM Standard states that CDROMEJECT opens the drive tray.
> >It does not mention any prerequisite such as media being present.
> >
> >Is this the expected behavior? If so, I am curious to hear the rationale
> >behind it.
>
Well the open fails with ENOMEDIUM (errno 123). This is hardly appropriate
since you can't insert any "media" on some machines without a paperclip.
readlink("/dev/cdrom", "", 256) = 9
open("/dev/scd0", O_RDONLY) = -1 ERRNO_123 (errno 123)
Cheers,
Dick Johnson
Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: test11-pre5 breaks vmware
Followup to: <[EMAIL PROTECTED]> By author:Scott Murray <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > > > Oh. I did not compiled 11-test5, as G450 finally arrived ;-) OK, > > I'll release patch for vmware, as I cannot stop kernel developers > > from changing field names :-) > > Actually, I know of at least one other shipping commercial product > (Sitraka's JProbe Java Profiler) that will require patching because of > this change. It seems unwise to be changing field names in commonly > used /proc files like cpuinfo at this point in time. > The problem with "flags" is that it no longer contains quite the same information. Since the semantics of the field changed slightly, changing the field name is sometimes more correct. Also, if a piece of software needs raw CPUID information (unlike the "cooked" one provided by recent kernels) it should use /dev/cpu/*/cpuid. -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] Please read the FAQ at http://www.tux.org/lkml/
test11-pre5, Athlon, and Machine Check Architecture
Hi friends, I noticed a slight bug in my CPUID 2.4.0-test11-pre5, and when I unwound it, found some interesting things. This relates to the Machine Check Architecture code (bluesmoke.c), which in the previous code was conditionalized on running on an Intel CPU. It appears that that shouldn't be necessary. However, since at least AMD Athlon actually advertises MCA, I would like to verify that the code works on these processors before submitting it to Linus. Most importantly, of course, that it doesn't crash; I don't expect anyone to actually see an #MF exception in real life. I'm trying to get confirmation from AMD that the code should be correct even for Athlon. If it *doesn't* work, there are two possibilities: a) Athlon is advertising a capability it doesn't have, or implements incorrectly. This can be handled in setup.c as an Athlon bug. b) Athlon is implementing a by-the-(Intel-)book correct version of MCA that still differs in the details from Intel, and the code isn't handling that correctly. This would be a bluesmoke.c bug and should be fixed there. So I would really appreciate if Athlon-equipped people would test this patch (against 2.4.0-test11-pre5), and also if there are AMD people that could comment on their implementation of MCA, I would really appreciate it. In the future, if I get around to it, I might also extend bluesmoke.c to handle the case of a processor which implements MCE but not MCA (in which case you get the exception that something died, but no information about what caused it.) This patch is also available at: ftp://ftp.kernel.org/pub/linux/kernel/people/hpa/cpuid-2.4.0-test11-pre5-1.diff Thanks, -hpa --- include/asm-i386/cpufeature.h.old Wed Nov 15 11:24:21 2000 +++ include/asm-i386/cpufeature.h Wed Nov 15 11:35:10 2000 @@ -20,7 +20,7 @@ #define X86_FEATURE_TSC(0*32+ 4) /* Time Stamp Counter */ #define X86_FEATURE_MSR(0*32+ 5) /* Model-Specific Registers, RDMSR, WRMSR */ #define X86_FEATURE_PAE(0*32+ 6) /* Physical Address Extensions */ -#define X86_FEATURE_MCE(0*32+ 7) /* Machine Check Architecture */ +#define X86_FEATURE_MCE(0*32+ 7) /* Machine Check Exception */ #define X86_FEATURE_CX8(0*32+ 8) /* CMPXCHG8 instruction */ #define X86_FEATURE_APIC (0*32+ 9) /* Onboard APIC */ #define X86_FEATURE_SEP(0*32+11) /* SYSENTER/SYSEXIT */ --- arch/i386/kernel/bluesmoke.c.oldWed Nov 15 11:31:55 2000 +++ arch/i386/kernel/bluesmoke.cWed Nov 15 11:34:21 2000 @@ -72,10 +72,12 @@ int i; static int done; - if( c->x86_vendor != X86_VENDOR_INTEL ) - return; - - if( !test_bit(X86_FEATURE_TSC, >x86_capability) ) + /* We should not check for vendor here. The MCA capability + bit, below, should only be set if the CPU has the Intel + Machine Check Architecture (it's up to identify_cpu() to + make sure that is true! */ + + if( !test_bit(X86_FEATURE_MCE, >x86_capability) ) return; if( !test_bit(X86_FEATURE_MCA, >x86_capability) ) --- arch/i386/kernel/setup.c.oldWed Nov 15 11:24:19 2000 +++ arch/i386/kernel/setup.cWed Nov 15 11:37:38 2000 @@ -1483,7 +1483,6 @@ #ifndef CONFIG_M686 static int f00f_workaround_enabled = 0; #endif - extern void mcheck_init(struct cpuinfo_x86 *c); char *p = NULL; #ifndef CONFIG_M686 @@ -1575,9 +1574,6 @@ if ( p ) strcpy(c->x86_model_id, p); - - /* Enable MCA if available */ - mcheck_init(c); } void __init get_cpu_vendor(struct cpuinfo_x86 *c) @@ -1797,6 +1793,8 @@ return have_cpuid_p(); /* Check to see if CPUID now enabled? */ } +extern void mcheck_init(struct cpuinfo_x86 *c); + /* * This does the hard work of actually picking apart the CPU stuff... */ @@ -1919,6 +1917,9 @@ * The vendor-specific functions might have changed features. Now * we do "generic changes." */ + + /* Enable Machine Check Architecture if appropriate */ + mcheck_init(c); /* TSC disabled? */ #ifdef CONFIG_TSC -- <[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] Please read the FAQ at http://www.tux.org/lkml/
Re: EJECT ioctl fails on empty SCSI CD-ROM
Hi
this is what i get on 2.2.17
open("/dev/scd1", O_RDONLY|O_NONBLOCK) = 3
ioctl(3, CDROMEJECT, 0xbc78)= 0
close(3)= 0
In local.linux-kernel-list, you wrote:
>Apparently using the CDROMEJECT ioctl with kernel 2.4-testX fails on
>a SCSI CD-ROM that does not have a disc in it. The errno returned
>corresponds to the string ``No such file or directory.''
>
>The Linux CD-ROM Standard states that CDROMEJECT opens the drive tray.
>It does not mention any prerequisite such as media being present.
>
>Is this the expected behavior? If so, I am curious to hear the rationale
>behind it.
--
-
Check Out: http://stev.org
E-Mail: [EMAIL PROTECTED]
8:00pm up 32 days, 7:56, 5 users, load average: 0.17, 0.53, 0.29
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: test11-pre5 breaks vmware
On Wed, 15 Nov 2000, Petr Vandrovec wrote: > On 15 Nov 00 at 1:59, Tigran Aivazian wrote: > > > You probably noticed this already but I just wanted to bring it to your > > attention that /usr/bin/vmware-config.pl script needs updating since the > > flags in /proc/cpuinfo is now called "features" so it otherwise fails > > complaining that my 2xP6 has no tsc. Trivial change but still worthy of > > propagating into your latest .tar.gz file for 2.4.x > > Oh. I did not compiled 11-test5, as G450 finally arrived ;-) OK, > I'll release patch for vmware, as I cannot stop kernel developers > from changing field names :-) Actually, I know of at least one other shipping commercial product (Sitraka's JProbe Java Profiler) that will require patching because of this change. It seems unwise to be changing field names in commonly used /proc files like cpuinfo at this point in time. Scott -- = Scott Murrayemail: [EMAIL PROTECTED] http://www.interlog.com/~scottm ICQ: 10602428 - "Good, bad ... I'm the guy with the gun." - Ash, "Army of Darkness" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[BUG?] AMD 5x86 and 2.4 (was Re: [BUG?] AMD K5 and 2.4)
It looks like I was mistaken in my original message. I have an AMD 5x86, not a K5. Nevertheless, menuconfig lists the 586 option as "586/K5/5x86/6x86/6x86MX". But, it fails to boot on my 5x86 and I have to compile for a 486 (for 2.4). As I mentioned in my previous message, the 586/... option boots with 2.2. I just noticed that, under both 2.2 and 2.4, uname -a identifies the machine as an i486. Should the 486 option be changed to "486/5x86" and the 586/... option changed to "586/K5/6x86/6x86MX"? Or is there a bug here that needs fixing? (IIRC, Cyrix and IBM made 5x86's as well - are those more like fast 486's or slow Pentiums? I don't remember. If they're like Pentiums, perhaps "486/AMD 5x86" and "586/non-AMD 5x86/6x86/6x86MX"...?) -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] Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Hard lockup using emu10k1-based sound card
On Wed, 15 Nov 2000, Jonathan Corbet wrote: > Just as another data point, I, too, had trouble with lockups with the > emu10k1 (with the 2.4.0-test driver and ALSA both). I noticed that it was > sharing an interrupt with ACPI. As soon as I rebuilt the kernel with the > ACPI Interpreter option turned off, the problem went away. In my case, the emu10k1 has an IRQ all to itself... (and I don't have ACPI enabled). Been running the kernel emu10k1 on test11-pre5 since this morning. I've only had one lockup (older testX emu10k1's locked up more frequently). So there still appears to be a problem with (or triggered by) test11-pre5 emu10k1. As I was under X at that stage (XMMS & two xterms), I did not see any panic()'s or BUG()'s. Next I'm going to compile with serial console & see if I can see any panic() or BUG()s. -- Hans. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Hard lockup using emu10k1-based sound card
Just as another data point, I, too, had trouble with lockups with the emu10k1 (with the 2.4.0-test driver and ALSA both). I noticed that it was sharing an interrupt with ACPI. As soon as I rebuilt the kernel with the ACPI Interpreter option turned off, the problem went away. It's not the first time I've gotten burned with the "turn on some option because I might want to mess with it someday" approach to kernel configuration... jon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
BUG: isofs broken (2.2 and 2.4)
Hi, both 2.2.x and 2.4.x kernels can't read `real sky' CDs from the Space Telescope Science Institute containing lotsof directories (~100) which each contain lots of small files (~700 files/dir). only ~10 directories with ~10 files each are displayed, all the other files/diretories can't be accessed. the kernel gives the following message: next_offset (212) > bufsize (200) and with 2.2.x kernels I additionally get Invalid session number or type of track at mount time (that's the 2nd instance of this message, i == -22 (RTFS)). you can find an isofs image for testing (only directory part, no real data, compressed ~620kb) on http://www.tat.physik.uni-tuebingen.de/~koenig/buggy_fs.iso.gz any idea/patch/fix ? thanks, Harald PS: I'm not subscribed to linux-kernel right now, so please reply directly using Cc:. thanks! -- All SCSI disks will from now on ___ _ be required to send an email notice0--,|/OOO\ 24 hours prior to complete hardware failure! <_/ / /OOO\ \ \/OOO\ \ O|// Harald Koenig, \/\/\/\/\/\/\/\/\/ Inst.f.Theoret.Astrophysik // / \\ \ [EMAIL PROTECTED] ^ ^ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: keyboard lockup after kdb session
Hi, I have the same problem with kdb. In a controlled environment, I always start a script before entering kdb: while [ 1 ] ; do sleep 3 /etc/rc.d/init.d/gpm restart > /dev/null done This will re-enable the kbd every 3 seconds. But it would be nice to find the problem, eh? ~Randy_ |randy.dunlap_at_intel.com503-677-5408| |NOTE: Any views presented here are mine alone| |& may not represent the views of my employer.| --- > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, November 15, 2000 4:51 AM > To: [EMAIL PROTECTED] > Subject: keyboard lockup after kdb session > > > Hi, > I am new to kdb. my keyboard is locked after kdb-session (either by > generating oops or manual). > is there any way to restore it without rebooting... > thanks > anil > > > - > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in > the body of a message to [EMAIL PROTECTED] > 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] Please read the FAQ at http://www.tux.org/lkml/
stop e mails
dear, if possible, could you please stop sensding the e mails concerning the linux... . As my father died a sudden death on the 2 oktober 2000. thanks - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
JIT/JRE
Hi, I have a redhat 7.0 and I need to compile some codes. I need to use JIT (just in time) compiler and JRE on this redhat box. How do i know if have these on my system?. Or the installl CD for the RH7.0 may have it... J _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)
[EMAIL PROTECTED] wrote: > > Well, not necessarily so while lkcd is not get accepted into the standard > > kernel source. [..] > > It won't until it uses a separate driver that doesn't depend on scsi or > ide layer. We're working on it ... can't quit my day job, you know ... :) --Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Newbie
Not even Intel can spell kernal [sic] - see 486 Programmer's reference - description of protection mechanism. BTW one of the enhancements to the Pentium was an improvement in the spelling of kernel. :-) Richard Moore - RAS Project Lead - Linux Technology Centre (PISC). http://oss.software.ibm.com/developerworks/opensource/linux Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183 IBM UK Ltd, MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
EJECT ioctl fails on empty SCSI CD-ROM
Apparently using the CDROMEJECT ioctl with kernel 2.4-testX fails on a SCSI CD-ROM that does not have a disc in it. The errno returned corresponds to the string ``No such file or directory.'' The Linux CD-ROM Standard states that CDROMEJECT opens the drive tray. It does not mention any prerequisite such as media being present. Is this the expected behavior? If so, I am curious to hear the rationale behind it. Thanks! -- W. Michael Petullo :wq - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
CONFIG_USB_HOTPLUG (was Patch(?): linux-2.4.0-test11-pre4/drivers/sound/yss225.c compile failure)
>From [EMAIL PROTECTED] Wed Nov 15 09:04:36 2000
>> From: Jeff Garzik [mailto:[EMAIL PROTECTED]]
>>
>> Greg KH wrote:
>> > On Wed, Nov 15, 2000 at 12:29:15AM -0500, Jeff Garzik wrote:
>> > > If we are going to create CONFIG_USB_HOTPLUG, we must -eliminate-
>> > > CONFIG_HOTPLUG, and create CONFIG_PCI_HOTPLUG, and
>> > > CONFIG_ANOTHERBUS_HOTPLUG and so on, for each hotplug bus.
>> >
>> > Argh!
>> > I thought the whole point of this was to make there be only
>> one hotplug
>> > strategy, due to the fact that this is a real need.
>> >
>> > Please let's not go down this path. It was all starting to look so
>> > nice...
>>
>> I -want- there to be only one hotplug strategy, but Adam seemed to be
>> talking about the opposite, with his CONFIG_USB_HOTPLUG suggestion.
>I told Adam that I didn't want that patch, but it's not
>up to me now.
You said you wanted to "hold of on CONFIG_USB_HOTPLUG for now",
which I take to mean up to 2.4.0.
I have not asked that CONFIG_USB_HOTPLUG be put in 2.4.0, although
I would not mind. I am just agreeing with you (Randy) when you
identified the problem and wrote in linux-usb-devel "[Why] is it safe to
use __devinitdata on the usb_device_id table? It's used during any new
device connect, after driver init, right ...?" You were right: the
__devinitdata being used in the USB drivers will probably crash the
kernel if CONFIG_HOTPLUG is not defined and the USB code attempts to
recover from an error by faking disconnect/reconnect.
The statements about how we might address this issue more
fully have been about in the context of after 2.4.0. To refresh your
memory, in my first message on this thread I wrote:
|After 2.4.0, and after the fake disconnect/reconnect code in
^^^
| drivers/usb/{devio,storage/scsiglue}.c is designed out, then we may
| want to explore adding __usbdevinit{,data} defines in include/linux/init.h
| that would be controlled by a new CONFIG_USB_HOTPLUG option, as in
| the patches that I posted for this to linux-usb-devel.
Until there is __usbdev{init,exit}{,data}, the incorrect
__devinitdata qualifiers should be removed from the USB device
drivers (but not from the host controller drivers, which are PCI drivers).
Would you like to propose a different solution, Randy?
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
RE: Patch(?): linux-2.4.0-test11-pre4/drivers/sound/yss225.c compilefailure
> From: Jeff Garzik [mailto:[EMAIL PROTECTED]] > > Greg KH wrote: > > On Wed, Nov 15, 2000 at 12:29:15AM -0500, Jeff Garzik wrote: > > > If we are going to create CONFIG_USB_HOTPLUG, we must -eliminate- > > > CONFIG_HOTPLUG, and create CONFIG_PCI_HOTPLUG, and > > > CONFIG_ANOTHERBUS_HOTPLUG and so on, for each hotplug bus. > > > > Argh! > > I thought the whole point of this was to make there be only > one hotplug > > strategy, due to the fact that this is a real need. > > > > Please let's not go down this path. It was all starting to look so > > nice... > > I -want- there to be only one hotplug strategy, but Adam seemed to be > talking about the opposite, with his CONFIG_USB_HOTPLUG suggestion. I told Adam that I didn't want that patch, but it's not up to me now. > I'm hoping that Linus will disagree with the splintering of > CONFIG_HOTPLUG too... And JE. > I think it's too late in 2.4.x cycle to change now anyway. And I told Adam that also. > Jeff ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test11-pre5 breaks vmware
On 15 Nov 00 at 17:47, Petr Vandrovec wrote: > On 15 Nov 00 at 1:59, Tigran Aivazian wrote: > > > You probably noticed this already but I just wanted to bring it to your > > attention that /usr/bin/vmware-config.pl script needs updating since the > > flags in /proc/cpuinfo is now called "features" so it otherwise fails > > complaining that my 2xP6 has no tsc. Trivial change but still worthy of > > propagating into your latest .tar.gz file for 2.4.x > > Oh. I did not compiled 11-test5, as G450 finally arrived ;-) OK, ^ Matrox G450 for innocents > I'll release patch for vmware, as I cannot stop kernel developers > from changing field names :-) Petr Vandrovec [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
