Re: r232411 breaks onboard 1068 detection
On Tue, Apr 03, 2012 at 05:55:19AM +0400, Andrew Pantyukhin wrote: Hello, r232411 broke onboard 1068 detection on all boxes with SuperMicro X8ST3 motherboards for us. All of them are also equipped with two extra 1068 controllers, which are detected fine. Reverting to r231518 with otherwise latest stable kernel works around the problem. The issue is still there at r233425. Here's the disappearing device: mpt2@pci0:5:0:0:class=0x01 card=0x10001000 chip=0x00591000 rev=0x08 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = 'MegaRAID SAS 8208ELP/8208ELP' class = mass storage subclass = SCSI Should be fixed in r233827. Marius ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Contractjobs.com - 250,000 Live Searchable Contractor CVs
___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: r232411 breaks onboard 1068 detection
On Tue, Apr 03, 2012 at 10:29:27AM +0200, Marius Strobl wrote: On Tue, Apr 03, 2012 at 05:55:19AM +0400, Andrew Pantyukhin wrote: Hello, r232411 broke onboard 1068 detection on all boxes with SuperMicro X8ST3 motherboards for us. All of them are also equipped with two extra 1068 controllers, which are detected fine. Reverting to r231518 with otherwise latest stable kernel works around the problem. The issue is still there at r233425. Here's the disappearing device: mpt2@pci0:5:0:0:class=0x01 card=0x10001000 chip=0x00591000 rev=0x08 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = 'MegaRAID SAS 8208ELP/8208ELP' class = mass storage subclass = SCSI Should be fixed in r233827. Btw., Kashyap, could you please trigger LSI to update their mpi_cnfg.h to include all the device IDs that actually should be handled by MPT drivers. The FreeBSD mpt(4) additionally knows about the devices below, which based on the fact they are not probed by the Linux counterpart and are not found in PCI ID lists might not even exist in the wild, or as in the above case, still might miss some actual devices not currently found in mpi_cnfg.h. #define MPI_MANUFACTPAGE_DEVICEID_FC909_FB 0x0620 #define MPI_MANUFACTPAGE_DEVICEID_FC919_LAN_FB 0x0625 #define MPI_MANUFACTPAGE_DEVICEID_FC929_LAN_FB 0x0623 #define MPI_MANUFACTPAGE_DEVICEID_FC929X_LAN_FB 0x0627 #define MPI_MANUFACTPAGE_DEVICEID_FC919X_LAN_FB 0x0629 #define MPI_MANUFACTPAGE_DEVID_SAS1068A_FB 0x0055 #define MPI_MANUFACTPAGE_DEVID_SAS1068E_FB 0x0059 #define MPI_MANUFACTPAGE_DEVID_SAS1078DE_FB 0x007C Marius ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: r232411 breaks onboard 1068 detection
-Original Message- From: Marius Strobl [mailto:mar...@alchemy.franken.de] Sent: Tuesday, April 03, 2012 5:59 PM To: Desai, Kashyap Cc: sta...@freebsd.org; zvq...@di.vc; k...@freebsd.org; Andrew Pantyukhin Subject: Re: r232411 breaks onboard 1068 detection On Tue, Apr 03, 2012 at 10:29:27AM +0200, Marius Strobl wrote: On Tue, Apr 03, 2012 at 05:55:19AM +0400, Andrew Pantyukhin wrote: Hello, r232411 broke onboard 1068 detection on all boxes with SuperMicro X8ST3 motherboards for us. All of them are also equipped with two extra 1068 controllers, which are detected fine. Reverting to r231518 with otherwise latest stable kernel works around the problem. The issue is still there at r233425. Here's the disappearing device: mpt2@pci0:5:0:0:class=0x01 card=0x10001000 chip=0x00591000 rev=0x08 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = 'MegaRAID SAS 8208ELP/8208ELP' class = mass storage subclass = SCSI Should be fixed in r233827. Btw., Kashyap, could you please trigger LSI to update their mpi_cnfg.h to include all the device IDs that actually should be handled by MPT drivers. The FreeBSD mpt(4) additionally knows about the devices below, which based on the fact they are not probed by the Linux counterpart and are not found in PCI ID lists might not even exist in the wild, or as in the above case, still might miss some actual devices not currently found in mpi_cnfg.h. #define MPI_MANUFACTPAGE_DEVICEID_FC909_FB 0x0620 #define MPI_MANUFACTPAGE_DEVICEID_FC919_LAN_FB 0x0625 #define MPI_MANUFACTPAGE_DEVICEID_FC929_LAN_FB 0x0623 #define MPI_MANUFACTPAGE_DEVICEID_FC929X_LAN_FB 0x0627 #define MPI_MANUFACTPAGE_DEVICEID_FC919X_LAN_FB 0x0629 #define MPI_MANUFACTPAGE_DEVID_SAS1068A_FB0x0055 #define MPI_MANUFACTPAGE_DEVID_SAS1068E_FB 0x0059 #define MPI_MANUFACTPAGE_DEVID_SAS1078DE_FB 0x007C Hi Marius, This is very critical part of discussion and I do not have really best answer, because I don't know the history behind it. Added Steve M for better help. Also I have contacted Megaraid Driver team to respond what is device id 0x0059 ? FYI: I am referring pciid from below link. http://pciids.sourceforge.net/v2.2/pci.ids Marius ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [stable-ish 9] Dell R815 ipmi(4) attach failure
On Monday, April 02, 2012 7:27:13 pm Doug Ambrisko wrote:
Doug Ambrisko writes:
| John Baldwin writes:
| | On Saturday, March 31, 2012 3:25:48 pm Doug Ambrisko wrote:
| | Sean Bruno writes:
| | | Noting a failure to attach to the onboard IPMI controller with this
dell
| | | R815. Not sure what to start poking at and thought I'd though this
over
| | | here for comment.
| | |
| | | -bash-4.2$ dmesg |grep ipmi
| | | ipmi0: KCS mode found at io 0xca8 on acpi
| | | ipmi1: IPMI System Interface on isa0
| | | device_attach: ipmi1 attach returned 16
| | | ipmi1: IPMI System Interface on isa0
| | | device_attach: ipmi1 attach returned 16
| | | ipmi0: Timed out waiting for GET_DEVICE_ID
| |
| | I've run into this recently. A quick hack to fix it is:
| |
| | Index: ipmi.c
| | ===
| | RCS file: /cvs/src/sys/dev/ipmi/ipmi.c,v
| | retrieving revision 1.14
| | diff -u -p -r1.14 ipmi.c
| | --- ipmi.c 14 Apr 2011 07:14:22 - 1.14
| | +++ ipmi.c 31 Mar 2012 19:18:35 -
| | @@ -695,7 +695,6 @@ ipmi_startup(void *arg)
| | if (error == EWOULDBLOCK) {
| | device_printf(dev, Timed out waiting for
GET_DEVICE_ID\n);
| | ipmi_free_request(req);
| | - return;
| | } else if (error) {
| | device_printf(dev, Failed GET_DEVICE_ID: %d\n, error);
| | ipmi_free_request(req);
| |
| | The issue is that the wakeup doesn't actually wake up the msleep
| | in ipmi_submit_driver_request. The error being reported is that
| | the msleep timed out. This doesn't seem to be critical problem
| | since after this things seemed to work work. I saw this on 9.X.
| | Haven't seen it on 8.2. Not sure about -current.
| |
| | It doesn't happen on all machines.
| |
| | Hmm, are you seeing the KCS thread manage the request but the wakeup()
is
| | lost?
|
| It was a couple of weeks ago that I played with it. I put printf's
| around the msleep and wakeup. I saw the wakeup called but the sleep
| not get it. I can try the test again later today. Right now my main
| work machine is recovering from a power outage. This was with 9.0
| when I first saw it. This issue seems to only happen at boot time.
| If I kldload the module after the system is booted then it seems to work
| okay. The KCS part was working fine and got the data okay from the
| request. I haven't seen or heard any issues with 8.2.
With -current I patched ipmi.c with:
Index: ipmi.c
===
--- ipmi.c (revision 233806)
+++ ipmi.c (working copy)
@@ -523,7 +523,11 @@
* waiter that we awaken.
*/
if (req-ir_owner == NULL)
+{
+device_printf(sc-ipmi_dev, DEBUG %s %d before wakeup
%d\n,__FUNCTION__,__LINE__,ticks);
wakeup(req);
+device_printf(sc-ipmi_dev, DEBUG %s %d after wakeup
%d\n,__FUNCTION__,__LINE__,ticks);
+}
else {
dev = req-ir_owner;
TAILQ_INSERT_TAIL(dev-ipmi_completed_requests, req,
ir_link);
@@ -543,7 +547,11 @@
IPMI_LOCK(sc);
error = sc-ipmi_enqueue_request(sc, req);
if (error == 0)
+{
+device_printf(sc-ipmi_dev, DEBUG %s %d before msleep
%d\n,__FUNCTION__,__LINE__,ticks);
error = msleep(req, sc-ipmi_lock, 0, ipmireq, timo);
+device_printf(sc-ipmi_dev, DEBUG %s %d after msleep
%d\n,__FUNCTION__,__LINE__,ticks);
+}
if (error == 0)
error = req-ir_error;
IPMI_UNLOCK(sc);
@@ -695,8 +703,11 @@
error = ipmi_submit_driver_request(sc, req, MAX_TIMEOUT);
if (error == EWOULDBLOCK) {
device_printf(dev, Timed out waiting for GET_DEVICE_ID\n);
+ printf(DJA\n);
+/*
ipmi_free_request(req);
return;
+*/
} else if (error) {
device_printf(dev, Failed GET_DEVICE_ID: %d\n, error);
ipmi_free_request(req);
and get
# dmesg | grep ipmi
ipmi0: KCS mode found at io 0xca8 on acpi
ipmi1: IPMI System Interface on isa0
device_attach: ipmi1 attach returned 16
ipmi1: IPMI System Interface on isa0
device_attach: ipmi1 attach returned 16
ipmi0: DEBUG ipmi_submit_driver_request 551 before msleep 2
ipmi0: DEBUG ipmi_complete_request 527 before wakeup 6201
ipmi0: DEBUG ipmi_complete_request 529 after wakeup 6263
ipmi0: DEBUG ipmi_submit_driver_request 553 after msleep 6323
Actually, can you compile with:
options KTR
options KTR_COMPILE=KTR_SCHED
options KTR_MASK=KTR_SCHED
and then add a temporary hack to ipmi.c to set ktr_mask to 0 after
ipmi_submit_driver_request() returns in ipmi_startup()? You can
then use 'ktrdump -ct' after boot to capture a log of what the scheduler
did including if it timed
Re: 9-STABLE, ZFS, NFS, ggatec - suspected memory leak
Hi, On Fri, Mar 30, 2012 at 09:02:03PM +, Philip M. Gollucci wrote: http://lists.freebsd.org/pipermail/freebsd-questions/2012-March/239643.html Same issue different thread. Different software. Its not NFS, its ZFS. I don't really have a place to try it on 8.2, but my hunch from things I've done rather similarly which don't cause tell me its a new issue in 9.0, though I won't swear by that. So we're having different issues. I could boil it down to NFS definitely: If I change back to the old NFS server the problem immediately stops. I'm currently checking, where in the new NFS server might be the problem (together with people who have a deeper understanding of what's happening). - Oliver -- | Oliver Brandmueller http://sysadm.in/ o...@sysadm.in | |Ich bin das Internet. Sowahr ich Gott helfe. | pgpHns42tmk9T.pgp Description: PGP signature
Re: r232411 breaks onboard 1068 detection
On Tue, Apr 03, 2012 at 10:29:27 +0200, Marius Strobl wrote: On Tue, Apr 03, 2012 at 05:55:19AM +0400, Andrew Pantyukhin wrote: Hello, r232411 broke onboard 1068 detection on all boxes with SuperMicro X8ST3 motherboards for us. All of them are also equipped with two extra 1068 controllers, which are detected fine. Reverting to r231518 with otherwise latest stable kernel works around the problem. The issue is still there at r233425. Here's the disappearing device: mpt2@pci0:5:0:0:class=0x01 card=0x10001000 chip=0x00591000 rev=0x08 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = 'MegaRAID SAS 8208ELP/8208ELP' class = mass storage subclass = SCSI Should be fixed in r233827. We should get this into 8.3 if that is still possible. Otherwise folks with these machines will not be able to boot 8.3. Ken -- Kenneth Merry k...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: r232411 breaks onboard 1068 detection
On Tue, Apr 03, 2012 at 09:13:14AM -0600, Kenneth D. Merry wrote: On Tue, Apr 03, 2012 at 10:29:27 +0200, Marius Strobl wrote: On Tue, Apr 03, 2012 at 05:55:19AM +0400, Andrew Pantyukhin wrote: Hello, r232411 broke onboard 1068 detection on all boxes with SuperMicro X8ST3 motherboards for us. All of them are also equipped with two extra 1068 controllers, which are detected fine. Reverting to r231518 with otherwise latest stable kernel works around the problem. The issue is still there at r233425. Here's the disappearing device: mpt2@pci0:5:0:0:class=0x01 card=0x10001000 chip=0x00591000 rev=0x08 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = 'MegaRAID SAS 8208ELP/8208ELP' class = mass storage subclass = SCSI Should be fixed in r233827. We should get this into 8.3 if that is still possible. Otherwise folks with these machines will not be able to boot 8.3. I'll try but based on previous experiences it's just too late in the release cycle. Marius ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [stable-ish 9] Dell R815 ipmi(4) attach failure
John Baldwin writes:
| On Monday, April 02, 2012 7:27:13 pm Doug Ambrisko wrote:
| Doug Ambrisko writes:
| | John Baldwin writes:
| | | On Saturday, March 31, 2012 3:25:48 pm Doug Ambrisko wrote:
| | | Sean Bruno writes:
| | | | Noting a failure to attach to the onboard IPMI controller with this
| dell
| | | | R815. Not sure what to start poking at and thought I'd though this
| over
| | | | here for comment.
| | | |
| | | | -bash-4.2$ dmesg |grep ipmi
| | | | ipmi0: KCS mode found at io 0xca8 on acpi
| | | | ipmi1: IPMI System Interface on isa0
| | | | device_attach: ipmi1 attach returned 16
| | | | ipmi1: IPMI System Interface on isa0
| | | | device_attach: ipmi1 attach returned 16
| | | | ipmi0: Timed out waiting for GET_DEVICE_ID
| | |
| | | I've run into this recently. A quick hack to fix it is:
| | |
| | | Index: ipmi.c
| | | ===
| | | RCS file: /cvs/src/sys/dev/ipmi/ipmi.c,v
| | | retrieving revision 1.14
| | | diff -u -p -r1.14 ipmi.c
| | | --- ipmi.c14 Apr 2011 07:14:22 - 1.14
| | | +++ ipmi.c31 Mar 2012 19:18:35 -
| | | @@ -695,7 +695,6 @@ ipmi_startup(void *arg)
| | |if (error == EWOULDBLOCK) {
| | |device_printf(dev, Timed out waiting for
GET_DEVICE_ID\n);
| | |ipmi_free_request(req);
| | | - return;
| | |} else if (error) {
| | |device_printf(dev, Failed GET_DEVICE_ID: %d\n, error);
| | |ipmi_free_request(req);
| | |
| | | The issue is that the wakeup doesn't actually wake up the msleep
| | | in ipmi_submit_driver_request. The error being reported is that
| | | the msleep timed out. This doesn't seem to be critical problem
| | | since after this things seemed to work work. I saw this on 9.X.
| | | Haven't seen it on 8.2. Not sure about -current.
| | |
| | | It doesn't happen on all machines.
| | |
| | | Hmm, are you seeing the KCS thread manage the request but the wakeup()
| is
| | | lost?
| |
| | It was a couple of weeks ago that I played with it. I put printf's
| | around the msleep and wakeup. I saw the wakeup called but the sleep
| | not get it. I can try the test again later today. Right now my main
| | work machine is recovering from a power outage. This was with 9.0
| | when I first saw it. This issue seems to only happen at boot time.
| | If I kldload the module after the system is booted then it seems to work
| | okay. The KCS part was working fine and got the data okay from the
| | request. I haven't seen or heard any issues with 8.2.
|
| With -current I patched ipmi.c with:
| Index: ipmi.c
| ===
| --- ipmi.c (revision 233806)
| +++ ipmi.c (working copy)
| @@ -523,7 +523,11 @@
| * waiter that we awaken.
| */
| if (req-ir_owner == NULL)
| +{
| +device_printf(sc-ipmi_dev, DEBUG %s %d before wakeup
| %d\n,__FUNCTION__,__LINE__,ticks);
| wakeup(req);
| +device_printf(sc-ipmi_dev, DEBUG %s %d after wakeup
| %d\n,__FUNCTION__,__LINE__,ticks);
| +}
| else {
| dev = req-ir_owner;
| TAILQ_INSERT_TAIL(dev-ipmi_completed_requests, req,
| ir_link);
| @@ -543,7 +547,11 @@
| IPMI_LOCK(sc);
| error = sc-ipmi_enqueue_request(sc, req);
| if (error == 0)
| +{
| +device_printf(sc-ipmi_dev, DEBUG %s %d before msleep
| %d\n,__FUNCTION__,__LINE__,ticks);
| error = msleep(req, sc-ipmi_lock, 0, ipmireq, timo);
| +device_printf(sc-ipmi_dev, DEBUG %s %d after msleep
| %d\n,__FUNCTION__,__LINE__,ticks);
| +}
| if (error == 0)
| error = req-ir_error;
| IPMI_UNLOCK(sc);
| @@ -695,8 +703,11 @@
| error = ipmi_submit_driver_request(sc, req, MAX_TIMEOUT);
| if (error == EWOULDBLOCK) {
| device_printf(dev, Timed out waiting for GET_DEVICE_ID\n);
| + printf(DJA\n);
| +/*
| ipmi_free_request(req);
| return;
| +*/
| } else if (error) {
| device_printf(dev, Failed GET_DEVICE_ID: %d\n, error);
| ipmi_free_request(req);
|
| and get
|# dmesg | grep ipmi
|ipmi0: KCS mode found at io 0xca8 on acpi
|ipmi1: IPMI System Interface on isa0
|device_attach: ipmi1 attach returned 16
|ipmi1: IPMI System Interface on isa0
|device_attach: ipmi1 attach returned 16
|ipmi0: DEBUG ipmi_submit_driver_request 551 before msleep 2
|ipmi0: DEBUG ipmi_complete_request 527 before wakeup 6201
|ipmi0: DEBUG ipmi_complete_request 529 after wakeup 6263
|ipmi0: DEBUG ipmi_submit_driver_request 553 after msleep 6323
|
| Actually, can you compile with:
|
| options KTR
| options KTR_COMPILE=KTR_SCHED
| options
RE: r232411 breaks onboard 1068 detection
Marius, Since the 0x59 device is a MegaRAID device, shouldn't you be using the MegaRAID driver. Why is the MPT driver being used in this case? The problem is that the MPT driver was wrongly attaching to some MegaRAID controllers and that was causing conflict problems, so that was fixed by removing MegaRAID ID's from the MPT driver. Steve McConnell -Original Message- From: Desai, Kashyap Sent: Tuesday, April 03, 2012 6:35 AM To: Marius Strobl Cc: sta...@freebsd.org; zvq...@di.vc; k...@freebsd.org; Andrew Pantyukhin; McConnell, Stephen Subject: RE: r232411 breaks onboard 1068 detection -Original Message- From: Marius Strobl [mailto:mar...@alchemy.franken.de] Sent: Tuesday, April 03, 2012 5:59 PM To: Desai, Kashyap Cc: sta...@freebsd.org; zvq...@di.vc; k...@freebsd.org; Andrew Pantyukhin Subject: Re: r232411 breaks onboard 1068 detection On Tue, Apr 03, 2012 at 10:29:27AM +0200, Marius Strobl wrote: On Tue, Apr 03, 2012 at 05:55:19AM +0400, Andrew Pantyukhin wrote: Hello, r232411 broke onboard 1068 detection on all boxes with SuperMicro X8ST3 motherboards for us. All of them are also equipped with two extra 1068 controllers, which are detected fine. Reverting to r231518 with otherwise latest stable kernel works around the problem. The issue is still there at r233425. Here's the disappearing device: mpt2@pci0:5:0:0:class=0x01 card=0x10001000 chip=0x00591000 rev=0x08 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = 'MegaRAID SAS 8208ELP/8208ELP' class = mass storage subclass = SCSI Should be fixed in r233827. Btw., Kashyap, could you please trigger LSI to update their mpi_cnfg.h to include all the device IDs that actually should be handled by MPT drivers. The FreeBSD mpt(4) additionally knows about the devices below, which based on the fact they are not probed by the Linux counterpart and are not found in PCI ID lists might not even exist in the wild, or as in the above case, still might miss some actual devices not currently found in mpi_cnfg.h. #define MPI_MANUFACTPAGE_DEVICEID_FC909_FB 0x0620 #define MPI_MANUFACTPAGE_DEVICEID_FC919_LAN_FB 0x0625 #define MPI_MANUFACTPAGE_DEVICEID_FC929_LAN_FB 0x0623 #define MPI_MANUFACTPAGE_DEVICEID_FC929X_LAN_FB 0x0627 #define MPI_MANUFACTPAGE_DEVICEID_FC919X_LAN_FB 0x0629 #define MPI_MANUFACTPAGE_DEVID_SAS1068A_FB0x0055 #define MPI_MANUFACTPAGE_DEVID_SAS1068E_FB 0x0059 #define MPI_MANUFACTPAGE_DEVID_SAS1078DE_FB 0x007C Hi Marius, This is very critical part of discussion and I do not have really best answer, because I don't know the history behind it. Added Steve M for better help. Also I have contacted Megaraid Driver team to respond what is device id 0x0059 ? FYI: I am referring pciid from below link. http://pciids.sourceforge.net/v2.2/pci.ids Marius ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: r232411 breaks onboard 1068 detection
On Tue, Apr 03, 2012 at 03:52:14PM -0600, McConnell, Stephen wrote: Marius, Since the 0x59 device is a MegaRAID device, shouldn't you be using the MegaRAID driver. Why is the MPT driver being used in this case? The problem is that the MPT driver was wrongly attaching to some MegaRAID controllers and that was causing conflict problems, so that was fixed by removing MegaRAID ID's from the MPT driver. Apparently, the 0x59 devices worked just fine using mpt(4) before r232411. Are MegaRAID devices backwards-compatible so they can alternatively be driven by MPT drivers? Marius ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: r232411 breaks onboard 1068 detection
On Wed, Apr 4, 2012 at 1:57 AM, Marius Strobl mar...@alchemy.franken.de wrote: On Tue, Apr 03, 2012 at 03:52:14PM -0600, McConnell, Stephen wrote: Marius, Since the 0x59 device is a MegaRAID device, shouldn't you be using the MegaRAID driver. Why is the MPT driver being used in this case? The problem is that the MPT driver was wrongly attaching to some MegaRAID controllers and that was causing conflict problems, so that was fixed by removing MegaRAID ID's from the MPT driver. Apparently, the 0x59 devices worked just fine using mpt(4) before r232411. Are MegaRAID devices backwards-compatible so they can alternatively be driven by MPT drivers? The device in question is a built-in 1068-based controller on a SuperMicro X8ST3 board. It can be converted to MegaRAID mode with a special addon button (AOC-IButton68). http://www.supermicro.com/products/motherboard/Xeon3000/X58/X8ST3-F.cfm ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: r232411 breaks onboard 1068 detection
On Wed, Apr 04, 2012 at 02:26:38AM +0400, Andrew Pantyukhin wrote: On Wed, Apr 4, 2012 at 1:57 AM, Marius Strobl mar...@alchemy.franken.de wrote: On Tue, Apr 03, 2012 at 03:52:14PM -0600, McConnell, Stephen wrote: Marius, Since the 0x59 device is a MegaRAID device, shouldn't you be using the MegaRAID driver. ??Why is the MPT driver being used in this case? ??The problem is that the MPT driver was wrongly attaching to some MegaRAID controllers and that was causing conflict problems, so that was fixed by removing MegaRAID ID's from the MPT driver. Apparently, the 0x59 devices worked just fine using mpt(4) before r232411. Are MegaRAID devices backwards-compatible so they can alternatively be driven by MPT drivers? The device in question is a built-in 1068-based controller on a SuperMicro X8ST3 board. It can be converted to MegaRAID mode with a special addon button (AOC-IButton68). http://www.supermicro.com/products/motherboard/Xeon3000/X58/X8ST3-F.cfm Okay, so unless these devices also can be driven by mfi(4) when not in MegaRAID mode, we need a way to tell both modes apart in the probe functions of both drivers. Marius ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: r232411 breaks onboard 1068 detection
On Wed, Apr 4, 2012 at 2:33 AM, Marius Strobl mar...@alchemy.franken.de wrote: On Wed, Apr 04, 2012 at 02:26:38AM +0400, Andrew Pantyukhin wrote: The device in question is a built-in 1068-based controller on a SuperMicro X8ST3 board. It can be converted to MegaRAID mode with a special addon button (AOC-IButton68). http://www.supermicro.com/products/motherboard/Xeon3000/X58/X8ST3-F.cfm Okay, so unless these devices also can be driven by mfi(4) when not in MegaRAID mode, we need a way to tell both modes apart in the probe functions of both drivers. mfi(4) obviously didn't attach, but if anyone is willing to provide a quick patch listing the IDs in mfi(4), I'll try. I wouldn't welcome the change though, as we prefer the JBOD way. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: r232411 breaks onboard 1068 detection
On Wed, Apr 04, 2012 at 02:38:54AM +0400, Andrew Pantyukhin wrote: On Wed, Apr 4, 2012 at 2:33 AM, Marius Strobl mar...@alchemy.franken.de wrote: On Wed, Apr 04, 2012 at 02:26:38AM +0400, Andrew Pantyukhin wrote: The device in question is a built-in 1068-based controller on a SuperMicro X8ST3 board. It can be converted to MegaRAID mode with a special addon button (AOC-IButton68). http://www.supermicro.com/products/motherboard/Xeon3000/X58/X8ST3-F.cfm Okay, so unless these devices also can be driven by mfi(4) when not in MegaRAID mode, we need a way to tell both modes apart in the probe functions of both drivers. mfi(4) obviously didn't attach, but if anyone is willing to provide a quick patch listing the IDs in mfi(4), I'll try. I wouldn't welcome the change though, as we prefer the JBOD way. I still highly doubt that 0x59 will work with mfi(4) in non-MegaRAID mode. Looking at the source of the Linux megasr driver, that one attaches to several 0x59 devices but only in case of certain sub-vendor (amongst other Supermicro) and sub-device IDs, but not in case of a sub-vendor ID of LSI and a sub-device ID of 0x1000 like in your case. So this seems like a way to go to distinguish the modes if LSI can provide a complete list of sub-device IDs (and sub-vendor in case something besides LSI is used) in which case 0x59 should be treated in MPT mode. Marius ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
