linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Cordes <peter@llama.nslug.ns.ca>
To: linux-kernel@vger.kernel.org
Subject: Oopses with heavy disk activity with 2.4 on VIA Apollo (VT82C586B)
Date: Sat, 16 Jun 2001 19:02:03 -0300	[thread overview]
Message-ID: <20010616190202.D25955@llama.nslug.ns.ca> (raw)

 This is a bug report about the VIA IDE driver.  I'm forwarding it here
because bugs@linux-ide.org bounced.

----- Forwarded message from Mail Delivery System <Mailer-Daemon@llama.nslug.ns.ca> -----
  bugs@linux-ide.org
    SMTP error from remote mailer after RCPT TO:<bugs@linux-ide.org>:
    host mail.linux-ide.org [24.219.123.215]: 550 5.7.1 Unable to relay for bugs@linux-ide.org

------ This is a copy of the message, including all the headers. ------

Return-path: <peter@llama.nslug.ns.ca>
Received: from peter by llama.nslug.ns.ca with local (Exim 3.22 #1 (Debian))
	id 15Ajcp-0005Jz-00
	for <bugs@linux-ide.org>; Thu, 14 Jun 2001 23:46:19 -0300
Date: Thu, 14 Jun 2001 23:46:19 -0300
To: bugs@linux-ide.org
Subject: oopses with heavy disk activity with 2.4 on VIA Apollo (VT82C586B)
Message-ID: <20010614234619.D20351@llama.nslug.ns.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
From: Peter Cordes <peter@llama.nslug.ns.ca>


 I rescued a P5BV3+ (a super 7) mobo with a VIA MVP3 chipset from the trash
(I know the guy who was tossing it, and he didn't say anything about it
being damaged, just old).  I moved my disks over from my old system, and
compiled myself a kernel for it.  It's got an AMD k6-2 at 350MHz, and the
memory bus is running at 100MHz.  I've run memtest86 for a long time
(several complete passes, one with "extended tests") and found no errors.

 The problem is that all the 2.4 kernels I've tried oops under heavy disk
load.  A couple typical ones are like this:

ksymoops 2.4.1 on i586 2.2.19-idepci.  Options used
     -v /usr/src/linux/vmlinux (specified)
     -K (specified)
     -l /proc/modules (default)
     -o /lib/modules/2.4.5 (specified)
     -m /boot/System.map-2.4.5 (specified)

No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Jun 12 02:11:40 yeti kernel: Unable to handle kernel paging request at virtual address 0000848d
Jun 12 02:11:40 yeti kernel: c010fb03
Jun 12 02:11:40 yeti kernel: *pde = 00000000
Jun 12 02:11:40 yeti kernel: Oops: 0000
Jun 12 02:11:40 yeti kernel: CPU:    0
Jun 12 02:11:40 yeti kernel: EIP:    0010:[__wake_up+51/168]
Jun 12 02:11:40 yeti kernel: EFLAGS: 00010017
Jun 12 02:11:40 yeti kernel: eax: c123fe10   ebx: 00008491   ecx: c8b6a6e4   edx: c123fdf8
Jun 12 02:11:40 yeti kernel: esi: c8b6a6e4   edi: 00008489   ebp: c8b87ef4   esp: c8b87ed8
Jun 12 02:11:40 yeti kernel: ds: 0018   es: 0018   ss: 0018
Jun 12 02:11:40 yeti kernel: Process bonnie++ (pid: 329, stackpage=c8b87000)
Jun 12 02:11:40 yeti kernel: Stack: c123fdf4 c8b6a6e4 c123fdcc c123fdf8 00000001 00000282 00000003 000020e9 
Jun 12 02:11:40 yeti kernel:        c0125481 c01e2134 c01e2304 00000002 00000000 c0126b34 c01e2134 00000000 
Jun 12 02:11:40 yeti kernel:        c01e230c 00000000 c13bee48 c0126c11 c01e2300 00000000 00000002 00000001 
Jun 12 02:11:40 yeti kernel: Call Trace: [reclaim_page+969/1016] [__alloc_pages_limit+108/148] [__alloc_pages+181/584] [generic_file_write+843/1336] [sys_write+142/196] [system_call+51/64] 
Jun 12 02:11:40 yeti kernel: Code: 8b 4f 04 8b 1b 8b 01 85 45 fc 74 51 31 c0 9c 5e fa c7 01 00 
Using defaults from ksymoops -t elf32-i386 -a i386

Code;  00000000 Before first symbol
00000000 <_EIP>:
Code;  00000000 Before first symbol
   0:   8b 4f 04                  mov    0x4(%edi),%ecx
Code;  00000003 Before first symbol
   3:   8b 1b                     mov    (%ebx),%ebx
Code;  00000005 Before first symbol
   5:   8b 01                     mov    (%ecx),%eax
Code;  00000007 Before first symbol
   7:   85 45 fc                  test   %eax,0xfffffffc(%ebp)
Code;  0000000a Before first symbol
   a:   74 51                     je     5d <_EIP+0x5d> 0000005d Before first symbol
Code;  0000000c Before first symbol
   c:   31 c0                     xor    %eax,%eax
Code;  0000000e Before first symbol
   e:   9c                        pushf  
Code;  0000000f Before first symbol
   f:   5e                        pop    %esi
Code;  00000010 Before first symbol
  10:   fa                        cli    
Code;  00000011 Before first symbol
  11:   c7 01 00 00 00 00         movl   $0x0,(%ecx)




Jun 12 04:06:20 yeti kernel: Unable to handle kernel paging request at virtual address 000045bd
Jun 12 04:06:20 yeti kernel: c010fb03
Jun 12 04:06:20 yeti kernel: *pde = 075d6067
Jun 12 04:06:20 yeti kernel: Oops: 0000
Jun 12 04:06:20 yeti kernel: CPU:    0
Jun 12 04:06:20 yeti kernel: EIP:    0010:[__wake_up+51/168]
Jun 12 04:06:20 yeti kernel: EFLAGS: 00010017
Jun 12 04:06:20 yeti kernel: eax: c123fe10   ebx: 000045c1   ecx: c8b6a6e4   edx: c111edf8
Jun 12 04:06:20 yeti kernel: esi: c111edf4   edi: 000045b9   ebp: c13c3f94   esp: c13c3f78
Jun 12 04:06:20 yeti kernel: ds: 0018   es: 0018   ss: 0018
Jun 12 04:06:20 yeti kernel: Process kswapd (pid: 3, stackpage=c13c3000)
Jun 12 04:06:20 yeti kernel: Stack: c111edcc c111edf4 00000000 c111edf8 00000001 00000282 00000003 000041c8 
Jun 12 04:06:20 yeti kernel:        c01259dc 00000004 00000000 00000000 0008e000 00000000 00000004 00000000 
Jun 12 04:06:20 yeti kernel:        00002159 00000000 c0125ffd 00000004 00000000 c13c2000 c01bc391 c13c2239 
Jun 12 04:06:20 yeti kernel: Call Trace: [page_launder+1324/2096] [do_try_to_free_pages+29/88] [kswapd+83/224] [kernel_thread+40/56] 
Jun 12 04:06:20 yeti kernel: Code: 8b 4f 04 8b 1b 8b 01 85 45 fc 74 51 31 c0 9c 5e fa c7 01 00 

Code;  00000000 Before first symbol
00000000 <_EIP>:
Code;  00000000 Before first symbol
   0:   8b 4f 04                  mov    0x4(%edi),%ecx
Code;  00000003 Before first symbol
   3:   8b 1b                     mov    (%ebx),%ebx
Code;  00000005 Before first symbol
   5:   8b 01                     mov    (%ecx),%eax
Code;  00000007 Before first symbol
   7:   85 45 fc                  test   %eax,0xfffffffc(%ebp)
Code;  0000000a Before first symbol
   a:   74 51                     je     5d <_EIP+0x5d> 0000005d Before first symbol
Code;  0000000c Before first symbol
   c:   31 c0                     xor    %eax,%eax
Code;  0000000e Before first symbol
   e:   9c                        pushf  
Code;  0000000f Before first symbol
   f:   5e                        pop    %esi
Code;  00000010 Before first symbol
  10:   fa                        cli    
Code;  00000011 Before first symbol
  11:   c7 01 00 00 00 00         movl   $0x0,(%ecx)


 This happens pretty consistently when I run 2.4.5.  I haven't tried earlier
2.4 kernels, since I thought it would be unlikely to help.

 Luckily for me, 2.2 kernels seem to have no trouble, even when doing ultra
DMA.  I ran bonnie++ after running hdparm -m16 -u1 -d1 -c1 /dev/hdc, and it
completed without causing any problems.  Under 2.4.5, this always gave an
oops pretty quickly, and the bonnie++ process would be in an un-killable
disk-sleep.  I had to reboot the machine to get rid of it.

The precompiled Debian 2.2.19-idepci kernel says this on bootup:
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: not 100% native mode: will probe irqs later
   ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:DMA, hdb:DMA
   ide1: BM-DMA at 0xe008-0xe00f, BIOS settings: hdc:DMA, hdd:DMA
hda: FUJITSU MPG3307AT, ATA DISK drive
hdc: QUANTUM FIREBALL CR13.0A, ATA DISK drive
hdd: SAMSUNG CD-R/RW DRIVE SW-212B, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: FUJITSU MPG3307AT, 29319MB w/2048kB Cache, CHS=59570/16/63
hdc: QUANTUM FIREBALL CR13.0A, 12416MB w/418kB Cache, CHS=25228/16/63
hdd: ATAPI 32X CD-ROM CD-R/RW drive, 8192kB Cache

 My 2.4.5 kernel was compiled with gcc version 2.95.4 20010319 (Debian
prerelease).  (I'm running Debian woody.)

 This is really annoying, because I want to use 2.4 on this machine for DRI
with the 3DFX Voodoo3 I just got for it, netfilter, and raid2...  Oh well, I
guess I'll survive with 2.2.19 until this gets figured out.  I'm willing to
do some testing on this, since I've got other computers that I can send
email from if this one eats its disk.

-- 
#define X(x,y) x##y
Peter Cordes ;  e-mail: X(peter@llama.nslug. , ns.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BCE

----- End forwarded message -----

-- 
#define X(x,y) x##y
Peter Cordes ;  e-mail: X(peter@llama.nslug. , ns.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BCE

             reply	other threads:[~2001-06-16 22:02 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-16 22:02 Peter Cordes [this message]
2001-06-17 13:13 ` Oopses with heavy disk activity with 2.4 on VIA Apollo (VT82C586B) Vojtech Pavlik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010616190202.D25955@llama.nslug.ns.ca \
    --to=peter@llama.nslug.ns.ca \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).