pciback for usb-controller and usb-storage on x86_64 ends in Oops

pciback for usb-controller and usb-storage on x86_64 ends in Oops

[Patrick Scharrenberg]

Hi!

I tried to pcipassthrough usb-controllers to domu to use it with a
memory-stick.

First xen complained that the driver needs write-access to its
configuration space, so I added these to pci-quirks.
Since it still didn't work I also added the device to pci-permissive but
I still get an errormessage with Oops (at the end of this email) when
sticking in the memory-stick.

I tried xen-3.0.3 and latest unstable (12053:874cc0ff214d).
I use the fedora 2.6.18.1-xen0 since otherwise my sata-controller is not
detected.

What can I do?

Patrick

lspci:
00:10.0 0c03: 1106:3038 (rev a0) (prog-if 00 [UHCI])
        Subsystem: 1462:7253
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 64, Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 21
        Region 4: I/O ports at f900 [size=32]
        Capabilities: [80] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:10.1 0c03: 1106:3038 (rev a0) (prog-if 00 [UHCI])
        Subsystem: 1462:7253
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 64, Cache Line Size: 32 bytes
        Interrupt: pin B routed to IRQ 22
        Region 4: I/O ports at f800 [size=32]
        Capabilities: [80] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:10.2 0c03: 1106:3038 (rev a0) (prog-if 00 [UHCI])
        Subsystem: 1462:7253
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 64, Cache Line Size: 32 bytes
        Interrupt: pin C routed to IRQ 20
        Region 4: I/O ports at f700 [size=32]
        Capabilities: [80] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:10.3 0c03: 1106:3038 (rev a0) (prog-if 00 [UHCI])
        Subsystem: 1462:7253
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 64, Cache Line Size: 32 bytes
        Interrupt: pin D routed to IRQ 19
        Region 4: I/O ports at f600 [size=32]
        Capabilities: [80] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:10.4 0c03: 1106:3104 (rev 86) (prog-if 20 [EHCI])
        Subsystem: 1462:7253
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 64, Cache Line Size: 32 bytes
        Interrupt: pin C routed to IRQ 5
        Region 0: Memory at dffff000 (32-bit, non-prefetchable) [size=256]
        Capabilities: [80] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-


Errormessage:


usb usb3: wakeup_rh (auto-start)
hub 3-0:1.0: state 7 ports 2 chg 0000 evt 0002
uhci_hcd 0000:00:10.2: port 1 portsc 0093,00
hub 3-0:1.0: port 1, status 0101, change 0001, 12 Mb/s
hub 3-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x101
usb 3-1: new full speed USB device using uhci_hcd and address 2
usb 3-1: default language 0x0409
usb 3-1: new device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-1: Product: USB Mass Storage Device
usb 3-1: Manufacturer: USBest Technology
usb 3-1: SerialNumber: 551114559c3fc7
usb 3-1: uevent
usb 3-1: configuration #1 chosen from 1 choice
usb 3-1: adding 3-1:1.0 (config #1, interface 0)
usb 3-1:1.0: uevent
libusual 3-1:1.0: usb_probe_interface
libusual 3-1:1.0: usb_probe_interface - got id
drivers/usb/core/inode.c: creating file '002'
Initializing USB Mass Storage driver...
usb-storage 3-1:1.0: usb_probe_interface
usb-storage 3-1:1.0: usb_probe_interface - got id
usb-storage: USB Mass Storage device detected
usb-storage: -- associate_dev
usb-storage: Vendor: 0x0457, Product: 0x0150, Revision: 0x0100
usb-storage: Interface Subclass: 0x06, Protocol: 0x50
usb-storage: Transport: Bulk
usb-storage: Protocol: Transparent SCSI
scsi0 : SCSI emulation for USB Mass Storage devices
usb-storage: *** thread sleeping.
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
usb-storage: usb_stor_control_msg: rq=fe rqtype=a1 value=0000 index=00 len=1
usb-storage: GetMaxLUN command result is 1, data is 0
Unable to handle kernel NULL pointer dereference at 0000000000000078 RIP:
 [<ffffffff804a3929>] scsi_calculate_bounce_limit+0x19/0x60
PGD 7d6c067 PUD 7c53067 PMD 0
Oops: 0000 [1]
CPU 0
Modules linked in: usb_storage uhci_hcd
Pid: 2017, comm: usb-stor-scan Not tainted 2.6.18.1-xen0 #7
RIP: e030:[<ffffffff804a3929>]  [<ffffffff804a3929>]
scsi_calculate_bounce_limit+0x19/0x60
RSP: e02b:ffff880006ddbc20  EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff880007e0c188 RCX: 0000000000000067
RDX: 0000000000000071 RSI: 00000000000000f0 RDI: ffff8800083a2800
RBP: ffff880006ddbc20 R08: ffff880007e35000 R09: 000000000000000d
R10: ffff8800000caec0 R11: 00000000000001a0 R12: ffff8800083a2800
R13: ffff880007139028 R14: ffff8800083a2800 R15: 0000000000000000
FS:  00002aebaf08cae0(0000) GS:ffffffff80757000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000
Process usb-stor-scan (pid: 2017, threadinfo ffff880006dda000, task
ffff880007d35610)
Stack:  ffff880006ddbc40  ffffffff804a412a  ffff8800080e0800 
ffff880007139000
 ffff880006ddbc80  ffffffff804a5fc6  ffff880006ddbc80  ffff8800083a2800
 0000000000000000  0000000000000000
Call Trace:
 [<ffffffff804a412a>] scsi_alloc_queue+0x6a/0xc0
 [<ffffffff804a5fc6>] scsi_alloc_sdev+0x126/0x1e0
 [<ffffffff804a6192>] scsi_probe_and_add_lun+0xe2/0x8f0
 [<ffffffff804a6fd2>] __scsi_scan_target+0xd2/0x5b0
 [<ffffffff80233990>] process_timeout+0x0/0x10
 [<ffffffff8023e360>] keventd_create_kthread+0x0/0x70
 [<ffffffff8022b6e7>] printk+0x67/0x70
 [<ffffffff804a7515>] scsi_scan_channel+0x65/0xa0
 [<ffffffff804a75e6>] scsi_scan_host_selected+0x96/0xe0
 [<ffffffff8023e360>] keventd_create_kthread+0x0/0x70
 [<ffffffff804a7645>] scsi_scan_host+0x15/0x20
 [<ffffffff8800c53a>] :usb_storage:usb_stor_scan_thread+0x17a/0x19e
 [<ffffffff8023e790>] autoremove_wake_function+0x0/0x40
 [<ffffffff8800c3c0>] :usb_storage:usb_stor_scan_thread+0x0/0x19e
 [<ffffffff8023e4a9>] kthread+0xd9/0x110
 [<ffffffff8020a814>] child_rip+0xa/0x12
 [<ffffffff8023e360>] keventd_create_kthread+0x0/0x70
 [<ffffffff8023e3d0>] kthread+0x0/0x110
 [<ffffffff8020a80a>] child_rip+0x0/0x12


Code: 8b 40 78 85 c0 75 10 48 8b 05 51 31 34 00 48 c1 e0 0c eb 25
RIP  [<ffffffff804a3929>] scsi_calculate_bounce_limit+0x19/0x60
 RSP <ffff880006ddbc20>
CR2: 0000000000000078

RE: pciback for usb-controller and usb-storage on x86_64ends in Oops

[Ian Pratt]

> I tried to pcipassthrough usb-controllers to domu to use it with a
> memory-stick.
> 
> First xen complained that the driver needs write-access to its
> configuration space, so I added these to pci-quirks.
> Since it still didn't work I also added the device to pci-permissive
but
> I still get an errormessage with Oops (at the end of this email) when
> sticking in the memory-stick.
> 
> I tried xen-3.0.3 and latest unstable (12053:874cc0ff214d).
> I use the fedora 2.6.18.1-xen0 since otherwise my sata-controller is
not
> detected.
> 
> What can I do?

Have you made sure the device is hidden from dom0? Having two drivers
going at it would be bad...

Ian

 
> Patrick
> 
> lspci:
> 00:10.0 0c03: 1106:3038 (rev a0) (prog-if 00 [UHCI])
>         Subsystem: 1462:7253
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>         Latency: 64, Cache Line Size: 32 bytes
>         Interrupt: pin A routed to IRQ 21
>         Region 4: I/O ports at f900 [size=32]
>         Capabilities: [80] Power Management version 2
>                 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
> PME(D0+,D1+,D2+,D3hot+,D3cold+)
>                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 
> 00:10.1 0c03: 1106:3038 (rev a0) (prog-if 00 [UHCI])
>         Subsystem: 1462:7253
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>         Latency: 64, Cache Line Size: 32 bytes
>         Interrupt: pin B routed to IRQ 22
>         Region 4: I/O ports at f800 [size=32]
>         Capabilities: [80] Power Management version 2
>                 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
> PME(D0+,D1+,D2+,D3hot+,D3cold+)
>                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 
> 00:10.2 0c03: 1106:3038 (rev a0) (prog-if 00 [UHCI])
>         Subsystem: 1462:7253
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>         Latency: 64, Cache Line Size: 32 bytes
>         Interrupt: pin C routed to IRQ 20
>         Region 4: I/O ports at f700 [size=32]
>         Capabilities: [80] Power Management version 2
>                 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
> PME(D0+,D1+,D2+,D3hot+,D3cold+)
>                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 
> 00:10.3 0c03: 1106:3038 (rev a0) (prog-if 00 [UHCI])
>         Subsystem: 1462:7253
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>         Latency: 64, Cache Line Size: 32 bytes
>         Interrupt: pin D routed to IRQ 19
>         Region 4: I/O ports at f600 [size=32]
>         Capabilities: [80] Power Management version 2
>                 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
> PME(D0+,D1+,D2+,D3hot+,D3cold+)
>                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 
> 00:10.4 0c03: 1106:3104 (rev 86) (prog-if 20 [EHCI])
>         Subsystem: 1462:7253
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>         Latency: 64, Cache Line Size: 32 bytes
>         Interrupt: pin C routed to IRQ 5
>         Region 0: Memory at dffff000 (32-bit, non-prefetchable)
[size=256]
>         Capabilities: [80] Power Management version 2
>                 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
> PME(D0+,D1+,D2+,D3hot+,D3cold+)
>                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 
> 
> Errormessage:
> 
> 
> usb usb3: wakeup_rh (auto-start)
> hub 3-0:1.0: state 7 ports 2 chg 0000 evt 0002
> uhci_hcd 0000:00:10.2: port 1 portsc 0093,00
> hub 3-0:1.0: port 1, status 0101, change 0001, 12 Mb/s
> hub 3-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x101
> usb 3-1: new full speed USB device using uhci_hcd and address 2
> usb 3-1: default language 0x0409
> usb 3-1: new device strings: Mfr=1, Product=2, SerialNumber=3
> usb 3-1: Product: USB Mass Storage Device
> usb 3-1: Manufacturer: USBest Technology
> usb 3-1: SerialNumber: 551114559c3fc7
> usb 3-1: uevent
> usb 3-1: configuration #1 chosen from 1 choice
> usb 3-1: adding 3-1:1.0 (config #1, interface 0)
> usb 3-1:1.0: uevent
> libusual 3-1:1.0: usb_probe_interface
> libusual 3-1:1.0: usb_probe_interface - got id
> drivers/usb/core/inode.c: creating file '002'
> Initializing USB Mass Storage driver...
> usb-storage 3-1:1.0: usb_probe_interface
> usb-storage 3-1:1.0: usb_probe_interface - got id
> usb-storage: USB Mass Storage device detected
> usb-storage: -- associate_dev
> usb-storage: Vendor: 0x0457, Product: 0x0150, Revision: 0x0100
> usb-storage: Interface Subclass: 0x06, Protocol: 0x50
> usb-storage: Transport: Bulk
> usb-storage: Protocol: Transparent SCSI
> scsi0 : SCSI emulation for USB Mass Storage devices
> usb-storage: *** thread sleeping.
> usbcore: registered new driver usb-storage
> USB Mass Storage support registered.
> usb-storage: device found at 2
> usb-storage: waiting for device to settle before scanning
> usb-storage: usb_stor_control_msg: rq=fe rqtype=a1 value=0000 index=00
> len=1
> usb-storage: GetMaxLUN command result is 1, data is 0
> Unable to handle kernel NULL pointer dereference at 0000000000000078
RIP:
>  [<ffffffff804a3929>] scsi_calculate_bounce_limit+0x19/0x60
> PGD 7d6c067 PUD 7c53067 PMD 0
> Oops: 0000 [1]
> CPU 0
> Modules linked in: usb_storage uhci_hcd
> Pid: 2017, comm: usb-stor-scan Not tainted 2.6.18.1-xen0 #7
> RIP: e030:[<ffffffff804a3929>]  [<ffffffff804a3929>]
> scsi_calculate_bounce_limit+0x19/0x60
> RSP: e02b:ffff880006ddbc20  EFLAGS: 00010246
> RAX: 0000000000000000 RBX: ffff880007e0c188 RCX: 0000000000000067
> RDX: 0000000000000071 RSI: 00000000000000f0 RDI: ffff8800083a2800
> RBP: ffff880006ddbc20 R08: ffff880007e35000 R09: 000000000000000d
> R10: ffff8800000caec0 R11: 00000000000001a0 R12: ffff8800083a2800
> R13: ffff880007139028 R14: ffff8800083a2800 R15: 0000000000000000
> FS:  00002aebaf08cae0(0000) GS:ffffffff80757000(0000)
> knlGS:0000000000000000
> CS:  e033 DS: 0000 ES: 0000
> Process usb-stor-scan (pid: 2017, threadinfo ffff880006dda000, task
> ffff880007d35610)
> Stack:  ffff880006ddbc40  ffffffff804a412a  ffff8800080e0800
> ffff880007139000
>  ffff880006ddbc80  ffffffff804a5fc6  ffff880006ddbc80
ffff8800083a2800
>  0000000000000000  0000000000000000
> Call Trace:
>  [<ffffffff804a412a>] scsi_alloc_queue+0x6a/0xc0
>  [<ffffffff804a5fc6>] scsi_alloc_sdev+0x126/0x1e0
>  [<ffffffff804a6192>] scsi_probe_and_add_lun+0xe2/0x8f0
>  [<ffffffff804a6fd2>] __scsi_scan_target+0xd2/0x5b0
>  [<ffffffff80233990>] process_timeout+0x0/0x10
>  [<ffffffff8023e360>] keventd_create_kthread+0x0/0x70
>  [<ffffffff8022b6e7>] printk+0x67/0x70
>  [<ffffffff804a7515>] scsi_scan_channel+0x65/0xa0
>  [<ffffffff804a75e6>] scsi_scan_host_selected+0x96/0xe0
>  [<ffffffff8023e360>] keventd_create_kthread+0x0/0x70
>  [<ffffffff804a7645>] scsi_scan_host+0x15/0x20
>  [<ffffffff8800c53a>] :usb_storage:usb_stor_scan_thread+0x17a/0x19e
>  [<ffffffff8023e790>] autoremove_wake_function+0x0/0x40
>  [<ffffffff8800c3c0>] :usb_storage:usb_stor_scan_thread+0x0/0x19e
>  [<ffffffff8023e4a9>] kthread+0xd9/0x110
>  [<ffffffff8020a814>] child_rip+0xa/0x12
>  [<ffffffff8023e360>] keventd_create_kthread+0x0/0x70
>  [<ffffffff8023e3d0>] kthread+0x0/0x110
>  [<ffffffff8020a80a>] child_rip+0x0/0x12
> 
> 
> Code: 8b 40 78 85 c0 75 10 48 8b 05 51 31 34 00 48 c1 e0 0c eb 25
> RIP  [<ffffffff804a3929>] scsi_calculate_bounce_limit+0x19/0x60
>  RSP <ffff880006ddbc20>
> CR2: 0000000000000078
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: pciback for usb-controller and usb-storage on x86_64ends in Oops

[Patrick Scharrenberg]

Ian Pratt schrieb:
> Have you made sure the device is hidden from dom0? Having two drivers
> going at it would be bad...
Yes, I have.
The  usb-controllers are hidden from dom0 by kernel command-line.

atlantis-xen:~# find /sys/bus/pci/ -iname "0000:00:10.*"
/sys/bus/pci/drivers/pciback/0000:00:10.4
/sys/bus/pci/drivers/pciback/0000:00:10.3
/sys/bus/pci/drivers/pciback/0000:00:10.2
/sys/bus/pci/drivers/pciback/0000:00:10.1
/sys/bus/pci/drivers/pciback/0000:00:10.0
/sys/bus/pci/devices/0000:00:10.4
/sys/bus/pci/devices/0000:00:10.3
/sys/bus/pci/devices/0000:00:10.2
/sys/bus/pci/devices/0000:00:10.1
/sys/bus/pci/devices/0000:00:10.0


What further information do you need ?
How can I help investigating this error?

Patrick

RE: pciback for usb-controller and usb-storage on x86_64ends in Oops

[Ian Pratt]

> Ian Pratt schrieb:
> > Have you made sure the device is hidden from dom0? Having two
drivers
> > going at it would be bad...
> Yes, I have.
> The  usb-controllers are hidden from dom0 by kernel command-line.

You're not using the xen blkfront device attached to an sdX device in
the guest are you? Best to use xvdX.

It might be worth adding some tracing to confirm what's NULL in
scsi_calculate_bounce_limit

Ian

Xen hangs up when restore Domain-0 from UP to SMP.

[Liang Yang]

Hi,

I used xm vcpu-set to change the number of CPUs assigned to domain-0 frm 4 
to 1 by using the command "xm vcpu-set Domain-0 1". Xen domain0 works 
properly. But when I try to re-assign 4 CPUs to domain0 by using "xm 
vcpu-set Domain-0 4". Xen hangs up and the whole system is dead.

Could anyone here explain why this will happen?

Thanks,

Liang

Re: pciback for usb-controller and usb-storage on x86_64ends in Oops

[Patrick Scharrenberg]

> You're not using the xen blkfront device attached to an sdX device in
> the guest are you? Best to use xvdX.
>   
I used a hdX device and now changed it to xvdX.
There are no other scsi devices in this domain.

Patrick

RE: pciback for usb-controller and usb-storage on x86_64ends in Oops

[Ian Pratt]

> > You're not using the xen blkfront device attached to an sdX device
in
> > the guest are you? Best to use xvdX.
> >
> I used a hdX device and now changed it to xvdX.
> There are no other scsi devices in this domain.

Does this crash only happen when you have a USB memory stick plugged in,
or is it just on initialisation? 

Would be good to add some tracing to the scsi_calculate_bounce_limit
function

Ian 

RE: Xen hangs up when restore Domain-0 from UP to SMP.

[Ian Pratt]

> I used xm vcpu-set to change the number of CPUs assigned to domain-0
frm 4
> to 1 by using the command "xm vcpu-set Domain-0 1". Xen domain0 works
> properly. But when I try to re-assign 4 CPUs to domain0 by using "xm
> vcpu-set Domain-0 4". Xen hangs up and the whole system is dead.
> 
> Could anyone here explain why this will happen?

It shouldn't. What version of Xen?

Please can you try a debug=y build, and then get a serial line on the
machine and access the xen emergency console and hit 'q' and 'd' a few
times and post the result.

Thanks,
Ian

Re: pciback for usb-controller and usb-storage on x86_64ends in Oops

[Keir Fraser]

On 1/11/06 10:22 pm, "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> wrote:

> Would be good to add some tracing to the scsi_calculate_bounce_limit
> function

Yes, it's way down in the bowels of the SCSI code. It's not obvious what we
might be doing wrong.

 -- Keir

Re: pciback for usb-controller and usb-storage on x86_64ends in Oops

[Patrick Scharrenberg]

Ian Pratt schrieb:
> Does this crash only happen when you have a USB memory stick plugged in,
> or is it just on initialisation? 
>   
I first loaded all necessary modules without problems and after plugging
the memory stick in the error occurs.

Other usb-devices like bluetooth or a printer work.
> Would be good to add some tracing to the scsi_calculate_bounce_limit
> function
>   
It seems that PCI_DMA_BUS_IS_PHYS doesn't get initialized.
The crash takes place when executing my printk of PCI_DMA_BUS_IS_PHYS in
drivers/scsi/scsi_lib.c

Patrick

Re: pciback for usb-controller and usb-storage on x86_64 ends in Oops

[Keir Fraser]

On 1/11/06 7:19 pm, "Patrick Scharrenberg" <pittipatti@web.de> wrote:

> I tried xen-3.0.3 and latest unstable (12053:874cc0ff214d).
> I use the fedora 2.6.18.1-xen0 since otherwise my sata-controller is not
> detected.
> 
> What can I do?

Is dma_ops == NULL at that point? If not, what value does it have?

You could also check its value immediately after the call to no_iommu_init()
in arch/x86_64/mm/init-xen.c:mem_init(). It should definitely contain a
valid kernel address at that point.

 -- Keir

Re: pciback for usb-controller and usb-storage on x86_64 ends in Oops

[Patrick Scharrenberg]

Keir Fraser schrieb:
>> I tried xen-3.0.3 and latest unstable (12053:874cc0ff214d).
>> I use the fedora 2.6.18.1-xen0 since otherwise my sata-controller is not
>> detected.
>>
>> What can I do?
>>     
>
> Is dma_ops == NULL at that point? If not, what value does it have?
>   
It is indeed NULL at that point and as far as I can see it's an issue of
the fedora-kernel since there in arch/x86_64/mm/init-xen.c:mem_init()
"pci_iommu_alloc()" is called instead of "no_iommu_init()"!
I replaced pci_iommu_alloc() with the "pci_swiotlb_init()" /
"no_iommu_init()"-block from xen-unstable and now it works!

The fedora init-xen.c looks very different to the one on your repository
in many places, but I can't see if theses changes were intended or if
it's just an older revision in the fedora-tree.

Patrick

Re: pciback for usb-controller and usb-storage on x86_64 ends in Oops

[Keir Fraser]

On 2/11/06 11:13, "Patrick Scharrenberg" <pittipatti@web.de> wrote:

>> 
>> Is dma_ops == NULL at that point? If not, what value does it have?
>>   
> It is indeed NULL at that point and as far as I can see it's an issue of
> the fedora-kernel since there in arch/x86_64/mm/init-xen.c:mem_init()
> "pci_iommu_alloc()" is called instead of "no_iommu_init()"!
> I replaced pci_iommu_alloc() with the "pci_swiotlb_init()" /
> "no_iommu_init()"-block from xen-unstable and now it works!
> 
> The fedora init-xen.c looks very different to the one on your repository
> in many places, but I can't see if theses changes were intended or if
> it's just an older revision in the fedora-tree.

Most likely it's just a result of some dodgy forward porting from 2.6.16 to
2.6.18. We will upgrade our vanilla kernel version before 3.0.4 and it's
likely that vendors will sync with us when we do (or at least compare ports
for bugs).

Another 'fix' for the issue you saw, and maybe a good idea anyway if you
have 4GB or more of memory, is to put 'swiotlb=force,1' on your
driver-domain command line.

 -- Keir

Re: pciback for usb-controller and usb-storage on x86_64 ends in Oops

[Patrick Scharrenberg]

Keir Fraser schrieb:
> Most likely it's just a result of some dodgy forward porting from 2.6.16 to
> 2.6.18. We will upgrade our vanilla kernel version before 3.0.4 and it's
> likely that vendors will sync with us when we do (or at least compare ports
> for bugs).
>   
That's good to hear! :-)
> Another 'fix' for the issue you saw, and maybe a good idea anyway if you
> have 4GB or more of memory, is to put 'swiotlb=force,1' on your
> driver-domain command line.
>   
I'll give this a try too and inform the fedora-maintainers about this issue.

Thanks for helping me solving this problem although it wasn't your code!

Patrick

Re: pciback for usb-controller and usb-storage on x86_64 ends in Oops

[Muli Ben-Yehuda]

On Thu, Nov 02, 2006 at 11:26:23AM +0000, Keir Fraser wrote:
> On 2/11/06 11:13, "Patrick Scharrenberg" <pittipatti@web.de> wrote:
> 
> >> 
> >> Is dma_ops == NULL at that point? If not, what value does it have?
> >>   
> > It is indeed NULL at that point and as far as I can see it's an issue of
> > the fedora-kernel since there in arch/x86_64/mm/init-xen.c:mem_init()
> > "pci_iommu_alloc()" is called instead of "no_iommu_init()"!
> > I replaced pci_iommu_alloc() with the "pci_swiotlb_init()" /
> > "no_iommu_init()"-block from xen-unstable and now it works!
> > 
> > The fedora init-xen.c looks very different to the one on your repository
> > in many places, but I can't see if theses changes were intended or if
> > it's just an older revision in the fedora-tree.
> 
> Most likely it's just a result of some dodgy forward porting from 2.6.16 to
> 2.6.18. We will upgrade our vanilla kernel version before 3.0.4 and it's
> likely that vendors will sync with us when we do (or at least compare ports
> for bugs).
> 
> Another 'fix' for the issue you saw, and maybe a good idea anyway if you
> have 4GB or more of memory, is to put 'swiotlb=force,1' on your
> driver-domain command line.

Fixing the un-holy Xen IOMMU initialization mes^H^H^Hcode is also a
good idea... would you be receptive to a forward port of
http://marc.theaimsgroup.com/?l=xen-devel&m=114840457908143&w=2 at
this time?

Cheers,
Muli

Re: pciback for usb-controller and usb-storage on x86_64 ends in Oops

[Keir Fraser]

On 2/11/06 13:25, "Muli Ben-Yehuda" <muli@il.ibm.com> wrote:

>> Another 'fix' for the issue you saw, and maybe a good idea anyway if you
>> have 4GB or more of memory, is to put 'swiotlb=force,1' on your
>> driver-domain command line.
> 
> Fixing the un-holy Xen IOMMU initialization mes^H^H^Hcode is also a
> good idea... would you be receptive to a forward port of
> http://marc.theaimsgroup.com/?l=xen-devel&m=114840457908143&w=2 at
> this time?

I'd be happy to see it forward ported *and* sanity checked. Last time I
looked I think it was still a bit rough round the edges: multiple
declarations in various places and so on.

 -- Keir

Re: pciback for usb-controller and usb-storage on x86_64 ends in Oops

[Muli Ben-Yehuda]

On Thu, Nov 02, 2006 at 01:56:15PM +0000, Keir Fraser wrote:
> On 2/11/06 13:25, "Muli Ben-Yehuda" <muli@il.ibm.com> wrote:
> 
> >> Another 'fix' for the issue you saw, and maybe a good idea anyway if you
> >> have 4GB or more of memory, is to put 'swiotlb=force,1' on your
> >> driver-domain command line.
> > 
> > Fixing the un-holy Xen IOMMU initialization mes^H^H^Hcode is also a
> > good idea... would you be receptive to a forward port of
> > http://marc.theaimsgroup.com/?l=xen-devel&m=114840457908143&w=2 at
> > this time?
> 
> I'd be happy to see it forward ported *and* sanity checked. Last time I
> looked I think it was still a bit rough round the edges: multiple
> declarations in various places and so on.

Excellent. Any point in doing it against 2.6.16.29, or is the move to
2.6.18 imminent?

Cheers,
Muli

Re: pciback for usb-controller and usb-storage on x86_64 ends in Oops

[Keir Fraser]

On 2/11/06 14:14, "Muli Ben-Yehuda" <muli@il.ibm.com> wrote:

>> I'd be happy to see it forward ported *and* sanity checked. Last time I
>> looked I think it was still a bit rough round the edges: multiple
>> declarations in various places and so on.
> 
> Excellent. Any point in doing it against 2.6.16.29, or is the move to
> 2.6.18 imminent?

Good question. I'm not sure how much that code has changed in mainline Linux
now anyway. Might be worth waiting.

 -- Keir

Re: pciback for usb-controller and usb-storage on x86_64 ends in Oops

[Muli Ben-Yehuda]

On Thu, Nov 02, 2006 at 02:35:17PM +0000, Keir Fraser wrote:

> On 2/11/06 14:14, "Muli Ben-Yehuda" <muli@il.ibm.com> wrote:
> 
> >> I'd be happy to see it forward ported *and* sanity checked. Last time I
> >> looked I think it was still a bit rough round the edges: multiple
> >> declarations in various places and so on.
> > 
> > Excellent. Any point in doing it against 2.6.16.29, or is the move to
> > 2.6.18 imminent?
> 
> Good question. I'm not sure how much that code has changed in mainline Linux
> now anyway. Might be worth waiting.

The dma_ops interface hasn't changed significantly since we put it in,
but the current Xen IOMMU code is convulted enough I'm inclined to
wait and only suffer once :-)

Cheers,
Muli

ATI Support for XEN

[Sven Oehme]

[-- Attachment #1.1: Type: text/plain, Size: 496 bytes --]

Hi,

i saw several people complaining about missing Support for XEN in the 
proprietary drivers of ATI.
i am not a friend of proprietary drivers, but it looks like the only way 
to get support for the newest cards from ATI.
i opened a bug report at the unofficial ATI Bugzilla and ask everybody who 
wants/needs this, to register there and vote for this bug !!!

the bugfix entry can be reached under --> 
http://ati.cchtml.com/show_bug.cgi?id=531

May be this is a way to convince them. 

Sven


[-- Attachment #1.2: Type: text/html, Size: 858 bytes --]

[-- Attachment #2: Type: text/plain, Size: 137 bytes --]

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