Re: changing mm->mmap_sem (was: Re: system call for processinformation?)
On Fri, 16 Mar 2001, Stephen C. Tweedie wrote: > Right, I'm not suggesting removing that: making the mmap_sem > read/write is fine, but yes, we still need that semaphore. Initial patch (against 2.4.2-ac20) is available at http://www.surriel.com/patches/ > But as for the "page faults would use an extra lock to protect against > each other" bit --- we already have another lock, the page table lock, > which can be used in this way, so ANOTHER lock should be unnecessary. Tomorrow I'll take a look at the various ->nopage functions and do_swap_page to see if these functions would be able to take simultaneous faults at the same address (from multiple threads). If not, either we'll need to modify these functions, or we could add a (few?) extra lock to prevent these functions from faulting at the same address at the same time in multiple threads. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CML2 0.9.4 is available
The latest version is always available at http://www.tuxedo.org/~esr/cml2/ Release 0.9.4: Sun Mar 18 01:48:12 EST 2001 * Move to hand-rolled LL parser for increased compilation speed. * Compile numbers as numbers (solves Giacomo's 0.9.3 bug). The compilation-speed improvement is pretty dramatic -- factor of two. As a happy side effect, this change cuts the line count of CML2 by about 500 lines; the whole system is now 4874 lines of Python code. The rules file in this version is current to 2.4.2. -- http://www.tuxedo.org/~esr/">Eric S. Raymond The two pillars of `political correctness' are, a) willful ignorance, and b) a steadfast refusal to face the truth -- George MacDonald Fraser - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.x on netpliance i-opener
I am having difficulty booting 2.4-based Linux kernels on my
Netpliance I-Opener. The Linux 2.4 TODO list has the following entry:
IDE fails on some VIA boards (eg the i-opener) (reported fixed by Konrad
Stepien)
This issue is not really "fixed" as reported in the TODO. Mr. Stepien
has indicated to me in e-mail that his problem went away on a
non-i-opener motherboard with a VIA chipset when he upgraded to 2.4.0.
There is a long history of this issue. There was a patch posted to
the linux-kernel mailing list that allegedly solved the problem:
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0009.3/1218.html
This patch was reposted here:
http://boudicca.tux.org/hypermail/linux-kernel/2000week51/0317.html
The patch fixes a bug in the way the IDE probing code handles flash
disks. The bug occurs when there is one (and only one) hard disk
attached to the IDE connector on the I-Opener motherboard.
Here is what happens when I boot 2.4.2 without the patch:
...
VP_IDE: ide controller on pci bus 00 dev 39
VP_IDE: chipset revsion 6
VP_IDE: not 100% native mode: will probe irqs later
hda: ibm-dyka-22160, ata disk drive
hdb: sundisk sdtb-128, ata disk drive
hdb: set_drive_speed_status: status 0x51 { driveready seekcomplete error }
hdb: set_drive_speed_status: error=0x04 { DriveStatusError}
ide0: Drive 1 didn't accept speed setting. Oh, well.
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdb: 31360 sectors (16 MB) w/1KiB Cache, CHS=490/2/32
Partition check:
hdb: hdb1 hdb2 hdb3 hdb4
floppy0: no floppy controllers found
...
VFS: Cannot open root device "301" or 03:01
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 03:01
... and here is what happens when I boot it *with* the patch:
...
VP_IDE: ide controller on pci bus 00 dev 39
VP_IDE: chipset revsion 6
VP_IDE: not 100% native mode: will probe irqs later
hda: ibm-dyka-22160, ata disk drive
hdb: sundisk sdtb-128, ata disk drive
hdb: set_drive_speed_status: status 0x51 { driveready seekcomplete error }
hdb: set_drive_speed_status: error=0x04 { DriveStatusError}
ide0: Drive 1 didn't accept speed setting. Oh, well.
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: 4233600 sectors (2168 MB) w/90KiB Cache, CHS=525/128/63, UDMA(33)
hdb: 31360 sectors (16 MB) w/1KiB Cache, CHS=490/2/32
Partition check:
hda: hda1 hda2
hdb: hdb1 hdb2 hdb3 hdb4
floppy0: no floppy controllers found
...
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 176k freed
You'll notice that the kernel sees hda's geometry and partitions after
the patch is applied, but I am still unable to get my i-opener to
boot. I have tried the following kernels to no avail: 2.2.16, 2.4.0,
2.4.1, 2.4.2, 2.4.3pre3. My installation method was to install Redhat
7.0 and upgrade my kernel to 2.4.x. Yes, I got the latest modutils.
I have tried the following LILO parameters without success:
hdb=noprobe
hdb=flash
hdb=none
hdb=noprobe
After doing a little debugging with the patch enabled, it appears as
if the execve("/sbin/init") in main.c's init() is never succeeding. I
tried passing "init=/bin/sh" to LILO and I still get the "silent
hang".
Note: all of the above kernels *will* boot when I plug the harddisk
into my ATX clone machine, but they won't boot on my i-opener. I
*have* been successful in getting the i-opener to boot when I use an
old 2.0.35 kernel. But I need USB mass storage to turn my box into an
MP3 player, so I need a 2.4 kernel. So the problem is not the
harddisk because it boots in other computers, and it's not the BIOS
because I can boot older 2.0 kernels. I am hypothesizing the problem
is at the driver/filesystem layer.
There are many people in the same predicament as I am. The i-opener
newsgroups are littered with people who are unable to get 2.4-based
kernels to boot on their machines. Any help would be appreciated.
_
Get your FREE download of MSN Explorer at http://explorer.msn.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
What's a return stack worth?
These are the occurance counts of the 256 byte values in a big monolithic stripped 2.4.0 UP 386 vmlinux. 1/256 is .39% . countdec hex octal/ascii % possible meaning 334170 0 0 [ 0]17.05%ADD 63889 255ff [377] 3.26%2-byte escape 635363624 $ 3.24%AND with AL 52652 1398b [213] 2.68%MOV 50862 192c0 [300] 2.59%2 byte escape 44628 13183 [203] 2.27%2-byte escape 42419 13789 [211] 2.16%MOV 39630 11674 t 2.02%JZ 378323220 1.93%AND 27742 1 1 [ 1] 1.41%ADD 22879 4 4 [ 4] 1.16%ADD with AL 22307 232e8 [350] 1.13%CALL 21945 196c4 [304] 1.11%LES 217696844 D 1.11%INC eSP 19960 10266 f 1.01%other operand size prefix 19793 8 8 [ 10] 1.01%OR 1921215 f [ 17] .98%2-byte escape 18234 11775 u .93%JNZ 17335 10165 e .88%GS prefix 17204 1418d [215] .87%LEA 170661610 [ 20] .87%ADC 16673 13385 [205] .85%TEST 1466612 c [ 14] .74%OR with AL 13710 11573 s .69%JNB 13642 195c3 [303] .69%RET near 13293 246f6 [366] .67%2-byte escape 131038353 S .66%PUSHeBX 12969 10064 d .66%FS prefix 12895 10468 h .65%PUSH immediate 12820 2 2 [ 2] .65%ADD 125253725 % .63%AND with eAX 124122014 [ 24] .63%ADC with AL 11661 11472 r .59%JB 116198050 P .59%PUSHeAX 10791 12880 [200] .55%2-byte escape 107766743 C .54%INC eBX 10702 199c7 [307] .54%MOV 10640 1116f o .54%OUTSW/D 105772418 [ 30] .53%SBB 10546 1247c | .53%JL 10517 10569 i .53%IMUL 10256955f _ .52%POP eDI 100738454 T .51%PUSHeSP 10055 1106e n .51%OUTSB 9965 11876 v .50%JBE 98129761 a .50%POPA 96674028 ( .49%SUB 94354931 1 .48%XOR 9410764c L .48%DEC eSP 9304 1086c l .47%INSB 9277 3 3 [ 3] .47%ADD 89886440 @ .45%INC eAX 8922915b [ .45%POP eBX 8903 193c1 [301] .45%2 byte escape 8638 13284 [204] .44%TEST 8580 14490 [220] .43%NOP 84238656 V .42%PUSHeSI 84224830 0 .42%XOR 8417 5 5 [ 5] .42%ADD with eAX 8267281c [ 34] .42%SBB with AL 8116 235eb [353] .41%JNP 7963462e . .40%CS prefix 7882945e ^ .40%POP eSI 78569963 c .40%ARPL 7723 13688 [210] .39%MOV 76674129 ) .39%SUB 740410 a [ 12] .37%OR 7226 11270 p .36%JO 7220 12981 [201] .36%2-byte escape 68185739 9 .34%CMP 6732 1388a [212] .34%MOV 6680 194c2 [302] .34%RET near with stacked data 6518442c , .33%SUB with AL 6509925c \ .33%POP eSP 6363 184b8 [270] .32%MOV immediate 6246 224e0 [340] .31%LOOPNE 61398555 U .31%PUSHeBP 6117422a * .31%SUB 60018757 W .30%PUSHeDI 5937 254fe [376] .30%INC/DEC 5839 1066a j .29%PUSH immediate 5829 7 7 [ 7] .29%POP ES 5703 182b6 [266] .29%MOV immediate 5654 198c6 [306] .28%MOV 555370
[2.4.3-pre4] comparing eepro100 & e100
Hi, I'm setting up a new server with Intel 82559 LOM (733470-066), this is ASUS CUR-DLS. While testing the NIC performance with eepro100 driver, I was getting those famous "card reports no resources" and "too much work in interrupt". The perfomance test was actually a "ping -f -s 65507" from another host (both hosts are in 100baseTX-FD IBM switch) and some other program doing basicly the same. I played around with module parameters but had no luck. So I've had to try the Intel supplied driver *e100-1.5.5a*. ftp://download.intel.com/df-support/2250/eng/e100-1.5.5a.tar.gz And it works just rock&solid - no problems at all. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] /proc/uptime on SMP machines
The patch works on 2.2.19pre17. The second machine (asus) has Uwe's patch modified for 2.2. The machine 'smp' is not patched. rgds, tim. [tim@smp ~]# cat /proc/uptime ; cat /proc/stat | grep cpu ; yes > /dev/null & ; sleep 180 ; killall yes ; cat /proc/uptime ; cat /proc/stat | grep cpu [2] 1485 22689.88 21324.40 cpu 175685 0 32321 4329972 cpu0 121396 0 15195 2132398 cpu1 54289 0 17126 2197574 Terminated 22869.90 21324.40 cpu 193551 0 33066 4347365 cpu0 139179 0 15414 2132398 cpu1 54372 0 17652 2214967 [2] - Exit 143 ( cat /proc/uptime; cat /proc/stat | grep cpu; yes > /dev/null ) [tim@asus ~]# date ; cat /proc/uptime ; cat /proc/stat | grep cpu ; yes > /dev/null & ; sleep 180 ; killall yes ; cat /proc/uptime ; cat /proc/stat | grep cpu [1] 870 Sat Mar 17 20:41:49 PST 2001 3260.19 2337.13 cpu 174676 0 9849 467515 cpu0 90385 0 4666 230969 cpu1 84291 0 5183 236546 Terminated 3440.20 2424.73 cpu 192352 0 10656 485034 cpu0 108059 0 4992 230970 cpu1 84293 0 5664 254064 [1] + Exit 143 ( date; cat /proc/uptime; cat /proc/stat | grep cpu; yes > /dev/null ) [tim@asus ~]# cat /proc/version Linux version 2.2.19pre17 (root@asus) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #5 SMP Sat Mar 17 19:44:42 PST 2001 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: ksymoops 2.4.1 is available
On Sun, 18 Mar 2001 05:30:54 +0100, Dieter N tzel <[EMAIL PROTECTED]> wrote: >but I can't find it all over the world? >I've looked at au, uk, us, fi, de, ... There is something wrong with the kernel.org mirror system. ftpadmin has been notified. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: ksymoops 2.4.1 is available
Sorry, Keith, but I can't find it all over the world? I've looked at au, uk, us, fi, de, ... Thanks, Dieter -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[CHECKER] blocking w/ spinlock or interrupt's disabled
> enclosed are 163 potential bugs in 2.4.1 where blocking functions are > called with either interrupts disabled or a spin lock held. The > checker works by: Here's the file manifest. Apologies. drivers/atm/idt77105.c drivers/atm/iphase.c drivers/atm/uPD98402.c drivers/block/cciss.c drivers/block/cpqarray.c drivers/char/applicom.c drivers/char/cyclades.c drivers/char/epca.c drivers/char/esp.c drivers/char/istallion.c drivers/char/moxa.c drivers/char/mxser.c drivers/char/n_r3964.c drivers/char/rio/rioctrl.c drivers/char/rio/riotable.c drivers/char/rio/riotty.c drivers/char/riscom8.c drivers/char/serial.c drivers/char/specialix.c drivers/i2o/i2o_proc.c drivers/ide/ide-probe.c drivers/ide/umc8672.c drivers/isdn/act2000/act2000_isa.c drivers/isdn/hisax/gazel.c drivers/isdn/icn/icn.c drivers/isdn/isdnloop/isdnloop.c drivers/md/raid1.c drivers/net/aironet4500_core.c drivers/net/depca.c drivers/net/irda/irport.c drivers/net/irda/irtty.c drivers/net/irda/smc-ircc.c drivers/net/pcmcia/netwave_cs.c drivers/net/ppp_generic.c drivers/net/wan/comx-hw-locomx.c drivers/net/wan/comx-hw-mixcom.c drivers/net/wan/comx.c drivers/net/wan/lmc/lmc_main.c drivers/scsi/aha1542.c drivers/scsi/atp870u.c drivers/scsi/psi240i.c drivers/scsi/sym53c416.c drivers/scsi/tmscsim.c drivers/sound/cmpci.c drivers/sound/emu10k1/audio.c drivers/sound/emu10k1/midi.c drivers/sound/midibuf.c drivers/sound/nm256_audio.c drivers/sound/sb_ess.c drivers/sound/sequencer.c drivers/usb/serial/empeg.c drivers/usb/serial/keyspan_pda.c drivers/usb/serial/mct_u232.c drivers/usb/serial/omninet.c drivers/usb/serial/usbserial.c fs/hfs/catalog.c net/bridge/br_if.c net/irda/ircomm/ircomm_tty.c - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] /proc/uptime on SMP machines
> Same for 2.2.19p17
except that init_tasks is a 2.4 struc. Corrected as below.
rgds,
tim
--- 2.2.19pre17/fs/proc/array.c.old Fri Mar 16 04:09:41 2001
+++ 2.2.19pre17/fs/proc/array.c.idleSat Mar 17 19:35:36 2001
@@ -339,9 +339,16 @@
{
unsigned long uptime;
unsigned long idle;
+ int i;
uptime = jiffies;
+#ifdef CONFIG_SMP
+ for (idle =0,i = 0; i < smp_num_cpus; i++)
+ idle += (task[i]->times.tms_utime +
+ task[i]->times.tms_stime)/smp_num_cpus;
+#else
idle = task[0]->times.tms_utime + task[0]->times.tms_stime;
+#endif
/* The formula for the fraction parts really is ((t * 100) / HZ) % 100, but
that would overflow about every five days at HZ == 100.
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] /proc/uptime on SMP machines
> At present the idle value in /proc/uptime is only the idle time for the first
> processor. With 2.4, processes seam "stickier" for my, and e.g "yes
> >/dev/null" on an otherwise idle machine can stay for a long time on one
> processor of my (intel) SMP machine. That way, the present output of
> /proc/uptime can lead to a wrong conclusion.
Same for 2.2.19p17
[tim@smp ~]# cat /proc/uptime
19262.25 18487.44
[tim@smp ~]# cat /proc/stat | grep cpu
cpu 108661 0 24741 3719438
cpu0 65697 0 11814 1848909
cpu1 42964 0 12927 1870529
--- 2.2.19pre17/fs/proc/array.c Fri Mar 16 04:09:41 2001
+++ 2.2.19pre17/fs/proc/array.c.idleSat Mar 17 19:20:22 2001
@@ -339,9 +339,16 @@
{
unsigned long uptime;
unsigned long idle;
+ int i;
uptime = jiffies;
+#ifdef CONFIG_SMP
+ for (idle =0,i = 0; i < smp_num_cpus; i++)
+ idle += (init_tasks[i]->times.tms_utime +
+ init_tasks[i]->times.tms_stime)/smp_num_cpus;
+#else
idle = task[0]->times.tms_utime + task[0]->times.tms_stime;
+#endif
/* The formula for the fraction parts really is ((t * 100) / HZ)
% 100, but
that would overflow about every five days at HZ == 100.
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: USB Mouse Problem in 2.4 Kernels - 2.2.18 Works Fine
> From: Andree Leidenfrost ([EMAIL PROTECTED]) > I am experiencing problems with a USB mouse: The machine boots, X > starts, I log on, everything works as expected. When I restart X or just > change to an alpha terminal and back to x the mouse does not work any > more. [...] > Hardware is an ASUS K7V motherboard (VIA chip set), [...] > T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 5 Spd=1.5 MxCh= 0 I am working on something similar. After a device reset a hub drops PORT_CONNECTION flag from wPortStatus. The reason is unknown. Unfortunately, I do not have a hardware that exibits this. If would be invaluable someone enabled dbg() in devices/usb/hub.c only, run the test with BOTH working (2.2) and not working (2.4) kernels then sent me dmesg. If you do, please tell me precisely what you were doing to trip this. Here is an example of a change: --- linux-2.4.2-0.1.19/drivers/usb/hub.cTue Mar 13 12:04:05 2001 +++ linux-2.4.2-0.1.19-p3/drivers/usb/hub.c Tue Mar 13 13:49:32 2001 @@ -29,6 +29,10 @@ #include "hub.h" +/* P3 #23670 run01 */ +#undef dbg +#define dbg(format, arg...) printk(KERN_DEBUG __FILE__ ": " format "\n" , ## arg) + /* Wakes up khubd */ static spinlock_t hub_event_lock = SPIN_LOCK_UNLOCKED; static DECLARE_MUTEX(usb_address0_sem); Example output of broken kernel: ub.c: enabling power on all ports hub.c: port 1 connection change hub.c: port 1, portstatus 301, change 1, 1.5 Mb/s hub.c: port 1, portstatus 303, change 0, 1.5 Mb/s hub.c: USB new device connect on bus1/1, assigned device number 2 usb.c: USB device 2 (vend/prod 0x458/0x3) is not claimed by any active driver. usb.c: registered new driver hid input0: USB HID v1.00 Mouse [KYE Genius USB Wheel Mouse] on usb1:2.0 mouse0: PS/2 mouse device for input0 mice: PS/2 mouse device common for all mice [ok, works, pulling the cable] hub.c: port 1 connection change hub.c: port 1, portstatus 100, change 3, 12 Mb/s usb.c: USB disconnect on device 2 hub.c: port 1 enable change, status 100 [cable pulled, putting it back] hub.c: port 1 connection change hub.c: port 1, portstatus 301, change 1, 1.5 Mb/s hub.c: port 1, portstatus 100, change 0, 12 Mb/s hub.c: port 1 of hub 1 not enabled, trying reset again... hub.c: port 1, portstatus 100, change 0, 12 Mb/s hub.c: port 1 of hub 1 not enabled, trying reset again... hub.c: port 1, portstatus 100, change 0, 12 Mb/s hub.c: port 1 of hub 1 not enabled, trying reset again... hub.c: port 1, portstatus 100, change 0, 12 Mb/s hub.c: port 1 of hub 1 not enabled, trying reset again... hub.c: port 1, portstatus 100, change 0, 12 Mb/s hub.c: port 1 of hub 1 not enabled, trying reset again... hub.c: Cannot enable port 1 of hub 1, disabling port. hub.c: Maybe the USB cable is bad? Now I need something like that for a working kernel on the same hardware. I'll let folks know if I find anything. If anyone wants to investigate in parallel, it would be appreciated too. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IP Alias with 2.2.18?
Marco, Recompile your kernel and select IP: aliasing support under Networking Options Steve On 17 Mar 2001 22:06:44 +0100, Marco Calistri wrote: > My first post on the "top of mailing-list"... > > Is there same IP aliasing support with kernel 2.2.18? > > My eth0:0 doesn't works anymore. > > Thanks! > > -- > Regards,: Marco Calistri <[EMAIL PROTECTED]> > gpg key available on http://www.qsl.net/ik5bcu > Xfmail 1.4.7p2 on linux RedHat 6.2 > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH against 2.4.2: TTY hangup on PPP channel corrupts kernel memory
Paul Mackerras <[EMAIL PROTECTED]> writes: > > But the waiting process must have had an instance of /dev/ppp open and > attached to the channel in order to be doing anything with rwait, > within either ppp_file_read or ppp_poll. The process of attaching to > the channel increases its refcnt, meaning that the channel shouldn't > be destroyed until the instance of /dev/ppp is closed and ppp_release > is called. Ugh... I duplicated the hangs and verified my patch fixed them under kernel 2.4.0 with "pppd" 2.3.11; and I also verified that kernel 2.4.2 with my patch and "pppd" 2.4.0f correctly deferred channel destruction on modem hangup. However, I forget to double-check that the hangs were actually still possible with 2.4.2 and "pppd" 2.4.0f. I didn't realize my specific hang was a peculiarity of the older attachment style. The channel created by pushing the PPP line discipline onto a TTY was connected to a unit with a PPPIOCATTACH ioctl on the TTY---this didn't really "attach" the channel; it still had a refcnt of only one. Through the old compatibility interface, it was possible to call ppp_asynctty_read -> ppp_channel_read -> ppp_read on the channel's "struct ppp_file" and wait on the channel's "rwait". If the modem hung up, "do_tty_hangup" would call "ppp_asynctty_close" (with a reader still in "ppp_asynctty_read") and the "struct channel" would be freed in "ppp_unregister_channel". I think your analysis of how things presently are with 2.4.2 and a modern "pppd" is correct... Since the new "pppd" uses an explicit PPPIOCATTCHAN / PPPIOCCONNECT sequence, the refcnt gets bumped to 2 and stays there while the channel is attached. So, this specific hang isn't a problem anymore for "ppp_async.c". It's still a problem with "ppp_synctty.c", though (when used with "pppd" 2.3.11, say). Is the compatibility stuff in there slated for removal, too? > I presume that the generic file descriptor code ensures that the file > release function doesn't get called while any task is inside the read > or write function for that file, or while the file descriptor is in > use in a select or poll. It's not the file "release" function that's the problem. It's the line discipline's "close" call. On a real hardware hangup, The kernel thread "eventd" calls "do_tty_hangup" which grabs the big kernel lock and calls ppp_asynctty_close. I believe any line discipline or "/dev/ppp" file function that sleeps (and so gives up its big kernel lock) with refcnt == 1 is susceptible to having the "struct channel" pulled out from under it. In particular, the comment above "ppp_asynctty_close" is misleading. It's true that the TTY layer won't call any further line discipline entries while the "close" is executing; however, there may be processes already sleeping in line discipline functions called before the hangup. For example, "ppp_asynctty_close" could be called while we sleep in the "get_user" in "ppp_channel_ioctl" (called from "ppp_asynctty_ioctl"). Therefore, calling "PPPIOCATTACH" on an unattached PPP-disciplined TTY could, in unlikely circumstances (argument swapped out), lead to a crash. In fact, I think the only remaining PPP locking problem in "ppp_async.c" still in 2.4.2 has to do with those PPPIOCATTACH/DETACH ioctls for the TTY. They seem to be the only way someone can reference the "struct channel" of an unattached channel. I assume PPPIOCATTACH (on the TTY) is deprecated in favor of PPPIOCATTCHAN / PPPIOCCONNECT (on the "/dev/ppp" handle). Can we eliminate "ppp_channel_ioctl" from "ppp_async.c" entirely, as in the patch below? We're requiring people to upgrade to "pppd" 2.4.0 anyway, and it has no need for these calls. This would give me a warm, fuzzy feeling. Kevin <[EMAIL PROTECTED]> * * * --- linux-2.4.2/drivers/net/ppp_async.c Sun Mar 4 20:09:19 2001 +++ linux-2.4.2-local/drivers/net/ppp_async.c Sat Mar 17 20:11:45 2001 @@ -244,11 +244,6 @@ err = 0; break; - case PPPIOCATTACH: - case PPPIOCDETACH: - err = ppp_channel_ioctl(&ap->chan, cmd, arg); - break; - default: err = -ENOIOCTLCMD; } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] Secure Attention Key handling
The do_SAK() function is called from within interrupt context. It acquires several process-level spinlocks. This can deadlock. It is fairly trivial for an unprivileged user to deliberately deadlock the kernel of a system which has SAK enabled. So this patch moves do_SAK() into process context. It does a few other things: - Creates some missing tq_struct initialisation macros - In alloc_tty_struct(): once upon a time this function used get_free_page() to allocate the tty_struct. Then Russell King made it use kmalloc() on achines with 16k and 32k page sizes to save a bit of RAM. This patch makes it always use kmalloc(). - The tty_[un]register_devfs() functions are using several kbytes of kernel stack. Jeff has fixed this in UML, so this patch merges those changes in. - The locking rules for task_struct->files.file_lock, task_struct.alloc_lock and tasklist_lock are undocumented and unclear. It is also unclear what some of these locks are actually intended to protect. So I have reviewed the use of these locks and have defined and documented both their locking order, and the things which they are protecting. - The patch instantiates Documentation/SAK.txt, and initialises it with semi-accurate mortonbabble. Comments on the accuracy and completeness of this document would be appreciated. Now, it's pretty obvious that nobody has been testing SAK. It breaks lots of stuff. Pressing the SAK key when using a recent distribution from $(PROMINENT_DISRIBUTOR) instantly kills little things like sshd, httpd, crond, inetd, lpd and sendmail. It also exposes bugs in gpm and vixie cron. Workarounds are described in SAK.txt. My recommendation to distributors is: 1: Test SAK. 2: When launching daemons from within your initscripts, ensure that the daemon's standard input is redirected to /dev/null. 3: Test SAK. Can anyone tell me *why* our SAK implementation doesn't meet C2 requirements? Patch is against 2.4.2-ac20 --- linux-2.4.2-ac20/Documentation/SAK.txt Thu Jan 1 00:00:00 1970 +++ ac/Documentation/SAK.txtSun Mar 18 11:52:13 2001 @@ -0,0 +1,87 @@ +Linux 2.4.2 Secure Attention Key (SAK) handling +18 March 2001, Andrew Morton <[EMAIL PROTECTED]> + +An operating system's Secure Attention Key is a security tool which is +provided as protection against trojan password capturing programs. It +is an undefeatable way of killing all programs which could be +masquerading as login applications. Users need to be taught to enter +this key sequence before they log in to the system. + +From the PC keyboard, Linux has two similar but different ways of +providing SAK. One is the ALT-SYSRQ-K sequence. You shouldn't use +this sequence. It is only available if the kernel was compiled with +sysrq support. + +The proper way of generating a SAK is to define the key sequence using +`loadkeys'. This will work whether or not sysrq support is compiled +into the kernel. + +SAK works correctly when the keyboard is in raw mode. This means that +once defined, SAK will kill a running X server. If the system is in +run level 5, the X server will restart. This is what you want to +happen. + +What key sequence should you use? Well, CTRL-ALT-DEL is used to reboot +the machine. CTRL-ALT-BACKSPACE is magical to the X server. We'll +choose CTRL-ALT-PAUSE. + +In your rc.sysinit (or rc.local) file, add the command + + echo "control alt keycode 101 = SAK" | /bin/loadkeys + +And that's it! Only the superuser may reprogram the SAK key. + + +NOTES += + +1: Linux SAK is said to be not a "true SAK" as is required by + systems which implement C2 level security. This author does not + know why. + + +2: On the PC keyboard, SAK kills all applications which have + /dev/console opened. + + Unfortunately this includes a number of things which you don't + actually want killed. This is because these appliccaitons are + incorrectly holding /dev/console open. Be sure to complain to your + Linux distributor about this! + + You can identify processes which will be killed by SAK with the + command + + # ls -l /proc/[0-9]*/fd/* | grep console + l-wx--1 root root 64 Mar 18 00:46 /proc/579/fd/0 -> +/dev/console + + Then: + + # ps aux|grep 579 + root 579 0.0 0.1 1088 436 ?S00:43 0:00 gpm -t ps/2 + + So `gpm' will be killed by SAK. This is a bug in gpm. It should + be closing standard input. You can work around this by finding the + initscript which launches gpm and changing it thusly: + + Old: + + daemon gpm + + New: + + daemon gpm < /dev/null + + Vixie cron also seems to have this problem, and needs the same treatment. + + Also, one prominent Linux distribution has the following three + lines in its rc.sysinit and rc scripts: + + exec 3<&0 + exec 4>&1 + exec 5>&2 + + These commands cause *all* daemons which are launched by the + initscripts to have fil
Re: [CHECKER] 28 potential interrupt errors
David Woodhouse wrote: > > [ n_r3964.c stuff ] > ... > akpm, were you looking at this? I'm planning on poking through everything which has been identified as a posible problem. But I won't start for several weeks - give the maintainers (if any) time to address these things. So.. please go ahead :) There's another thing which needs doing to n_r3964.c, BTW - the abuse of task queues in r3964_close(). This is, I think, the only client of task queues which needs to poke so deeply into the implementation internals and Linus has mentioned something about needing to redesign the task queues in 2.5. So n_r3964 needs somehow to be redesigned so that it can use standard APIs. - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] /proc/uptime on SMP machines
Hallo,
I didn't see a maintainer for the /proc filesystem, to I send this mail to
linux-kernel for discussion.
At present the idle value in /proc/uptime is only the idle time for the first
processor. With 2.4, processes seam "stickier" for my, and e.g "yes
>/dev/null" on an otherwise idle machine can stay for a long time on one
processor of my (intel) SMP machine. That way, the present output of
/proc/uptime can lead to a wrong conclusion.
Appended patch returns the average of all idle processes an all
processors.
If I don't hear back, I will send to Linus and Alan for inclusion.
Bye
Uwe Bonnes[EMAIL PROTECTED]
Free Software: If you contribute nothing, expect nothing
--
--- linux-2.4.2.SuSE/fs/proc/proc_misc.cThu Mar 15 16:48:04 2001
+++ linux-2.4.2.SuSE-5/fs/proc/proc_misc.c Sat Mar 17 23:11:47 2001
@@ -105,11 +105,15 @@
{
unsigned long uptime;
unsigned long idle;
- int len;
+ int len,i;
uptime = jiffies;
+#ifdef CONFIG_SMP
+ for (idle =0,i = 0; i < smp_num_cpus; i++)
+ idle += (init_tasks[i]->times.tms_utime +
+init_tasks[i]->times.tms_stime)/smp_num_cpus;
+#else
idle = init_tasks[0]->times.tms_utime + init_tasks[0]->times.tms_stime;
-
+#endif
/* The formula for the fraction parts really is ((t * 100) / HZ) % 100, but
that would overflow about every five days at HZ == 100.
Therefore the identity a = (a / b) * b + a % b is used so that it is
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] 28 potential interrupt errors
On Fri, 16 Mar 2001, Junfeng Yang wrote:
> -
> [BUG] return with int disabled in an error path
>
> /u2/acc/oses/linux/2.4.1/drivers/char/n_r3964.c:1036:add_msg: ERROR:INTR:990:995:
>Interrupts inconsistent, severity `20':995
>
>
> save_flags(flags);
> Start --->
> cli();
>
> pMsg = kmalloc(sizeof(struct r3964_message), GFP_KERNEL);
> TRACE_M("add_msg - kmalloc %x",(int)pMsg);
> Return without
> enabling interrupt
> --->
> if(pMsg==NULL)
> return;
>
>
> ... DELETED 44 lines ...
>
>if(pClient->sig_flags & R3964_USE_SIGIO)
>{
> kill_proc(pClient->pid, SIGIO, 1);
>}
> Error --->
> }
>
> static struct r3964_message *remove_msg(struct r3964_info *pInfo,
>struct r3964_client_info *pClient)
> {
> -
The simple 'fix' is to move the offending kmalloc() up above the cli().
That might actually be something else to make an automated test for -
anything which schedules can re-enable interrupts. In general, it's bad to
call anything which can schedule when interrupts are disabled.
But actually, the cli() is there because of the fundamentally flawed
assumption that it provides sufficient locking. I've converted the whole
thing to use spinlocks instead, but haven't got a test setup ATM. I'll
poke at it more on Monday.
akpm, were you looking at this?
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] 16 potential locking bugs in 2.4.1
On Fri, 16 Mar 2001, Andy Chou wrote: > Here are some more results from the MC project. These are 16 errors found > in 2.4.1 related to inconsistent use of locks. > +-++ > | file| fn | > +-++ > | drivers/mtd/cfi_cmdset_0001.c | cfi_intelext_suspend | > | drivers/mtd/cfi_cmdset_0002.c | cfi_amdext_suspend | Fixed in CVS some time ago. Will be flushed to Linus some time in the near future, after I've cleaned up the inter_module_xxx abomination. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] 120 potential dereference to invalid pointers errors for linux 2.4.1
On Sat, Mar 17, 2001 at 01:30:54AM -0800, Junfeng Yang wrote: > - > [BUG] dereference to invalid pointer "bluetooth" in error message > /u2/acc/oses/linux/2.4.1/drivers/usb/bluetooth.c:924:bluetooth_read_bulk_callback: >ERROR:NULL:828:924: Using NULL ptr "bluetooth" illegally! set by >'get_usb_bluetooth':828 > > Start ---> > struct usb_bluetooth *bluetooth = get_usb_bluetooth ((struct usb_bluetooth >*)urb->context, __FUNCTION__); > unsigned char *data = urb->transfer_buffer; > unsigned int count = urb->actual_length; > unsigned int i; > unsigned int packet_size; > > ... DELETED 88 lines ... > > bluetooth->bulk_packet_pos = 0; > } > > exit: > Error ---> > FILL_BULK_URB(bluetooth->read_urb, bluetooth->dev, > usb_rcvbulkpipe(bluetooth->dev, >bluetooth->bulk_in_endpointAddress), This has already been fixed in a patch that was sent to the linux-usb-devel and bluetooth mailing lists, but hasn't made it into the kernel tree yet. But good catch! thanks, greg k-h -- greg@(kroah|wirex).com http://immunix.org/~greg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Potential free/use-after-free bugs
On Fri, Mar 16, 2001 at 10:17:30PM -0800, Seth Andrew Hallem wrote: > [BUG] Potential double or more free. > /home/shallem/oses/linux/2.4.1/drivers/usb/serial/belkin_sa.c:236:belkin_sa_shutdown: > ERROR:FREE:237:236: Use-after-free of 'private'! set by 'kfree':237 > > } > /* My special items, the standard routines free my urbs */ > if (serial->port->private) > Error ---> > Start ---> > kfree(serial->port->private); > } > > [BUG] Copy paste of above potential bug. > /home/shallem/oses/linux/2.4.1/drivers/usb/serial/mct_u232.c:277:mct_u232_shutdown: > ERROR:FREE:278:277: Use-after-free of 'private'! set by 'kfree':278 > > [BUG] Damn fine catch, the author meant to say serial->port[i].private there. Thanks, I'll fix these up. greg k-h -- greg@(kroah|wirex).com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH for 2.5] preemptible kernel
Hi! > Here is the latest preemptible kernel patch. It's much cleaner and > smaller than previous versions, so I've appended it to this mail. This > patch is against 2.4.2, although it's not intended for 2.4. I'd like > comments from anyone interested in a low-latency Linux kernel solution > for the 2.5 development tree. > > Kernel preemption is not allowed while spinlocks are held, which means > that this patch alone cannot guarantee low preemption latencies. But > as long held locks (in particular the BKL) are replaced by finer-grained > locks, this patch will enable lower latencies as the kernel also becomes > more scalable on large SMP systems. > > Notwithstanding the comments in the Configure.help section for > CONFIG_PREEMPT, I think this patch has a negligible effect on > throughput. In fact, I got better average results from running 'dbench > 16' on a 750MHz PIII with 128MB with kernel preemption turned on > (~30MB/s) than on the plain 2.4.2 kernel (~26MB/s). That is not bad result! > (I had to rearrange three headers files that are needed in sched.h before > task_struct is defined, but which include inline functions that cannot > now be compiled until after task_struct is defined. I chose not to > move them into sched.h, like d_path(), as I don't want to make it more > difficult to apply kernel patches to my kernel source tree.) > diff -Nur 2.4.2/arch/i386/kernel/traps.c linux/arch/i386/kernel/traps.c > --- 2.4.2/arch/i386/kernel/traps.cWed Mar 14 12:16:46 2001 > +++ linux/arch/i386/kernel/traps.cWed Mar 14 12:22:45 2001 > @@ -973,7 +973,7 @@ > set_trap_gate(11,&segment_not_present); > set_trap_gate(12,&stack_segment); > set_trap_gate(13,&general_protection); > - set_trap_gate(14,&page_fault); > + set_intr_gate(14,&page_fault); > set_trap_gate(15,&spurious_interrupt_bug); > set_trap_gate(16,&coprocessor_error); > set_trap_gate(17,&alignment_check); Are you sure about this piece? Add least add a comment, because it *looks* strange. Pavel -- 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] 28 potential interrupt errors
> Your reporting is a little misleading here.
Thanks for verifying these bugs ;)
The interrupt checker checks for inconsistent interrupt states. For
example, if a function has one exit point with interrupt disabled, and
another exit point with interrupt enabled, the checker will report an
error at the second exit point. The code snippets are automatically culled
from the source based on the line number in the error report. So the
reporting is sometimes misleading. I'll put the actuall line number in the
comments.
>
> Yes, there's a bug in this function - the `return -EPERM'
> doesn't do a `restore_flags()'. But there is no bug
> in the place you've reported.
>
> (Personally, I think *any* C function which has more than
> one `return' statement is a bug, and we see a classic
> instance here of one of the problems which this practice
> can cause. Religious issue. )
It may be better to have two exit points, one for normal path and one for
error path. All error handling code can be put at the end of the function.
>
>
> > ...
>
> > [BUG] error path
> >
> > /u2/acc/oses/linux/2.4.1/drivers/net/wan/comx-hw-mixcom.c:505:MIXCOM_open:
>ERROR:INTR:514:562: Interrupts inconsistent, severity `20':562
> >
> > }
> >
> > Start --->
> > save_flags(flags); cli();
> >
> > if(hw->channel==1) {
> > request_region(dev->base_addr, MIXCOM_IO_EXTENT, dev->name);
> > }
> >
> > if(hw->channel==0 && !(ch->init_status & IRQ_ALLOCATED)) {
> >
> > ... DELETED 38 lines ...
> >
> > procfile->mode = S_IFREG | 0444;
> > }
> > }
> >
> > Error --->
> > return 0;
> > }
>
> There's another problem here. We're calling request_region()
> inside cli(). request_region() can sleep.
>
> On SMP, cli() does all sorts of bizarre things which are
> quite different between different architectures. I don't
> know if this practice is actually unsafe on any architectures,
> but it is really bad practice. It's certainly the case that
> schedue() will enable interrupts for you, so whatever you're
> protecting won't be protected!
>
> So I'd add `sleep inside cli()' to your list of things to
> look out for.
>
> Does your tool have the ability to track which functions
> can and can't sleep? This is a very common source of bug.
> Grab a spinlock, then call a function which calls a function
> which calls a function which calls kmalloc(GFP_KERNEL). Unless
> the spinlock is always protected by a semaphore, this can deadlock.
>
> >
> > /u2/acc/oses/linux/2.4.1/drivers/scsi/eata_dma.c:490:eata_queue:
>ERROR:INTR:464:506: Interrupts inconsistent, severity `20':506
> >
> > save_flags(flags);
> > Start --->
> > cli();
> >
> > #if 0
> > for (x = 1, sh = first_HBA; x <= registered_HBAs; x++, sh = SD(sh)->next) {
> > if(inb((uint)sh->base + HA_RAUXSTAT) & HA_AIRQ) {
> > printk("eata_dma: scsi%d interrupt pending in eata_queue.\n"
> >" Calling interrupt handler.\n", sh->host_no);
> >
> > ... DELETED 32 lines ...
> >
> > printk(KERN_CRIT "eata_queue pid %ld, HBA QUEUE FULL..., "
> >"returning DID_BUS_BUSY\n", cmd->pid));
> > done(cmd);
> > restore_flags(flags);
> > Error --->
> > return(0);
> > }
> > ccb = &hd->ccb[y];
>
> Something's gone a little wrong here. The bug is in fact about
> 20 lines higher up.
>
>
> Generally: yes, everything you've found needs fixing.
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
IP Alias with 2.2.18?
My first post on the "top of mailing-list"... Is there same IP aliasing support with kernel 2.2.18? My eth0:0 doesn't works anymore. Thanks! -- Regards,: Marco Calistri <[EMAIL PROTECTED]> gpg key available on http://www.qsl.net/ik5bcu Xfmail 1.4.7p2 on linux RedHat 6.2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] how to catch HW fault
On Sat, Mar 17, 2001 at 01:22:46PM -0500, you [Aaron Lunansky] claimed: > Sounds like the only thing you haven't swapped out of your machine is the > ram/cpu. > > It could very well be your ram (I don't suspect the cpu). If you can, try a > different stick of ram. Or try memtest86 (http://reality.sgi.com/cbrady_denver/memtest86/) it's a very good memory tester. My first option if I suspect a hardware fault. -- v -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE UDMA on a CMD-648 Chip
> I can't find the chip's datasheet. CMD only gives it to direct customers. > I do have the datasheet for the CMD-646U, a prior UDMA supporting chip. Have you tried mailing them?. I sent mail to something silly like support@cmd. After they found the right person for me to talk to, I mentioned wanting to play with linux support, and he happily sent the datasheets for the 648 and 649. I use andre's 2.2 ide patches to get support for it.. -- zach - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA audio and parport in 2.4.2
On Sat, 17 Mar 2001, Will Newton wrote: > On Sat, 17 Mar 2001, Mike Galbraith wrote: > > > > messages.1:Mar 8 22:49:00 dogfox kernel: spurious 8259A interrupt: IRQ7. > > > > I see these once in a while too in 2.4.x, and only when copying largish > > files between boxes. NIC is IRQ-10, but the spurious interrupt is always > > IRQ-7. I'm not using the printer port for anything on this box. It only > > happens here when the network is going full bore for at least a few secs. > > With the VIA chipset? Yes. > There definitely seems to be something wrong in the IRQ handling on this > board. e.g. when I insmod the sound driver it just sits there on IRQ 10, > getting no interrupts. Unfortunately I don't know enough about Linux > internals to really investigate this further. No device I'm using has irq troubles.. at least nothing obvious. I've no idea if the spurious irq is VIA chipset related or not.. only that it's a fairly recent arrival. All devices work fine here. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] how to catch HW fault
On Sat, 17 Mar 2001, Aaron Lunansky wrote: > It could very well be your ram (I don't suspect the cpu). If you can, try a > different stick of ram. I've found a good exercise for exercising memory faults is to recompile the kernel with a -j16 flag; and in a second virtual console, do something like dd if=/dev/hda of=/dev/null bs=2048k Either the kernel compile will fail with a sig11, or the dd will fail and lock the system, in my experience. I've used this method, crudely, to chase down memory problems in systems using 256-512MB ram. YMMV. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] 120 potential dereference to invalid pointers errors for linux 2.4.1
> > [BUG] fore200e_kmalloc can return NULL > > /u2/acc/oses/linux/2.4.1/drivers/atm/fore200e.c:2032:fore200e_get_esi: >ERROR:NULL:2020:2032: Using unknown ptr "prom" illegally! set by >'fore200e_kmalloc':2020 > > I don't see the bug - there is an explicit "if(!prom) return -ENOMEM;" after > the allocation. It looks fine to me. We checked 2.4.1; it appears that by 2.4.2 someone had already fixed it :) -Andy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] how to catch HW fault
Sounds like the only thing you haven't swapped out of your machine is the ram/cpu. It could very well be your ram (I don't suspect the cpu). If you can, try a different stick of ram. -Original Message- From: kees <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Sent: Sat Mar 17 11:29:35 2001 Subject: [OT] how to catch HW fault Hi, I'm getting mad because of random freezes of my system. Linux-2.2.19pre7 on MSI 694D dual PIII(677MHz) 128 MB, no OC. I tried to isolate the problem with replacing cards (S3 video, 3com 59X, ES1373 and AIC7xxx) didn't solve anything. Even in initlevel 1 with only a videocard the freeze happens. It is a total lockup, no SYSRQ , no ping from network, nothing in the logs. A freeze may happen 4 times in a hour or once in 2 weeks. I have the same mobo and PIII's at home without the slightest problems. Who knows of a suitable diagnostics to track this down? regards Kees - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is swap == 2 * RAM a permanent thing?
On Sat, 17 Mar 2001, Boris Pisarcik wrote: > On Thu, Mar 15, 2001 at 11:44:52PM -0300, Rik van Riel wrote: > i cannot delete executable file when it's just run, but under linux > i can delete /bin/bash without any problem. You can't delete it. You can unlink it, but the file itself remains alive until the last reference goes away. mapping counts as reference. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
Hi Albert. >> +o Mount # 2.10e# mount --version > Concerning mount: (i) the version mentioned is too old, >>> Exactly why? Mere missing features don't make for a required >>> upgrade. Version number inflation should be resisted. >> These days you can mount several filesystems at the same mount >> point. The old mount does not understand this at all. Recent >> versions of mount act better in this respect, even though it is >> still easy to confuse them. > The rule should be like this: > List the lowest version number required to get > 2.2.xx-level features while running a 2.4.xx kernel. That's a meaningless definition, and can only be taken as such. What use would such a list be to somebody wishing (like I recently was) to upgrade a system running the 2.0.12 kernel so it runs the 2.4.2 kernel instead? The ONLY kernel version that any list can be meaningful for is that of the kernel source tree it is a member of, and that leads to the following definition for the versions to be included in such a list: List the lowest version number required to compile this kernel, and to allow the resulting kernel to be used as the heart of a running system. Basically, required upgrades can fall into any of the following categories, and need to be dealt with accordingly: 1. Development tools used to compile and/or link the kernel. 2. System libraries needed to run these development tools: 3. System tools that interact intimately with the kernel. If the kernel interface changes in an incompatible way, these will also need to be updated. 4. System tools that analyse kernel-supplied information and advise the user of the results. 5. Other tools that are dependant on kernel version. 6. Other tools that have been upgraded. My opinion is that only tools that fall in category (6) should be omitted from the list. > Remember what the purpose of the table is. It is a list of > REQUIRED upgrades. Failure to upgrade should result in a broken > system. So pppd must be listed, since somebody changed the > kernel API for 2.4.1. > If I run the mount command from Red Hat 6.2, using it as > intended for a 2.2.xx kernel, doesn't everything work? There > won't be any multi-mount confusion because 2.2.xx can't do that > anyway. There isn't any problem with NFSv3 either, since 2.2.xx > lacks NFSv3. Whilst that's a good question, it misses the whole point of such a list. Can I replace it with a more realistic one: If I take a random Linux-based system and boot it using the kernel I've just compiled using this kernel source tree, will it work? If not, what is the minimum that I need to upgrade to make it work? Remember, there's absolutely NOTHING in ANY of the kernel source trees that depends on what a particular user is running on their system before they get that source tree. > Basically I ask: would existing scripts for a 2.2.xx kernel > break? If the old mount can still do what it used to do, then > "mount" need not be listed at all. Replace that "a 2.2.xx" with "my current" and remove all restrictions on what the current kernel is, and that becomes an important question. After all, if I take the network print server I'm running with a 2.0.19 kernel and drop a 2.4.2 kernel in, will it work without any other changes? Best wishes from Riley. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA audio and parport in 2.4.2
On Sat, 17 Mar 2001, Mike Galbraith wrote: > > messages.1:Mar 8 22:49:00 dogfox kernel: spurious 8259A interrupt: IRQ7. > > I see these once in a while too in 2.4.x, and only when copying largish > files between boxes. NIC is IRQ-10, but the spurious interrupt is always > IRQ-7. I'm not using the printer port for anything on this box. It only > happens here when the network is going full bore for at least a few secs. With the VIA chipset? There definitely seems to be something wrong in the IRQ handling on this board. e.g. when I insmod the sound driver it just sits there on IRQ 10, getting no interrupts. Unfortunately I don't know enough about Linux internals to really investigate this further. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is swap == 2 * RAM a permanent thing?
On Thu, Mar 15, 2001 at 11:44:52PM -0300, Rik van Riel wrote: > On Thu, 15 Mar 2001, William T Wilson wrote: > > > it seems to me that in 2.2.x it looks like this: > > > > total usage == swap + RAM > > under 2.4.x it looks like: > > total usage == swap > > total usage == maximum(swap, ram) Hi, Do you in fact talk about 1) curren usage == maximum(swap, ram) or 2) virtual ram capacity == maximum(swap, ram) ? I'm a bit confused. My next question is: some time ago i've read, that code segments of process, which comes from executable and should stay unmodified during process duration, are not swapped into swap space, cause they can be restored back from the executable. This should be ok, because in protect mode no one can write into code seg. This does seem to be true for win, because i cannot delete executable file when it's just run, but under linux i can delete /bin/bash without any problem. Why this is so ? Because of security ? Say my disk gets corrupted right at blocks executable image si contained and swapping in page(s) from this errorneous area should lock/corrupt system ? Code content can be changed indirectly in case data or some read-write segment overlaps code segment. Does linux count with such a situation ? (may data segment overlap code seg ?) ThanksBoro email: [EMAIL PROTECTED] PGP signature
Re: [PATCH] Improved version reporting
Hi Andries.
>> {Shrug} Thinking isn't sufficient - check your facts.
> Poor Riley,
>
> Probably I should not answer, I think you know all the facts
> already. But just to be sure:
> (i) There are two different packages, kbd and a forked version,
> console-tools. Both contain roughly the same programs. In your
> earlier mails you seemed aware of that, but now you report that
> the console-tools version of loadkeys does not want to print a
> kbd version. No surprise there.
You make claims for me there that I've never made, so can I suggest
you get your facts right this time. For reference:
1. My claim was NOT that the loadkeys from console-tools does
not print a kbd version, as you claim in the comment quoted
above. I claimed that it doesn't print ANY version, including
one for loadkeys itself.
2. YOUR claim was that the loadkeys command ALWAYS displays the
version number, so the command in ver_linux is thus always
guaranteed to produce a version number. MY claim was that
at least one loadkeys command fails to do so, and thus that
one can't expect it to do so.
Thank you for confirming that your claim was false.
> (ii) I am the maintainer of both mount and util-linux.
> If I say that there exists no more recent version of mount
> than the one found in util-linux, you can believe me.
Neither of us has claimed otherwise, nor have we been disputing that.
YOUR claim was that all systems always have the same version of mount
and util-linux installed, even when they are from different packages.
MY claim was that no such guarantee can be given, as it's possible for
somebody to upgrade either without upgrading the other when they are
supplied separately.
Again, thank you for confirming that your claimwas false.
Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Mounting ISO via Loop Devices
On my redhat 7.1 machine I have been using the 2.4.0 redhat kernel and mounting ISO's to loop devices and it worked fine. I upgraded to a 2.4.2 kernel and now none of the ISO's will mount. They all hang when the command is run. Are there any other known occurences of this? I am not on the list so if there some issue that you would like to tell me or if you need more information please write me back directly. Brent Norris System Admin - WKU-Center for BioDiversity (4) WKU-Linux (3) Best Mechanical (3) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OT] how to catch HW fault
Hi, I'm getting mad because of random freezes of my system. Linux-2.2.19pre7 on MSI 694D dual PIII(677MHz) 128 MB, no OC. I tried to isolate the problem with replacing cards (S3 video, 3com 59X, ES1373 and AIC7xxx) didn't solve anything. Even in initlevel 1 with only a videocard the freeze happens. It is a total lockup, no SYSRQ , no ping from network, nothing in the logs. A freeze may happen 4 times in a hour or once in 2 weeks. I have the same mobo and PIII's at home without the slightest problems. Who knows of a suitable diagnostics to track this down? regards Kees - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: problems compiling scsi_ioctl on kernels later 2.4.1
i don't understand how it got corrupted but it looks like i'm missing a lot of things
if
i compare it to your scsi_ioctl file
I will use your scsi_ioctl or i will untar kernel 2.4.2 again without patch pre4
i hope it will work
Erik
Douglas Gilbert schreef:
> Erik van Asselt wrote:
> >
> > I did link the usr/include/scsi to usr/srs/linux/include/scsi
> > isn't that the right way for compiling the new kernel?
>
> That link may be useful for running various apps but it
> is not recommended. It shouldn't make any difference to
> building a kernel.
>
> My scsi_ioctl.h file for lk 2.4.2 is attached.
>
> Doug Gilbert
>
> > Erik
> >
> > Douglas Gilbert schreef:
> >
> > > Erik,
> > > It looks like you are missing (or have a corrupted)
> > > include/scsi/scsi_ioctl.h header file. It contains
> > > the definition of the struct Scsi_Ioctl_Command .
> > >
> > > Doug Gilbert
>
>
> #ifndef _SCSI_IOCTL_H
> #define _SCSI_IOCTL_H
>
> #define SCSI_IOCTL_SEND_COMMAND 1
> #define SCSI_IOCTL_TEST_UNIT_READY 2
> #define SCSI_IOCTL_BENCHMARK_COMMAND 3
> #define SCSI_IOCTL_SYNC 4 /* Request synchronous parameters */
> #define SCSI_IOCTL_START_UNIT 5
> #define SCSI_IOCTL_STOP_UNIT 6
> /* The door lock/unlock constants are compatible with Sun constants for
>the cdrom */
> #define SCSI_IOCTL_DOORLOCK 0x5380 /* lock the eject mechanism */
> #define SCSI_IOCTL_DOORUNLOCK 0x5381/* unlock the mechanism */
>
> #define SCSI_REMOVAL_PREVENT1
> #define SCSI_REMOVAL_ALLOW 0
>
> #ifdef __KERNEL__
>
> /*
> * Structures used for scsi_ioctl et al.
> */
>
> typedef struct scsi_ioctl_command {
> unsigned int inlen;
> unsigned int outlen;
> unsigned char data[0];
> } Scsi_Ioctl_Command;
>
> typedef struct scsi_idlun {
> __u32 dev_id;
> __u32 host_unique_id;
> } Scsi_Idlun;
>
> /* Fibre Channel WWN, port_id struct */
> typedef struct scsi_fctargaddress
> {
> __u32 host_port_id;
> unsigned char host_wwn[8]; // include NULL term.
> } Scsi_FCTargAddress;
>
> extern int scsi_ioctl (Scsi_Device *dev, int cmd, void *arg);
> extern int kernel_scsi_ioctl (Scsi_Device *dev, int cmd, void *arg);
> extern int scsi_ioctl_send_command(Scsi_Device *dev,
>Scsi_Ioctl_Command *arg);
>
> #endif
>
> #endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
USB Mouse Problem in 2.4 Kernels - 2.2.18 Works Fine
Dear kernel hackers, I am experiencing problems with a USB mouse: The machine boots, X starts, I log on, everything works as expected. When I restart X or just change to an alpha terminal and back to x the mouse does not work any more. It does not necessarily happen the first time I do this but it eventually will. The device is still there, ie. I can do a 'cat /dev/input/mice' with out error but it does not do anything, there are no characters when I move the mouse. This does at least happen with 2.4.2, 2.4.3pre4, 2.4.2-ac17, 2.4.2-ac18, and 2.4.2-ac20 on both Debian stable and unstable. It does not happen with 2.2.18. So I assume that it is neither a hardware issue nor an environment one (as in compiler version and so forth), but a problem with the USB code itself. I think the problem might perhaps be that the USB subsystem initialises the mouse correctly on boot with 1.5 MB/s but tries to use 12 MB/s on later attempts which fails. But I do not really know what I am talking about here... Hardware is an ASUS K7V motherboard (VIA chip set), BIOS versions 1008.01c/1008.01d/1007. It happens with both USB compiled into the kernel and compiled as modules. A USB scanner works fine. Please let me know if I can be of further assistance or more information is needed. Thanks very much, Andree PS: I send a message with similar contents to the linux-usb list. Unfortunately, I got no reply so far. However, that message mentioned only 2.4.2-ac18 and -ac17, maybe that is why. Since then I tested some more kernels (see above). PPS: I am not subscribed to this list, I just follow it via GeoCrawler, so it would be great if replies could be cc'ed to me directly. Thanks a lot. --- T H E D E T A I L S --- /proc/bus/usb/devices looks like this: T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 3 Spd=12 MxCh= 2 B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 0.00 S: Product=USB UHCI Root Hub S: SerialNumber=d000 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc=104/900 us (12%), #Int= 2, #Iso= 0 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor= ProdID= Rev= 0.00 S: Product=USB UHCI Root Hub S: SerialNumber=d400 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 4 D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0451 ProdID=2046 Rev= 1.25 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=255ms T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=ff(vend.) Sub=00 Prot=ff MxPS= 8 #Cfgs= 1 P: Vendor=04b8 ProdID=0103 Rev= 0.01 S: Manufacturer=EPSON S: Product=Perfection610 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 2mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=usbscanner E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl= 0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl= 0ms T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 5 Spd=1.5 MxCh= 0 D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0458 ProdID=0003 Rev= 0.00 S: Manufacturer=KYE S: Product=Genius USB Wheel Mouse C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=usb_mouse E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl= 10ms Story Board = The machine boots and everything seems fine: Linux version 2.4.2 (root@aurich) (gcc version 2.95.2 2220 (Debian GNU/Linux)) #3 Sat Mar 17 23:56:57 EST 2001 BIOS-provided physical RAM map: BIOS-e820: 000a @ (usable) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 0feec000 @ 0010 (usable) BIOS-e820: 3000 @ 0ffec000 (ACPI data) BIOS-e820: 0001 @ 0ffef000 (reserved) BIOS-e820: 1000 @ 0000 (ACPI NVS) BIOS-e820: 0001 @ (reserved) On node 0 totalpages: 65516 zone(0): 4096 pages. zone(1): 61420 pages. zone(2): 0 pages. Kernel command line: auto BOOT_IMAGE=linux ro root=302 BOOT_FILE=/vmlinuz idebus=33 video=matrox:vesa:0x193 hdc=ide-scsi hdd=ide-scsi ide_setup: idebus=33 ide_setup: hdc=ide-scsi ide_setup: hdd=ide-scsi Initializing CPU#0 Detected 700.050 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1395.91 BogoMIPS Memory: 255956k/262064k available (731k kernel code, 5724k reserved, 248k data, 168k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 byt
Re: Performance is weird (fwd) -> results
On Fri, 16 Mar 2001, Manfred Spraul wrote: > Sampsa Ranta wrote: > > > > After either of your patches, the result was the same, sorry. > > > Is apm or acpi running? No, I tried both SMP and non-SMP version of kernel, the machine is however single processor Athlon 900. CONFIG_ACPI is not set, CONFIG_APM is not set. The 2.4.3pre4 still performs 66M/s without "the load" and 124M/s+ with load. However there is much different between 2.4.2 and 2.4.3pre about 33M/s to 66M/s. - Sampsa Ranta [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: problems compiling scsi_ioctl on kernels later 2.4.1
I did link the usr/include/scsi to usr/srs/linux/include/scsi isn't that the right way for compiling the new kernel? Erik Douglas Gilbert schreef: > Erik, > It looks like you are missing (or have a corrupted) > include/scsi/scsi_ioctl.h header file. It contains > the definition of the struct Scsi_Ioctl_Command . > > Doug Gilbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] 120 potential dereference to invalid pointers errors for linux 2.4.1
Junfeng Yang wrote: > [BUG] fore200e_kmalloc can return NULL > /u2/acc/oses/linux/2.4.1/drivers/atm/fore200e.c:2032:fore200e_get_esi: >ERROR:NULL:2020:2032: Using unknown ptr "prom" illegally! set by >'fore200e_kmalloc':2020 I don't see the bug - there is an explicit "if(!prom) return -ENOMEM;" after the allocation. It looks fine to me. > [BUG] break the while loop, but not the for loop > /u2/acc/oses/linux/2.4.1/drivers/atm/zatm.c:1817:zatm_detect: ERROR:NULL:1804:1817: >Using NULL ptr "zatm_dev" illegally! set by 'kmalloc':1804 Ah, good catch. It'd be almost impossible to actually trigger this since you'd need multiple cards of different types (all of which are rare) and end up with really bad allocation luck, but it is technically a bug. Really line 1829 should be "if(!zatm_dev) return devs;" > [BUG] at line 1796 > /u2/acc/oses/linux/2.4.1/net/atm/lec.c:1799:lec_arp_update: ERROR:NULL:1798:1799: >Using unknown ptr "entry" illegally! set by 'make_entry':1798 Yep, all three of the catches in lec.c are real bugs - great work as always. -Mitch - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LFS patch for 2.2.18
On Fri, Mar 16, 2001 at 03:24:58PM +0200, Jussi Hamalainen wrote: > Where can I get the LFS patch for 2.2.18? Www.scyld.com doesn't > seem to be carrying it anymore. ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.2/2.2.19pre7aa1/40_lfs-2.2.19pre6aa1-24.bz2 ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.2/2.2.19pre17aa1.bz2 Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] 28 potential interrupt errors
Junfeng Yang wrote:
>
> ...
>
> [BUG] sleep_or_timeout will call interruptible_sleep_on, which will save disabled
>flags and then restore them.
>
> /u2/acc/oses/linux/2.4.1/drivers/cdrom/cm206.c:474:send_command: ERROR:INTR:462:474:
>Interrupts inconsistent, severity `20':474
>
> if (!(inw(r_line_status) & ls_transmitter_buffer_empty)) {
> cd->command = command;
> Start --->
> cli(); /* don't interrupt before sleep */
> outw(dc_mask_sync_error | dc_no_stop_on_error |
> (inw(r_data_status) & 0x7f), r_data_control);
> /* interrupt routine sends command */
>
> Save & Restore
> flags here --->
> if (sleep_or_timeout(&cd->uart, UART_TIMEOUT)) {
> debug(("Time out on write-buffer\n"));
> stats(write_timeout);
>
> ... DELETED 2 lines ...
>
> }
> debug(("Write commmand delayed\n"));
> }
> else outw(command, r_uart_transmit);
> Error --->
> }
Yes, this is a bug.
> ...
> /u2/acc/oses/linux/2.4.1/drivers/net/irda/irport.c:943:irport_net_ioctl:
>ERROR:INTR:947:997: Interrupts inconsistent, severity `20':997
>
> /* Disable interrupts & save flags */
> save_flags(flags);
> Start --->
> cli();
>
> switch (cmd) {
> case SIOCSBANDWIDTH: /* Set bandwidth */
> if (!capable(CAP_NET_ADMIN))
> return -EPERM;
> irda_task_execute(self, __irport_change_speed, NULL, NULL,
>
> ... DELETED 40 lines ...
>
> }
>
> restore_flags(flags);
>
> Error --->
> return ret;
> }
Your reporting is a little misleading here.
Yes, there's a bug in this function - the `return -EPERM'
doesn't do a `restore_flags()'. But there is no bug
in the place you've reported.
(Personally, I think *any* C function which has more than
one `return' statement is a bug, and we see a classic
instance here of one of the problems which this practice
can cause. Religious issue. )
> ...
> [BUG] error path
>
> /u2/acc/oses/linux/2.4.1/drivers/net/wan/comx-hw-mixcom.c:505:MIXCOM_open:
>ERROR:INTR:514:562: Interrupts inconsistent, severity `20':562
>
> }
>
> Start --->
> save_flags(flags); cli();
>
> if(hw->channel==1) {
> request_region(dev->base_addr, MIXCOM_IO_EXTENT, dev->name);
> }
>
> if(hw->channel==0 && !(ch->init_status & IRQ_ALLOCATED)) {
>
> ... DELETED 38 lines ...
>
> procfile->mode = S_IFREG | 0444;
> }
> }
>
> Error --->
> return 0;
> }
There's another problem here. We're calling request_region()
inside cli(). request_region() can sleep.
On SMP, cli() does all sorts of bizarre things which are
quite different between different architectures. I don't
know if this practice is actually unsafe on any architectures,
but it is really bad practice. It's certainly the case that
schedue() will enable interrupts for you, so whatever you're
protecting won't be protected!
So I'd add `sleep inside cli()' to your list of things to
look out for.
Does your tool have the ability to track which functions
can and can't sleep? This is a very common source of bug.
Grab a spinlock, then call a function which calls a function
which calls a function which calls kmalloc(GFP_KERNEL). Unless
the spinlock is always protected by a semaphore, this can deadlock.
>
> /u2/acc/oses/linux/2.4.1/drivers/scsi/eata_dma.c:490:eata_queue: ERROR:INTR:464:506:
>Interrupts inconsistent, severity `20':506
>
> save_flags(flags);
> Start --->
> cli();
>
> #if 0
> for (x = 1, sh = first_HBA; x <= registered_HBAs; x++, sh = SD(sh)->next) {
> if(inb((uint)sh->base + HA_RAUXSTAT) & HA_AIRQ) {
> printk("eata_dma: scsi%d interrupt pending in eata_queue.\n"
>" Calling interrupt handler.\n", sh->host_no);
>
> ... DELETED 32 lines ...
>
> printk(KERN_CRIT "eata_queue pid %ld, HBA QUEUE FULL..., "
>"returning DID_BUS_BUSY\n", cmd->pid));
> done(cmd);
> restore_flags(flags);
> Error --->
> return(0);
> }
> ccb = &hd->ccb[y];
Something's gone a little wrong here. The bug is in fact about
20 lines higher up.
Generally: yes, everything you've found needs fixing.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH against 2.4.2: TTY hangup on PPP channel corrupts kernel memory
Kevin Buhr writes:
> If there's a hangup in the TTY layer on an async PPP channel,
> do_tty_hangup shuts down the PPP line discipline, and, in ppp_async.c,
> the function ppp_asynctty_close unregisteres the channel. In
> ppp_generic.c, ppp_unregister_channel merrily wakes up the rwait
> queue, then proceeds to destroy the channel, freeing the "struct
> channel" which contains the "struct ppp_file" that contains the
> "wait_queue_head_t rwait". When the waiting process wakes up, it
> removes itself from the wait queue, modifying freed memory.
But the waiting process must have had an instance of /dev/ppp open and
attached to the channel in order to be doing anything with rwait,
within either ppp_file_read or ppp_poll. The process of attaching to
the channel increases its refcnt, meaning that the channel shouldn't
be destroyed until the instance of /dev/ppp is closed and ppp_release
is called.
Note that pppd will not be blocking inside ppp_file_read since it sets
the file descriptor non-blocking. Most of the time pppd would be
inside a select, so rwait would be in use by the poll/select code.
I presume that the generic file descriptor code ensures that the file
release function doesn't get called while any task is inside the read
or write function for that file, or while the file descriptor is in
use in a select or poll. If that assumption is wrong then it would
indeed be possible for the channel to be destroyed while some process
is waiting on rwait. But in any case it shouldn't be a problem in
practice since it would only be pppd that would have the channel open
and pppd is single-threaded, i.e. it couldn't be closing the file
descriptor while it is blocked inside read or select.
So, to put it in other words, this is the sequence (simplified):
fd = open("/dev/ppp", O_RDWR);
ioctl(fd, PPPIOCATTCHAN, &channel_number);
fcntl(fd, F_SETFL, fcntl(fd, F_GETFL) | O_NONBLOCK);
select(...);/* fd_sets including fd */
read(fd, ...);
...
close(fd);
I believe the channel structure is guaranteed to exist from the ioctl
to the close, and all the selects and reads (i.e. all the uses of
rwait) have to happen within that time interval.
> A patch against 2.4.2 follows. I've overloaded the "refcnt" in
> "struct ppp_file" to also keep track of rwaiters. The last refcnt
> user destroys the channel and decreases the module use count. I've
> tested this with printks in all the right places, and it seems to fix
> the problem correctly.
I'm not sure this is the right fix, this sounds to me like the
refcounts are going awry somehow or there is an SMP race that I
haven't considered, and I am concerned that this patch will just cover
over the real problem. Actually, given that you've seen it 4 times in
6 months it's more likely that it is an SMP race IMHO.
In any case I don't think your patch does the right thing with
ppp_poll, because poll_wait doesn't actually wait, it just adds rwait
to a list of things to watch for wakeups. In other words, rwait will
be in use from the time poll_wait is called until the time that the
poll/select logic (in fs/select.c) decides that it's time to return to
the user. So increasing the refcount around just the poll_wait call
won't help much.
Do you have a way to reproduce the problem at will? Have you seen it
happen on a UP box (i.e. could it be an SMP race)? How sure are you
that your patch really fixes the problem?
Regards,
Paul.
--
Paul Mackerras, Open Source Research Fellow, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
[EMAIL PROTECTED], http://www.linuxcare.com.au/
Linuxcare. Putting Open Source to work.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] big stack variables
On Sat, Mar 17, 2001 at 01:01:22AM -0500, Jeff Dike wrote: > [EMAIL PROTECTED] said: > > ObUML: something fishy happens in UML with multiple exec() in PID 1. > > Try to say "telinit u" (or just boot with init=/bin/sh and say exec / > > sbin/init) and you've got a nice panic()... > > ObFix: This is fixed in my current CVS. If you're not so desperate for the > fix, then it will be in my 2.4.3 release. Basically, the problem was that it > assumed that the only exec done by pid 1 was the kernel thread execing init, > and things got exciting when that turned out not to be true. ObUML (again): Any estimated time of submission to Linus?! Is this an early v2.5-thing, or are the changes minor enough to the rest of the tree to allow for an v2.4-merge? /David _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Potential free/use-after-free bugs
Seth Andrew Hallem wrote: > > I also have some questions regarding skbs. Our checker > found a lot of instances where the skb is freed, then its length field is > accessed. I have included an example location below. Is this a bug or > not? Yes, we should regard it as a bug. A dev_kfree_skb_irq(skb) followed by a reference to *skb is in fact safe, because the skb isn't freed until after the interrupt function returns. But it's cruddy code and should be changed. Arnaldo recently went through a whole bunch of drivers fixing a similar problem: netif_rx(skb); diddle_with(skb); This is poor form because netif_rx() "gives away" the skb and it's no longer yours to diddle with. In theory, netif_rx() could have kfree'ed it on the spot. With regard to the "16 potential locking bugs" email: nice one. They all appear to be complete box-busting shockers. If there was anyone around to send patches to, I'd fix em :) But I'll hang on to that email and make sure everything is ticked off next month. So: ack and thanks. - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: parport not detected
On Sat, Mar 17, 2001 at 01:05:51AM -0500, Michael B. Allen wrote: > I setup everything as you describe below. I don't remember having to > do all this stuff before(on other machines anyway). I guess I'm used to > RH's fluffed-up stock kernels. Which stock kernel didn't work for you? Tim. */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: parport not detected
On Fri, Mar 16, 2001 at 06:52:53PM -0500, Michael B. Allen wrote: > The parallel port is not being detected on my ABIT KT7A KT133 w/ Athlon Need dmesg output to see what parport is being told and what is finding out for itself. > BIOS options are: > > 728/IRQ5 ^^^ 278, probably > 378/IRQ7 > 3BC/IRQ7 But which one is it actually set to? > Of the above what's optimal? It depends what you're doing, really. > I also tried an options line in modules.conf. I believe it was: > > options parport_pc io=0x3bc irq=7 Take that out and see what happens. > That was reflected in /proc but no difference in actually "detecting" > the parallel port. I don't know what you mean really. Are you saying that you can't print, or just that the device ID probe (to get the printer name) isn't working? > Also, if I build parpart into the kernel I get nothing but a > hard lockup on 'Starting kswapd v 1.5'. That's quite strange. Which kernel version are you using? Take a look at the 'troubleshooting' section of Documentation/parport.txt. Tim. */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oops in 2.4.2-ac20
John R Lenton wrote:
>
> What the subject says.
>
> I copied the oops by hand, but the output of ksymoops doesn't
> seem too totally wrong, so I guess I didn't botch it :)
>
The trace dosn't look right, but you've probably hit
the con_flush_chars-called-from-interrupt problem.
Please add these two lines, let me know if it recurs.
--- linux-2.4.2-ac20/drivers/char/console.c Tue Mar 13 20:29:21 2001
+++ ac/drivers/char/console.c Sat Mar 17 22:16:14 2001
@@ -2304,6 +2335,9 @@
static void con_flush_chars(struct tty_struct *tty)
{
struct vt_struct *vt = (struct vt_struct *)tty->driver_data;
+
+ if (in_interrupt()) /* from flush_to_ldisc */
+ return;
pm_access(pm_con);
acquire_console_sem();
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fs/nls/Makefile - fix a dependency problem
The problem: When both nls_iso8859_8 and nls_cp1255 are compiled into the kernel (=Y), init_nls_iso8859_8() is called before init_nls_cp1255() - this causes iso_8859_8 to call request_module() which obviously fails. Kernel log: (from dmesg + traces I added) TRACE: init_nls_iso8859_8() request_module[nls_cp1255]: Root fs not mounted Unable to load NLS charset cp1255 TRACE: init_nls_cp1255() The fix: (changing the link order of the two modules) --- linux-2.4.2-ac20/fs/nls/MakefileSat Mar 3 16:13:21 2001 +++ linux-2.4.2-ac20/fs/nls/MakefileSat Mar 17 12:39:28 2001 @@ -42,7 +42,7 @@ obj-$(CONFIG_NLS_ISO8859_5)+= nls_iso8859-5.o obj-$(CONFIG_NLS_ISO8859_6)+= nls_iso8859-6.o obj-$(CONFIG_NLS_ISO8859_7)+= nls_iso8859-7.o -obj-$(CONFIG_NLS_ISO8859_8)+= nls_iso8859-8.o nls_cp1255.o +obj-$(CONFIG_NLS_ISO8859_8)+= nls_cp1255.o nls_iso8859-8.o obj-$(CONFIG_NLS_ISO8859_9)+= nls_iso8859-9.o obj-$(CONFIG_NLS_ISO8859_10) += nls_iso8859-10.o obj-$(CONFIG_NLS_ISO8859_13) += nls_iso8859-13.o -- Dan Aloni [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pivot_root & linuxrc problem
On Sat, 17 Mar 2001, Bernd Eckenfels wrote: > In article <[EMAIL PROTECTED]> you wrote: > > Aha.. so that's it. I've never been able to get /linuxrc to execute > > automagically. I wonder why /linuxrc executes on Art's system, but > > not on mine. I can call it whatever I want and it doesn't run unless > > I explicitly start it with init=whatever. > > linuxrc is executed iff: > > CONFIG_BLK_DEV_INITRD is defined > you actually have a initrd mounted > /dev/console can be found and opened > a executable "/linuxrc" is in the ramdisk There's one more important condition to add to this iff list. ROOT_DEV as set at kbuild or boot time may not be identical with the device used as a container for the initrd image. Greetings from bash. My pid is 8 PID TTY STAT TIME COMMAND 1 ? SW 0:05 (swapper) 2 ? SW 0:00 (keventd) 3 ? SW 0:00 (kapm-idled) 4 ? SW 0:00 (kswapd) 5 ? SW 0:00 (kreclaimd) 6 ? SW 0:00 (bdflush) 7 ? SW 0:00 (kupdate) 8 ? S0:00 /bin/sh /linuxrc 11 ? R0:00 /bin/ps ax /dev/root / ext2 rw 0 0 /dev/hda5 /test ext2 rw 0 0 none /proc proc rw 0 0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
> If the old mount can still do what it used to do, > then "mount" need not be listed at all. Well, I started saying that the mount line should be deleted, so we somewhat agree. > If I run the mount command from Red Hat 6.2, using it > as intended for a 2.2.xx kernel, doesn't everything work? Roughly, yes. (In other words: no.) Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[CHECKER] 120 potential dereference to invalid pointers errors forlinux 2.4.1
Hi, This checker warns when the pointer returned by a "plausibly" failing routine is not checked before being used. It automatically builds up the list of failing routines by examining all callsites. If a function's returned pointer is checked at more than one callsite, the checker ensures it is always checked. (Functions like strtok or hash-table lookups are culled from this list by hand.) Sometimes we are unaware of preconditions that make such checks unnecessary, so the "errors" might still have false positives. Junfeng & Dawson Where the errors are: --+-+ | file | fn | +--+-+ | arch/i386/kernel/irq.c | init_irq_proc | | arch/i386/kernel/irq.c | register_irq_proc | | arch/i386/kernel/mtrr.c | mtrr_init | | drivers/acpi/dispatcher/dswload.c| acpi_ds_load2_end_op| | drivers/acpi/interpreter/amutils.c | acpi_aml_build_copy_internal_package_object | | drivers/acpi/parser/psparse.c| acpi_ps_parse_loop | | drivers/atm/fore200e.c | fore200e_get_esi| | drivers/atm/zatm.c | zatm_detect | | drivers/block/DAC960.c | DAC960_V1_ExecuteType3 | | drivers/block/DAC960.c | DAC960_V1_ExecuteType3D | | drivers/block/DAC960.c | DAC960_V2_ControllerInfo| | drivers/block/DAC960.c | DAC960_V2_DeviceOperation | | drivers/block/DAC960.c | DAC960_V2_GeneralInfo | | drivers/block/DAC960.c | DAC960_V2_LogicalDeviceInfo | | drivers/block/DAC960.c | DAC960_V2_PhysicalDeviceInfo| | drivers/block/DAC960.c | DAC960_V2_ReadDeviceConfiguration | | drivers/block/ll_rw_blk.c| blk_init_free_list | | drivers/char/drm/context.c | drm_alloc_queue | | drivers/char/drm/fops.c | drm_open_helper | | drivers/char/drm/proc.c | drm_proc_init | | drivers/char/ip2main.c | old_ip2_init| | drivers/char/pc_keyb.c | psaux_init | | drivers/char/rio/rio_linux.c | rio_init_datastructures | | drivers/i2o/i2o_core.c | i2o_core_evt| | drivers/ide/ide-probe.c | init_gendisk| | drivers/ide/ide-probe.c | init_irq| | drivers/ide/ide-tape.c | idetape_onstream_read_back_buffer | | drivers/isdn/avmb1/avm_cs.c | avmcs_attach| | drivers/isdn/avmb1/capi.c| capinc_raw_write| | drivers/isdn/avmb1/capi.c| capi_write | | drivers/isdn/avmb1/capidrv.c | if_readstat | | drivers/isdn/avmb1/capidrv.c | if_sendbuf | | drivers/md/raid5.c | grow_buffers| | drivers/md/raid5.c | __check_consistency | | drivers/media/video/i2c-parport.c| i2c_parport_attach | | drivers/media/video/videodev.c | videodev_proc_create_dev| | drivers/net/3c505.c | receive_packet | | drivers/net/3c515.c | corkscrew_found_device | | drivers/net/aironet4500_card.c | awc4500_isa_probe | | drivers/net/aironet4500_card.c | awc4500_pnp_probe | | drivers/net/defxx.c | dfx_rcv_init| | drivers/net/dgrs.c | dgrs_found_device | | drivers/net/pcmcia/aironet4500_cs.c | awc_attach | | drivers/net/pcmcia/wavelan_cs.c | wavelan_attach | | drivers/net/pcmcia/xircom_tulip_cb.c | tulip_probe1| | drivers/net/skfp/ess.c | ess_raf_received_pack | | drivers/net/skfp/ess.c | ess_send_response | | drivers/net/smc9194.c| smc_rcv
LDT allocated for cloned task!
hi all, When I was starting X, I got this in the syslog: Mar 17 10:19:20 brefatox kernel: LDT allocated for cloned task! _What is this?_. A grep on /var/log/messages shows that I had this several times. I'm using ext2fs on an IDE drive. Tell me what more info I can provide. Balazs Pozsar. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Who did the time list insert code?
At https://high-res-timers.sourceforge.net we are trying to define a high resolution timer patch for linux (please join us if you are interested). We would like to know who wrote the time list management code that is currently in the kernel. Or Any help on any studies done on the nature of the timer list. The code seems to indicate that most entries are in the first 2.56 seconds from NOW. Has this been verified? Are there other hidden issues we should know about? George - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.1-pre10: Does Reiserfs eat files?
Hi,
when I came to my computer this morning, I noticed that the file
~/.netscape/history.dat was missing. So I tried to copy over a backup
copy from another computer and got "permission denied". I realized that
the file was still there but not accessible at all, even by root.
Here's an strace of "ls -l ~.netscape/history.dat":
3917 lstat(".netscape/history.dat", 0x804e9bc) = -1 EACCES (Permission denied)
Then I looked in the kernel log, and no suprise, I found these entries:
vs-13048: reiserfs_iget: bad_inode. Stat data of (381 3930411) not found
vs-13048: reiserfs_iget: bad_inode. Stat data of (12541 173718) not found
The system is a Dual-Celeron with ABIT mainboard (Intel BX chipset) and
IDE disk, recently upgraded to 256 MB of ECC RAM.
How can I recover from this problem without reformatting?
Regards,
hjb
--
Pro-Linux - Germany's largest volunteer Linux support site
http://www.pro-linux.de/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
