Bug 121454

Summary:	[pst] Promise SuperTrak SX6000 does not load during boot in 7.0-RELEASE
Product:	Base System	Reporter:	Marc Muncke <m.muncke>
Component:	kern	Assignee:	freebsd-acpi (Nobody) <acpi>
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	7.0-RELEASE
Hardware:	Any
OS:	Any

Description Marc Muncke 2008-03-06 23:10:06 UTC

I was successfully using 6.2-RELEASE until I had sudden System freezes
and I wonder where these came from.

I suspected a hd failure or a compromised system.

I took off the machine from public network to a private segment and it
was running ok for one day.

So I suspected a compromised system and I decided to upgrade to 7.0-RELEASE.
I followed the guidelines in
http://www.daemonology.net/blog/2007-11-11-freebsd-major-version-upgrade.html
but after first reboot I had this problem :

The Promise SuperTrak RAID controller is detected but it does not initialize :
it writes this (typed manually, cannot boot) :

pst0: <Promise Supertrak RAID on pstpci0>
pst0: 1430511MB <PROMISE TECH. I20 RAID DEVICE> [182364/255/63] on pstpci0
pstpci0: [THREAD]
pst: timeout mfa=0x002a4dd0 cmd=0x01
pst: timeout mfa=0x002a5070 cmd=0x01
pst: timeout mfa=0x002a5310 cmd=0x01
pst: timeout mfa=0x002a5850 cmd=0x01
pst: timeout mfa=0x002a5af0 cmd=0x01
pst: timeout mfa=0x002a5d90 cmd=0x01
pst: timeout mfa=0x002a6030 cmd=0x01
pst: timeout mfa=0x002a62d0 cmd=0x01
pst: timeout mfa=0x002a6570 cmd=0x01
pst: timeout mfa=0x002a6810 cmd=0x01
pst: timeout mfa=0x002a6ab0 cmd=0x01
etc...etc... and never stops -> boot never finished

During system startup the cntroller BIOS starts ok and displays the RAID
as functional.  When I boot the system in "safe mode", the controller is
detected and initialised and booting works fine.

----snip
ad0: 286168MB <WDC WD3000JB-00KFA0 08.05J08> at ata0-master PIO4
acd0: CDROM <SONY CD-ROM CDU5221/0.30> at ata1-slave PIO4
pst0: <Promise SuperTrak RAID> on pstpci0
pst0: 1430511MB <PROMISE TECH. I2O RAID DEVICE> [182364/255/63] on pstpci0
pstpci0: [ITHREAD]
Trying to mount root from ufs:/dev/ad0s1a
----snip

This is the workaround but I do not want to run a production server in
safe mode. (why shouldnt I?) 

All data is present on the mounted RAID directories when I booted in safe mode
also the File Systems are shown as CLEAN in safe mode

I rebooted in verbose mode :
It added lines like this :

pst0: 1430511MB <PROMISE TECH. I20 RAID DEVICE> [182364/255/63] on pstpci0
pstpci0: [MPSAFE]
pstpci0: [THREAD]
ATAPseudoRAID loaded
GEOM new disk pst0
fdc0: output ready timeout
fdc0: input ready timeout
fdc0: output ready timeout
fdc0: input ready timeout
fdc0: output ready timeout
fdc0: input ready timeout
fdc0: output ready timeout
fdc0: input ready timeout
fdc0: output ready timeout
fdc0: input ready timeout
pst: timeout mfa=0x002a4dd0 cmd=0x01
pst: timeout mfa=0x002a5070 cmd=0x01
pst: timeout mfa=0x002a5310 cmd=0x01
pst: timeout mfa=0x002a5850 cmd=0x01
pst: timeout mfa=0x002a5af0 cmd=0x01
pst: timeout mfa=0x002a5d90 cmd=0x01
pst: timeout mfa=0x002a6030 cmd=0x01
pst: timeout mfa=0x002a62d0 cmd=0x01
pst: timeout mfa=0x002a6570 cmd=0x01
pst: timeout mfa=0x002a6810 cmd=0x01
pst: timeout mfa=0x002a6ab0 cmd=0x01
etc...etc... and never stops

Before the upgrade-reboot-problem started, I was able to reboot the
system im 6-2RELEASE without any problems.

Thank you for your investigation
M.Muncke

Fix: 

boot in safe mode
How-To-Repeat: reboot in default mode

Comment 1 Gavin Atkinson freebsd_committer

2008-03-07 11:38:30 UTC

State Changed
From-To: open->feedback

To submitter:  There are three things that booting in safe mode does: 

set hint.acpi.0.disabled="1" 
set hint.apic.0.disabled="1" 
unsetenv acpi_load 

I wonder if you could establish which of these is actually making the 
difference you see?  Please reboot, select "excape to loader prompt" from 
the loader menu, enter one of them and then type "boot" to carry on booting. 
Try that for each one, and perhaps for combinations of them, so that we can 
start to figure out what is happening here.

Comment 2 Gavin Atkinson freebsd_committer

2008-03-07 11:38:30 UTC

Responsible Changed
From-To: freebsd-i386->gavin

Track

Comment 3 Marc Muncke 2008-03-13 19:32:07 UTC

I realised that the system freezes were due to a harddisk failure on
my EIDE OS Drive that is seperate from the storage mount point.
I replaced the OS harddisk and wanted to install free BSD 7.0 release 
from boot floppies but there I have the same problem.
When the kernel initilalizes, I am stuck with timeouts.

Now I am stuck because I cannot use 7.0 Release in this state.
Can I boot 7.0 in save mode from floppies for installation ? I dont 
think so.
I have to go back to 6.2 release and leave the follow up of this bug to 
someone else, because this is my production system and my customers 
start complaining.

I have my "old hd" that can still boot and perform tests, but for these 
I will always have to take down my production system....

MM

OK, here are my testing results :

set hint.acpi.0.disabled="1"  boots
set hint.apic.0.disabled="1"  boots NOT
unsetenv acpi_load
returns:
acpi_load not found
unsetenv apci_load
returns
Error: stack underflow

Comment 4 Gavin Atkinson freebsd_committer

2008-03-18 18:23:59 UTC

State Changed
From-To: feedback->open

Feedback was received

Comment 5 Gavin Atkinson freebsd_committer

2008-03-18 18:23:59 UTC

Responsible Changed
From-To: gavin->freebsd-acpi

Over to -acpi.  Setting hint.acpi.0.disabled="1" at the loader seems 
to fix the problem the submitter is seeing.  This may well still be 
an issue with the pst driver, or ACPI, leave it up to -acpi to decide.

Comment 6 John Baldwin freebsd_committer

2008-03-19 12:50:35 UTC

You will need to do a verbose boot in both cases to get the pstpci0 messages 
as well as interrupt routing messages.

-- 
John Baldwin

Comment 7 Gavin Atkinson freebsd_committer

2008-06-01 20:01:30 UTC

State Changed
From-To: open->feedback

To submitter: please provide a verbose boot dmesg in both cases, 
showing both the pstpci0 messages and the interrupt routing messages

Comment 8 Jaakko Heinonen freebsd_committer

2010-09-19 09:43:46 UTC

State Changed
From-To: feedback->closed

Feedback timeout.