1.18f reads the user address from the data field, but the new interface packet has one data transfer field. So your best bet is to provide addresses in both fields. Thanks -Atul > -----Original Message----- > From: Aleks Sheynkman [mailto:aleks@xxxxxxxxx] > Sent: Friday, September 03, 2004 3:25 PM > To: Mukker, Atul; linux-raid@xxxxxxxxxxxxxxx; > linux-scsi@xxxxxxxxxxxxxxx > Subject: RE: megaraid megaraid2-2.10.7 causing kernel panic > > > Isn't the same as was before in version megraid1.8f ? > > Thanks ! > > Aleks > > > -----Original Message----- > > From: Mukker, Atul [mailto:Atulm@xxxxxxxx] > > Sent: Friday, September 03, 2004 12:20 PM > > To: Aleks Sheynkman; linux-raid@xxxxxxxxxxxxxxx; > > linux-scsi@xxxxxxxxxxxxxxx > > Subject: RE: megaraid megaraid2-2.10.7 causing kernel panic > > > > > > 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
