cam subsystem vs usb
Hi, I use a 5-hdd bunch connected via USB3 in JBOD mode; that 5 hdd builds a zpool and are listed during boot process as da0 to da4. Here is my /boot/loader.conf file: .../... hw.snd.default_device=2 dev.pcm.1.play.vchans=2 fuse_load="YES" kern.cam.boot_delay=12000 kern.vty=vt sysctl net.local.stream.recvspace=65536 cpu_microcode_load="YES" cpu_microcode_name="/boot/firmware/intel-ucode.bin" sysctl net.local.stream.recvspace=65536 sysctl net.local.stream.sendspace=65536 .../... Under FBSD12.0, the boot process got fine. Since recent upgrade to 12.1, the first "cold" boot shows: .../... Dec 7 10:17:25 H97M-G43 kernel: Trying to mount root from ufs:/dev/ada1p2 [rw]... Dec 7 10:17:25 H97M-G43 kernel: da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 Dec 7 10:17:25 H97M-G43 kernel: da0: Fixed Direct Access SPC-4 SCSI device Dec 7 10:17:25 H97M-G43 kernel: da0: Serial Number 2019083100443 Dec 7 10:17:25 H97M-G43 kernel: da0: 400.000MB/s transfers Dec 7 10:17:25 H97M-G43 kernel: da0: 953869MB (1953525168 512 byte sectors) Dec 7 10:17:25 H97M-G43 kernel: da0: quirks=0x2 Dec 7 10:17:25 H97M-G43 kernel: da1 at umass-sim0 bus 0 scbus3 target 0 lun 1 Dec 7 10:17:25 H97M-G43 kernel: da1: Fixed Direct Access SPC-4 SCSI device Dec 7 10:17:25 H97M-G43 kernel: da1: Serial Number 2019083100443 Dec 7 10:17:25 H97M-G43 kernel: da1: 400.000MB/s transfers Dec 7 10:17:25 H97M-G43 kernel: da1: 953869MB (1953525168 512 byte sectors) Dec 7 10:17:25 H97M-G43 kernel: da1: quirks=0x2 Dec 7 10:17:25 H97M-G43 kernel: da2 at umass-sim0 bus 0 scbus3 target 0 lun 2 Dec 7 10:17:25 H97M-G43 kernel: da2: Fixed Direct Access SPC-4 SCSI device Dec 7 10:17:25 H97M-G43 kernel: da2: Serial Number 2019083100443 Dec 7 10:17:25 H97M-G43 kernel: da2: 400.000MB/s transfers Dec 7 10:17:25 H97M-G43 kernel: da2: 953869MB (1953525168 512 byte sectors) Dec 7 10:17:25 H97M-G43 kernel: da2: quirks=0x2 Dec 7 10:17:25 H97M-G43 kernel: da3 at umass-sim0 bus 0 scbus3 target 0 lun 3 Dec 7 10:17:25 H97M-G43 kernel: da3: Fixed Direct Access SPC-4 SCSI device Dec 7 10:17:25 H97M-G43 kernel: da3: Serial Number 2019083100443 Dec 7 10:17:25 H97M-G43 kernel: da3: 400.000MB/s transfers Dec 7 10:17:25 H97M-G43 kernel: da3: 953869MB (1953525168 512 byte sectors) Dec 7 10:17:25 H97M-G43 kernel: da3: quirks=0x2 Dec 7 10:17:25 H97M-G43 kernel: da4 at umass-sim0 bus 0 scbus3 target 0 lun 4 Dec 7 10:17:25 H97M-G43 kernel: da4: Fixed Direct Access SPC-4 SCSI device Dec 7 10:17:25 H97M-G43 kernel: da4: Serial Number 2019083100443 Dec 7 10:17:25 H97M-G43 kernel: da4: 400.000MB/s transfers Dec 7 10:17:25 H97M-G43 kernel: da4: 953869MB (1953525168 512 byte sectors) Dec 7 10:17:25 H97M-G43 kernel: da4: quirks=0x2 Dec 7 10:17:25 H97M-G43 kernel: (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 74 70 6d 71 00 00 04 00 Dec 7 10:17:25 H97M-G43 kernel: (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error Dec 7 10:17:25 H97M-G43 kernel: (da0:umass-sim0:0:0:0): SCSI status: Check Condition Dec 7 10:17:25 H97M-G43 kernel: (da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:4,1(Logical unit is in process of becoming ready) Dec 7 10:17:25 H97M-G43 kernel: (da0:umass-sim0:0:0:0): Polling device for readiness Dec 7 10:17:25 H97M-G43 kernel: ZFS filesystem version: 5Dec 7 10:17:25 H97M-G43 kernel: ZFS storage pool version: features support (5000) .../... The readiness time takes about 10 seconds. Curiously, further "warm" reboots are going fine, without any readiness sequence. Could this behaviour be related to the cam_system/usb_system problem leading to hang the boot process, recently reported? Hope this be usefull for debugging the cam subsystem. Roger Genre ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.x installer and GPT vs geom, features in bsdinstall
On 10/13/11, Oliver Hartman wrote: On 10/13/11 10:39, Johan Hendriks wrote: Hello all. I just used the 9.0 B3 installer, and it defaults to GPT, which is nice. However, and there has been some discussions about it, it would be nice if the installer warns me that i could get in trouble if i want to use gmirror and the like. Also i find it a little strange that the default mode, GPT in this case is in some sort not compatible with the other default geom structure. For a newcomer or for people who use gmirror and glabel on a regular basis because there somewhat default, it could strike them if they start using the default GPT. It is not logical. Two default ways to do things that are in a way not compatible. So a warning at the installer level could make a lot of users aware of this, and they can decide what to do, use GPT or go back to the old MBR. They can start looking at the mailling list and so on to make the right decision is GPT acceptable for me or not. And not install FreeBSD and find out later that you could not use your old gmirror and glabel tactics without corrupting the GPT structure. Just my thoughts about this. regards, Johan Hendriks Shouldn't be there also a warning that GPT can not be used with the FreeBSD native bootselector? I had trouble installing FreeBSD 9.0-CURRENT a while ago with default being GPT on my notebook and also wanting a Windows 7/x64 for presentations, selectable via the FreeBSD bootselector. This was possible with MBR, but it seems gone with GPT. Regards, Oliver GPT shouldn't be installed with ANY bootselector present on the same device ! But, I noticed that when installing 9.0B1 on 2nd slice of a MBR disk (1st slice with 8.2), using expert mode in Bsdinstall, (so selecting a MBR installation), I did not have the expected choice (like in sysinstall) between a MBR bootloader, a standard MBR , or don't touch to bootsector; (no damage for me, as my bootselector --grub--is installed on a separate disk dedicated to rescue and booting, allowing me to be more safe when testing newer releases); could this usefull previous choice be merged in Bsdinstall ? Later, I installed the 9.0B3 on a free disk, using the guided mode in Bsdinstall, and selecting an GPT installation, that worked fine; but I found very few differences between guided and expert mode (both require a minimal expertise). The use of auto choice would be too more documented, instead of letting the user to see what will happen ?. I agree with the suggestion to introduce warnings in the installer itself, against the most dangerous incompatibilities, between gpt and geom, or whatever that could appear during the beta testing; but more generally the question is : what level of information need to be present in the installation medium, apart of the installer, allowing non-expert to succed installation whit a minimum of mistakes; it is obvious that having a look on the mailing lists BEFORE to begin is very helpfull, and a digest of the most important threads could appear as a README-1st or an installation-FAQ with the proper comments, at the ordinary-user level? Regards Roger ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
hd numbering in 9.0beta1
Hi everybody, I would point out a problem related with the new way, coming in 9.0, to hard disks numbering. As far I remember (5.0 ?), hardware detection of H.D.'s at O.S. boot-up numbered every channel potentially able to attach a disk to, and tagged the disks really attached with the number of his control channel; the sequence (from lowers to highers numbers) begins with scsi or scsi-like (e-sata, usb, fire-wire,...) controllers and ends with the controllers directly depending from the chipset (sata at this time). Such strategy allows to attach easily a new mass-storage device without modifying the disks numbering and thus the relevant fstab files. 9.0beta1 use a different numbering strategy,(with a similar sequence in harware detection) tagging succesively detected disks with adjacent numbers. Please, let me show an example from my computer: lines relevant to hard disks from /var/log/messages (recently installed FreeBSD-9.0beta1): --- Aug 26 09:21:30 P5E-WS kernel: pci2: ACPI PCI bus on pcib8 Aug 26 09:21:30 P5E-WS kernel: siis0: SiI3132 SATA controller port 0xac00-0xac7f mem 0xfe6ffc00-0xfe6ffc7f,0xfe6f8000-0xfe6fbfff irq 17 at device 0.0 on pci2 Aug 26 09:21:30 P5E-WS kernel: siisch0: SIIS channel at channel 0 on siis0 Aug 26 09:21:30 P5E-WS kernel: siisch1: SIIS channel at channel 1 on siis0 Aug 26 09:21:30 P5E-WS kernel: ada0 at siisch1 bus 0 scbus6 target 0 lun 0 Aug 26 09:21:30 P5E-WS kernel: ada0: WDC WD20EARS-00MVWB0 51.0AB51 ATA-8 SATA 2.x device Aug 26 09:21:30 P5E-WS kernel: ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) Aug 26 09:21:30 P5E-WS kernel: ada0: Command Queueing enabled Aug 26 09:21:30 P5E-WS kernel: ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) Aug 26 09:21:30 P5E-WS kernel: ada0: Previously was known as ad16 Aug 26 09:21:30 P5E-WS kernel: ada1 at ata3 bus 0 scbus9 target 0 lun 0 Aug 26 09:21:30 P5E-WS kernel: ada1: WDC WD3200AAKS-00B3A0 01.03A01 ATA-8 SATA 2.x device Aug 26 09:21:30 P5E-WS kernel: ada1: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) Aug 26 09:21:30 P5E-WS kernel: ada1: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) Aug 26 09:21:30 P5E-WS kernel: ada1: Previously was known as ad18 Aug 26 09:21:30 P5E-WS kernel: ada2 at ata4 bus 0 scbus10 target 0 lun 0 Aug 26 09:21:30 P5E-WS kernel: ada2: Maxtor 6V160E0 VA111630 ATA-7 SATA 2.x device Aug 26 09:21:30 P5E-WS kernel: ada2: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) Aug 26 09:21:30 P5E-WS kernel: ada2: 152627MB (312581808 512 byte sectors: 16H 63S/T 16383C) Aug 26 09:21:30 P5E-WS kernel: ada2: Previously was known as ad20 Aug 26 09:21:30 P5E-WS kernel: ada3 at ata5 bus 0 scbus11 target 0 lun 0 Aug 26 09:21:30 P5E-WS kernel: ada3: SAMSUNG HD502IJ 1AA01110 ATA-7 SATA 2.x device Aug 26 09:21:30 P5E-WS kernel: ada3: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) Aug 26 09:21:30 P5E-WS kernel: ada3: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) Aug 26 09:21:30 P5E-WS kernel: ada3: Previously was known as ad22 - Well, the system remembers the previous numbering (in my example, numbering from 8.2 release, as production release installed on a different slice), avoiding confusion. But the funny things are that : 1- AMI Bios (MBR style) in my Asus M.B.(3 years old) shows, in the POST table relevant to disks, only the 3 first ones, i.e does not show the disk controlled by the SiI3132 pci-card; ami-bios don't list this disk as bootable in the disk-boot-order selection menu, and it's impossible to select it as a bootable disks. (but this disk appears correctly detected by the pci-card internal bios.); and I suppose the ami-bios detects and records the scsi-like disk, but hide it to the user. 2- Grub detects as hd0,hd1,hd2,hd3 the disks appearing in 9.0 as ada1, ada2, ada3, ada0 (i.e. Grub numbers with the scsi-like ones at the end and the chipset-controlled ones at the beginning).(Grub is said to extract the info from bios). At this point, no real problem, as Bsd users warn carefully in the management of their disks between different releases of the O.S. But adding a new hard disk will shift one, more, or all the previous numbers, (depênding from the channel the new disk is attached to), making the /etc/fstab files irrelevant, and leading kernel in panic at boot-up. Well, I could, after adding a new disk, boot-up from a rescue disk to update files, (or rootmount manually, log as single, edit the proper config files, ...) but really the old numbering strategy was less painfull ! And I would panic if I have to explain that process to a newbee. Perhaps I miss some important new feature introduced in 9.0 to work around that problem ? Moreover, 9.0beta1 installs very easily and works fine; I am near to agree with the recently stated opinion that 9.1 release will never be necessary !! Congratulations to the team Roger As frenchie, I apologize for
