Kernel 2.6.0-testX show stoppers

Kernel 2.6.0-testX show stoppers

[Roberto Sanchez]

[-- 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 --]

Re: Kernel 2.6.0-testX show stoppers

[Craig Bradney]

For the Athlon, keep in touch with the nforce thread on here.. There are
patches due to timing issues with the nforce chipset. 

For me, so far, just using this one works:
http://www.kernel.org/pub/linux/kernel/people/bart/2.6.0-test11-bart1/broken-out/nforce2-apic.patch

There is a program called athcool to turn off CPU Disconnect if you dont
have that in your BIOS. I havent used this patch as I have found
reliability using the first one I mentioned.

Craig

On Mon, 2003-12-08 at 16:28, Roberto Sanchez wrote:
> 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

Re: Kernel 2.6.0-testX show stoppers

[Roberto Sanchez]

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

Craig Bradney wrote:
> For the Athlon, keep in touch with the nforce thread on here.. There are
> patches due to timing issues with the nforce chipset. 
> 
> For me, so far, just using this one works:
> http://www.kernel.org/pub/linux/kernel/people/bart/2.6.0-test11-bart1/broken-out/nforce2-apic.patch
> 
> There is a program called athcool to turn off CPU Disconnect if you dont
> have that in your BIOS. I havent used this patch as I have found
> reliability using the first one I mentioned.
> 
> Craig

Thanks for the info.  I will give it a shot tonight.

-Roberto

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

Re: Kernel 2.6.0-testX show stoppers

[Bob]

Craig Bradney wrote:

>For the Athlon, keep in touch with the nforce thread on here.. There are
>patches due to timing issues with the nforce chipset. 
>
>For me, so far, just using this one works:
>http://www.kernel.org/pub/linux/kernel/people/bart/2.6.0-test11-bart1/broken-out/nforce2-apic.patch
>
>There is a program called athcool to turn off CPU Disconnect if you dont
>have that in your BIOS. I havent used this patch as I have found
>reliability using the first one I mentioned.
>
>Craig
>  
>
The patch works for a lot of people. I've seen those drive
errors, irq7 disabled, spurious 8259a messages with a
bios and acpi and apic and lapic and linux acpi handling
conflict usually related to nforce2 and amd cpu's are
usually involved.

My nforce2 amd system got to working with apic and lapic
and acpi when I did a bios flash update.

On a via chip system, amd cpu, savage pro vid onboard,
it would run stable but there were some no-no's with
regard to acpi-apic-lapic until a bios flash helped.

Things I tried and saw some improvement from were
leaving acpi on and apic on in linux, turn lapic off in
linux. 2) Turn apic off in bios and on in linux. 3) Use
anticipatory scheduling and turn deadline scheduling
off really helped with driver errors on the via box.
4) hdparm off unmask irq feature on drive controllers
by siig sis.

My pcmcia controller doesn't show a sign of life. In
the documentation mine says it's very touchy about
sharing irq's even though it's a pci card. These nforce2
acpi conflicts cause just that sort of problem. On the
bright side, they can go away, it's only a hardware
problem causing juxtaposed by software that can
be changed either in kernel or bios update.

-Bob

>On Mon, 2003-12-08 at 16:28, Roberto Sanchez wrote:
>  
>
>>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
>>
>
>  
>

Re: Kernel 2.6.0-testX show stoppers

[Roberto Sanchez]

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

Bob wrote:
> Craig Bradney wrote:
> 
>> For the Athlon, keep in touch with the nforce thread on here.. There are
>> patches due to timing issues with the nforce chipset.
>> For me, so far, just using this one works:
>> http://www.kernel.org/pub/linux/kernel/people/bart/2.6.0-test11-bart1/broken-out/nforce2-apic.patch 
[SNIP]
> The patch works for a lot of people. I've seen those drive
> errors, irq7 disabled, spurious 8259a messages with a
> bios and acpi and apic and lapic and linux acpi handling
> conflict usually related to nforce2 and amd cpu's are
> usually involved.
> 
> My nforce2 amd system got to working with apic and lapic
> and acpi when I did a bios flash update.

I also tried flashing the BIOS, but that was a complete disaster.
I have a BioStar motherboard (M7NCD Pro), and when I flashed to the 1007
BIOS, I started getting segfaults during init, was unable to log in most
times, and the machine was generally unusable.

When I reflashed to the (old) 0630 BIOS, the above patch worked its
magic.

Incidentally, everyone should stay away from the 1007 BIOS for the
M7NCD Pro.

-Roberto

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

Re: Kernel 2.6.0-testX show stoppers

[Roberto Sanchez]

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

Craig Bradney wrote:
> For the Athlon, keep in touch with the nforce thread on here.. There are
> patches due to timing issues with the nforce chipset. 
> 
> For me, so far, just using this one works:
> http://www.kernel.org/pub/linux/kernel/people/bart/2.6.0-test11-bart1/broken-out/nforce2-apic.patch
> 
> There is a program called athcool to turn off CPU Disconnect if you dont
> have that in your BIOS. I havent used this patch as I have found
> reliability using the first one I mentioned.
> 
> Craig
> 

I went ahead and used the entire -bart1 patch and life is good.  No more
lockups.  It would be great to see this go into the main tree.

-Roberto

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