SATA hotswap / hotplug
Hi list, I'm trying to get SATA hot-swapping to work in Fedora 9 but I'm either having no luck or doing it wrong. I've tried a variety of disk controllers including an LSI MegaRaid, 3Ware 9550SX, and I'm now working with a Supermicro SAT2-MV8 (Marvell chipset - sata_mv module). I was under the (possibly mistaken) impression that if I insert or remove a disk, I should see something in /var/log/messages. I've also been running "ls -l /dev/disk/by-path" to see if the device name appears or disappears, but it never does. Is there any kind of special setup required or should it "just work"? The disks I'm using are either Seagate SATA2 or older Hitachi SATA1 drives, I have a few to play with. The disks are not formatted in any way as my application treats them as raw block devices. Still, I would expect to see the contents of /dev/disk/by-path to change when I insert or remove a disk. When using the 3Ware card, I did get a message from the 3Ware driver saying that a disk had been removed or inserted, but it didn't change the contents of /dev/disk/by-path and the message was from the driver, not the kernel or udev or any other subsystem. I should mention that the disks appear fine if they are inserted before I boot on all the disk controllers I've tried. Any suggestions gratefully received. Regards, -- Chris -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: SATA hotswap / hotplug
Todd Denniston wrote: lsi does not show up on http://linux-ata.org/driver-status.html so you have to figure out what driver supports the card and ask about that driver. It's the megaraid_sas driver but it's not shown on the linux-ata.org site, so that doesn't bode too well! 3Ware 9550SX, http://linux-ata.org/driver-status.html#tware apparently you need to ask at the driver maker's site if they support it. Aha, I shall do so. according to the 'Driver / feature matrix' http://linux-ata.org/driver-status.html#matrix driver=sata_mv feature=Device Hotplug feature state=no Well spotted, I saw this bit of the same page... http://linux-ata.org/driver-status.html#marvell ... and it says: Driver name: sata_mv Summary: Similar to ServerWorks "frodo": per-device queues, full SATA control including hotplug. So I'm a little bit puzzled. Unless it means hotplugging the card itself?!? Anyway, thanks for the pointers. -- Chris Mocock [EMAIL PROTECTED] www.wavestore.com Office: +44 (0) 208 756 5456 Mobile: +44 (0) 7967 321 628 Wavelet Technology Ltd., Unit 1 Hayes Metro Centre, Springfield Road, Hayes, Middlesex UB4 0LE The contents of the e-mail and any attached files are confidential and intended solely for the use of the individual to whom they are addressed. If you are not the intended recipient and have received this email in error, you are advised that the subsequent use, dissemination, forwarding, printing or copying of any part of the e-mail is strictly prohibited. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: stop kernel messages from splashing on the console
Vikram Goyal wrote: Hello, I am getting these kernel messages on the consoles which I want to avoid as many times I have to login through them as the system runs in level 3. I have edited the /etc/syslog.conf as: I believe the relevant config file is now /etc/rsyslog.conf although I don't know why /etc/syslog.conf still exists. Might be worth a try. Regards, -- Chris -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: F8 vs F9
Tom Horsley wrote: since the release. My main blocker with F9 now is that I haven't yet figured out how to rip pulseaudio out and get alsa functioning again. I've never managed to get pulse-audio working (although TBH I haven't tried very hard), so I just do a "yum remove pulse*" and that's always fixed the problem for me, alsa just seems to work after that - on F8 and F9. -- Chris -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: F8 vs F9
Russell Miller wrote: It might bea permissions problem... I found that by changing the ownership on the alsa device files to root:pulse-rt and adding your local user to pulse-rt, it started working. Someone is insisting that's not a bug, which does not make me happy. Thanks. I did try that on Fedora 8 when I actually put some effort into investigating, with no success, but haven't tried again on F9. Might give it another go tonight. -- Chris -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Anaconda (or libata?) device detection order
Hi, I've been creating a custom spin with revisor and it's going very well, except for one fairly major problem... It seems that when booting an installed system, /dev/sda corresponds to a PATA device, but during installation (via anaconda), /dev/sda corresponds to a SATA device. To clarify... when anaconda runs I would like it to install to the primary master PATA drive if present. Strangely (or strange to me anyway), it seems that SATA devices get detected first. I thought that PATA devices would be detected first, so that in my kickstart file I could specify my desired partitioning to be on disk /dev/sda. When there are only PATA devices installed this works fine, it goes on the primary master. However if SATA devices are present as well as PATA, it installs to the first SATA device. If I set grub.conf of the installed system to boot from /dev/sda, it tries to boot from the PATA disk rather than the SATA disk to which it installed. I can get around this by pointing grub.conf to the UUID of the disk to which it installed. However, I'm surprised that /dev/sda seems to be a SATA disk during installation, and a PATA disk during boot. Any thoughts as to why this might be? What decides the device detection order? Is it libata or something else? Thanks, -- Chris -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: Anaconda (or libata?) device detection order
Alan Cox wrote: >> I do not think that there is any way for anaconda, given the constraints >> of libata and the BIOS, to determine if the first drive offered is PATA. > > In theory you can map BIOS drives to PCI devices using EDD 3.0 tables and > then use word 93 of the identify data to map the devices to PATA v SATA. > > In practice EDD tables seem to be pretty good but various devices get > word 93 wrong - notably cruddy ATAPI devices. > > Our current order is basically > > - link order for compiled in drivers (if any), which is fairly undefined > but does put acpi, generic, legacy last > > - module load order otherwise > > For multiple devices off the same module it is then defined by the PCI > bus ordering of devices which depends on the PCI scan order. > > The order modules get loaded is from userspace Thanks, that's all useful info. Maybe I can use it to figure out a solution. -- Chris -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list