Aleks, What you are using are undocumented interfaces to issue commands to the driver. We do not provide support for these. But you could easily reverse-engineer the driver code to see what you are doing wrong :-) This driver version expects the data transfer address to be available in the FW packet transfer address field, which you are not providing. That mean the HBA is doing DMA to a junk address causing the bizzare behaviors observed by you. Thanks -Atul Mukker -----Original Message----- From: Aleks Sheynkman [mailto:aleks@xxxxxxxxx] Sent: Friday, September 03, 2004 1:06 PM To: linux-raid@xxxxxxxxxxxxxxx; linux-scsi@xxxxxxxxxxxxxxx Subject: megaraid megaraid2-2.10.7 causing kernel panic Greetings, I'm really sorry to bother you ,and I hope this is a correct list to post these kind of messages. I did post a similar message a day ago. We are currently experiencing problem with a new version of megaraid driver (megaraid2-2.10.7). All our severs in the past were running RH 7.3 and now we started migration process AS 2.1 specifically to update 2.4.9-e.49smp and dkms megaraid version 2.10.7. After upgrade, all our systems were stable until we started to run our hardware monitoring software. What it does, it polls the status of all physical and logical driver through ioctl call. Please see sample code below that would cause a kernel panic. The code was working just fine until version 1.8f version of megaraid drivers, with introduction of new driver it started to fail and cause kernel panics, which kind of inconstant, sometimes it kills kernel swapper sometimes wait queues. It seems like ioctl "M_RD_IOCTL_CMD " is totally broken, we can retrieve correct number of adapters! by issuing ioctl suboption MEGAIOC_QNADAP. Did any one ever seen this before, can you please advice ? Thank you ! Code that will panic the kernel, run it few times: #include "megaraid.h" int main() { int fd; struct uioctl_t uioctl; if ( (fd = open("/dev/megadev0", O_RDWR)) < 0 && (fd = open("/dev/megadev", O_RDWR)) < 0) return -1; uioctl.inlen = 1024; uioctl.outlen = 1024; if(!(uioctl.data = malloc(1024))){ return 0; } memset(uioctl.data, 0, 1024); uioctl.ui.fcs.opcode = M_RD_IOCTL_CMD; uioctl.ui.fcs.subopcode = 0; uioctl.ui.fcs.adapno = MKADAP(0); uioctl.mbox[0] = FC_NEW_CONFIG; uioctl.mbox[2] = NC_SUBOP_ENQUIRY3; uioctl.mbox[3] = ENQ3_GET_SOLICITED_FULL; if(ioctl(fd, MEGAIOCCMD, &uioctl) == -1){ fprintf(stderr,"Error %d \n\n", uioctl.ui.fcs.adapno); fflush(stderr); free(uioctl.data); close(fd); return 0; } close(fd); return 0; } Panic: 1) ug 31 20:54:03 Analyzer kernel: EIP is at iput_free [kernel] 0x1e Aug 31 20:54:03 Analyzer kernel: eax: 2e0001e3 ebx: f6880e40 ecx: f6880e50 edx: f6880e50 Aug 31 20:54:03 Analyzer kernel: esi: f6880e40 edi: 00000000 ebp: 0008e000 esp: f7383f60 Aug 31 20:54:03 Analyzer kernel: ds: 0018 es: 0018 ss: 0018 Aug 31 20:54:03 Analyzer kernel: Process kswapd (pid: 10, stackpage=f7383000) Aug 31 20:54:03 Analyzer kernel: Stack: f587cb40 f5753b60 c015a45c f587cb40 f393c3e0 f6880e40 00000006 c015a41b Aug 31 20:54:03 Analyzer kernel: f6880e40 f393c3f8 f393c3e0 c015a806 f393c3e0 c02fa190 00000286 00000286 Aug 31 20:54:03 Analyzer kernel: 00000000 f7382000 00000000 00000000 00000000 00000000 00000000 00000000 Aug 31 20:54:03 Analyzer kernel: Call Trace: [dput+28/304] dput [kernel] 0x1c (0xf7383f68) Aug 31 20:54:03 Analyzer kernel: Call Trace: [<c015a45c>] dput [kernel] 0x1c (0xf7383f68) Aug 31 20:54:03 Analyzer kernel: [dentry_iput+75/112] dentry_iput [kernel] 0x4b (0xf7383f7c) Aug 31 20:54:03 Analyzer kernel: [<c015a41b>] dentry_iput [kernel] 0x4b (0xf7383f7c) Aug 31 20:54:03 Analyzer kernel: [prune_dcache+182/336] prune_dcache [kernel] 0xb6 (0xf7383f8c) 2)p 1 18:41:36 Analyzer kernel: Oops: 0000 Sep 1 18:41:36 Analyzer kernel: Kernel 2.4.9-e.49smp Sep 1 18:41:36 Analyzer kernel: CPU: 1 Sep 1 18:41:36 Analyzer kernel: EIP: 0010:[__wake_up+51/144] Tainted: P Sep 1 18:41:36 Analyzer kernel: EIP: 0010:[<c01198a3>] Tainted: P Sep 1 18:41:36 Analyzer kernel: EFLAGS: 00010046 Sep 1 18:41:36 Analyzer kernel: EIP is at __wake_up [kernel] 0x33 Sep 1 18:41:36 Analyzer kernel: eax: f688800c ebx: f6888014 ecx: 00000001 edx: 00000000 Sep 1 18:41:36 Analyzer kernel: esi: 00000001 edi: f4c8a880 ebp: f4f25a94 esp: f4f25a7c Sep 1 18:41:36 Analyzer kernel: ds: 0018 es: 0018 ss: 0018 Sep 1 18:41:36 Analyzer kernel: Process snmpd (pid: 626, stackpage=f4f25000) Sep 1 18:41:36 Analyzer kernel: Stack: 00000000 00000282 00000001 f4c8a880 f4c7f040 00000000 f4ec28c0 c01daad9 Sep 1 18:41:36 Analyzer kernel: 00000002 00000026 f4c7f178 00001060 00007fff f4c7f178 c01ff422 f4c7f040 Sep 1 18:41:36 Analyzer kernel: 00000000 c01fe2f4 f4c7f040 f4c7f178 ffffffff f4a8f0c0 3a6ade00 00000000 Sep 1 18:41:36 Analyzer kernel: Call Trace: [sock_def_readable+57/112] sock_def_readable [kernel] 0x39 (0xf4f25a98) Sep 1 18:41:36 Analyzer kernel: Call Trace: [<c01daad9>] sock_def_readable [kernel] 0x39 (0xf4f25a98) Sep 1 18:41:36 Analyzer kernel: [tcp_data_queue+898/2688] tcp_data_queue [kernel] 0x382 (0xf4f25ab4) Sep 1 18:41:36 Analyzer kernel: [<c01ff422>] tcp_data_queue [kernel] 0x382 (0xf4f25ab4) Sep 1 18:41:36 Analyzer kernel: [tcp_ack+180/784] tcp_ack [kernel] 0xb4 (0xf4f25ac0) Sep 1 18:41:36 Analyzer kernel: [<c01fe2f4>] tcp_ack [kernel] 0xb4 (0xf4f25ac0) - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
