tws(4) kernel panic on boot
On migrating one of my servers to -current, I discovered that the tws driver panics on boot; I will follow up with a full backtrace once I have a chance to extract it. In the meantime, there is a PR about a very similar error in twa - 177020. Is it possible those are related, and the same sort of change needs to be made to tws? ~Andreas Turriff ___ 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"
Re: tws(4) kernel panic on boot
On 5/21/2013 5:33 AM, Konstantin Belousov wrote: On Mon, May 20, 2013 at 07:09:41PM -0700, Andreas Turriff wrote: On migrating one of my servers to -current, I discovered that the tws driver panics on boot; I will follow up with a full backtrace once I have a chance to extract it. In the meantime, there is a PR about a very similar error in twa - 177020. Is it possible those are related, and the same sort of change needs to be made to tws? It is possible that the regression was in r246713, but the code is structured differently, and there were more tws(4) changes since then. You need to provide data for somebody to start looking into the problem. I know. That's why I said, I'd follow up with more info once I can extract it. The system in question is a Dell PowerEdge 840 server, 8 GiByte RAM, with an Intel NIC driven by em(4) and a 3Ware 9750-4i RAID controller. There is no src.conf /etc/make.conf: CPUTYPE?=core2 Error message: LSI 3ware device driver for SAS/SATA storage controllers, version: 10.80.00.005 tws0: port 0xec00-0xecff mem 0xfe9fc000-0xfe9f,0xfe98-0xfe9b irq 16 at device 0.0 o1 tws0: Using MSIng APIC ID to 4 panic: _bus_dmamap_load_ccb: Unsupported func code 0 cpuid = 0Version 2.0> irqs 0-23 on motherboard KDB: enter: panic2.0> irqs 32-55 on motherboard [ thread pid 0 tid 10 ] Stopped at kdb_enter+0x3e: movq$0,kdb_why Backtrace Tracing pid 0 tid 10 td 0x81376610 kdb_enter() at kdb_enter+0x3e/frame 0x8191a340 panic() at panic+0x175/frame 0x8191a3c0 _bus_dmamap_load_ccb() at _bus_dmamap_load_ccb+0x1c3/frame 0x8191a420 bus_dmamap_load_ccb() at bus_dmamap_load_ccb+0x91/frame 0x8191a480 tws_map_request() at tws_map_request+0x71/frame 0x8191a4c0 tws_get_param() at tws_get_param+0xdd/frame 0x8191a520 tws_display_ctlr_info() at tws_display_ctlr_info+0x38/frame 0x8191a590 tws_init_ctlr() at tws_init_ctlr+0x6b/frame 0x8191a5b0 tws_attach() at tws_attach+0xd79/frame 0x8191a670 device_attach() at device_attach+0x396/frame 0x8191a6c0 bus_generic_attach() at bus_generic_attach+0x2d/frame 0x8191a6e0 acpi_pci_attach() at acpi_pci_attach+0x15f/frame 0x8191a730 device_attach() at device_attach+0x396/frame 0x8191a780 bus_generic_attach() at bus_generic_attach+0x2d/frame 0x8191a7a0 acpi_pcib_attach() at acpi_pcib_attach+0x24d/frame 0x8191a7f0 acpi_pcib_pci_attach() at acpi_pcib_pci_attach+0x9f/frame 0x8191a830 device_attach() at device_attach+0x396/frame 0x8191a880 bus_generic_attach() at bus_generic_attach+0x2d/frame 0x8191a8a0 acpi_pci_attach() at acpi_pci_attach+0x15f/frame 0x8191a8f0 device_attach() at device_attach+0x396/frame 0x8191a940 bus_generic_attach() at bus_generic_attach+0x2d/frame 0x8191a960 acpi_pcib_attach() at acpi_pcib_attach+0x24d/frame 0x8191a9b0 acpi_pcib_acpi_attach() at acpi_pcib_acpi_attach+0x299/frame 0x8191aa00 device_attach() at device_attach+0x396/frame 0x8191aa50 bus_generic_attach() at bus_generic_attach+0x2d/frame 0x8191aa70 acpi_attach() at acpi_attach+0xdd6/frame 0x8191ab30 device_attach() at device_attach+0x396/frame 0x8191ab80 bus_generic_attach() at bus_generic_attach+0x2d/frame 0x8191aba0 nexus_acpi_attach() at nexus_acpi_attach+0x76/frame 0x8191abd0 device_attach() at device_attach+0x396/frame 0x8191ac20 bus_generic_new_pass() at bus_generic_new_pass+0xe9/frame 0x8191ac50 bus_set_pass() at bus_set_pass+0x8f/frame 0x8191ac80 configure() at configure+0xa/frame 0x8191ac90 mi_startup() at mi_startup+0x118/frame 0x8191acb0 btext() at btext+0x2c ___ 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"
Re: tws(4) kernel panic on boot
On 5/21/2013 9:25 AM, Andreas Turriff wrote:
On 5/21/2013 5:33 AM, Konstantin Belousov wrote:
On Mon, May 20, 2013 at 07:09:41PM -0700, Andreas Turriff wrote:
On migrating one of my servers to -current, I discovered that the tws
driver panics on boot; I will follow up with a full backtrace once I
have a chance to extract it. In the meantime, there is a PR about a
very
similar error in twa - 177020. Is it possible those are related, and
the
same sort of change needs to be made to tws?
It is possible that the regression was in r246713, but the code is
structured differently, and there were more tws(4) changes since then.
You need to provide data for somebody to start looking into the problem.
I know. That's why I said, I'd follow up with more info once I can
extract it.
The system in question is a Dell PowerEdge 840 server, 8 GiByte RAM,
with an Intel NIC driven by em(4) and a 3Ware 9750-4i RAID controller.
There is no src.conf
/etc/make.conf:
CPUTYPE?=core2
Error message:
LSI 3ware device driver for SAS/SATA storage controllers, version:
10.80.00.005
tws0: port 0xec00-0xecff mem
0xfe9fc000-0xfe9f,0xfe98-0xfe9b irq 16 at device 0.0 o1
tws0: Using MSIng APIC ID to 4
panic: _bus_dmamap_load_ccb: Unsupported func code 0
cpuid = 0Version 2.0> irqs 0-23 on motherboard
KDB: enter: panic2.0> irqs 32-55 on motherboard
[ thread pid 0 tid 10 ]
Stopped at kdb_enter+0x3e: movq$0,kdb_why
Backtrace
Tracing pid 0 tid 10 td 0x81376610
kdb_enter() at kdb_enter+0x3e/frame 0x8191a340
panic() at panic+0x175/frame 0x8191a3c0
_bus_dmamap_load_ccb() at _bus_dmamap_load_ccb+0x1c3/frame
0x8191a420
bus_dmamap_load_ccb() at bus_dmamap_load_ccb+0x91/frame
0x8191a480
tws_map_request() at tws_map_request+0x71/frame 0x8191a4c0
tws_get_param() at tws_get_param+0xdd/frame 0x8191a520
tws_display_ctlr_info() at tws_display_ctlr_info+0x38/frame
0x8191a590
tws_init_ctlr() at tws_init_ctlr+0x6b/frame 0x8191a5b0
tws_attach() at tws_attach+0xd79/frame 0x8191a670
device_attach() at device_attach+0x396/frame 0x8191a6c0
bus_generic_attach() at bus_generic_attach+0x2d/frame 0x8191a6e0
acpi_pci_attach() at acpi_pci_attach+0x15f/frame 0x8191a730
device_attach() at device_attach+0x396/frame 0x8191a780
bus_generic_attach() at bus_generic_attach+0x2d/frame 0x8191a7a0
acpi_pcib_attach() at acpi_pcib_attach+0x24d/frame 0x8191a7f0
acpi_pcib_pci_attach() at acpi_pcib_pci_attach+0x9f/frame
0x8191a830
device_attach() at device_attach+0x396/frame 0x8191a880
bus_generic_attach() at bus_generic_attach+0x2d/frame 0x8191a8a0
acpi_pci_attach() at acpi_pci_attach+0x15f/frame 0x8191a8f0
device_attach() at device_attach+0x396/frame 0x8191a940
bus_generic_attach() at bus_generic_attach+0x2d/frame 0x8191a960
acpi_pcib_attach() at acpi_pcib_attach+0x24d/frame 0x8191a9b0
acpi_pcib_acpi_attach() at acpi_pcib_acpi_attach+0x299/frame
0x8191aa00
device_attach() at device_attach+0x396/frame 0x8191aa50
bus_generic_attach() at bus_generic_attach+0x2d/frame 0x8191aa70
acpi_attach() at acpi_attach+0xdd6/frame 0x8191ab30
device_attach() at device_attach+0x396/frame 0x8191ab80
bus_generic_attach() at bus_generic_attach+0x2d/frame 0x8191aba0
nexus_acpi_attach() at nexus_acpi_attach+0x76/frame 0x8191abd0
device_attach() at device_attach+0x396/frame 0x8191ac20
bus_generic_new_pass() at bus_generic_new_pass+0xe9/frame
0x8191ac50
bus_set_pass() at bus_set_pass+0x8f/frame 0x8191ac80
configure() at configure+0xa/frame 0x8191ac90
mi_startup() at mi_startup+0x118/frame 0x8191acb0
btext() at btext+0x2c
___
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"
And after taking a very close look at the source code for tws, I spotted
the problem. Patch included.
~Andreas
Index: sys/dev/tws/tws.h
===
--- sys/dev/tws/tws.h (revision 250856)
+++ sys/dev/tws/tws.h (working copy)
@@ -137,7 +137,7 @@
TWS_DIR_IN = 0x2,
TWS_DIR_OUT = 0x4,
TWS_DIR_NONE = 0x8,
-TWS_DATA_CCB = 0x16,
+TWS_DATA_CCB = 0x10,
};
enum tws_intrs {
___
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"
Re: tws(4) kernel panic on boot
On 5/22/2013 11:23 PM, Konstantin Belousov wrote:
On Wed, May 22, 2013 at 11:08:50AM -0700, Andreas Turriff wrote:
On 5/21/2013 9:25 AM, Andreas Turriff wrote:
On 5/21/2013 5:33 AM, Konstantin Belousov wrote:
On Mon, May 20, 2013 at 07:09:41PM -0700, Andreas Turriff wrote:
On migrating one of my servers to -current, I discovered that the tws
driver panics on boot; I will follow up with a full backtrace once I
have a chance to extract it. In the meantime, there is a PR about a
very
similar error in twa - 177020. Is it possible those are related, and
the
same sort of change needs to be made to tws?
It is possible that the regression was in r246713, but the code is
structured differently, and there were more tws(4) changes since then.
You need to provide data for somebody to start looking into the problem.
I know. That's why I said, I'd follow up with more info once I can
extract it.
The system in question is a Dell PowerEdge 840 server, 8 GiByte RAM,
with an Intel NIC driven by em(4) and a 3Ware 9750-4i RAID controller.
There is no src.conf
/etc/make.conf:
CPUTYPE?=core2
Error message:
LSI 3ware device driver for SAS/SATA storage controllers, version:
10.80.00.005
tws0: port 0xec00-0xecff mem
0xfe9fc000-0xfe9f,0xfe98-0xfe9b irq 16 at device 0.0 o1
tws0: Using MSIng APIC ID to 4
panic: _bus_dmamap_load_ccb: Unsupported func code 0
cpuid = 0Version 2.0> irqs 0-23 on motherboard
KDB: enter: panic2.0> irqs 32-55 on motherboard
[ thread pid 0 tid 10 ]
Stopped at kdb_enter+0x3e: movq$0,kdb_why
Backtrace
Tracing pid 0 tid 10 td 0x81376610
kdb_enter() at kdb_enter+0x3e/frame 0x8191a340
panic() at panic+0x175/frame 0x8191a3c0
_bus_dmamap_load_ccb() at _bus_dmamap_load_ccb+0x1c3/frame
0x8191a420
bus_dmamap_load_ccb() at bus_dmamap_load_ccb+0x91/frame
0x8191a480
tws_map_request() at tws_map_request+0x71/frame 0x8191a4c0
tws_get_param() at tws_get_param+0xdd/frame 0x8191a520
tws_display_ctlr_info() at tws_display_ctlr_info+0x38/frame
0x8191a590
tws_init_ctlr() at tws_init_ctlr+0x6b/frame 0x8191a5b0
tws_attach() at tws_attach+0xd79/frame 0x8191a670
device_attach() at device_attach+0x396/frame 0x8191a6c0
bus_generic_attach() at bus_generic_attach+0x2d/frame 0x8191a6e0
acpi_pci_attach() at acpi_pci_attach+0x15f/frame 0x8191a730
device_attach() at device_attach+0x396/frame 0x8191a780
bus_generic_attach() at bus_generic_attach+0x2d/frame 0x8191a7a0
acpi_pcib_attach() at acpi_pcib_attach+0x24d/frame 0x8191a7f0
acpi_pcib_pci_attach() at acpi_pcib_pci_attach+0x9f/frame
0x8191a830
device_attach() at device_attach+0x396/frame 0x8191a880
bus_generic_attach() at bus_generic_attach+0x2d/frame 0x8191a8a0
acpi_pci_attach() at acpi_pci_attach+0x15f/frame 0x8191a8f0
device_attach() at device_attach+0x396/frame 0x8191a940
bus_generic_attach() at bus_generic_attach+0x2d/frame 0x8191a960
acpi_pcib_attach() at acpi_pcib_attach+0x24d/frame 0x8191a9b0
acpi_pcib_acpi_attach() at acpi_pcib_acpi_attach+0x299/frame
0x8191aa00
device_attach() at device_attach+0x396/frame 0x8191aa50
bus_generic_attach() at bus_generic_attach+0x2d/frame 0x8191aa70
acpi_attach() at acpi_attach+0xdd6/frame 0x8191ab30
device_attach() at device_attach+0x396/frame 0x8191ab80
bus_generic_attach() at bus_generic_attach+0x2d/frame 0x8191aba0
nexus_acpi_attach() at nexus_acpi_attach+0x76/frame 0x8191abd0
device_attach() at device_attach+0x396/frame 0x8191ac20
bus_generic_new_pass() at bus_generic_new_pass+0xe9/frame
0x8191ac50
bus_set_pass() at bus_set_pass+0x8f/frame 0x8191ac80
configure() at configure+0xa/frame 0x8191ac90
mi_startup() at mi_startup+0x118/frame 0x8191acb0
btext() at btext+0x2c
___
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"
And after taking a very close look at the source code for tws, I spotted
the problem. Patch included.
~Andreas
Index: sys/dev/tws/tws.h
===
--- sys/dev/tws/tws.h (revision 250856)
+++ sys/dev/tws/tws.h (working copy)
@@ -137,7 +137,7 @@
TWS_DIR_IN = 0x2,
TWS_DIR_OUT = 0x4,
TWS_DIR_NONE = 0x8,
-TWS_DATA_CCB = 0x16,
+TWS_DATA_CCB = 0x10,
};
enum tws_intrs {
Do you mean that this change alone fixes your panic and the controller
works after the boot ?
I started looking at the code, and thought that there some issues
with DATA_CCB flag set too eagerly.
I've been running that kernel all day, rebuilding userland (ports) on a
4-drive ZFS RAID-Z on that controller, and not seen a single crash,
slowdown,
