NULL pointer deref in iscsi_sw_tcp_host_get_param

] __ticket_spin_lock+0x9/0x30 [ 29.859101] RSP 880114ca7d98 [ 29.859101] CR2: 00d0 [ 29.926003] ---[ end trace 3db857a832dd3e91 ]--- Kernel is mainline 3.8.13. Can anybody please advise if this is some known issue and/or how to investigate this further? Thanks, Alex. -- You received

hdparm -I gives random output on open-iscsi connected CDROM device

-mmc and prevents MMC/AACS playback via bluray since the kernel detects CDROM capabilities in a similar way. Is this a problem in open-iscsi (initiator), the target drivers (scst-iscsi / tgt) or something connected (e.g. incomplete emulation of MMC command set)? How can I fix this? Best, Alex

Removing individual LUNs

I have a Linux machine running as a target with LVM-backed devices and the setup is working fine. However, when I change the size of one of the underlying devices, the initiators (running open-iscsi 2.0-865) don't pick up the change. I know that if I logout the entire session and then log in

Re: Removing individual LUNs

On Jun 16, 4:29 pm, Mike Christie [EMAIL PROTECTED] wrote: Do: iscsiadm -m session -r $SID --rescan Doing a rescan doesn't appear to pick up the new size of the devices. Having manually resized the filesystem on the target end, I now get errors on the initiator since the filesystem extents

Re: Removing individual LUNs

On Jun 17, 7:00 am, Konrad Rzeszutek [EMAIL PROTECTED] wrote: You can delete the old block devices that have changed and do a SCSI rescan: You have to delete the old devices (well, this script deletes _ALL_ so that might not be that good): for disk in `find

Re: Removing individual LUNs

On Jun 23, 1:27 pm, Mike Christie [EMAIL PROTECTED] wrote: --snip-- However, there is issue outstanding I think. I think you then need a new a newer kernel (like 2.6.26 or something) so that the block layer can see the changes and pick up the scsi layer changes. Also see my comment on FSs

[PATCH] support multidisk iBFTs

Please could the attached patch be considered for inclusion in the open-iscsi source. Regards, Alex Zeffertt Changelog: - iSCSI Boot Firmware Tables are able to specify up to two iSCSI targets, but until now open-iscsi has only been able to display/attach one of these. This change

Re: [PATCH] support NIC configuration in iBFT

All, Please ignore the patch in my previous email and use the one attached instead. I fixed a bug in the previous patch where iscsistart -n was assuming that the interface being configured was already up. Regards, Alex Alex Zeffertt wrote: Please could the attached patch be considered

Re: [PATCH] support multidisk iBFTs

Mike Christie wrote: Alex Zeffertt wrote: Please could the attached patch be considered for inclusion in the open-iscsi source. Regards, Alex Zeffertt Changelog: - iSCSI Boot Firmware Tables are able to specify up to two iSCSI targets, but until now open-iscsi has only

Re: [PATCH] support multidisk iBFTs

Mike Christie wrote: Alex Zeffertt wrote: Mike Christie wrote: Alex Zeffertt wrote: Please could the attached patch be considered for inclusion in the open-iscsi source. Regards, Alex Zeffertt Changelog: - iSCSI Boot Firmware Tables are able to specify up to two iSCSI

Re: [PATCH] support multidisk iBFTs

configuration in iBFT). Thanks for your help. Alex -- 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

Re: [PATCH] support NIC configuration in iBFT

+* using IP addresses and routing info from iBFT. +*/ .. to some helper function, so it is not so crowed and a little easier to read? No problem. Please find a new patch attached. Regards, Alex -- You received this message because you are subscribed to the Google

Re: [PATCH] support NIC configuration in iBFT

Hannes Reinecke wrote: Mike Christie wrote: On 01/07/2010 08:16 AM, Alex Zeffertt wrote: Mike Christie wrote: Thanks for doing this. Sorry for the late reply. Just one comment on the patch. Could you move the code in the 'n' case + case 'n': + /* + * Bring up NICs required by targets

Re: Halt on diskless node

MUST bring up the interface and configure it to access the root disk, and ANY change to its configuration after the root filesystem is mounted could make your system hang. Regards, Alex Thanks a lot. -- Antoine Castaing -- You received this message because you are subscribed

Re: Failover time of iSCSI multipath devices.

, The bugzilla ticket requests a merge of two git commits, but neither of those contain the libiscsi.c change that addresses bug #2. Was this a mistake, or did you deliberately omit that part of your speed-up-conn-fail-take3.patch when you raised the ticket? TIA, Alex -- You received this message

Re: Failover time of iSCSI multipath devices.

Mike Christie wrote: On 03/15/2010 05:56 AM, Alex Zeffertt wrote: The bugzilla ticket requests a merge of two git commits, but neither of those contain the libiscsi.c change that addresses bug #2. Was this a mistake, or did you deliberately omit that part of your speed-up-conn-fail-take3.patch

Re: Using failover with differing EUI / IQN values

be able to failover between them. The path failovers are handled by the kernel part of the device-mapper-multipath package, and path recovery is handled by multipathd. Regards, Alex Claude Bing wrote: Hello, I am wondering if it is possible to failover an iSCSI path from one EUI / IQN to one

Re: Using failover with differing EUI / IQN values

them to be paths to the same device and add them to the same map. (See /etc/multipath.conf for the exact /sbin/scsi_id usage.) Regards, Alex Claude Bing wrote: Does this still apply if I'm using two separate iSCSI target devices sharing the same data source (RAID)? On Mar 19, 2010 1:24 PM

NULL pointer deref in iscsi_sw_tcp_host_get_param

[ 29.859101] RSP 880114ca7d98 [ 29.859101] CR2: 00d0 [ 29.926003] ---[ end trace 3db857a832dd3e91 ]--- Kernel is mainline 3.8.13. Can anybody please advise if this is some known issue and/or how to investigate this further? Thanks, Alex. -- You received this message because you

Re: NULL pointer deref in iscsi_sw_tcp_host_get_param

Hello Alex, Dmitry, this looks like a real kernel issue in an non-ancient kernel. Has my bug report been noticed? Thanks, Alex. -Original Message- From: Alex Lyakas Sent: 23 June, 2013 11:06 AM To: open-iscsi@googlegroups.com Subject: NULL pointer deref

Re: NULL pointer deref in iscsi_sw_tcp_host_get_param

a different iSCSI target. Thanks, Alex. -Original Message- From: Mike Christie Sent: 02 July, 2013 8:23 PM To: open-iscsi@googlegroups.com Cc: Alex Lyakas ; Lev Vainblat ; Yair Hershko Subject: Re: NULL pointer deref in iscsi_sw_tcp_host_get_param Hey, Is it easy for you to replicate

Re: NULL pointer deref in iscsi_sw_tcp_host_get_param

Hi Mike, any advice on how to proceed further with this issue? Thanks, Alex. -Original Message- From: Alex Lyakas Sent: 02 July, 2013 9:41 PM To: Mike Christie ; open-iscsi@googlegroups.com Cc: Lev Vainblat ; Yair Hershko Subject: Re: NULL pointer deref in iscsi_sw_tcp_host_get_param

Re: NULL pointer deref in iscsi_sw_tcp_host_get_param

Thank you, Mike. We are running kernel 3.8.13, and now we can repro this pretty reliably. Alex. -Original Message- From: Mike Christie Sent: 29 July, 2013 9:29 PM To: Alex Lyakas Cc: open-iscsi@googlegroups.com ; Lev Vainblat ; Yair Hershko ; Liran Strugano Subject: Re: NULL

Multiple Targets Via Kernel Options

I'm using Ubuntu's MAAS system which boots nodes via PXE and feeds the kernel iSCSI options to boot the actual OS image. The MAAS server feeds kernel options such as... iscsi_target_name=iqn.2004-05.com.ubuntu:maas:ephemeral-amd64-generic-trusty-release iscsi_target_ip=10.0.0.49