Re: Bioctl ciss controller status
--- Quoting Doros Eracledes on 2007/07/19 at 10:42 +0100: I have a proliant DL360-G5 and loaded 4.1-stable on it, all hardware is detected fine. I want see if I can get the raid controller status with bioctl. Controller initially came with firmware 1.20 so I upgraded it to the latest (1.66) version but still can't get the raid controller status using bioctl. Here is what I get: #bioctl sd0 bioctl: BIOCINQ: Inappropriate ioctl for device Known issue, no fix. mickey@ told me he found the issue but I'm not sure what happened to the code. FYI, this issue doesn't seem to happen on the DL380. .joel
Re: Bioctl ciss controller status
On Fri, 20 Jul 2007 00:49:03 -0600 Joel Knight [EMAIL PROTECTED] wrote: --- Quoting Doros Eracledes on 2007/07/19 at 10:42 +0100: I have a proliant DL360-G5 and loaded 4.1-stable on it, all hardware is detected fine. I want see if I can get the raid controller status with bioctl. Controller initially came with firmware 1.20 so I upgraded it to the latest (1.66) version but still can't get the raid controller status using bioctl. Here is what I get: #bioctl sd0 bioctl: BIOCINQ: Inappropriate ioctl for device Known issue, no fix. mickey@ told me he found the issue but I'm not sure what happened to the code. FYI, this issue doesn't seem to happen on the DL380. I do have the same issue with 4.1 on a DL385, though. Only one volume configured, controller firmware 2.08. # bioctl ciss0 bioctl: Can't locate ciss0 device via /dev/bio -- Stephan A. Rickauer --- Institute of Neuroinformatics Tel +41 44 635 30 50 University / ETH Zurich Sec +41 44 635 30 52 Winterthurerstrasse 190 Fax +41 44 635 30 53 CH-8057 ZurichWeb www.ini.unizh.ch RSA public key: https://www.ini.uzh.ch/~stephan/pubkey.asc ---
Re: Bioctl ciss controller status
On Fri, 20 Jul 2007, Stephan A. Rickauer wrote:
On Fri, 20 Jul 2007 00:49:03 -0600
Joel Knight [EMAIL PROTECTED] wrote:
--- Quoting Doros Eracledes on 2007/07/19 at 10:42 +0100:
I have a proliant DL360-G5 and loaded 4.1-stable on it, all
hardware is detected fine.
I want see if I can get the raid controller status with bioctl.
Controller initially came with firmware 1.20 so I upgraded it to the
latest (1.66) version but still can't get the raid controller status
using bioctl.
Here is what I get:
#bioctl sd0
bioctl: BIOCINQ: Inappropriate ioctl for device
Known issue, no fix.
mickey@ told me he found the issue but I'm not sure what happened to
the code. FYI, this issue doesn't seem to happen on the DL380.
I do have the same issue with 4.1 on a DL385, though. Only one volume
configured, controller firmware 2.08.
# bioctl ciss0
bioctl: Can't locate ciss0 device via /dev/bio
The cause is that the ciss_inquiry struct returned by the firmware has the
member buswidth set to 0 (zero). So the physical drives do not get probed
by the driver. If you set this to some other value (the original value in
the last firmware versions was 16) the Identify Drive commands will
fail. If you change the addressing mode from the Big Bit method to the
old scheme the drives can be queried. I hacked up a small patch that made
it work for the servers used in our project (DL 380 G5). I attach it
here, but beware that it has some problems:
1. Drives that are identified by the scsi id 0:0.0 do not display the
right status. We do not have a drive there, so I did not look into that
for longer (no time for beauty work).
2. I had to check the drive present bit and would add only those drives
that were present on driver initialisation. Else the bioctl would show all
drives as Invalid (with exception to the one that would get the id
0:0.0).
Overall it is only a quick and dirty hack to make it work. I try to look
into that because I will have the servers here available a little bit
longer, but I can't promise that. The other parts of the overall project
are eating up all my time...
So this is the hack, I checked the functionality by removing one of the
drives and reinserting it. All seems to work ok with the exceptions
mentioned above. You can even mark a drive via bioctl. The patch is
against 4.1-stable, dmesg and bioctl output follows below. There is a
similar system with 5 HDs in a RAID 5 that works too. Use this at your
own risk:
Index: ciss.c
===
RCS file: /cvs/src/sys/dev/ic/ciss.c,v
retrieving revision 1.24
diff -u -p -r1.24 ciss.c
--- ciss.c 18 Jan 2007 14:46:24 - 1.24
+++ ciss.c 20 Jul 2007 10:21:41 -
@@ -330,6 +330,14 @@ ciss_attach(struct ciss_softc *sc)
sc-maxunits = inq-numld;
sc-nbus = inq-nscsi_bus;
sc-ndrives = inq-buswidth;
+
+ if (sc-ndrives == 0) {
+ /* Handle the new firmware */
+
+ sc-sc_flags |= CISS_NOBIGBIT;
+ sc-ndrives = 16;
+ }
+
printf(: %d LD%s, HW rev %d, FW %4.4s/%4.4s\n,
inq-numld, inq-numld == 1? : s,
inq-hw_rev, inq-fw_running, inq-fw_stored);
@@ -1152,11 +1160,19 @@ ciss_ioctl(struct device *dev, u_long cm
if (!ldp)
continue;
for (pd = 0; pd ldp-ndrives; pd++)
- if (ldp-tgts[pd] == (CISS_BIGBIT +
- bb-bb_channel * sc-ndrives +
- bb-bb_target))
- error = ciss_blink(sc, ld, pd,
- bb-bb_status, blink);
+ if (sc-sc_flags CISS_NOBIGBIT) {
+ if (ldp-tgts[pd] == (
+ bb-bb_channel * sc-ndrives +
+ bb-bb_target))
+ error = ciss_blink(sc, ld, pd,
+ bb-bb_status, blink);
+ } else {
+ if (ldp-tgts[pd] == (CISS_BIGBIT +
+ bb-bb_channel * sc-ndrives +
+ bb-bb_target))
+ error = ciss_blink(sc, ld, pd,
+ bb-bb_status, blink);
+ }
}
break;
@@ -1318,9 +1334,14 @@ ciss_pdscan(struct ciss_softc *sc, int l
pdid = sc-scratch;
for (i = 0; i sc-nbus; i++)
for (j = 0; j sc-ndrives; j++) {
- drv = CISS_BIGBIT + i * sc-ndrives + j;
- if (!ciss_pdid(sc, drv, pdid, SCSI_NOSLEEP|SCSI_POLL))
-
Re: Bioctl ciss controller status
On Fri, 20 Jul 2007 12:35:53 +0200 (CEST) Markus Hennecke [EMAIL PROTECTED] wrote: # bioctl ciss0 bioctl: Can't locate ciss0 device via /dev/bio The cause is that the ciss_inquiry struct returned by the firmware has the member buswidth set to 0 (zero). So the physical drives do not get probed by the driver. If you set this to some other value (the original value in the last firmware versions was 16) the Identify Drive commands will fail. If you change the addressing mode from the Big Bit method to the old scheme the drives can be queried. I hacked up a small patch that made it work for the servers used in our project (DL 380 G5). I attach it here, but beware that it has some problems: 1. Drives that are identified by the scsi id 0:0.0 do not display the right status. We do not have a drive there, so I did not look into that for longer (no time for beauty work). 2. I had to check the drive present bit and would add only those drives that were present on driver initialisation. Else the bioctl would show all drives as Invalid (with exception to the one that would get the id 0:0.0). Overall it is only a quick and dirty hack to make it work. I try to look into that because I will have the servers here available a little bit longer, but I can't promise that. The other parts of the overall project are eating up all my time... So this is the hack, I checked the functionality by removing one of the drives and reinserting it. All seems to work ok with the exceptions mentioned above. You can even mark a drive via bioctl. The patch is against 4.1-stable, dmesg and bioctl output follows below. There is a similar system with 5 HDs in a RAID 5 that works too. Use this at your own risk: This is good news, thanks a lot. I will test it next week. However, if there is a developer interested in getting this quick fix more beautiful, I could enable remote login on one of our machines for testing and developing. Please contact me off list. Thanks, -- Stephan A. Rickauer --- Institute of Neuroinformatics Tel +41 44 635 30 50 University / ETH Zurich Sec +41 44 635 30 52 Winterthurerstrasse 190 Fax +41 44 635 30 53 CH-8057 ZurichWeb www.ini.unizh.ch RSA public key: https://www.ini.uzh.ch/~stephan/pubkey.asc ---
Bioctl ciss controller status
I have a proliant DL360-G5 and loaded 4.1-stable on it, all hardware is detected fine. I want see if I can get the raid controller status with bioctl. Controller initially came with firmware 1.20 so I upgraded it to the latest (1.66) version but still can't get the raid controller status using bioctl. Here is what I get: #bioctl sd0 bioctl: BIOCINQ: Inappropriate ioctl for device Any help would be appreciated. Here is the dmesg of the machine: OpenBSD 4.1-stable (GENERIC.MP) #0: Wed May 9 03:47:33 PDT 2007 [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2145349632 (2095068K) avail mem = 1833291776 (1790324K) using 22937 buffers containing 214740992 bytes (209708K) of memory mainbus0 (root) bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xee000 (67 entries) bios0: HP ProLiant DL360 G5 acpi at mainbus0 not configured ipmi0 at mainbus0: version 2.0 interface KCS iobase 0xca2/2 spacing 1 mainbus0: Intel MP Specification (Version 1.4) cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU 5120 @ 1.86GHz, 1866.99 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST ,TM2,CX16,xTPR,LONG cpu0: 4MB 64b/line 16-way L2 cache cpu0: apic clock running at 266MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Xeon(R) CPU 5120 @ 1.86GHz, 1866.74 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36, CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST ,TM2,CX16,xTPR,LONG cpu1: 4MB 64b/line 16-way L2 cache mpbios: bus 0 is type PCI mpbios: bus 1 is type PCI mpbios: bus 2 is type PCI mpbios: bus 3 is type PCI mpbios: bus 4 is type PCI mpbios: bus 5 is type PCI mpbios: bus 6 is type PCI mpbios: bus 9 is type PCI mpbios: bus 10 is type PCI mpbios: bus 11 is type PCI mpbios: bus 14 is type PCI mpbios: bus 15 is type PCI mpbios: bus 16 is type PCI mpbios: bus 19 is type PCI mpbios: bus 22 is type PCI mpbios: bus 39 is type ISA ioapic0 at mainbus0 apid 8 pa 0xfec0, version 20, 24 pins ioapic1 at mainbus0 apid 9 pa 0xfec8, version 20, 24 pins pci0 at mainbus0 bus 0: configuration mode 1 pchb0 at pci0 dev 0 function 0 vendor Intel, unknown product 0x25d8 rev 0xb1 ppb0 at pci0 dev 2 function 0 Intel 5000 PCIE rev 0xb1 pci1 at ppb0 bus 9 ppb1 at pci1 dev 0 function 0 Intel 6321ESB PCIE rev 0x01 pci2 at ppb1 bus 10 ppb2 at pci2 dev 0 function 0 Intel 6321ESB PCIE rev 0x01 pci3 at ppb2 bus 11 ppb3 at pci2 dev 1 function 0 Intel 6321ESB PCIE rev 0x01 pci4 at ppb3 bus 14 ppb4 at pci2 dev 2 function 0 Intel 6321ESB PCIE rev 0x01 pci5 at ppb4 bus 15 ppb5 at pci1 dev 0 function 3 Intel 6321ESB PCIE-PCIX rev 0x01 pci6 at ppb5 bus 16 ppb6 at pci0 dev 3 function 0 Intel 5000 PCIE rev 0xb1 pci7 at ppb6 bus 6 ppb7 at pci7 dev 0 function 0 ServerWorks PCIE-PCIX rev 0xb4 pci8 at ppb7 bus 7 ppb8 at pci8 dev 4 function 0 ServerWorks HT-1000 PCIX rev 0xb2 pci9 at ppb8 bus 8 ciss0 at pci8 dev 8 function 0 Hewlett-Packard Smart Array rev 0x00: apic 8 int 16 (irq 5) ciss0: 1 LD, HW rev 0, FW 1.66/1.66 scsibus0 at ciss0: 1 targets sd0 at scsibus0 targ 0 lun 0: HP, LOGICAL VOLUME, 1.66 SCSI3 0/direct fixed sd0: 34699MB, 34699 cyl, 64 head, 32 sec, 512 bytes/sec, 71065440 sec total ppb9 at pci0 dev 4 function 0 Intel 5000 PCIE rev 0xb1 pci10 at ppb9 bus 19 ppb10 at pci0 dev 5 function 0 Intel 5000 PCIE rev 0xb1 pci11 at ppb10 bus 22 ppb11 at pci0 dev 6 function 0 vendor Intel, unknown product 0x25e6 rev 0xb1 pci12 at ppb11 bus 2 ppb12 at pci12 dev 0 function 0 ServerWorks PCIE-PCIX rev 0xc3 pci13 at ppb12 bus 3 bnx0 at pci13 dev 0 function 0 Broadcom BCM5708 rev 0x12: apic 8 int 18 (irq 10) ppb13 at pci0 dev 7 function 0 Intel 5000 PCIE rev 0xb1 pci14 at ppb13 bus 4 ppb14 at pci14 dev 0 function 0 ServerWorks PCIE-PCIX rev 0xc3 pci15 at ppb14 bus 5 bnx1 at pci15 dev 0 function 0 Broadcom BCM5708 rev 0x12: apic 8 int 19 (irq 10) pchb1 at pci0 dev 16 function 0 Intel 5000 Error Reporting rev 0xb1 pchb2 at pci0 dev 16 function 1 Intel 5000 Error Reporting rev 0xb1 pchb3 at pci0 dev 16 function 2 Intel 5000 Error Reporting rev 0xb1 pchb4 at pci0 dev 17 function 0 Intel 5000 Reserved rev 0xb1 pchb5 at pci0 dev 19 function 0 Intel 5000 Reserved rev 0xb1 pchb6 at pci0 dev 21 function 0 Intel 5000 FBD rev 0xb1 pchb7 at pci0 dev 22 function 0 Intel 5000 FBD rev 0xb1 uhci0 at pci0 dev 29 function 0 Intel 6321ESB USB rev 0x09: apic 8 int 16 (irq 5) usb0 at uhci0: USB revision 1.0 uhub0 at usb0 uhub0: Intel UHCI root hub, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1 at pci0 dev 29 function 1 Intel 6321ESB USB rev 0x09: apic 8 int 17 (irq 7) usb1 at uhci1: USB revision 1.0 uhub1 at usb1 uhub1: Intel UHCI root hub, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2 at pci0 dev 29 function 2 Intel 6321ESB USB rev 0x09: apic 8 int 18 (irq 10) usb2 at uhci2: USB revision 1.0 uhub2 at usb2 uhub2: Intel UHCI
