WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

[Xen-users] problems with external mass storage using pciback.hide

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-users] problems with external mass storage using pciback.hide
From: Daniele P. <daniele@xxxxxxxxxxxx>
Date: Mon, 4 Dec 2006 12:49:32 +0100
Delivery-date: Mon, 04 Dec 2006 03:51:21 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
Organization: Interline
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.1
Hi all,
I'm trying to use external mass storage devices inside a domU with
pciback.hide.
Before filing a bug report I'd like to check with the community if
this is a known behaviour.

I'm using debian sarge and xen from backports.org
Linux testme 2.6.18-2-xen-686 #1 SMP Fri Nov 10 05:04:18 CET 2006 i686 
GNU/Linux
xen-hypervisor-3.0.3-1-i386 3.0.3-0-2~bpo1

The disk attached using firewire (ieee1394) or usb (usb2) is correctly
recognised in the domU and it's available by default as /dev/sda
conflicting with the sda1 that is the root partition specified in
domU.cfg and in domU /etc/fstab.

The workaround is simple: use xvdaX instead of sdaX in domU.cfg and 
fstab.

I don't made any other investigation but I guess that the kernel should
name the new devices starting from the first name available, in my
case sdb.

The system, however is really unstable. The system without pciback works
well. Pciback causes a freeze and every two hours I have to do a manual
reboot. The serial console usually show the following message:

NETDEV WATCHDOG: peth1: transmit timed out
peth1: link up, 100Mbps, full-duplex, lpa 0x41E1
peth1: Promiscuous mode enabled.
NETDEV WATCHDOG: peth1: transmit timed out
peth1: link up, 100Mbps, full-duplex, lpa 0x41E1
peth1: Promiscuous mode enabled.
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata1.00: tag 0 cmd 0xea Emask 0x4 stat 0x40 err 0x0 (timeout)
ata1: soft resetting port
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: tag 0 cmd 0xea Emask 0x4 stat 0x40 err 0x0 (timeout)
ata2: soft resetting port
NETDEV WATCHDOG: peth1: transmit timed out
peth1: link up, 100Mbps, full-duplex, lpa 0x41E1
peth1: Promiscuous mode enabled.
NETDEV WATCHDOG: peth1: transmit timed out
peth1: link up, 100Mbps, full-duplex, lpa 0x41E1
peth1: Promiscuous mode enabled.
ata1.00: qc timeout (cmd 0xec)
ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata1.00: revalidation failed (errno=-5)
ata1: failed to recover some devices, retrying in 5 secs
ata2.00: qc timeout (cmd 0xec)
ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata2.00: revalidation failed (errno=-5)
ata2: failed to recover some devices, retrying in 5 secs
NETDEV WATCHDOG: peth1: transmit timed out
ata1: soft resetting port
ata2: soft resetting port
peth1: link up, 100Mbps, full-duplex, lpa 0x41E1
peth1: Promiscuous mode enabled.
NETDEV WATCHDOG: peth1: transmit timed out
peth1: link up, 100Mbps, full-duplex, lpa 0x41E1
[...]

The following happended once at boot time:

PCI: Enabling device 0000:05:04.0 (0000 -> 0002)
ACPI: PCI Interrupt 0000:05:04.0[A] -> GSI 16 (level, low) -> IRQ 17
 XXX.cfg(skip) YYY.cfg(skip) ZZZ.cfgdevice vif9.0 entered promiscuous 
mode
audit(1164796812.410:14): dev=vif9.0 prom=256 old_prom=0 auid=4294967295
ADDRCONF(NETDEV_UP): vif9.0: link is not ready
------------[ cut here ]------------
kernel BUG at drivers/xen/core/evtchn.c:481!
invalid opcode: 0000 [#1]
SMP
Modules linked in: xt_physdev iptable_filter ip_tables x_tables bridge 
netloop ipv6 ext2 mbcache snd_hda_intel snd_hda_codec psmouse parpon
CPU:    1
EIP:    0061:[<c020e679>]    Not tainted VLI
EFLAGS: 00010046   (2.6.18-2-xen-686 #1)
EIP is at retrigger+0x1f/0x35
eax: 00000000   ebx: 02080000   ecx: 00000038   edx: fbf46000
esi: c0330920   edi: 0000011d   ebp: c0ff3f04   esp: c0ff3eb4
ds: 007b   es: 007b   ss: 0069
Process xenwatch (pid: 11, ti=c0ff2000 task=c1021000 task.ti=c0ff2000)
Stack: c013b865 c0330920 0000011d 00000000 c013b21f ce970ec0 00000000 ce970ec0
       c0219953 00000000 c0219ebb ce970ec0 c0155767 fffffffe cf309780 cf4c6200
       c0212f71 00000000 c0ff3f2c cda95a60 c0210009 00000008 00000038 cda95a60
Call Trace:
 [<c013b865>] check_irq_resend+0x41/0x48
 [<c013b21f>] enable_irq+0x72/0x86
 [<c0219953>] __netif_up+0xb/0x13
 [<c0219ebb>] netif_map+0x15d/0x190
 [<c0155767>] kfree+0xe/0x71
 [<c0212f71>] xenbus_read+0x31/0x37
 [<c0210009>] post_suspend+0x98/0x123
 [<c0219910>] connect_rings+0x1d6/0x204
 [<c02196c7>] connect+0xb/0x7e
 [<c0213dbd>] otherend_changed+0x82/0x88
 [<c0213592>] xenwatch_handle_callback+0x12/0x43
 [<c02136df>] xenwatch_thread+0x11c/0x133
 [<c012b0aa>] autoremove_wake_function+0x0/0x2d
 [<c012b0aa>] autoremove_wake_function+0x0/0x2d
 [<c02135c3>] xenwatch_thread+0x0/0x133
 [<c012ad58>] kthread+0x7d/0xa1
 [<c012acdb>] kthread+0x0/0xa1
 [<c0102b59>] kernel_thread_helper+0x5/0xb
Code: 89 c2 89 d8 e8 6f ff ff ff 59 5b c3 0f b7 0c 85 a0 64 39 c0 8b 15 
1c 4c 2e c0 85 c9 74 1d 0f a3 8a 80 08 00 00 19 c0 85 c0 75 08 <0f
EIP: [<c020e679>] retrigger+0x1f/0x35 SS:ESP 0069:c0ff3eb4

Thanks in advance,
Daniele P.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-users] problems with external mass storage using pciback.hide, Daniele P . <=