Bug 139731

Summary: Kernel panic trying to use Promise TX4 controller on a NCCH-DL
Product: Red Hat Enterprise Linux 4 Reporter: Jared Oberhaus <jared.oberhaus>
Component: kernelAssignee: David Milburn <dmilburn>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: medium    
Version: 4.0CC: jgarzik, jturner, tburke
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-07-24 21:33:51 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 Jared Oberhaus 2004-11-17 19:36:37 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3)
Gecko/20040913 Firefox/0.10.1

Description of problem:
I am trying to run linux on an ASUS NCCH-DL mother board.

Hardware:
Assus NCCH-DL motherboard,  dual 3.2ghz / 800 mhz / 1mb L2 cache cpus
2 gb RAM

Western Digital Raptor 36.7GB 10,000RPM SATA boot disk via on board
controller

4 x WD 250g 7,000rpm  sata disks via on board PDC20319 controller (ie
Promise TX4)

I do a straight install of RHEL4 Beta-2.

fdisk /dev/sda (the first of the 4 drives on the TX4),  allocating the
whole disk as /dev/sda1.

Under RHEL4 beta 2, the modules loaded look like:

Module                  Size  Used by
md5                     4033  1 
ipv6                  235393  10 
parport_pc             24705  1 
lp                     12077  0 
parport                42121  2 parport_pc,lp
netconsole              6749  0 
netdump                12449  0 
autofs4                24389  3 
sunrpc                161189  1 
dm_mod                 54997  0 
button                  6481  0 
battery                 8901  0 
ac                      4805  0 
uhci_hcd               31449  0 
ehci_hcd               31557  0 
hw_random               5717  0 
snd_intel8x0           33641  0 
snd_ac97_codec         64401  1 snd_intel8x0
snd_pcm_oss            49145  0 
snd_mixer_oss          17985  1 snd_pcm_oss
snd_pcm               100425  2 snd_intel8x0,snd_pcm_oss
snd_timer              30789  1 snd_pcm
snd_page_alloc          9673  2 snd_intel8x0,snd_pcm
snd_mpu401_uart         8769  1 snd_intel8x0
snd_rawmidi            27237  1 snd_mpu401_uart
snd_seq_device          8137  1 snd_rawmidi
snd                    55717  9
snd_intel8x0,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer,snd_mpu401_uart,snd_rawmidi,snd_seq_device
soundcore               9889  1 snd
e1000                  77389  0 
ext3                  117065  1 
jbd                    74969  1 ext3
ata_piix                8389  2 
sata_promise            9669  0 
libata                 40261  2 ata_piix,sata_promise
sd_mod                 17089  3 
scsi_mod              119441  3 sata_promise,libata,sd_mod

Then, when I try to do an mkfs -t ext3 /dev/sda1, in about 1 second it
writes the inodes up to about 415/1864 , and then stops and writes
about 1 inode a second for a few seconds, and then crashes with a
stack trace looking like:

------------[ cut here ]------------
kernel BUG at mm/vmscan.c:564!
invalid operand: 0000 [#1]
Modules linked in: md5 ipv6 parport_pc lp parport netconsole netdump
autofs4 sunrpc dm_mod button battery ac uhci
_hcd ehci_hcd hw_random snd_intel8x0 snd_ac97_codec snd_pcm_oss
snd_mixer_oss snd_pcm snd_timer snd_page_alloc sn
d_mpu401_uart snd_rawmidiEIP is at shrink_cache+0xdb/0x4d5
eax: 00000000   ebx: c0358a14   ecx: c1449a18   edx: c1449a18
esi: c0358a68   edi: 00000007   ebp: 00000006   esp: c21beecc
ds: 007b   es: 007b   ss: 0068
Process kswapd0 (pid: 42, threadinfo=c21be000 task=c216e0b0)
Stack: 00000020 c21bef68 c1449a78 c14499d8 00000000 00000001 c14497a0
c14497c0
       c14497e0 c14498e0  shrink_zone+0x8f/0x9a
 [<c0151a95>] balance_pgdat+0x176/0x249
 [<c0151c21>] kswapd+0xb9/0xbb
 [<c011e277>] autoremove_wake_function+0x0/0x2d
 [<c030b2e2>] ret_from_fork+0x6/0x14
 [<c011e277>] autoremove_wake_function+0x0/0x2d
 [<c0151b68>] kswapd+0x0/0xbb
 [<c01041d9>] kernel_thread_helper+0x5/0xb
Code: 31 ed bf 01 00 00 00 8d 73 54 39 73 54 74 7e 8b 4b 58 8b 41 04
39 f0 74 07 83 75 04

I have the same problem with both SMP and non-SMP version of RHEL4 beta 2.

I have tried this both with and without a raid0 disk array defined in
bios, and I have also tried it with various cominations of LVM.  All
with roughly the same results.  (kernel panic).

Any ideas?

Evan

Version-Release number of selected component (if applicable):
kernel-2.6.9-1

How reproducible:
Always

Steps to Reproduce:
1.See above
2.
3.
    

Actual Results:  kernel panic

Expected Results:  A usable file system.

Additional info:

Comment 3 Jeff Garzik 2004-11-23 18:13:56 UTC
Do we have test hardware in-house?

More importantly, is the Promise TX4 located on a 66Mhz, 100Mhz, or
133Mhz PCI bus?  There are reported problems when the TX4 is connected
to a PCI bus running > 33 Mhz.


Comment 4 Jared Oberhaus 2004-11-23 19:01:05 UTC
Note, the controller is a PDC20319 chip mounted on the mother board,
but according to the block diagram on page 107 of the manual: 

http://www.asus.com/pub/ASUS/mb/Socket604/NCCH-DL/e1636_ncch-dl.pdf

It's connected to the 6300ESB south bridge via a 33mhz bus.

Evan

Comment 8 Robert Perkins 2004-11-24 15:40:13 UTC
Removing from Blocker list.  This will not stop ship, albeit as Jeff
mentions this should be fixed asap, along with the 66+  MHz bus issues.

Comment 10 David Milburn 2009-07-24 21:33:51 UTC
I was not able to match your exact hardware, but, I was able to install RHEL4 U8
to a Seagate drive hanging off a TX4 controller, and successfully run some IO
stress. Please re-open if you can reproduce on a kernel-2.6.9-89.EL.