Bug 32660

Summary:	Newer aic7xxx driver causes kernel oops on 64bit SMP machines
Product:	[Retired] Red Hat Linux	Reporter:	Phil Copeland <copeland>
Component:	kernel	Assignee:	Arjan van de Ven <arjanv>
Status:	CLOSED RAWHIDE	QA Contact:	Brock Organ <borgan>
Severity:	high	Docs Contact:
Priority:	medium
Version:	7.3	CC:	gibbs
Target Milestone:	---
Target Release:	---
Hardware:	alpha
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-04-07 23:17:19 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Phil Copeland 2001-03-22 06:37:35 UTC

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
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=32041
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?

Phil
=--=

Comment 1 Justin T. Gibbs 2001-03-22 18:35:57 UTC

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
driver.

Comment 2 Arjan van de Ven 2001-04-18 12:35:27 UTC

Merged 6.1.11