Messages in this thread | | | Date | Tue, 02 Jan 2007 17:31:45 +0100 | From | Stefan Richter <> | Subject | Re: 2.6.20-rc2: kernel BUG at include/asm/dma-mapping.h:110! |
| |
(list address corrected, and a question added...)
On 1/2/2007 4:53 PM, I wrote: > Kyuma Ohta wrote: > ... >> Now,I'm testing 2.6.20-rc3 for x86_64, submitted patch for this issue; >> "Fault has happened in 'cleanuped' sbp2/1394 module in *not 32bit* >> architecture hardwares ." >> >> As result of, sbp2 driver in 2.6.20-rc3 is seems to running >> w/o any faults,but communication both host and harddrive(s) >> was seems to be unstable yet :-( >> Sometimes confuse packets,such as *very* older 1394 driver :-( > > That is, sbp2 on 2.6.20-rc3 works less stable for you than on 2.6.19? Or > which previous kernel is the basis of your comparison? Are there any log > messages or other diagnostics? And what hardware do you have? > > If you can tell which kernel was good for you, I could create a set of > patches for you which allows to revert sbp2 while keeping the rest of > the kernel at the level of 2.6.20-rc3, so that you could find the > destabilizing change (if it happened in sbp2, not somewhere else). > > Although there was a certain volume of changes to sbp2 between 2.6.19 > and 2.6.20-rc{1,3}, none of them should change the behavior except for: > > - commit 0b885449ac6fab42cd6808c9ea8d6e456e0e65b7 "ieee1394: sbp2: > remove duplicate code" modifying the extremely unlikely case that > a bus reset occurs right after completion status of an unsuccessfully > completed command came in, > > - commit 23077f1d72d279244536f11db51258fc4759c81a "ieee1394: sbp2: > slightly reorder sbp2scsi_abort" which improves a SCSI error handler, > mostly relevant if a command timed out. > > - commit b2bb550c4a10c44e99fe469cfaee81e2e3109994 "ieee1394: sbp2: pass > REQUEST_SENSE through to the target" which exposes targets to a SCSI > command which was previously blocked out. But this command is either > never issued by stock Linux SCSI drivers to SBP-2 targets anyway > because they provide autosense data, or has to be be properly > supported by SBP-2 targets if targets don't send autosense data. > (This is also about error handling, unless special application > software is explicitly generating this command.) > > The DMA mapping patch did only change behavior because it was just > faulty. After its correction in 2.6.20-rc3, it really is a trivial 1:1 > conversion from the pci_dma_ API to the generic dma_ API. I neither > added nor removed anything from the mapping operations and they should > behave exactly the same as before with PCI FireWire controllers. > > Or could there have been some hidden mistake in sbp2's old pci_dma_ > usage which now turns into real problems after 1:1 conversion to the > dma_API? > > Or are there any DMA related properties of hardware that the DMA mapping > infrastructure cannot figure out from the generic device (contained in a > pci_device) compared to the pci_device?
Or are there some restrictions implicit in mappings via pci_dma_ API which are lifted when using mappings via dma_ API? -- Stefan Richter -=====-=-=== ---= ---=- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |