All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roberto Sanchez <rcsanchez97@yahoo.es>
To: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Kernel 2.6.0-testX show stoppers
Date: Mon, 08 Dec 2003 10:28:32 -0500	[thread overview]
Message-ID: <3FD498A0.9080802@yahoo.es> (raw)

[-- Attachment #1: Type: text/plain, Size: 2211 bytes --]

I am having some problems getting 2.6.0-test11 working on my 2 boxes.
I am hoping that someone here can provide me some insight so that I
can provide some useful info to help get these solved.

Any help would be appreciated.

-Roberto

Here goes:

Box 1:

Athlon XP 2500+, 1 GB RAM, 120 GB HDD
nVidia nForce2 chipset
ATI Radeon 9000 Pro w/ 128 MB

This machine just randomly and frequently locks up under any 2.6.x
kernel.  I can't find a particular pattern, but it happens every few
minutes (enough to make the machine unusable).  It is now running a
2.4.23 kernel.


Box 2:

Toshiba Satellite 2805-S401 (laptop)
P-III 700 MHz, 256 MB RAM, 40 GB HDD
Intel 440BX chipset
S3 Savage IX/MV 8 MB video

Problem: Every kernel after 2.6.0-test4 gives me a hard lock-up during
the boot sequence when PCMCIA services start.  No 2.4.x kernel ever did
this, and 2.6.0-test1 thru -test4 work fine.  I have narrowed the 
problem to the point where the yenta_socket socket module is inserted.
However, if I pass acpi=off as a kernel boot parameter, it does not lock
up.  Also, if I build PCMCIA support directly into the kernel,
everything works.  I am currently running 2.6.0-test11 with PCMCIA
built in (but I would like it to be modular).

I am also receiving the following errors on boot when my scripts
set up the parameters on my HDD and CD/DVD (this is also particular
to the post -test4 kernels):

hda: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }

hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }

hda: drive not ready for command
hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }

hda: drive not ready for command
hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }

hda: DMA disabled
hda: drive not ready for command
hda: set_drive_speed_status: status=0x58 { DriveReady SeekComplete 
DataRequest }

But, eventhough it says DMA is disabled, it is still enabled.

# hdparm /dev/hda

/dev/hda:
  multcount    = 16 (on)
  IO_support   =  1 (32-bit)
  unmaskirq    =  1 (on)
  using_dma    =  1 (on)
  keepsettings =  0 (off)
  readonly     =  0 (off)
  readahead    = 256 (on)
  geometry     = 38760/16/63, sectors = 39070080, start = 0

[-- Attachment #2: Type: application/pgp-signature, Size: 256 bytes --]

             reply	other threads:[~2003-12-08 15:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-08 15:28 Roberto Sanchez [this message]
2003-12-08 15:40 ` Kernel 2.6.0-testX show stoppers Craig Bradney
2003-12-08 15:45   ` Roberto Sanchez
2003-12-08 17:18   ` Bob
2003-12-09  5:52     ` Roberto Sanchez
2003-12-09  5:48   ` Roberto Sanchez

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=3FD498A0.9080802@yahoo.es \
    --to=rcsanchez97@yahoo.es \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.