Bug 245627
|
Description
Gerry Reno
2007-06-25 19:14:49 UTC
Created attachment 157795 [details]
Screenshot of F7 xen kernel errors on boot.
Created attachment 157796 [details]
Screenshot of F7 xen kernel errors on boot.
What kind of hardware? Is there an FC6 smolt profile for this machine? I do not know the smolt UUID for this machine but a twin identical machine is: http://smolt.fedoraproject.org/show?UUID=ab65ac7d-1e79-4479-b7bf-14f4936b6e2a These are the same machines that Sergei and Chuck helped get booting on the 2.6.20 series kernels. It took a BIOS tweak to fix the "unknown bus timing" problem. And I checked and that tweak is still in effect but is not helping apparently for the F7 kernels. So this is the same problem as bug #234283, but with libata instead of old-ide drivers? Can you confirm that it's the disks on the HPT302x controller that are causing the problem again? Created attachment 157814 [details]
Screenshot of F7 regular kernel boot sequence.
Created attachment 157815 [details]
Screenshot of F7 regular kernel boot sequence.
Created attachment 157816 [details]
Screenshot of F7 xen kernel boot sequence.
Created attachment 157817 [details]
Screenshot of F7 xen kernel boot sequence.
All of the photos 157814 to 157817 are for the xen kernel. Created attachment 157819 [details]
Screenshot of F7 regular kernel boot sequence.
Created attachment 157820 [details]
Screenshot of F7 regular kernel boot sequence.
Created attachment 157821 [details]
Screenshot of F7 regular kernel boot sequence.
Created attachment 157822 [details]
Screenshot of F7 regular kernel boot sequence.
Created attachment 157823 [details]
Screenshot of F7 regular kernel boot sequence.
Created attachment 157824 [details]
Screenshot of F7 regular kernel boot sequence.
Created attachment 157825 [details]
Screenshot of F7 regular kernel boot sequence.
Created attachment 157826 [details]
Screenshot of F7 regular kernel boot sequence.
Can you connect a serial cable and capture the boot messages that way? Created attachment 157827 [details]
Screenshot of F7 regular kernel boot sequence.
Created attachment 157828 [details]
Screenshot of F7 regular kernel boot sequence.
All photos 157819 to 157828 are for the regular kernel. (In reply to comment #20) > Can you connect a serial cable and capture the boot messages that way? Chuck, that's on my todo list but I haven't got these machines configured for serial console yet. This bug is related to bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245626 I've managed to boot into F7 using the old FC6 kernel, 2.6.20-1.2952.fc6xen, and it is running. Haven't noticed any errors after a couple hours running. What ramifications are there to running F7 with this FC6 kernel? Are there any dependencies on the F7 kernels that would cause serious problems running it with this FC6 kernel? Other than lack of support for newer devices and some missing features that would enable more power saving, the FC6 kernel should work fine. Ok, I will continue to operate this server with the FC6 kernel for now but I would hope to see the F7 kernels fixed quickly for these issues with the highpoint controllers. Its unlikely to be fixed rapidly. There is very little documentation, the source code from the vendor drivers isn't very clear and most systems are working (which makes it hard to reproduce). Sergei is working upstream on this but its likely to be a slow process for both old and new IDE driver [which are basically the same logic internally] Alan, would it help if I sent you one of these hpt302n pci cards? I wouldn't mind doing that if it would be of use to you. I'm not sure it will help. The big lack is information not hardware. Thanks for the offer though. Hopefully the upstream work will get us somewhere in the end of the non working cases. Ok, I have the server running under the FC6 xen kernel but I have not been able to get any of my xen domains to start. They keep getting error: Error: Unable to connect to xend. No such file or directory. Is xend running? Of course I check xend and it is running. And to be safe I restart it. Still cannot start any xen domains. Is this problem somehow related to the fact that I'm using the FC6 xen kernel? I know xen version changed to 3.1 from 3.0 so does that tie it to a particular kernel? If so then this F7 kernel problem becomes a really big problem for us. Please file different bugs in differen bugzilla entries F7 using FC6 Xen kernel issue opened under: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246169 Thanks Gerry for the input. I have got a similar problem. Booting from the on-board p-ata controller works fine, but when using a disk attached to the htp-card it will screw up the system, displaying about the same errors than shown in your screen-shots. I have played a bit and the result is: (1) if the disk is on the Primary Channel, it works fine. (2) If it is on the Secondary Channel I cannot even create a partition. (3) The Secondary Channel is linked with an outside connector. The docs say one may either use the internal or outside one for connecting pata drives. I did not try to use the outside one, but thinking about the design, the Secondary Channel may be slightly different to the Primary one -- which makes the difference I see. It may be worth trying to boot from disks attached to the Primary-channel. Torsten, thanks for the info. We've had these servers (14) with the HPT controllers running this way for around four years on RH/Fedora and we do not want to take the risk of reconfiguring things and introducing other problems. We also do not have any spare time for experimentation. These machines have booted fine with dozens of previous RH/Fedora kernels and the kernel team needs to figure out what is necessary for the new libata drivers to be able to duplicate the old behavior under the previous IDE drivers. Has there been any progress on this hptxxx controller issue? It's getting closer to Fedora 8 release and I'm concerned that continuing to have to use an FC6 kernel with F7 because of not being able to use libata drivers is going to become very problematic. As it is I cannot update anything because everytime I try to do that yum tries to remove the FC6 kernel! It's killed the machines a couple times already so I just quit trying to update. (In reply to comment #37) > Has there been any progress on this hptxxx controller issue? It's getting > closer to Fedora 8 release and I'm concerned that continuing to have to use an > FC6 kernel with F7 because of not being able to use libata drivers is going to > become very problematic. As it is I cannot update anything because everytime I > try to do that yum tries to remove the FC6 kernel! It's killed the machines a > couple times already so I just quit trying to update. Manually remove the newer kernel before running an update. # rpm -e kernel-<version> I'm working on it and a lot has been done for the hpt37x and 3xxN series controllers. I've also *finally* hopefully sorted out some kind of NDA access to full documentation to the later devices. Today, I tried to update to the 2.6.23 kernel. It did not work. I no longer see the crash but instead now LVM is not working properly. I'll attach some screen shots. I also tried this on another server with Highpoint Controllers (but not hpt302n) and that server is able to boot but it too has problems with drive timeouts. That bug is https://bugzilla.redhat.com/show_bug.cgi?id=426896 Created attachment 290500 [details]
Screenshot #1: boot 2.6.23.8-34.f7
Created attachment 290501 [details]
Screenshot #2: boot 2.6.23.8-34.f7
Created attachment 290502 [details]
Screenshot #3: boot 2.6.23.8-34.f7
Created attachment 290503 [details]
Screenshot #4: boot 2.6.23.8-34.f7
Just for reference: We are using LVM over mdadm software RAID arrays. Has there been any progress on getting the HighPoint controllers and LVM to work with the libata kernels? can you mount a usb key when you're at that rescue prompt, and save the output of dmesg to it, and attach that here please ? For the xxxN cards not a lot recently. Most work but not all setups Dave, I'm working on getting the dmesg. I need to get some services moved off the machine before I can experiment with the kernels again. This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |