Hello,
I think that I have found a problem with proc_dir_entry(). It seems to
allow multiple /proc entries to be created with the same name, without
returning a NULL pointer. I asked the folks on #kernelnewbies, and they
said that perhaps this is a feature. In either case, I believe that the
following patch fixes the issue by checking if a proc entry already exists
before creating it. This mirrors the behavior of remove_proc_entry, which
checks for the presense of a proc entry before deleting it.
Thank you
- Brent
--- linux/fs/proc/generic.bak Tue Feb 5 10:51:30 2002
+++ linux/fs/proc/generic.c Tue Feb 5 11:03:24 2002
@@ -418,6 +418,7 @@
mode_t mode,
nlink_t nlink)
{
+ struct proc_dir_entry **p;
struct proc_dir_entry *ent = NULL;
const char *fn = name;
int len;
@@ -429,6 +430,12 @@
goto out;
len = strlen(fn);
+ /* check for a duplication */
+ for (p = &(*parent)->subdir; *p; p=&(*p)->next ) {
+ if (proc_match(len, fn, *p))
+ goto out;
+ }
+
ent = kmalloc(sizeof(struct proc_dir_entry) + len + 1, GFP_KERNEL);
if (!ent) goto out;
On Tue, Feb 05, 2002 at 09:52:55PM -0600, Brent Cook wrote:
> I think that I have found a problem with proc_dir_entry(). It seems to
> allow multiple /proc entries to be created with the same name, without
> returning a NULL pointer. I asked the folks on #kernelnewbies, and they
> said that perhaps this is a feature. In either case, I believe that the
> following patch fixes the issue by checking if a proc entry already exists
> before creating it. This mirrors the behavior of remove_proc_entry, which
> checks for the presense of a proc entry before deleting it.
The only instance I've seen of this happen is the acpi code.
Whilst the patch is good in the sense that it allows things like
/proc/acpi/button to become usable, the correct fix would be
to fix ACPI.
Maybe printk'ing a "tried to create duplicate xxx proc entry"
would be useful, so we at least don't paper over problems and
make them harder to find later.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Wed, 6 Feb 2002, Dave Jones wrote:
> On Tue, Feb 05, 2002 at 09:52:55PM -0600, Brent Cook wrote:
>
> > I think that I have found a problem with proc_dir_entry(). It seems to
> > allow multiple /proc entries to be created with the same name, without
> > returning a NULL pointer. I asked the folks on #kernelnewbies, and they
> > said that perhaps this is a feature. In either case, I believe that the
> > following patch fixes the issue by checking if a proc entry already exists
> > before creating it. This mirrors the behavior of remove_proc_entry, which
> > checks for the presense of a proc entry before deleting it.
>
> The only instance I've seen of this happen is the acpi code.
> Whilst the patch is good in the sense that it allows things like
> /proc/acpi/button to become usable, the correct fix would be
> to fix ACPI.
>
> Maybe printk'ing a "tried to create duplicate xxx proc entry"
> would be useful, so we at least don't paper over problems and
> make them harder to find later.
>
I had problems with loading kernel modules more in mind with this patch.
Try loading a kernel module that creates a /proc entry and then loading it
again with a different name. If the original module that created the /proc
entry is then unloaded, any further attempts to read the remaining proc
entry leads to a NULL pointer being handed back to the reading process.
I'm not sure about the printk's for that specific error condition, when
proc_dir_entry() already simply returns a NULL pointer on the two other
failure conditions that it checks. At the minimum, proc_dir_entry() should
hand back a NULL pointer on duplication. Then the calling module or kernel
code can look at the return value of proc_dir_entry() to determine if it
was successfull. The downside of just this is that you don't know why an
error occurred, just that one did.
It seems that this return value is handled differently (if at all ;)
throughout the kernel, so I don't know what effects having another error
condition might have on other code, such as acpi.
- Brent
On Thu, 7 Feb 2002, Brent Cook wrote:
> I had problems with loading kernel modules more in mind with this patch.
> Try loading a kernel module that creates a /proc entry and then loading it
> again with a different name. If the original module that created the /proc
> entry is then unloaded, any further attempts to read the remaining proc
> entry leads to a NULL pointer being handed back to the reading process.
"Doctor it hurts when I do this"
> It seems that this return value is handled differently (if at all ;)
> throughout the kernel, so I don't know what effects having another error
> condition might have on other code, such as acpi.
If the other code is doing something dumb, don't be afraid to break it.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Thu, 7 Feb 2002, Dave Jones wrote:
> On Thu, 7 Feb 2002, Brent Cook wrote:
>
> > I had problems with loading kernel modules more in mind with this patch.
> > Try loading a kernel module that creates a /proc entry and then loading it
> > again with a different name. If the original module that created the /proc
> > entry is then unloaded, any further attempts to read the remaining proc
> > entry leads to a NULL pointer being handed back to the reading process.
>
> "Doctor it hurts when I do this"
I do not think that there are any examples of how checking for duplicate
proc entries is useful at all for correct code. I did not mean to imply
that what I was doing was a smart or useful thing, just that it seemed odd
that it was even possible.
I can't argue that this fixes anything, it just gives proc a more
safety-scissors-like interface. The consequences of not having this check
are not life-threatening obviously. Its really more pedantic, and perhaps
an unnecessary performance penalty for correct code.
Maybe, someday there will be some sort of DEBUG flag to set in the kernel,
from which a slew of asserts and printk's will spring to life, pointing
out inconsistencies and bad assumptions. That is where this check would
probably work the best.
- Brent Cook
On Fri, Feb 08, 2002 at 10:13:26AM -0600, Brent Cook wrote:
> Maybe, someday there will be some sort of DEBUG flag to set in the kernel,
> from which a slew of asserts and printk's will spring to life, pointing
> out inconsistencies and bad assumptions. That is where this check would
> probably work the best.
>
Actually, there are seperate debug config options for different subsystems,
and I think that is good. The real problem is finding a way to add another
debug config option for procfs without littering the code with ifdefs...
Mike
On Fri, 8 Feb 2002, Mike Fedyk wrote:
> On Fri, Feb 08, 2002 at 10:13:26AM -0600, Brent Cook wrote:
> > Maybe, someday there will be some sort of DEBUG flag to set in the kernel,
> > from which a slew of asserts and printk's will spring to life, pointing
> > out inconsistencies and bad assumptions. That is where this check would
> > probably work the best.
> >
>
> Actually, there are seperate debug config options for different subsystems,
> and I think that is good. The real problem is finding a way to add another
> debug config option for procfs without littering the code with ifdefs...
No point. Check that file already exist and BUG() if it does.
Unconditionally. There's no need to be nice to broken code and yes,
any code that tries to register existing procfs entry _is_ broken.
That was never supposed to work.
Uttered "Alexander Viro" <[email protected]>, spoke thus:
> No point. Check that file already exist and BUG() if it does.
> Unconditionally. There's no need to be nice to broken code and yes,
> any code that tries to register existing procfs entry _is_ broken.
> That was never supposed to work.
Al, please confirm that your are asking Brent to reissue this patch with just
the checking and then BUG(). The current code fails but looks to the caller as
if it worked.
--
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- + -- -- -- -- -- -- -- -- -- --
Tommy Reynolds | mailto: <[email protected]>
Red Hat, Inc., Embedded Development Services | Phone: +1.256.704.9286
307 Wynn Drive NW, Huntsville, AL 35805 USA | FAX: +1.256.837.3839
Senior Software Developer | Mobile: +1.919.641.2923
On Fri, 8 Feb 2002, Mark Hahn wrote:
> > I can't argue that this fixes anything, it just gives proc a more
> > safety-scissors-like interface. The consequences of not having this check
>
> exactly why people oppose it: the kernel must be as sharp as possible.
> it should oops with a useful backtrace when a duplicate proc entry is attempted.
>
I'm on your side, really ;)
Currently, the kernel does not oops, produce a backtrace or anything for
this case. It doesn't really even fail in the normal sense, it just allows
something inconsistent to filesystems in general to happen without
indicating an error. What I have concluded from this is that proc is no
general filesystem, so there is no reason to treat it as such.
I can't argue that two birds in a bush are worth more than a bird in the
hand, the same as I can't argue that a check for an error is worth more
than the absence of that error.
I was really more interested in what its like to submit a kernel patch
than anything else (hmmph! tourists!) Thanks, it has been enlightening.
- Brent
Dear Kernel Troubleshooters,
I have an ABIT VP6 motherboard, using the VIA Apollo chipset and 2 700Mhz
PIII's, but please don't hold that against me. The system is running
2.4.19-pre6. I believe that I either have a system that has trouble
handling a sudden bursts of interrupts, or have found a fault in mouse
handling.
When using a PS/2 mouse, the system tends to hang completely whenever
there is sudden mouse movement after a brief period of inactivity when
using X11 or gpm (this usually occurs within an hour). If I run the system
with one processor, this hang occurs less frequently. Also, if I disable
ACPI in the bios, the hang also occurs less frequently, but in all cases,
the system is stuck within a few hours of normal use (sometimes a few
minutes.)
When I run the system using a USB mouse (using the regular usb-uhci driver
with the hci or usbmouse drivers), within a couple of hours with both
processors installed, the mouse hangs, but does not hang the entire
system. Luckily, I was able to get dmesg to run, which is posted at the
bottom of this message. This chronicles up to the the first USB mouse
hang. The system had run overnight, but when I touched the mouse in the
morning, it stopped within ten minutes.
What appears to happen in both mouse cases is that an cascade of
interrupts occur, triggered by the mouse, which does not leave the
interrupt handler properly. If I could get my system console to redirect
to a serial terminal, I would bet that an interrupt problem is reported by
the kernel shortly before the hang with the PS/2 mouse. Is it true that
Linux allows hardware interrupts to interrupt other hardware interrupts?
Would a mouse be able to cause so many interrupts that some sort of stack
for recursing back through interrupt handlers will overflow? Or, do I just
have bad hardware?
I have already tried removing memory, adding memory, changing processors,
video cards. The only thing that has remained constant is the VP6
motherboard and the hard drive.
Thanks for any help. I'm going to see if hardware interrupts are disabled
while handling the mouse for now.
- Brent
Linux version 2.4.19-pre6 (busterb@stampy) (gcc version 2.95.3 20010315 (release)) #6 SMP Tue Apr 9 20:40:36 CDT 2002
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000003fff0000 (usable)
BIOS-e820: 000000003fff0000 - 000000003fff3000 (ACPI NVS)
BIOS-e820: 000000003fff3000 - 0000000040000000 (ACPI data)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
Warning only 896MB will be used.
Use a HIGHMEM enabled kernel.
found SMP MP-table at 000f5700
hm, page 000f5000 reserved twice.
hm, page 000f6000 reserved twice.
hm, page 000f1000 reserved twice.
hm, page 000f2000 reserved twice.
On node 0 totalpages: 229376
zone(0): 4096 pages.
zone(1): 225280 pages.
zone(2): 0 pages.
Intel MultiProcessor Specification v1.4
Virtual Wire compatibility mode.
OEM ID: OEM00000 Product ID: PROD00000000 APIC at: 0xFEE00000
Processor #0 Pentium(tm) Pro APIC version 17
Processor #1 Pentium(tm) Pro APIC version 17
I/O APIC #2 Version 17 at 0xFEC00000.
Processors: 2
Kernel command line: auto BOOT_IMAGE=linux2419p6 ro root=307
Initializing CPU#0
Detected 703.183 MHz processor.
Console: colour VGA+ 80x50
Calibrating delay loop... 1402.47 BogoMIPS
Memory: 905028k/917504k available (1152k kernel code, 12092k reserved, 387k data, 232k init, 0k highmem)
Dentry-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Mount-cache hash table entries: 16384 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 65536 (order: 6, 262144 bytes)
Page-cache hash table entries: 262144 (order: 8, 1048576 bytes)
CPU: Before vendor init, caps: 0387fbff 00000000 00000000, vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU: After vendor init, caps: 0387fbff 00000000 00000000 00000000
CPU serial number disabled.
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After generic, caps: 0383fbff 00000000 00000000 00000000
CPU: Common caps: 0383fbff 00000000 00000000 00000000
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
CPU: Before vendor init, caps: 0383fbff 00000000 00000000, vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU: After vendor init, caps: 0383fbff 00000000 00000000 00000000
Intel machine check reporting enabled on CPU#0.
CPU: After generic, caps: 0383fbff 00000000 00000000 00000000
CPU: Common caps: 0383fbff 00000000 00000000 00000000
CPU0: Intel Pentium III (Coppermine) stepping 06
per-CPU timeslice cutoff: 730.87 usecs.
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Booting processor 1/1 eip 2000
Initializing CPU#1
masked ExtINT on CPU#1
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Calibrating delay loop... 1405.74 BogoMIPS
CPU: Before vendor init, caps: 0387fbff 00000000 00000000, vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU: After vendor init, caps: 0387fbff 00000000 00000000 00000000
CPU serial number disabled.
Intel machine check reporting enabled on CPU#1.
CPU: After generic, caps: 0383fbff 00000000 00000000 00000000
CPU: Common caps: 0383fbff 00000000 00000000 00000000
CPU1: Intel Pentium III (Coppermine) stepping 06
Total of 2 processors activated (2808.21 BogoMIPS).
ENABLING IO-APIC IRQs
Setting 2 in the phys_id_present_map
...changing IO-APIC physical APIC ID to 2 ... ok.
init IO_APIC IRQs
IO-APIC (apicid-pin) 2-0, 2-5, 2-10, 2-11, 2-12, 2-20, 2-21, 2-22, 2-23 not connected.
..TIMER: vector=0x31 pin1=2 pin2=0
number of MP IRQ sources: 19.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................
IO APIC #2......
.... register #00: 02000000
....... : physical APIC id: 02
.... register #01: 00178011
....... : max redirection entries: 0017
....... : PRQ implemented: 1
....... : IO APIC version: 0011
.... register #02: 00000000
....... : arbitration: 00
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 000 00 1 0 0 0 0 0 0 00
01 003 03 0 0 0 0 0 1 1 39
02 003 03 0 0 0 0 0 1 1 31
03 003 03 0 0 0 0 0 1 1 41
04 003 03 0 0 0 0 0 1 1 49
05 000 00 1 0 0 0 0 0 0 00
06 003 03 0 0 0 0 0 1 1 51
07 003 03 0 0 0 0 0 1 1 59
08 003 03 0 0 0 0 0 1 1 61
09 003 03 0 0 0 0 0 1 1 69
0a 000 00 1 0 0 0 0 0 0 00
0b 000 00 1 0 0 0 0 0 0 00
0c 000 00 1 0 0 0 0 0 0 00
0d 003 03 0 0 0 0 0 1 1 71
0e 003 03 0 0 0 0 0 1 1 79
0f 003 03 0 0 0 0 0 1 1 81
10 003 03 1 1 0 1 0 1 1 89
11 003 03 1 1 0 1 0 1 1 91
12 003 03 1 1 0 1 0 1 1 99
13 003 03 1 1 0 1 0 1 1 A1
14 000 00 1 0 0 0 0 0 0 00
15 000 00 1 0 0 0 0 0 0 00
16 000 00 1 0 0 0 0 0 0 00
17 000 00 1 0 0 0 0 0 0 00
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
IRQ16 -> 0:16
IRQ17 -> 0:17
IRQ18 -> 0:18
IRQ19 -> 0:19
.................................... done.
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 703.1004 MHz.
..... host bus clock speed is 100.4427 MHz.
cpu: 0, clocks: 1004427, slice: 334809
CPU0<T0:1004416,T1:669600,D:7,S:334809,C:1004427>
cpu: 1, clocks: 1004427, slice: 334809
CPU1<T0:1004416,T1:334784,D:14,S:334809,C:1004427>
checking TSC synchronization across CPUs: passed.
Waiting on wait_init_idle (map = 0x2)
All processors have done init_idle
PCI: PCI BIOS revision 2.10 entry at 0xfb370, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 0: assuming transparent
PCI: Using IRQ router VIA [1106/0686] at 00:07.0
PCI->APIC IRQ transform: (B0,I7,P3) -> 19
PCI->APIC IRQ transform: (B0,I7,P3) -> 19
PCI->APIC IRQ transform: (B0,I10,P0) -> 17
PCI->APIC IRQ transform: (B0,I12,P0) -> 19
PCI->APIC IRQ transform: (B0,I14,P0) -> 18
PCI->APIC IRQ transform: (B1,I0,P0) -> 16
PCI: Enabling Via external APIC routing
PCI: Via IRQ fixup for 00:07.2, from 5 to 3
PCI: Via IRQ fixup for 00:07.3, from 5 to 3
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16)
apm: disabled - APM is not SMP safe.
Starting kswapd
Journalled Block Device driver loaded
devfs: v1.12 (20020219) Richard Gooch ([email protected])
devfs: boot_options: 0x1
ACPI: Core Subsystem version [20011018]
ACPI: Subsystem enabled
Detected PS/2 Mouse Port.
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI SERIAL_ACPI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1
ide0: BM-DMA at 0x9000-0x9007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0x9008-0x900f, BIOS settings: hdc:DMA, hdd:DMA
HPT370: IDE controller on PCI bus 00 dev 70
HPT370: chipset revision 3
HPT370: not 100% native mode: will probe irqs later
HPT370: using 33MHz PCI clock
ide2: BM-DMA at 0xcc00-0xcc07, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0xcc08-0xcc0f, BIOS settings: hdg:pio, hdh:pio
hda: Maxtor 90845D4, ATA DISK drive
hdb: Pioneer CD-ROM ATAPI Model DR-A02S 0108, ATAPI CD/DVD-ROM drive
hdc: Maxtor 90845D4, ATA DISK drive
hdd: CREATIVE DVD-ROM DVD6240E, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 16514064 sectors (8455 MB) w/256KiB Cache, CHS=16383/16/63, UDMA(33)
hdc: 16514064 sectors (8455 MB) w/512KiB Cache, CHS=16383/16/63, UDMA(33)
hdb: ATAPI 24X CD-ROM drive, 128kB Cache, DMA
Uniform CD-ROM driver Revision: 3.12
hdd: ATAPI 24X DVD-ROM drive, 512kB Cache, DMA
Partition check:
/dev/ide/host0/bus0/target0/lun0: p1 < p5 p6 p7 >
/dev/ide/host0/bus1/target0/lun0: [PTBL] [1027/255/63] p1 p2 p3
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 816M
agpgart: Detected Via Apollo Pro chipset
agpgart: AGP aperture is 64M @ 0xd0000000
mice: PS/2 mouse device common for all mice
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 8192 buckets, 64Kbytes
TCP: Hash tables configured (established 262144 bind 65536)
Linux IP multicast router 0.06 plus PIM-SM
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Mounted devfs on /dev
Freeing unused kernel memory: 232k freed
Adding Swap: 262512k swap-space (priority -1)
EXT3 FS 2.4-0.9.17, 10 Jan 2002 on ide0(3,7), internal journal
kjournald starting. Commit interval 5 seconds
EXT3 FS 2.4-0.9.17, 10 Jan 2002 on ide0(3,6), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
parport0: PC-style at 0x378 [PCSPP,TRISTATE,EPP]
parport_pc: Via 686A parallel port: io=0x378
lp0: using parport0 (polling).
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb.c: registered new driver hiddev
usb.c: registered new driver hid
hid-core.c: v1.8 Andreas Gal, Vojtech Pavlik <[email protected]>
hid-core.c: USB HID support drivers
Linux Tulip driver version 0.9.15-pre10 (Mar 8, 2002)
tulip0: MII transceiver #1 config 3000 status 7829 advertising 01e1.
eth0: Lite-On 82c168 PNIC rev 32 at 0xf8886000, 02:00:09:E3:27:36, IRQ 17.
eth0: Setting full-duplex based on MII#1 link partner capability of 45e1.
usb.c: deregistering driver hiddev
usb.c: deregistering driver hid
usb.c: registered new driver usb_mouse
usbmouse.c: v1.6:USB HID Boot Protocol mouse driver
usb.c: deregistering driver usb_mouse
usb.c: deregistering driver usbdevfs
usb.c: deregistering driver hub
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-uhci.c: $Revision: 1.275 $ time 20:14:35 Apr 9 2002
usb-uhci.c: High bandwidth mode enabled
usb-uhci.c: USB UHCI at I/O 0x9400, IRQ 19
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
usb-uhci.c: USB UHCI at I/O 0x9800, IRQ 19
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 2
hub.c: USB hub found
hub.c: 2 ports detected
usb-uhci.c: v1.275:USB Universal Host Controller Interface driver
hub.c: USB new device connect on bus1/1, assigned device number 2
usb.c: USB device 2 (vend/prod 0x45e/0x39) is not claimed by any active driver.
usb.c: registered new driver usb_mouse
usb-uhci.c: interrupt, status 3, frame# 717
input0: Microsoft Microsoft IntelliMouse? Optical on usb1:2.0
usbmouse.c: v1.6:USB HID Boot Protocol mouse driver
[drm] AGP 0.99 on VIA Apollo Pro @ 0xd0000000 64MB
[drm] Initialized mga 3.0.2 20010321 on minor 0
usb.c: USB disconnect on device 2
hub.c: USB new device connect on bus1/1, assigned device number 3
usb-uhci.c: interrupt, status 3, frame# 62
input0: Microsoft Microsoft IntelliMouse? Optical on usb1:3.0
usb.c: USB disconnect on device 3
hub.c: USB new device connect on bus1/1, assigned device number 4
usb-uhci.c: interrupt, status 3, frame# 1668
input0: Microsoft Microsoft IntelliMouse? Optical on usb1:4.0
usb.c: USB disconnect on device 4
hub.c: USB new device connect on bus1/1, assigned device number 5
usb_control/bulk_msg: timeout
usb.c: USB device not accepting new address=5 (error=-110)
hub.c: USB new device connect on bus1/1, assigned device number 6
usb_control/bulk_msg: timeout
usb.c: USB device not accepting new address=6 (error=-110)
Hello!
On Wed, Apr 10, 2002 at 09:02:05AM -0500, Brent Cook wrote:
> I have an ABIT VP6 motherboard, using the VIA Apollo chipset and 2 700Mhz
> PIII's, but please don't hold that against me. The system is running
> 2.4.19-pre6. I believe that I either have a system that has trouble
> handling a sudden bursts of interrupts, or have found a fault in mouse
> handling.
Have you tried to change MPS mode to 1.1 from 1.4 (I see addres message timeouts
in your log)?
> I have already tried removing memory, adding memory, changing processors,
> video cards. The only thing that has remained constant is the VP6
> motherboard and the hard drive.
My VP6 died on me recently with some funny symptoms:
it hangs in X when I start netscape and move mouse, or if I do
bk clone on kernel tree, it dies with
kernel BUG at /usr/src/linux-2.4.18/include/asm/smplock.h:62!
BUG in various places pretty soon.
(this BUG is only appears if 2 CPUs are present in motherboard).
So if your troubles began only recently, you might want to try another
motherboard just to be sure.
Bye,
Oleg
On Wed, 10 Apr 2002, Oleg Drokin wrote:
> Hello!
>
> On Wed, Apr 10, 2002 at 09:02:05AM -0500, Brent Cook wrote:
>
> > I have an ABIT VP6 motherboard, using the VIA Apollo chipset and 2 700Mhz
> > PIII's, but please don't hold that against me. The system is running
> > 2.4.19-pre6. I believe that I either have a system that has trouble
> > handling a sudden bursts of interrupts, or have found a fault in mouse
> > handling.
>
> Have you tried to change MPS mode to 1.1 from 1.4 (I see addres message timeouts
> in your log)?
No, I had not. I will though, and will report if this causes some change.
Everything looks fine for the first five minutes though.
> > I have already tried removing memory, adding memory, changing processors,
> > video cards. The only thing that has remained constant is the VP6
> > motherboard and the hard drive.
>
> My VP6 died on me recently with some funny symptoms:
> it hangs in X when I start netscape and move mouse, or if I do
> bk clone on kernel tree, it dies with
> kernel BUG at /usr/src/linux-2.4.18/include/asm/smplock.h:62!
Very interesting. I could do the same thing, and have a similar lock with
a PS/2 mouse. I will start looking in smplock.h if the MPS change does not
help.
> BUG in various places pretty soon.
> (this BUG is only appears if 2 CPUs are present in motherboard).
> So if your troubles began only recently, you might want to try another
> motherboard just to be sure.
I received the motherboard used, so I do not know if this is a recent
development. I have tried several other kernels which all show the same
locking behavior with PS/2 mice (2.4.17, 2.4.18, 2.5.7-dj3.) The previous
owner ran Windows XP (developer preview) on the board, and it had a
tendency to lock often, especially under high IO. I attributed this to
software issues, though now I wonder why the previous owner _really_ gave
it to me!
I have used a Tyan Tiger 100 with two processors and an Intel BX chipset,
with great success and no similar locks, so I am 50% certain that a
hardware difference is the root cause of the problem. Hopefully, someone
else will have seen similar problems.
> Bye,
> Oleg
>
On Wed, Apr 10, 2002 at 11:43:13AM -0500, Brent Cook wrote:
> I have used a Tyan Tiger 100 with two processors and an Intel BX
> chipset, with great success and no similar locks, so I am 50% certain
> that a hardware difference is the root cause of the problem.
> Hopefully, someone else will have seen similar problems.
Sorry to jump in the middle of thread... I missed the previous posts.
I have VP6, and it freezes when PS/2 mouse is unplugged and then plugged
back in. When the mouse is pulled out, it's okey. But, when the mouse
is plugged back in, the machine hangs. This occurs in BP6 as well, I've
been tolded.
--
William Park, Open Geometry Consulting, <[email protected]>
8 CPU cluster, NAS, (Slackware) Linux, Python, LaTeX, Vim, Mutt, Tin
Hello!
On Wed, Apr 10, 2002 at 11:43:13AM -0500, Brent Cook wrote:
> > > I have already tried removing memory, adding memory, changing processors,
> > > video cards. The only thing that has remained constant is the VP6
> > > motherboard and the hard drive.
> > My VP6 died on me recently with some funny symptoms:
> > it hangs in X when I start netscape and move mouse, or if I do
> > bk clone on kernel tree, it dies with
> > kernel BUG at /usr/src/linux-2.4.18/include/asm/smplock.h:62!
> Very interesting. I could do the same thing, and have a similar lock with
> a PS/2 mouse. I will start looking in smplock.h if the MPS change does not
> help.
No need to look there.
If you see sch a BUG message in your logs, you seems to have bad hardware.
> > BUG in various places pretty soon.
> > (this BUG is only appears if 2 CPUs are present in motherboard).
> > So if your troubles began only recently, you might want to try another
> > motherboard just to be sure.
> I received the motherboard used, so I do not know if this is a recent
> development. I have tried several other kernels which all show the same
> locking behavior with PS/2 mice (2.4.17, 2.4.18, 2.5.7-dj3.) The previous
> owner ran Windows XP (developer preview) on the board, and it had a
> tendency to lock often, especially under high IO. I attributed this to
> software issues, though now I wonder why the previous owner _really_ gave
> it to me!
Yeah, Windows crashed on me too (win2k, though) when I tried.
Luckily I bought my as a new one 11 months ago and I still have 1 month of
warranty, and the good thing is my board will be replaced tomorrow ;)
> I have used a Tyan Tiger 100 with two processors and an Intel BX chipset,
> with great success and no similar locks, so I am 50% certain that a
> hardware difference is the root cause of the problem. Hopefully, someone
> else will have seen similar problems.
Who knows. May be people in question silently replaced damaged harware with
good one and forgot about it already ;)
Or may be they ustill use windows and blame Microsoft on all the crashes ;)
Bye,
Oleg
On Wednesday 10 April 2002 11:23 am, Oleg Drokin wrote:
> Hello!
>
> On Wed, Apr 10, 2002 at 09:02:05AM -0500, Brent Cook wrote:
> > I have an ABIT VP6 motherboard, using the VIA Apollo chipset and 2
> > 700Mhz PIII's, but please don't hold that against me. The system is
> > running 2.4.19-pre6. I believe that I either have a system that has
> > trouble handling a sudden bursts of interrupts, or have found a fault
> > in mouse handling.
>
> Have you tried to change MPS mode to 1.1 from 1.4 (I see addres message
> timeouts in your log)?
>
> > I have already tried removing memory, adding memory, changing
> > processors, video cards. The only thing that has remained constant is
> > the VP6 motherboard and the hard drive.
>
> My VP6 died on me recently with some funny symptoms:
> it hangs in X when I start netscape and move mouse, or if I do
> bk clone on kernel tree, it dies with
> kernel BUG at /usr/src/linux-2.4.18/include/asm/smplock.h:62!
> BUG in various places pretty soon.
> (this BUG is only appears if 2 CPUs are present in motherboard).
> So if your troubles began only recently, you might want to try another
> motherboard just to be sure.
I have a VP6 with 2 CPUs. Its has both a PS/2 mouse and a usb mouse. Its
been up for 90 days and handled lots of mouse interrupts. See below.
CPU0 CPU1
0: 392228152 392338774 IO-APIC-edge timer
1: 312494 312380 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
3: 1 3 IO-APIC-edge serial
12: 40362907 40324010 IO-APIC-edge PS/2 Mouse
14: 3386577 3383180 IO-APIC-edge ide0
15: 679030 672810 IO-APIC-edge ide1
17: 1165246 1162993 IO-APIC-level DC395x_TRM
18: 83937970 83935445 IO-APIC-level ide2, eth0
19: 131956 132468 IO-APIC-level es1371, usb-uhci, usb-uhci
NMI: 0 0
LOC: 784686934 784686951
ERR: 191
MIS: 0
Its running a recent kernel. Maybe 2.4.18 is broken. Here's a uname -a
Linux flash 2.5.0 #16 SMP Wed Jan 9 16:48:16 EST 2002 i686 unknown
johna
On Wed, 10 Apr 2002, John Adams wrote:
> On Wednesday 10 April 2002 11:23 am, Oleg Drokin wrote:
> > Hello!
> >
> > On Wed, Apr 10, 2002 at 09:02:05AM -0500, Brent Cook wrote:
> > > I have an ABIT VP6 motherboard, using the VIA Apollo chipset and 2
> > > 700Mhz PIII's, but please don't hold that against me. The system is
> > > running 2.4.19-pre6. I believe that I either have a system that has
> > > trouble handling a sudden bursts of interrupts, or have found a fault
> > > in mouse handling.
> >
> > Have you tried to change MPS mode to 1.1 from 1.4 (I see addres message
> > timeouts in your log)?
> >
> > > I have already tried removing memory, adding memory, changing
> > > processors, video cards. The only thing that has remained constant is
> > > the VP6 motherboard and the hard drive.
> >
> > My VP6 died on me recently with some funny symptoms:
> > it hangs in X when I start netscape and move mouse, or if I do
> > bk clone on kernel tree, it dies with
> > kernel BUG at /usr/src/linux-2.4.18/include/asm/smplock.h:62!
> > BUG in various places pretty soon.
> > (this BUG is only appears if 2 CPUs are present in motherboard).
> > So if your troubles began only recently, you might want to try another
> > motherboard just to be sure.
>
> I have a VP6 with 2 CPUs. Its has both a PS/2 mouse and a usb mouse. Its
> been up for 90 days and handled lots of mouse interrupts. See below.
> CPU0 CPU1
> 0: 392228152 392338774 IO-APIC-edge timer
> 1: 312494 312380 IO-APIC-edge keyboard
> 2: 0 0 XT-PIC cascade
> 3: 1 3 IO-APIC-edge serial
> 12: 40362907 40324010 IO-APIC-edge PS/2 Mouse
> 14: 3386577 3383180 IO-APIC-edge ide0
> 15: 679030 672810 IO-APIC-edge ide1
> 17: 1165246 1162993 IO-APIC-level DC395x_TRM
> 18: 83937970 83935445 IO-APIC-level ide2, eth0
> 19: 131956 132468 IO-APIC-level es1371, usb-uhci, usb-uhci
> NMI: 0 0
> LOC: 784686934 784686951
> ERR: 191
> MIS: 0
Oleg's suggestion about MPS didn't work, but it was fun. Instead of dying
instantly, a USB mouse pauses about 9 times before it finally halts. The
device in dmesg also disconnects/reconnects 9 times before it is unable to
assign a device number again to the mouse. PS/2 still locks the entire
machine. Loading and unloading usb-uhci.o does reinitialize the USB mouse
for a while, so it is fixable w/o rebooting.
This is also interesting. You appear to not have the strange ACPI device
at hardware interrupt 9 that I do. While the VP6 BIOS does not have the
option to turn off ACPI, perhaps I should try one of the hacked bioses at
abitvp6.com to turn off ACPI (maybe it is the culprit..) This is my
current situation (right after a USB lock):
CPU0 CPU1
0: 260203 267484 IO-APIC-edge timer
1: 10471 10704 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
5: 29249 29198 IO-APIC-level usb-uhci, usb-uhci
9: 0 0 IO-APIC-edge acpi
10: 13715 13332 IO-APIC-level eth0
14: 6255 5839 IO-APIC-edge ide0
15: 10 3 IO-APIC-edge ide1
NMI: 0 0
LOC: 527647 527647
ERR: 0
MIS: 0
The acpi device appears whether or not I have ACPI support in the kernel.
- Brent
> Its running a recent kernel. Maybe 2.4.18 is broken. Here's a uname -a
> Linux flash 2.5.0 #16 SMP Wed Jan 9 16:48:16 EST 2002 i686 unknown
>
> johna
2.5 exhibits similar behavior.
Thanks,
Brent
On Wed, Apr 10, 2002 at 12:49:24PM -0400, William Park wrote:
> I have VP6, and it freezes when PS/2 mouse is unplugged and then plugged
> back in. When the mouse is pulled out, it's okey. But, when the mouse
> is plugged back in, the machine hangs. This occurs in BP6 as well, I've
> been tolded.
doesn't happen on my bp6, with one or two processors.
j.
--
R N G G "Well, there it goes again... And we just sit
I G G G here without opposable thumbs." -- gary larson
As another data point I also have a VP6 (2x PIII 700)
Up until Tuesday only had a serial mouse, but now has a PS/2
Never any problems before (on most 2.4.x kernels) now running 2.4.17 + Int +
XFS and haven't seen any problems after a couple of heavy desktop session ~6
hours.
But I can keep an eye out, not at the machine right now but can forward on
some info tonight if required.
Jeremy
> -----Original Message-----
> From: John Adams [mailto:[email protected]]
> Sent: 10 April 2002 18:17
> To: [email protected]; Oleg Drokin; Brent Cook
> Cc: [email protected]
> Subject: Re: Mouse interrupts: the death knell of a VP6
>
>
> On Wednesday 10 April 2002 11:23 am, Oleg Drokin wrote:
> > Hello!
> >
> > On Wed, Apr 10, 2002 at 09:02:05AM -0500, Brent Cook wrote:
> > > I have an ABIT VP6 motherboard, using the VIA Apollo chipset and 2
> > > 700Mhz PIII's, but please don't hold that against me. The
> system is
> > > running 2.4.19-pre6. I believe that I either have a
> system that has
> > > trouble handling a sudden bursts of interrupts, or have
> found a fault
> > > in mouse handling.
> >
> > Have you tried to change MPS mode to 1.1 from 1.4 (I see
> addres message
> > timeouts in your log)?
> >
> > > I have already tried removing memory, adding memory, changing
> > > processors, video cards. The only thing that has remained
> constant is
> > > the VP6 motherboard and the hard drive.
> >
> > My VP6 died on me recently with some funny symptoms:
> > it hangs in X when I start netscape and move mouse, or if I do
> > bk clone on kernel tree, it dies with
> > kernel BUG at /usr/src/linux-2.4.18/include/asm/smplock.h:62!
> > BUG in various places pretty soon.
> > (this BUG is only appears if 2 CPUs are present in motherboard).
> > So if your troubles began only recently, you might want to
> try another
> > motherboard just to be sure.
>
> I have a VP6 with 2 CPUs. Its has both a PS/2 mouse and a
> usb mouse. Its
> been up for 90 days and handled lots of mouse interrupts. See below.
> CPU0 CPU1
> 0: 392228152 392338774 IO-APIC-edge timer
> 1: 312494 312380 IO-APIC-edge keyboard
> 2: 0 0 XT-PIC cascade
> 3: 1 3 IO-APIC-edge serial
> 12: 40362907 40324010 IO-APIC-edge PS/2 Mouse
> 14: 3386577 3383180 IO-APIC-edge ide0
> 15: 679030 672810 IO-APIC-edge ide1
> 17: 1165246 1162993 IO-APIC-level DC395x_TRM
> 18: 83937970 83935445 IO-APIC-level ide2, eth0
> 19: 131956 132468 IO-APIC-level es1371, usb-uhci, usb-uhci
> NMI: 0 0
> LOC: 784686934 784686951
> ERR: 191
> MIS: 0
>
> Its running a recent kernel. Maybe 2.4.18 is broken. Here's
> a uname -a
> Linux flash 2.5.0 #16 SMP Wed Jan 9 16:48:16 EST 2002 i686 unknown
>
> johna
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Sat, 15 Jun 2002, Dave Jones wrote:
> On Fri, Jun 14, 2002 at 05:30:01PM -0500, Brent Cook wrote:
>
> > Looks like there is a problem with NFSv3 and file permissions in the DJ
> > kernels.
> >
> > A file that is marked as executable will lose its executable flag whenever
> > it is written to. I suspect the proble lies in the changes to the NFS file
> > info cacheing in the DJ kernels at least since 2.5.20-dj1 (I was unable
> > to find where this change occured in the changelog).
>
> The NFS changes need going over. I'll see whats left after backing out
> Trond's READDIRPLUS patch. I'm expecting it to be just some small bits
> like BKL shifting around, but that shouldn't be causing the problems
> you saw..
>
> Dave
>
You were right. Backing out READDIRPLUS fixes the problem with NFS and
files losing the executable bit. I just tried things with 2.5.23-dj1 and
all is well.
Here are a couple of compile fixes for that kernel though:
drivers/input/keyboard/ps2serkbd.c is missing
#include <linux/tqueue.h>
drivers/input/serio/ct82c710.c is missing
#include <linux/sched.h>
#include <asm/errno.h>
Thanks,
- Brent
On Wed, Jun 19, 2002 at 12:45:31PM -0500, Brent Cook wrote:
> You were right. Backing out READDIRPLUS fixes the problem with NFS and
> files losing the executable bit. I just tried things with 2.5.23-dj1 and
> all is well.
Excellent, thanks for testing..
> Here are a couple of compile fixes for that kernel though:
Thanks, added to the pending queue with the others
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
Here's another error I'm getting from sched.c and don't seem to be
able to find where it should be #define'd.
gcc -Wp,-MD,./.sched.o.d -D__KERNEL__
-I/usr/src/linux-2.5.23/include -Wall -Wstrict-prototypes
-Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing
-fno-common -pipe -mpreferred-stack-boundary=2 -march=i686
-malign-functions=4 -nostdinc -iwithprefix include
-fno-omit-frame-pointer -DKBUILD_BASENAME=sched -c -o sched.o
sched.c
sched.c: In function `sys_sched_setaffinity':
sched.c:1332: `cpu_online_map' undeclared (first use in this function)
sched.c:1332: (Each undeclared identifier is reported only once
sched.c:1332: for each function it appears in.)
sched.c: In function `sys_sched_getaffinity':
sched.c:1391: `cpu_online_map' undeclared (first use in this function)
make[1]: *** [sched.o] Error 1
The only reference I can find is in smp.h but don't see it actually
declared there either only used. I'm not using smp and have
CONFIG_smp set to no.
Kirk
--
Kirk Reiser The Computer Braille Facility
e-mail: [email protected] University of Western Ontario
phone: (519) 661-3061
On 19 Jun 2002, Kirk Reiser wrote:
> Here's another error I'm getting from sched.c and don't seem to be
> able to find where it should be #define'd.
>
> gcc -Wp,-MD,./.sched.o.d -D__KERNEL__
> -I/usr/src/linux-2.5.23/include -Wall -Wstrict-prototypes
> -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing
> -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686
> -malign-functions=4 -nostdinc -iwithprefix include
> -fno-omit-frame-pointer -DKBUILD_BASENAME=sched -c -o sched.o
> sched.c
> sched.c: In function `sys_sched_setaffinity':
> sched.c:1332: `cpu_online_map' undeclared (first use in this function)
> sched.c:1332: (Each undeclared identifier is reported only once
> sched.c:1332: for each function it appears in.)
> sched.c: In function `sys_sched_getaffinity':
> sched.c:1391: `cpu_online_map' undeclared (first use in this function)
> make[1]: *** [sched.o] Error 1
The following patch (that is already in Linus' BK repository) fixes this:
--- a/include/linux/smp.h Wed Jun 19 00:00:41 2002
+++ b/include/linux/smp.h Wed Jun 19 00:00:41 2002
@@ -86,6 +86,7 @@
#define smp_call_function(func,info,retry,wait) ({ 0; })
static inline void smp_send_reschedule(int cpu) { }
static inline void smp_send_reschedule_all(void) { }
+#define cpu_online_map 1
#define cpu_online(cpu) 1
#define num_online_cpus() 1
#define __per_cpu_data
> Kirk
cu
Adrian
--
You only think this is a free country. Like the US the UK spends a lot of
time explaining its a free country because its a police state.
Alan Cox
Hi,
Looks like there is a problem with NFSv3 and file permissions in the DJ
kernels.
A file that is marked as executable will lose its executable flag whenever
it is written to. I suspect the proble lies in the changes to the NFS file
info cacheing in the DJ kernels at least since 2.5.20-dj1 (I was unable
to find where this change occured in the changelog).
Here is one example:
Enter NFS mount (in this case, the NFS server is a FreeBSD 4.6 machine)
Compile a simple program; gcc hello.c -o hello
Result: hello has the following permissions: -rw-r--r--
Modify the permissions manually; chmod 755 hello
Result: hello has the following permissions: -rwxr-xr-x
Here is another:
Enter NFS mount
Compile a simple program; gcc hello.c -o hello
Result: hello has the following permissions: -rw-r--r--
Unmount the NFS mount; umount /home
Remount the NFS mount; mount server:/home /home
Result: hello has the following permissions: -rwxr-xr-x
Here is the final one:
Enter NFS mount, find a file with executable permissions;
Edit a file; vi whahoo.sh
Save and close the file
Results: file has the following permissions: -rw-r--r--
So, in the process of writing a file, its executable bits are lost. Can
someone help? The problem is not present with vanilla Linux-2.5.20.
Regards,
- Brent Cook
On Fri, Jun 14, 2002 at 05:30:01PM -0500, Brent Cook wrote:
> Looks like there is a problem with NFSv3 and file permissions in the DJ
> kernels.
>
> A file that is marked as executable will lose its executable flag whenever
> it is written to. I suspect the proble lies in the changes to the NFS file
> info cacheing in the DJ kernels at least since 2.5.20-dj1 (I was unable
> to find where this change occured in the changelog).
The NFS changes need going over. I'll see whats left after backing out
Trond's READDIRPLUS patch. I'm expecting it to be just some small bits
like BKL shifting around, but that shouldn't be causing the problems
you saw..
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs