Bug 32660 - Newer aic7xxx driver causes kernel oops on 64bit SMP machines
Newer aic7xxx driver causes kernel oops on 64bit SMP machines
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
alpha Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2001-03-22 01:37 EST by Phil Copeland
Modified: 2007-04-18 12:32 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-04-07 19:17:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Phil Copeland 2001-03-22 01:37:35 EST
I've proven that on boot, as a module, the aic7xxx_mod (new driver) oopses
the kernel on SMP alpha and not uniprocessor alpha. The older aic7xxx
driver continues to fuction normally for SMP and UNIP Alpha's.

This looks identical to
This is not a HW problem (I've since discounted that)

Code:  f440000a bge t1,.+44
 a02a01e0 x y
 a46a01e8 x y
 219f0002 x y
 482050c1 x y
 40610403 x y
*2c430000 x y
 484300c2 x y

Trace:8161b4 8172a4 825ee4 817af8 810c38 8128b0 82a900 812890 810044 853d3c
810e48 8543dc 82f524 82f548

(I'd to scribble that down,.. no save to disk thank you very much 8/ )

Which yields this
8161b4 - handle_IRQ_event             
8172a4 - handle_irq
825ee4 - dp264_srm_device_interrupt
817af8 - do_entInt       
810c38 - ret_from_sys_call
8128b0 - cpu_idle
82a900 - do_check_pgt_cache
812890 - cpu_idle
810044 - __smp_callin
853d3c - kmem_cache_grow
810e48 - ret_from_smp_fork
8543dc - kmem_cache_alloc
82f524 - do_fork
82f548 - do_fork

which is identical to the old bug report which at this time I'll have to
say was a big bogus because I'd too many things going on similtanously to
make a good bug report.

As the older driver *does* still work, and as you're probably under time
pressure would the recommendation be (at this time) to simply go with the
older driver and leave the newer one for harsher scruteny in a couple of
weeks time?

Comment 1 Justin T. Gibbs 2001-03-22 13:35:57 EST
This looks like something I've recently fixed.  The past driver releases
have been a bit lax in ensuring that they don't generate interrupts until
the driver is fully setup.  I still have to test the code on my EISA box
(will do so today) and the code should be released in 6.1.8 of the aic7xxx
Comment 2 Arjan van de Ven 2001-04-18 08:35:27 EDT
Merged 6.1.11

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