Red Hat Bugzilla – Bug 161724
install onto i2o RAID5 volume fails with "Unable to get HRT" error
Last modified: 2012-06-20 09:32:49 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:1.7.7) Gecko/20050418 Firefox/1.0.3
Description of problem:
We have an Intel SCB2 system with Adaptec AIC 7899 (firmware: 2.57S4) and Adaptec I2O RAID controller (firmware: v001.3W). It's currently running Red Hat AS 3, update 5. Everything is installed on a single RAID5 volume.
I attempted to re-install the system with RHEL AS 4, and the install failed. Even booting off the RHEL AS 4 CD into "rescue" mode, the kernel loads both the i2o and aic7xxx drivers, but it can't see any disk devices.
Looking through the dmesg output, I see the following messages:
iop0: Unable to get HRT (status=0x6e)
iop0: controller could not activated
I2O controller: probe of 0000:01:08.1 failed with error -110
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Boot AS 4 in rescue mode, or try install AS 4 on the system.
Actual Results: Kernel can't see the single RAID5 volume that the controller is presenting.
Expected Results: kernel sees the "hard drive" (really a RAID5 volume) and I partition it and proceed happily.
Available upon request.
The i2o_iop_activate failed with "iop0: Unable to get HRT (status=0x6e)". Can
you decode that for us?
the status 0x6e means that the function to get the HRT timed out...
The timeout is the same as in the dpt_i2o module, so i think it's not a problem
of a too short timeout. It could be probably because the aic7xxx driver tried to
access the controller too.
Another possibility, if this is the first command issued to the board, and the
first interrupt we are waiting to recieve, then it might indicate something
wrong with interrupt routing. Is that possible Markus?
indeed the command is the first which uses interrupts, so it is possible :-)
We have several boxes with this exact config, including one that's not a
production box. I tried flashing the firmware on the I2O controller on that
non-production box to the latest version available from Adaptec (v1.62, from
2003). That updated it from v001.3W to v001.62.
I booted the Red Hat AS 4 CD via "linux rescue". I get the same error on this
test box, even after flashing the firmware to the latest version.
Is there anything happening on this bug??
I have the similar problem. However it has presented itself slightly differently.
I have two Dell 410 Precision Workstations with an Adaptec 2400A, both ran FC3
perfectly with these cards, I reinstalled with RHEL4 no problem, running the OS
off the RAID on seperate disks, I remounted the old filesystems and away they
went. These boxes are due to go into production with a slightly different
filesystem setup, so I removed the partitions and recreated what I needed, made
the filesystem and mounted up OK. I always like to reboot to check everything
reloads ok, but it didn't, it failed with the above errors. Both boxes are
patched to the same level, the one I have not changed yet reboots ok. No devices
are created in /dev/ for i2o/hda1 or hda2. The RAID checks out OK in the bios.
the timeout for retreiving all devices was in kernel <= 2.6.9 too short for some
controllers. In 2.6.10 the timeout was increased to the same value as in dpt_i2o.
Could you tell me which kernel version you use?
Thank you very much.
Are you asking for Neil's kernel version or ours? We're using the default Red
Hat AS 4 kernel, as part of the "update 1" release. That would be 2.6.9 + whatever
patches Red Hat has backported.
Although Neil is getting the same error message, it's happening under different
circumstances. We can't even install Red Hat AS 4 update 1 on a box that's
currently running Red Hat 3 AS (update 5).
then it's most likely that the patch is missing.
It is easy to fix this bug in a running system, but it is a little bit
complicated to do it when booting from CD. In any case you have to increase the
timeout in the kernel header "include/linux/i2o.h" under the kernel source tree.
There should be a line
#define I2O_TIMEOUT_LCT_GET 20
and this should be changed into
#define I2O_TIMEOUT_LCT_GET 360
After you compile and install the new kernel everything should be fine. But when
booting from CD you have to download the module from another machine somehow.
You may find this link usefull.
It describes how you could download the module (in your case it's i2o_core.ko
and not i2o_proc.ko).
Hope i could help you a little bit. If you have further questions, please feel
free to contact me.
Thanks for the link, that looks very useful.
It may be a couple weeks before we have a down-time window
to test this, but I will test and report back.
Mr. Coughlan, I assume this is something Red Hat is looking
at backporting into a future kernel release for AS 4?
The patch to increase the timeout from 20 to 360 is in RHEL 4 U2 (BZ 140002).
This is available in beta now, and will be final later this month. U2 includes
install media, so it will solve that issue as well.
I will leave this BZ open until we have confirmation that this patch fixes the
problems reported here. Please provide an update when you have tested it. Thanks.
Trying the 4 AS U2 beta sounded like the easier route, so I downloaded ISO disc
1 for RHEL4 AS U2 from the "Betas" channel of rhn.redhat.com.
I tested the install from the 4 AS U2 CD on a non-production system we have
that also has the I2O card, and the problem is NOT fixed. The installer still
gets the same error, and it still cannot see any devices to install onto.
Is it possible that the install kernel on the ISO that's on RHN hasn't yet
picked up the patch?
today another user has reported that he tried out U2 and it worked. Could you
try it out again?
Using the same CD I mentioned in comment #13, I tried another system with an I2O
card, and received the same problem.
I'll try fetching the AS 4 U2 beta image again, to make sure I have the correct
ISO. If U2 is going to be released to production in the next week, I may wait
until after that's released before doing much more testing.
As far as I can tell right now, the problem is not fixed using the stock U2 beta.
I have not yet tried the custom module method that Markus mentions in comment
#10, simply because using the U2 beta ISO seemed a lot easier.
I just tested today with the released RH AS 4 u2 disc 1, and the problem is
If I look at the i2o.h header that's installed as part of the Red Hat
2.6.9-22.EL kernel, I can see that the change is included in that header, but
either the kernel on the disc1 ISO is older than 2.6.9-22.EL or the timeout
still isn't long enough.
If I drop to an ALT-F2 prompt after the installer tells me it couldn't find any
disks to install onto, I can see that i2o_core and i2o_block are loaded. If I
rmmod them, fetch versions (kernel 2.6.9-22.EL) of those modules from a
different system and then modprobe them and go back into the installer, then
the installer can see system storage and I can proceed.
So, using the workaround that Markus provided in comment #10, it should be
possible to proceed. Tom's comment #10 appears to be only partially correct;
it looks like the fix did make it into U2, but the fix appears to *NOT* be
included in the install media (even though the kernel says it's 2.6.9-22.EL),
because the problem is still there for the install off the U2 media.
Please try this again with RHEL 4.4. Thanks.
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life.
Please See https://access.redhat.com/support/policy/updates/errata/
If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.