Bug 17206 - 2.2.16-21 USB modules cause problem on i840 SMP system?
Summary: 2.2.16-21 USB modules cause problem on i840 SMP system?
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: kernel
Version: 1.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Michael K. Johnson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-09-03 16:44 UTC by dunwoody
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2002-06-03 17:40:52 UTC
Embargoed:


Attachments (Terms of Use)

Description dunwoody 2000-09-03 16:44:50 UTC
This could well be pilot error or even a hardware problem, but here goes:

I have some Silicon Graphics 550 Visual Workstations, each with 2 800+ MHZ
Xeon CPUs and
a i840 chipset.   When I ran the 2.2.16-21smp kernel along with the rest of
the 2000/08/11 Rawhide
release on these systems, I noticed what seemed to be a problem with the
kernel USB modules.

Specifically, if  I "modprobe uhci" or "modprobe usb-uhci" (either way also
pulling in usbcore), then
isubsequently "insmod aic7xxx" so I can talk to SCSI, the system begins
probing the SCSI
devices (printing out progress on the console) and then hangs hard, not
even responding to the magic-sysrq-key sequences at the console.  So far I
haven't tried to debug this any further.

I tried this on two different SG550 systems and got the same result.   Each
of the systems had
a single disk drive on SCSI bus A, and no external USB devices attached.

This problem doesn't happen on SG550 (insmod aic7xxx works fine) if the
uhci and usbcore kernel modules are not loaded.

This problem doesn't happen on SG550 if I run the 2.2.16-21 kernel instead
of the 2.2.16-21smp kernel.

This problem doesn't happen with the 2.2.16-21smp kernel and uhci/usbcore
kernel modules loaded
on a 2-processor SG330 system, which uses a Via Apollo Pro chipset instead
of the i840 chipset
used in the SG550.

Is it possible that there could be some problem with the kernel USB stuff
in 2.2.16-21smp not being
SMP-safe?

If it helps for me to provide additional details, I'd be happy to do so.

Comment 1 Alan Cox 2000-09-16 22:01:14 UTC
First question - are the AIC7xxx and the USB controller sharing the same
interrupt line ?


Comment 2 dunwoody 2000-09-18 18:58:09 UTC
alan writes:
> are the AIC7xxx and the USB controller sharing the same interrupt line?

Good question -- I checked, and yes, looks like they are.  It's a dual-channel
SCSI controller
that's integrated into the motherboard (like the USB controller).  Perhaps an
elementary
question, but I don't know if it's possible to change these IRQ assignments in
my system, or how to do it if indeed it is possible.  Suggestions always
appreciated.

I got the following info using the 2.2.16-21 (not SMP) kernel, because of course
the 2.2.16-21smp
kernel locks up immediately on this system when aic7xxx and uhci are loaded.

dunwoody2:/1.bak> cat /proc/interrupts
           CPU0       
  0:      74644          XT-PIC  timer
  1:        373          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  5:       5782          XT-PIC  aic7xxx, aic7xxx, usb-uhci
  8:          1          XT-PIC  rtc
 10:       4037          XT-PIC  Intel ICH 82801AA, eth0
 12:       1085          XT-PIC  PS/2 Mouse
 13:          1          XT-PIC  fpu
NMI:          0
dunwoody2:/1.bak> lspci
00:00.0 Host bridge: Intel Corporation 82840 840 (Carmel) Chipset Host Bridge
(Hub A) (rev 01)
00:01.0 PCI bridge: Intel Corporation 82840 840 (Carmel) Chipset AGP Bridge (rev
01)
00:02.0 PCI bridge: Intel Corporation 82840 840 (Carmel) Chipset PCI Bridge (Hub
B) (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801AA PCI Bridge (rev 02)
00:1f.0 ISA bridge: Intel Corporation 82801AA ISA Bridge (LPC) (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801AA IDE (rev 02)
00:1f.2 USB Controller: Intel Corporation 82801AA USB (rev 02)
00:1f.3 SMBus: Intel Corporation 82801AA SMBus (rev 02)
00:1f.5 Multimedia audio controller: Intel Corporation 82801AA AC'97 Audio (rev
02)
02:1f.0 PCI bridge: Intel Corporation 82806AA PCI64 Hub PCI Bridge (rev 03)
03:00.0 PIC: Intel Corporation 82806AA PCI64 Hub Advanced Programmable Interrupt
Controller (rev 01)
03:03.0 SCSI storage controller: Adaptec 7899P (rev 01)
03:03.1 SCSI storage controller: Adaptec 7899P (rev 01)
04:08.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2164W [Millennium
II]
04:09.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2164W [Millennium
II]
04:0c.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08)
dunwoody2:/1.bak> lsmod
Module                  Size  Used by
nfs                    28768   1 (autoclean)
uhci                   17872   0 (unused)
usbcore                42088   0 [uhci]
autofs                  9124   2 (autoclean)
nfsd                  143844   8 (autoclean)
lockd                  31176   1 (autoclean) [nfs nfsd]
sunrpc                 52964   1 (autoclean) [nfs nfsd lockd]
ppp                    20236   0 (autoclean) (unused)
slhc                    4504   0 (autoclean) [ppp]
eepro100               16180   1 (autoclean)
agpgart                18600   0 (unused)
i810_audio             10600   2
soundcore               2596   2 [i810_audio]
ac97_codec              6980   0 [i810_audio]
aic7xxx               137432   2
dunwoody2:/1.bak>

Comment 3 Pete Zaitcev 2002-06-03 17:43:32 UTC
2.2 kernels had "opportunistic" USB support, so we could
not do enhancements. I struggled with USB on SMP for a year
before it started working decently on 2.4. No way in hell
I am backporting all that to 2.2. I suggest using 7.2 release
with 2.4.9-31 kernel (latest is 2.4.18, but I think VisWS
support was dropped from that)


Comment 4 dunwoody 2002-06-03 18:08:43 UTC
No problem here -- I'm running RH7.2+2.4.9-31 now and everything works great.
BTW, "VisWS" support was indeed dropped
from the kernel, but that applied only to the SGI 320 and 540 models.  The
SGI 230,330,550 models were very standard PCs.


Note You need to log in before you can comment on or make changes to this bug.