I'm working with a customer who's getting the famous "scheduling while atomic" noise in the logs when using his tape library connected via iSCSI. The task is always an iscsi_q_31 and they're getting a lot of those BUG messages.
I have the backtrace but it's almost useless - the code path is unbelievable: the only reliable bit is [<f8acca0e>] iscsi_tcp_segment_done+0x1c7/0x2a7 [libiscsi_tcp] [<c05b7f45>] kernel_sendmsg+0x27/0x35 [<f8ad33e8>] iscsi_sw_tcp_pdu_xmit+0x9e/0x1e8 [iscsi_tcp] [<f8acc246>] iscsi_tcp_task_xmit+0x25/0x204 [libiscsi_tcp] [<f8d9b622>] iscsi_xmit_task+0x24/0x4b [libiscsi2] [<f8d9c190>] iscsi_xmitworker+0x122/0x202 [libiscsi2] He's running RHEL 5.5 i686 kernel - sorry, I cannot tell the version of open-iscsi bits in this kernel. After some digging into the code I'm starting to wonder if kmap_atomic is the right thing to do when dealing with tcp: tcp_sendmsg() can legitemately sleep on full socket buffer or when trying to allocate an skb which sort of violates the assumption that kmap_atomic is uses for "tight code paths". max PS. Should www.open-iscsi.org display Apache test page? -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
