Re: ata controller problem
Am 26.10.2012 18:33, schrieb Jeremy Chadwick: Regarding this: http://lists.freebsd.org/pipermail/freebsd-questions/2012-October/245862.html No no NO *NO*! I wish people would stop recommending this utter garbage. There is absolutely no justification behind using the highly convoluted labelling mechanisms at multiple layers within FreeBSD. There are 3 (possibly 4) different label mechanisms which do nothing but confuse the user, or cause other oddities/complexities. Good grief, there is so much hard evidence on the mailing lists over the past 5 (maybe even 7?) years talking about the utter mess that is filesystem/device/geom/blahblah labels that to recommend this is borderline insane. The proper way to solve this problem is to user /boot/loader.conf tie-downs to assign each disk to each individual controllers' device number (e.g. ada0 -- scbus0 -- ahcich0, or whatever you want). Please note I said ahcichX, not ahciX. Different things. I have helped others in the past do this; Randy Bush is one such person. Taken directly from my /boot/loader.conf with a single SATA controller, but obviously this can be adjusted to whatever you want. # Wire down device names (ada[0-5]) to each individual port # on the SATA/AHCI controller. This ensures that if we reboot # with a disk missing, the device names stay the same, and stay # attached to the same SATA/AHCI controller. # http://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011036.html # hint.scbus.0.at=ahcich0 hint.scbus.1.at=ahcich1 hint.scbus.2.at=ahcich2 hint.scbus.3.at=ahcich3 hint.scbus.4.at=ahcich4 hint.scbus.5.at=ahcich5 hint.ada.0.at=scbus0 hint.ada.1.at=scbus1 hint.ada.2.at=scbus2 hint.ada.3.at=scbus3 hint.ada.4.at=scbus4 hint.ada.5.at=scbus5 See CAM(4) man page (read it, don't skim!) for full details. Just please for the love of god do not use labels to solve this. Sorry this doesn't work because the numbering of the ahci change with the occupancy of the Hot-Swap Bays. And that is my Problem. This i have tried first. Any idea how i can fix which controller gets which number. Regard Estartu -- - Gerhard Schmidt | E-Mail und JabberID: TU-München| schm...@ze.tum.de WWW Online Services | Tel: 089/289-25270| Fax: 089/289-25257| PGP-Publickey auf Anfrage ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: ata controller problem
On 26.10.2012 18:00, Polytropon wrote: On Fri, 26 Oct 2012 14:18:16 +0200, Gerhard Schmidt wrote: The Problem is that, if there is a Drive in one of the HotSwap Bays the PCI-Express controller is detected as ahci0 and the onboard is detected as ahci1. Therefore any drives in the HotSwap Bays become ada0-3 and the drives on the mainboard controller are the upper numbers which causes the boot to fail as the Root Partition isn't there where it's expected. The BIOS has the PCI-Express Card as second Card only so the Kernel is Booted but the RootFS is not Found. You can use labels (GPT or UFS labels) or UFSIDs to become independent of the actual device name where things are stored on. You could also use this to make disks easier to identify (e. g. /dev/label/red1root = the disk with a red 1 on it, carrying the root file system). I suggest those pages for more detailed information: http://www.wonkity.com/~wblock/docs/html/disksetup.html http://www.freebsd.org/doc/handbook/geom-glabel.html Maybe as well (specific and general notes and inspiration): http://www.daemonforums.org/showthread.php?t=2666 http://www.freebsdonline.com/content/view/731/506/ http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/disks.html I assume that you are using UFS. Is there a way to ensure that the onboard SATA Controller is always probed first. I'm not sure if this can be done, but using labels should make the question go away, and the problem causing it. :-) Labels are good for naming Drives but how does it help me if the root filesystem changing device ids. I don't think the boot loader is able to use the label for the root Filesystem. Regards Estartu -- - Gerhard Schmidt | E-Mail und JabberID: TU-München| schm...@ze.tum.de WWW Online Services | Tel: 089/289-25270| Fax: 089/289-25257| PGP-Publickey auf Anfrage ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: ata controller problem
Hi, On Sat, 27 Oct 2012 10:22:01 +0200 Gerhard Schmidt schm...@ze.tum.de wrote: hint.ada.3.at=scbus3 hint.ada.4.at=scbus4 hint.ada.5.at=scbus5 See CAM(4) man page (read it, don't skim!) for full details. Just please for the love of god do not use labels to solve this. Sorry this doesn't work because the numbering of the ahci change with the occupancy of the Hot-Swap Bays. And that is my Problem. This i have tried first. Any idea how i can fix which controller gets which number. just you labels. Chose the labelling method which fits best your file system. gpt seems to fit most scenarios. Labels came up to solve your problem. Erich ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: ata controller problem
Hi, On Sat, 27 Oct 2012 10:25:41 +0200 Gerhard Schmidt schm...@ze.tum.de wrote: On 26.10.2012 18:00, Polytropon wrote: = I'm not sure if this can be done, but using labels should make the question go away, and the problem causing it. :-) Labels are good for naming Drives but how does it help me if the root filesystem changing device ids. I don't think the boot loader is able to use the label for the root Filesystem. put a root file system on all drives and make it bootable. I use this trick also. You do not need that much space there to get the system up compared to the size of current media. Erich ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: ata controller problem
Am 27.10.2012 10:39, schrieb Erich Dollansky: Hi, On Sat, 27 Oct 2012 10:22:01 +0200 Gerhard Schmidt schm...@ze.tum.de wrote: hint.ada.3.at=scbus3 hint.ada.4.at=scbus4 hint.ada.5.at=scbus5 See CAM(4) man page (read it, don't skim!) for full details. Just please for the love of god do not use labels to solve this. Sorry this doesn't work because the numbering of the ahci change with the occupancy of the Hot-Swap Bays. And that is my Problem. This i have tried first. Any idea how i can fix which controller gets which number. just you labels. Chose the labelling method which fits best your file system. gpt seems to fit most scenarios. Labels came up to solve your problem. Can I mount the root filesystem via label. That's the problem here. Regard Estartu -- - Gerhard Schmidt | E-Mail und JabberID: TU-München| schm...@ze.tum.de WWW Online Services | Tel: 089/289-25270| Fax: 089/289-25257| PGP-Publickey auf Anfrage signature.asc Description: OpenPGP digital signature
Re: ata controller problem / AHCI numbering
On 2012.10.26 14:18, Gerhard Schmidt wrote: if there is a Drive in one of the HotSwap Bays the PCI-Express controller is detected as ahci0 and the onboard is detected as ahci1. So Far i could have set some devices.hints entries to sort the scsi busses. But the problem is that if there are no drives in the Bays the PCI-Expresscard is detected as ahci1 On 2012.10.27 10:22, Gerhard Schmidt wrote: Am 26.10.2012 18:33, schrieb Jeremy Chadwick: The proper way to solve this problem is to user /boot/loader.conf tie-downs to assign each disk to each individual controllers' device number (e.g. ada0 -- scbus0 -- ahcich0, or whatever you want). Please note I said ahcichX, not ahciX. Different things. Sorry this doesn't work because the numbering of the ahci change with the occupancy of the Hot-Swap Bays. I'm surprised and curious about this... Don't all devices, including SATA/AHCI controllers, get probed and numbered in the order they are presented to a kernel ? What can cause that presentation order to vary when physical connections don't change ? How could even an intrusive x86 BIOS feature change that presentation order based on whether or not a disk is connected to a peripheral device ? Doesn't a BIOS stay ignorant of what is plugged into external controllers, which have their own boot ROM ? Certainly FreeBSD's kernel would not bother to reorder device numbers based on what is connected to them lower down the chain after it's discovered these children, right ? (I'd be curious to take a look at your dmesg, Gerhard) I wish I could test this and figure it out on my own, but I don't have the right hardware available to replicate it and VirtualBox only supports a single virtual SATA controller. Using two identical (crappy) ASMedia AHCI 6Gbps PCIe adapters, I wasn't able to get their ahci numbering reversed by plugging or unplugging disks from them before booting. But the mainboard's SATA controllers are driven by atapci instead of ahci, so it's not quite the same... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: ata controller problem
Gerhard Schmidt schm...@ze.tum.de writes: Labels are good for naming Drives but how does it help me if the root filesystem changing device ids. I don't think the boot loader is able to use the label for the root Filesystem. From my fstab: /dev/ufs/Oak / ufs rw,noatime 1 1 /dev/label/OakSwap none swapsw 0 0 I think any of the other label schemes will also work. If you don't remember which label is which device id, then 'glabel status' will show that, but you shouldn't need to. -- Carl Johnsonca...@peak.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
ata controller problem
Hi, i have a very strange Problem with my new Workstation. The Problem is the order of the sata controllers. The Mainboard has 6 sata Ports and i have a PCI-Express Card with 4 more sata Channels. I boot from a SSD connected to port 0 in the Mainboard. Channels 1-3 are additional Harddisks and 5 is a optical drive. I've a Hotswap-Bay for 3 SATA Drives the bay is connected to the PCI-Express Card SATA Channel. The Problem is that, if there is a Drive in one of the HotSwap Bays the PCI-Express controller is detected as ahci0 and the onboard is detected as ahci1. Therefore any drives in the HotSwap Bays become ada0-3 and the drives on the mainboard controller are the upper numbers which causes the boot to fail as the Root Partition isn't there where it's expected. The BIOS has the PCI-Express Card as second Card only so the Kernel is Booted but the RootFS is not Found. So Far i could have set some devices.hints entries to sort the scsi busses. But the problem is that if there are no drives in the Bays the PCI-Expresscard is detected as ahci1 Is there a way to ensure that the onboard SATA Controller is always probed first. Regards Gerhard -- - Gerhard Schmidt | E-Mail und JabberID: TU-München| schm...@ze.tum.de WWW Online Services | ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: ata controller problem
On Fri, 26 Oct 2012 14:18:16 +0200, Gerhard Schmidt wrote: The Problem is that, if there is a Drive in one of the HotSwap Bays the PCI-Express controller is detected as ahci0 and the onboard is detected as ahci1. Therefore any drives in the HotSwap Bays become ada0-3 and the drives on the mainboard controller are the upper numbers which causes the boot to fail as the Root Partition isn't there where it's expected. The BIOS has the PCI-Express Card as second Card only so the Kernel is Booted but the RootFS is not Found. You can use labels (GPT or UFS labels) or UFSIDs to become independent of the actual device name where things are stored on. You could also use this to make disks easier to identify (e. g. /dev/label/red1root = the disk with a red 1 on it, carrying the root file system). I suggest those pages for more detailed information: http://www.wonkity.com/~wblock/docs/html/disksetup.html http://www.freebsd.org/doc/handbook/geom-glabel.html Maybe as well (specific and general notes and inspiration): http://www.daemonforums.org/showthread.php?t=2666 http://www.freebsdonline.com/content/view/731/506/ http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/disks.html I assume that you are using UFS. Is there a way to ensure that the onboard SATA Controller is always probed first. I'm not sure if this can be done, but using labels should make the question go away, and the problem causing it. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: ata controller problem
Regarding this: http://lists.freebsd.org/pipermail/freebsd-questions/2012-October/245862.html No no NO *NO*! I wish people would stop recommending this utter garbage. There is absolutely no justification behind using the highly convoluted labelling mechanisms at multiple layers within FreeBSD. There are 3 (possibly 4) different label mechanisms which do nothing but confuse the user, or cause other oddities/complexities. Good grief, there is so much hard evidence on the mailing lists over the past 5 (maybe even 7?) years talking about the utter mess that is filesystem/device/geom/blahblah labels that to recommend this is borderline insane. The proper way to solve this problem is to user /boot/loader.conf tie-downs to assign each disk to each individual controllers' device number (e.g. ada0 -- scbus0 -- ahcich0, or whatever you want). Please note I said ahcichX, not ahciX. Different things. I have helped others in the past do this; Randy Bush is one such person. Taken directly from my /boot/loader.conf with a single SATA controller, but obviously this can be adjusted to whatever you want. # Wire down device names (ada[0-5]) to each individual port # on the SATA/AHCI controller. This ensures that if we reboot # with a disk missing, the device names stay the same, and stay # attached to the same SATA/AHCI controller. # http://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011036.html # hint.scbus.0.at=ahcich0 hint.scbus.1.at=ahcich1 hint.scbus.2.at=ahcich2 hint.scbus.3.at=ahcich3 hint.scbus.4.at=ahcich4 hint.scbus.5.at=ahcich5 hint.ada.0.at=scbus0 hint.ada.1.at=scbus1 hint.ada.2.at=scbus2 hint.ada.3.at=scbus3 hint.ada.4.at=scbus4 hint.ada.5.at=scbus5 See CAM(4) man page (read it, don't skim!) for full details. Just please for the love of god do not use labels to solve this. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: ata controller problem
On Fri, 26 Oct 2012 09:33:38 -0700, Jeremy Chadwick wrote: Regarding this: http://lists.freebsd.org/pipermail/freebsd-questions/2012-October/245862.html No no NO *NO*! No? :-) I wish people would stop recommending this utter garbage. There is absolutely no justification behind using the highly convoluted labelling mechanisms at multiple layers within FreeBSD. There are 3 (possibly 4) different label mechanisms which do nothing but confuse the user, or cause other oddities/complexities. Good grief, there is so much hard evidence on the mailing lists over the past 5 (maybe even 7?) years talking about the utter mess that is filesystem/device/geom/blahblah labels that to recommend this is borderline insane. Yes, the amount of different, present (in parallel) and differently implemented and accessible labeling mechanisms can be confusing. There is no the one true way to do it. Especially when dealing with metadata (e. g. for rare cases of data recovery) it might make things more complicated. I don't agree that labels in general do nothing but confuse the user - the same could be said about controllers, devices and how they are partitioned (again, many different ways here). But users usually don't deal with that. Sysadmins do. And they should be able to deal with it, as it's not _that_ complicated (from their educated and experienced point of view, I assume). That's why I would still say labels have their place, especially in settings with many disks (10 and more) where concluding which disk? is sometimes required, in terms of disk, not disk _bay_. The proper way to solve this problem is to user /boot/loader.conf tie-downs to assign each disk to each individual controllers' device number (e.g. ada0 -- scbus0 -- ahcich0, or whatever you want). Please note I said ahcichX, not ahciX. Different things. I have helped others in the past do this; Randy Bush is one such person. Taken directly from my /boot/loader.conf with a single SATA controller, but obviously this can be adjusted to whatever you want. # Wire down device names (ada[0-5]) to each individual port # on the SATA/AHCI controller. This ensures that if we reboot # with a disk missing, the device names stay the same, and stay # attached to the same SATA/AHCI controller. # http://lists.freebsd.org/pipermail/freebsd-fs/2011-March/011036.html # hint.scbus.0.at=ahcich0 hint.scbus.1.at=ahcich1 hint.scbus.2.at=ahcich2 hint.scbus.3.at=ahcich3 hint.scbus.4.at=ahcich4 hint.scbus.5.at=ahcich5 hint.ada.0.at=scbus0 hint.ada.1.at=scbus1 hint.ada.2.at=scbus2 hint.ada.3.at=scbus3 hint.ada.4.at=scbus4 hint.ada.5.at=scbus5 That's a very nice contribution to the topic - I hadn't thought it was that easy, and it actually solves the who comes first kind of problems. See CAM(4) man page (read it, don't skim!) for full details. Just please for the love of god do not use labels to solve this. Thanks, this contains inspiration of maybe how to make access to USB devices and memory card readers more efficient (i. e. making sure they are always represented by one and the same device, instead of the next free one). -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: ata controller problem
On Fri, Oct 26, 2012 at 06:43:28PM +0200, Polytropon wrote: I wish people would stop recommending this utter garbage. There is absolutely no justification behind using the highly convoluted labelling mechanisms at multiple layers within FreeBSD. There are 3 (possibly 4) different label mechanisms which do nothing but confuse the user, or cause other oddities/complexities. Good grief, there is so much hard evidence on the mailing lists over the past 5 (maybe even 7?) years talking about the utter mess that is filesystem/device/geom/blahblah labels that to recommend this is borderline insane. Yes, the amount of different, present (in parallel) and differently implemented and accessible labeling mechanisms can be confusing. There is no the one true way to do it. Especially when dealing with metadata (e. g. for rare cases of data recovery) it might make things more complicated. I don't agree that labels in general do nothing but confuse the user - the same could be said about controllers, devices and how they are partitioned (again, many different ways here). But users usually don't deal with that. Sysadmins do. And they should be able to deal with it, as it's not _that_ complicated (from their educated and experienced point of view, I assume). That's why I would still say labels have their place, especially in settings with many disks (10 and more) where concluding which disk? is sometimes required, in terms of disk, not disk _bay_. Let me make myself extra clear here -- and I won't be replying past this point (privately or publicly): What the OP wanted was to have a static mapping between a physical SATA port (e.g. Card #1 Port #0) and a device name (e.g. ada0) -- one which never changes no matter if there's a disk attached to the port or not. The wire-down method described above does this. Using labels does not. Here's a list of the wonderful fun things labels offer: - You get to remember or write down the label; don't forget it - You get to change /etc/fstab - You get to pray you never have to replace a disk, and if you do, that you remember which labelling method you used, and/or deal with partitioning complexities (see last item) - You get to be subjected to bugs in the GEOM layer or UFS layer when it comes to labels (this has happened!) - If using GPT (the only present way to align a partition properly to a 1MByte boundary -- matters greatly for SSDs due to NAND erase page size!), you're subjected to the problem where GEOM stores its metadata in the last sector, which is also where GPT stores its backup table. This is even documented in the Handbook, which is both good *and* hilarious at the same time And don't forget about the automatic vs. manual GEOM label method (but for this case I'm assuming automatic is used, since that method stores metadata). Every one of these situations has happened to at least one person in the past 5 (7?) years. They CONTINUE to happen. It cannot be denied. We FreeBSD users way too often shove our fingers into our ears and yell LALALA when people point out shortcomings. Blind advocacy of any kind of technology these days is something to be wary of. All that said: labels have a very, very specific purpose, backed by a list of many caveats. But I want to ensure controller port X maps to device X at all times is not one of those purposes. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: ata controller problem
On Fri, 26 Oct 2012, Jeremy Chadwick wrote: Regarding this: http://lists.freebsd.org/pipermail/freebsd-questions/2012-October/245862.html No no NO *NO*! I wish people would stop recommending this utter garbage. There is absolutely no justification behind using the highly convoluted labelling mechanisms at multiple layers within FreeBSD. There are 3 (possibly 4) different label mechanisms which do nothing but confuse the user, or cause other oddities/complexities. Good grief, there is so much hard evidence on the mailing lists over the past 5 (maybe even 7?) years talking about the utter mess that is filesystem/device/geom/blahblah labels that to recommend this is borderline insane. Hmm. Six months to April 1? Seriously, labels provide a simple, relocatable identification mechanism that works across machines. If someone finds them confusing, it can be cleared up easily: use GPT labels when possible, otherwise use filesystem labels or glabel. The proper way to solve this problem is to user /boot/loader.conf tie-downs to assign each disk to each individual controllers' device number (e.g. ada0 -- scbus0 -- ahcich0, or whatever you want). Please note I said ahcichX, not ahciX. Different things. Labels work on different machines or controllers without added configuration, and stay with the partition or filesystem. Your static config appears to not share those properties. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: ata controller problem
Hi, On Fri, 26 Oct 2012 09:33:38 -0700 Jeremy Chadwick j...@koitsu.org wrote: Regarding this: http://lists.freebsd.org/pipermail/freebsd-questions/2012-October/245862.html No no NO *NO*! YES, YES, YES, YES! The proper way to solve this problem is to user /boot/loader.conf How does this help when media is moved between machines? Erich ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
ata controller problem
You should try to disable ata dma. Press any key(besides enter) when you see the following message: Hit [Enter] to boot immediately, or any other key for command prompt. then type set hw.ata.ata_dma=0 boot That should fix -I mean you 'll be able to boot your system- the problem, but disk access will be slower without DMA and will be using much CPU power. Then you can provide more info using dmesg and pciconf -lv and get more help. Cheers. NikV On Thursday 01 September 2005 08:55, vola wrote: I have a question. Not long ago i have download the FreeBsd 4.10 operetion system. By the installation i have problems. I put the cd into the cd-rom and I restarted the computer. The computer boot from the cd and the installation began. It looks all ok - the computer was loading. But then had stop all. The last massage was reading time out (or somthing like this) and the next massage was resething deveises. I think it has somethink to do with my hard drive ( Maxtor 40GB ). Please help me with this. ( sorry for my english ) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
