Bug 139731 - Kernel panic trying to use Promise TX4 controller on a NCCH-DL
Kernel panic trying to use Promise TX4 controller on a NCCH-DL
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.0
i686 Linux
medium Severity high
: ---
: ---
Assigned To: David Milburn
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-17 14:36 EST by Jared Oberhaus
Modified: 2009-07-24 17:33 EDT (History)
3 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Jared Oberhaus 2004-11-17 14:36:37 EST
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 13:13:56 EST
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 14:01:05 EST
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 10:40:13 EST
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 17:33:51 EDT
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.

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