Bug 240471
| Summary: | fw-ohci module crashes under kernel-xen | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Eduardo Habkost <ehabkost> | ||||
| Component: | kernel-xen | Assignee: | Chris Wright <chrisw> | ||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Virtualization Bugs <virt-bugs> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | rawhide | CC: | bstein, chrisw, ehabkost, katzj, stefan-r-rhbz, triage, xen-maint | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i686 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | bzcl34nup | ||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2008-05-07 01:45:49 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Eduardo Habkost
2007-05-17 18:29:25 UTC
change QA contact There is a bug in ar_context_add_page(), at least according to what LDD3 says
about DMA mapping: The CPU shall not access memory after it has been
DMA-mapped. But I guess this bug is harmless because there is another
dma_sync_single_for_device() after the belated accesses by the CPU.
Regarding a possible optimization for DMA_TO_DEVICE: The struct ar_buffer which
is mapped there contains /1/ a "command descriptor" to program the controller,
and /2/ a buffer into which the controller will write incoming asynchronous
packets. ("AR DMA" = asynchronous receive DMA context.)
Part /2/, i.e. ab->data, could be mapped as DMA_FROM_DEVICE. Part /1/ is partly
to device, partly from device: The first 24 bytes ab->descriptor.req_count...
.branch_address could be mapped as DMA_TO_DEVICE. ab->descriptor.res_count is
to be initialized by the driver but will later be updated by the controller, so
I don't see a way around DMA_BIDIRECTIONAL here, except for allocation of
consistent memory. ab->descriptor.transfer_status is only written by the
controller.
The ohci1394 driver of the old ieee1394 stack simply uses consistent memory:
pci_alloc_consistent() for the buffers and pci_pool_alloc() for the descriptors.
The sbp2 problems seems to be fixed. However, bug #302471 has a report of crashes when loading fw-ohci (the problem that Chris mentioned on hist last comment above). The firewire modules were disabled on kernel-xen until the problems are solved. I will keep this bug open as a reminder that fw-ohci needs to be fixed before enabling it on kernel-xen. > as a reminder that fw-ohci needs to be fixed
> before enabling it on kernel-xen.
You mean: ...that XEN needs to be fixed before anything which uses
DMA_BIDIRECTIONAL can be enabled on it, or fw-ohci's AR DMA needs to be
converted to consistent memory allocations before it can be enabled on XEN.
Created attachment 208501 [details]
Experimental fix to make Xen swiotlb accept DMA_BIDIRECTIONAL DMA mappings
This is an experimental patch to make Xen swiotlb implementation accept
DMA_BIDIRECTIONAL mappings.
I am building a test kernel RPM with the experimental patch on attachment #208501 [details]. Testing by people with firewire ohci hardware will be welcome. The test package is available here: http://koji.fedoraproject.org/koji/taskinfo?taskID=176609 Additionally, I need people with sbp2 hardware to check if the fw-sbp2 module is really working under Xen, so I know if we can enable it on Rawhide/F-8 and F-7. A test package with fw-sbp2 enabled (but fw-ohci disabled) is being built at: http://koji.fedoraproject.org/koji/taskinfo?taskID=176648 Re comment #5: Eduardo, thanks for taking care of the root cause of the issue. Re comment #6: AFAIR fw-sbp2 won't do anything interesting as long as it hasn't access to an SBP-2 device. And for that it needs fw-ohci driving one or more controllers. (In reply to comment #7) > > Re comment #6: AFAIR fw-sbp2 won't do anything interesting as long as it hasn't > access to an SBP-2 device. And for that it needs fw-ohci driving one or more > controllers. You are right. I was supposing sbp2 was simply a different type of controller. Now I have read the description of the config options. :) As it doesn't make sense to enable sbp2 without ohci support, I will keep all firewire modules disabled while the fix is not included on the Fedora packages. Testing of fw-ohci and fw-sbp2 using the packages built on http://koji.fedoraproject.org/koji/taskinfo?taskID=176609 is still needed, however. Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp |