* iSCSI problems
@ 2005-10-31 11:12 Edwards, Nigel (Nigel Edwards)
2005-10-31 13:52 ` Alvin Starr
2005-10-31 14:57 ` Brian Wolfe
0 siblings, 2 replies; 3+ messages in thread
From: Edwards, Nigel (Nigel Edwards) @ 2005-10-31 11:12 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1: Type: text/plain, Size: 4335 bytes --]
Hi,
I am having problems getting iSCSI working with xen. I can access
iSCSI drives fine from Xen0 (e.g. untar a 500MB archive and I don't
see problems reported through dmesg or /proc/kmsg). However, if I try
to project them into an instance of XenU as a scsi device to boot the
unprivileged domain I get an oops in Xen0 - often resulting in the
whole machine crashing. This occurs in the very early stages of boot
of xenU.
I am using linux-iscsi-4.0.2 for iscsi_sfnet.ko
scsi_transport_iscsi.ko is being built in linux-2.6.12-xen0
I downloaded xen-unstable-src.tgz October 25th.
I notice that there appear to be some significant differences between
scsi_transport_iscsi.c in linux-iscsi-4.0.2 and the version in
linux-2.6.12 kernel.
Example oops below. I have also attached the domain config file. I am
not sure what to do next to get this working. Any suggestions would
be appreciated. If you have iSCSI working, if you could drop me a note
indicating what code and modules you are using I would be very grateful.
Cheers,
Nigel.
<1>Unable to handle kernel paging request at virtual address f3d55000
<1> printing eip:
<4>c0147bec
<1>*pde = ma 030cb067 pa 000cb067
<1>*pte = ma 00000000 pa 55555000
<1>Oops: 0002 [#1]
<4>PREEMPT
<4>Modules linked in: crc32c md5 iscsi_sfnet scsi_transport_iscsi
sworks_agp agpgart
<4>CPU: 0
<4>EIP: 0061:[<c0147bec>] Not tainted VLI
<4>EFLAGS: 00010292 (2.6.12.6-xen0)
<4>EIP is at buffered_rmqueue+0x19c/0x340
<4>eax: 00000000 ebx: 00000001 ecx: 00000400 edx: f3d55000
<4>esi: c167aaa0 edi: f3d55000 ebp: 00000000 esp: ecb41dd4
<4>ds: 007b es: 007b ss: 0069
<4>Process ifup (pid: 30665, threadinfo=ecb40000 task=f2180040)
<4>Stack: c167aaa0 00000003 00000000 eeda60c0 c0147660 c167aaa0 c050c5c0
00000000
<4> 00000000 000084d0 c0147f2f c050c5c0 00000000 00000010 00000000
00000000
<4> 00000000 00000000 00000000 f2180040 00000010 c050c92c 00000000
c011cbd3
<4>Call Trace:
<4> [<c0147660>] prep_new_page+0x50/0x60
<4> [<c0147f2f>] __alloc_pages+0xcf/0x430
<4> [<c011cbd3>] mm_init+0xa3/0xe0
<4> [<c0116c71>] pte_alloc_one+0x11/0x30
<4> [<c0153ab2>] pte_alloc_map+0x42/0x200
<4> [<c0153d9f>] copy_pte_range+0x2f/0x330
<4> [<c0154137>] copy_page_range+0x97/0xd0
<4> [<c011d0e5>] copy_mm+0x285/0x3d0
<4> [<c05aece0>] BusLogic_ProbeHostAdapter+0xe0/0x170
<4> [<c011db77>] copy_process+0x407/0xe10
<4> [<c011e685>] do_fork+0x75/0x19f
<4> [<c012dbc5>] sys_rt_sigprocmask+0x95/0x140
<4> [<c0107ae1>] sys_fork+0x31/0x40
<4> [<c0109365>] syscall_call+0x7/0xb
<4>Code: 8b 74 24 14 31 ed 89 f6 8d bc 27 00 00 00 00 89 34 24 bf 03 00
00 00 89 7c 24 04 e8 6f 1d fd ff 89 c2 89 c7 b9
00 04 00 00 89 e8 <f3> ab 89 14 24 b9 03 00 00 00 83 c6 20 89 4c 24 04
e8 ae 1d fd
<4> <6>note: ifup[30665] exited with preempt_count 2
<3>scheduling while atomic: ifup/0x00000002/30665
<4> [<c046fa61>] schedule+0x681/0x760
<4> [<c011fcc1>] release_console_sem+0x71/0x190
<4> [<c011fa4f>] vprintk+0x1df/0x330
<4> [<c0470d66>] rwsem_down_read_failed+0xc6/0x1e0
<4> [<c0123860>] .text.lock.exit+0x27/0x87
<4> [<c0122087>] do_exit+0xa7/0x410
<4> [<c0109d65>] die+0x1c5/0x1d0
<4> [<c0117fe4>] do_page_fault+0x3e4/0x65b
<4> [<c011b40a>] __wake_up+0x4a/0xb0
<4> [<c01e8461>] journal_stop+0x171/0x2f0
<4> [<c01da350>] ext3_mark_inode_dirty+0x50/0x60
<4> [<c01ded34>] __ext3_journal_stop+0x24/0x50
<4> [<c014ae56>] __do_page_cache_readahead+0xa6/0x270
<4> [<c01da3d1>] ext3_dirty_inode+0x71/0x90
<4> [<c01da360>] ext3_dirty_inode+0x0/0x90
<4> [<c018eb36>] __mark_inode_dirty+0x116/0x1e0
<4> [<c0124e21>] current_fs_time+0x51/0x70
<4> [<c01096ee>] page_fault+0x2e/0x34
<4> [<c0147bec>] buffered_rmqueue+0x19c/0x340
<4> [<c0147660>] prep_new_page+0x50/0x60
<4> [<c0147f2f>] __alloc_pages+0xcf/0x430
<4> [<c011cbd3>] mm_init+0xa3/0xe0
<4> [<c0116c71>] pte_alloc_one+0x11/0x30
<4> [<c0153ab2>] pte_alloc_map+0x42/0x200
<4> [<c0153d9f>] copy_pte_range+0x2f/0x330
<4> [<c0154137>] copy_page_range+0x97/0xd0
<4> [<c011d0e5>] copy_mm+0x285/0x3d0
<4> [<c05aece0>] BusLogic_ProbeHostAdapter+0xe0/0x170
<4> [<c011db77>] copy_process+0x407/0xe10
<4> [<c011e685>] do_fork+0x75/0x19f
<4> [<c012dbc5>] sys_rt_sigprocmask+0x95/0x140
<4> [<c0107ae1>] sys_fork+0x31/0x40
<4> [<c0109365>] syscall_call+0x7/0xb
[-- Attachment #2: iSCSI-Disk1 --]
[-- Type: application/octet-stream, Size: 4874 bytes --]
# -*- mode: python; -*-
#============================================================================
# Python configuration setup for 'xm create'.
# This script sets the parameters used when a domain is created using 'xm create'.
# You use a separate script for each domain you want to create, or
# you can set the parameters for the domain on the xm command line.
#============================================================================
#----------------------------------------------------------------------------
# Kernel image file.
kernel = "/boot/vmlinuz-2.6.12.6-xenU"
# Optional ramdisk.
#ramdisk = "/boot/initrd.gz"
# The domain build function. Default is 'linux'.
#builder='linux'
# Initial memory allocation (in megabytes) for the new domain.
memory = 64
# A name for your domain. All domains must have different names.
name = "Real-Disk-1"
# Which CPU to start domain on?
#cpu = -1 # leave to Xen to pick
# Number of Virtual CPUS to use, default is 1
#vcpus = 1
#----------------------------------------------------------------------------
# Define network interfaces.
# Number of network interfaces. Default is 1.
#nics=1
# Optionally define mac and/or bridge for the network interfaces.
# Random MACs are assigned if not given.
#vif = [ 'mac=aa:00:00:00:00:11, bridge=xenbr0' ]
vif = [ 'mac=aa:00:00:00:01:04, bridge=xenbr0' ]
#----------------------------------------------------------------------------
# Define the disk devices you want the domain to have access to, and
# what you want them accessible as.
# Each disk entry is of the form phy:UNAME,DEV,MODE
# where UNAME is the device, DEV is the device name the domain will see,
# and MODE is r for read-only, w for read-write.
#disk = [ 'phy:hda1,hda1,w' ]
disk = [ 'phy:sdb1,sda1,w' ]
#----------------------------------------------------------------------------
# Define to which TPM instance the user domain should communicate.
# The vtpm entry is of the form 'instance=INSTANCE,backend=DOM'
# where INSTANCE indicates the instance number of the TPM the VM
# should be talking to and DOM provides the domain where the backend
# is located.
# Note that no two virtual machines should try to connect to the same
# TPM instance. The handling of all TPM instances does require
# some management effort in so far that VM configration files (and thus
# a VM) should be associated with a TPM instance throughout the lifetime
# of the VM / VM configuration file. The instance number must be
# greater or equal to 1.
#vtpm = [ 'instance=1,backend=0' ]
#----------------------------------------------------------------------------
# Set the kernel command line for the new domain.
# You only need to define the IP parameters and hostname if the domain's
# IP config doesn't, e.g. in ifcfg-eth0 or via DHCP.
# You can use 'extra' to set the runlevel and custom environment
# variables used by custom rc scripts (e.g. VMID=, usr= ).
# Set if you want dhcp to allocate the IP address.
dhcp="dhcp"
# Set netmask.
#netmask=
# Set default gateway.
#gateway=
# Set the hostname.
#hostname= "vm%d" % vmid
# Set root device.
root = "/dev/sda1 ro"
# Root device for nfs.
#root = "/dev/nfs"
# The nfs server.
#nfs_server = '169.254.1.0'
# Root directory on the nfs server.
#nfs_root = '/full/path/to/root/directory'
# Sets runlevel 4.
extra = "5"
#----------------------------------------------------------------------------
# Configure the behaviour when a domain exits. There are three 'reasons'
# for a domain to stop: poweroff, reboot, and crash. For each of these you
# may specify:
#
# "destroy", meaning that the domain is cleaned up as normal;
# "restart", meaning that a new domain is started in place of the old
# one;
# "preserve", meaning that no clean-up is done until the domain is
# manually destroyed (using xm destroy, for example); or
# "rename-restart", meaning that the old domain is not cleaned up, but is
# renamed and a new domain started in its place.
#
# The default is
#
# on_poweroff = 'destroy'
# on_reboot = 'restart'
# on_crash = 'restart'
#
# For backwards compatibility we also support the deprecated option restart
#
# restart = 'onreboot' means on_poweroff = 'destroy'
# on_reboot = 'restart'
# on_crash = 'destroy'
#
# restart = 'always' means on_poweroff = 'restart'
# on_reboot = 'restart'
# on_crash = 'restart'
#
# restart = 'never' means on_poweroff = 'destroy'
# on_reboot = 'destroy'
# on_crash = 'destroy'
#on_poweroff = 'destroy'
#on_reboot = 'restart'
#on_crash = 'restart'
#============================================================================
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: iSCSI problems
2005-10-31 11:12 iSCSI problems Edwards, Nigel (Nigel Edwards)
@ 2005-10-31 13:52 ` Alvin Starr
2005-10-31 14:57 ` Brian Wolfe
1 sibling, 0 replies; 3+ messages in thread
From: Alvin Starr @ 2005-10-31 13:52 UTC (permalink / raw)
To: Edwards, Nigel (Nigel Edwards); +Cc: xen-devel
Edwards, Nigel (Nigel Edwards) wrote:
>Hi,
>I am having problems getting iSCSI working with xen. I can access
>iSCSI drives fine from Xen0 (e.g. untar a 500MB archive and I don't
>see problems reported through dmesg or /proc/kmsg). However, if I try
>to project them into an instance of XenU as a scsi device to boot the
>unprivileged domain I get an oops in Xen0 - often resulting in the
>whole machine crashing. This occurs in the very early stages of boot
>of xenU.
>
>I am using linux-iscsi-4.0.2 for iscsi_sfnet.ko
>scsi_transport_iscsi.ko is being built in linux-2.6.12-xen0
>I downloaded xen-unstable-src.tgz October 25th.
>
>I notice that there appear to be some significant differences between
>scsi_transport_iscsi.c in linux-iscsi-4.0.2 and the version in
>linux-2.6.12 kernel.
>
>Example oops below. I have also attached the domain config file. I am
>not sure what to do next to get this working. Any suggestions would
>be appreciated. If you have iSCSI working, if you could drop me a note
>indicating what code and modules you are using I would be very grateful.
>
>Cheers,
>Nigel.
>
>
Having played with this I would suggest that you use iSCSI in Dom0 and
export the disks from Dom0 to the varios DomU's.
I have managed to get this working with the aid of some hacks to the
UDEV configuration files so that I can get a deivce entry like
/dev/magical-iscsi-targetname.my.fun.domain.com.
It is then easy to map these things into the approprate DomU configs.
I would be concerned about using iSCSI in the DomU's because of the
extra network overhead in propigating the data across the bridge.
--
Alvin Starr || voice: (416)585-9971
Interlink Connectivity || fax: (416)585-9974
alvin@iplink.net ||
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: iSCSI problems
2005-10-31 11:12 iSCSI problems Edwards, Nigel (Nigel Edwards)
2005-10-31 13:52 ` Alvin Starr
@ 2005-10-31 14:57 ` Brian Wolfe
1 sibling, 0 replies; 3+ messages in thread
From: Brian Wolfe @ 2005-10-31 14:57 UTC (permalink / raw)
To: Edwards, Nigel (Nigel Edwards); +Cc: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 5438 bytes --]
The way I setup my dom-Us to use iscsi was with individual targets for
each dom-U and I used the iscsi-init driver from sf.net to boot directly
from the IETD (iscsi-target) server.
By doing this, I completely bypassed having to do any block IO on dom-0
thus making my dom-Us completely free of being dependant on dom-0 block
devices.
iscsi-init is fairly easy to setup. You create it as a kernel module and
load it via an initrd. It pulls it's sda target information from the
kernel line in the dom-u config file very similarly to ethernet
configuration via kernel parameters.
It worked for many months very stably in Xen-1.2 and xen-2.0.4 for
me. :)
On Mon, 2005-10-31 at 11:12 +0000, Edwards, Nigel (Nigel Edwards) wrote:
> Hi,
> I am having problems getting iSCSI working with xen. I can access
> iSCSI drives fine from Xen0 (e.g. untar a 500MB archive and I don't
> see problems reported through dmesg or /proc/kmsg). However, if I try
> to project them into an instance of XenU as a scsi device to boot the
> unprivileged domain I get an oops in Xen0 - often resulting in the
> whole machine crashing. This occurs in the very early stages of boot
> of xenU.
>
> I am using linux-iscsi-4.0.2 for iscsi_sfnet.ko
> scsi_transport_iscsi.ko is being built in linux-2.6.12-xen0
> I downloaded xen-unstable-src.tgz October 25th.
>
> I notice that there appear to be some significant differences between
> scsi_transport_iscsi.c in linux-iscsi-4.0.2 and the version in
> linux-2.6.12 kernel.
>
> Example oops below. I have also attached the domain config file. I am
> not sure what to do next to get this working. Any suggestions would
> be appreciated. If you have iSCSI working, if you could drop me a note
> indicating what code and modules you are using I would be very grateful.
>
> Cheers,
> Nigel.
>
>
> <1>Unable to handle kernel paging request at virtual address f3d55000
> <1> printing eip:
> <4>c0147bec
> <1>*pde = ma 030cb067 pa 000cb067
> <1>*pte = ma 00000000 pa 55555000
> <1>Oops: 0002 [#1]
> <4>PREEMPT
> <4>Modules linked in: crc32c md5 iscsi_sfnet scsi_transport_iscsi
> sworks_agp agpgart
> <4>CPU: 0
> <4>EIP: 0061:[<c0147bec>] Not tainted VLI
> <4>EFLAGS: 00010292 (2.6.12.6-xen0)
> <4>EIP is at buffered_rmqueue+0x19c/0x340
> <4>eax: 00000000 ebx: 00000001 ecx: 00000400 edx: f3d55000
> <4>esi: c167aaa0 edi: f3d55000 ebp: 00000000 esp: ecb41dd4
> <4>ds: 007b es: 007b ss: 0069
> <4>Process ifup (pid: 30665, threadinfo=ecb40000 task=f2180040)
> <4>Stack: c167aaa0 00000003 00000000 eeda60c0 c0147660 c167aaa0 c050c5c0
> 00000000
> <4> 00000000 000084d0 c0147f2f c050c5c0 00000000 00000010 00000000
> 00000000
> <4> 00000000 00000000 00000000 f2180040 00000010 c050c92c 00000000
> c011cbd3
> <4>Call Trace:
> <4> [<c0147660>] prep_new_page+0x50/0x60
> <4> [<c0147f2f>] __alloc_pages+0xcf/0x430
> <4> [<c011cbd3>] mm_init+0xa3/0xe0
> <4> [<c0116c71>] pte_alloc_one+0x11/0x30
> <4> [<c0153ab2>] pte_alloc_map+0x42/0x200
> <4> [<c0153d9f>] copy_pte_range+0x2f/0x330
> <4> [<c0154137>] copy_page_range+0x97/0xd0
> <4> [<c011d0e5>] copy_mm+0x285/0x3d0
> <4> [<c05aece0>] BusLogic_ProbeHostAdapter+0xe0/0x170
> <4> [<c011db77>] copy_process+0x407/0xe10
> <4> [<c011e685>] do_fork+0x75/0x19f
> <4> [<c012dbc5>] sys_rt_sigprocmask+0x95/0x140
> <4> [<c0107ae1>] sys_fork+0x31/0x40
> <4> [<c0109365>] syscall_call+0x7/0xb
> <4>Code: 8b 74 24 14 31 ed 89 f6 8d bc 27 00 00 00 00 89 34 24 bf 03 00
> 00 00 89 7c 24 04 e8 6f 1d fd ff 89 c2 89 c7 b9
> 00 04 00 00 89 e8 <f3> ab 89 14 24 b9 03 00 00 00 83 c6 20 89 4c 24 04
> e8 ae 1d fd
> <4> <6>note: ifup[30665] exited with preempt_count 2
> <3>scheduling while atomic: ifup/0x00000002/30665
> <4> [<c046fa61>] schedule+0x681/0x760
> <4> [<c011fcc1>] release_console_sem+0x71/0x190
> <4> [<c011fa4f>] vprintk+0x1df/0x330
> <4> [<c0470d66>] rwsem_down_read_failed+0xc6/0x1e0
> <4> [<c0123860>] .text.lock.exit+0x27/0x87
> <4> [<c0122087>] do_exit+0xa7/0x410
> <4> [<c0109d65>] die+0x1c5/0x1d0
> <4> [<c0117fe4>] do_page_fault+0x3e4/0x65b
> <4> [<c011b40a>] __wake_up+0x4a/0xb0
> <4> [<c01e8461>] journal_stop+0x171/0x2f0
> <4> [<c01da350>] ext3_mark_inode_dirty+0x50/0x60
> <4> [<c01ded34>] __ext3_journal_stop+0x24/0x50
> <4> [<c014ae56>] __do_page_cache_readahead+0xa6/0x270
> <4> [<c01da3d1>] ext3_dirty_inode+0x71/0x90
> <4> [<c01da360>] ext3_dirty_inode+0x0/0x90
> <4> [<c018eb36>] __mark_inode_dirty+0x116/0x1e0
> <4> [<c0124e21>] current_fs_time+0x51/0x70
> <4> [<c01096ee>] page_fault+0x2e/0x34
> <4> [<c0147bec>] buffered_rmqueue+0x19c/0x340
> <4> [<c0147660>] prep_new_page+0x50/0x60
> <4> [<c0147f2f>] __alloc_pages+0xcf/0x430
> <4> [<c011cbd3>] mm_init+0xa3/0xe0
> <4> [<c0116c71>] pte_alloc_one+0x11/0x30
> <4> [<c0153ab2>] pte_alloc_map+0x42/0x200
> <4> [<c0153d9f>] copy_pte_range+0x2f/0x330
> <4> [<c0154137>] copy_page_range+0x97/0xd0
> <4> [<c011d0e5>] copy_mm+0x285/0x3d0
> <4> [<c05aece0>] BusLogic_ProbeHostAdapter+0xe0/0x170
> <4> [<c011db77>] copy_process+0x407/0xe10
> <4> [<c011e685>] do_fork+0x75/0x19f
> <4> [<c012dbc5>] sys_rt_sigprocmask+0x95/0x140
> <4> [<c0107ae1>] sys_fork+0x31/0x40
> <4> [<c0109365>] syscall_call+0x7/0xb
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2005-10-31 14:57 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-10-31 11:12 iSCSI problems Edwards, Nigel (Nigel Edwards)
2005-10-31 13:52 ` Alvin Starr
2005-10-31 14:57 ` Brian Wolfe
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.