Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
Robert Hancock wrote: Can you (or others experiencing this problem) test the latest patch attached to the RH Bugzilla entry here: https://bugzilla.redhat.com/show_bug.cgi?id=351451 and see if it resolves the problem? I have one report of success so far. I've tested this patch and it seems to work OK with my hardware. Thank you! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
Robert Hancock wrote: Can you (or others experiencing this problem) test the latest patch attached to the RH Bugzilla entry here: https://bugzilla.redhat.com/show_bug.cgi?id=351451 and see if it resolves the problem? I have one report of success so far. I've tested this patch and it seems to work OK with my hardware. Thank you! -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
Robert Hancock wrote: Can you (or others experiencing this problem) test the latest patch attached to the RH Bugzilla entry here: https://bugzilla.redhat.com/show_bug.cgi?id=351451 and see if it resolves the problem? I have one report of success so far. I'll test it at this weekend. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
Robert Hancock wrote: Can you (or others experiencing this problem) test the latest patch attached to the RH Bugzilla entry here: https://bugzilla.redhat.com/show_bug.cgi?id=351451 and see if it resolves the problem? I have one report of success so far. I'll test it at this weekend. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
Alexander wrote: Hello! The problem described at https://bugzilla.redhat.com/show_bug.cgi?id=351451 and at http://ubuntuforums.org/showthread.php?t=655772 and supposedly fixed by the patch http://kerneltrap.org/mailarchive/linux-kernel/2007/11/25/445094 is still there. I have compiled 2.6.24-rc7 kernel and booted my PC with it just to find out that my SATA DVD-RW is sr0: scsi3-mmc drive: 0x/0x caddy as it was before with 2.6.23.12 and earlier 2.6 kernels compiled for x86_64. Trying to use sr0 after this results in dead hang or reboot. When I put sata_nv.adma=0 or mem=4096M then it's all ok: Can you (or others experiencing this problem) test the latest patch attached to the RH Bugzilla entry here: https://bugzilla.redhat.com/show_bug.cgi?id=351451 and see if it resolves the problem? I have one report of success so far. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
Alexander wrote: Hello! The problem described at https://bugzilla.redhat.com/show_bug.cgi?id=351451 and at http://ubuntuforums.org/showthread.php?t=655772 and supposedly fixed by the patch http://kerneltrap.org/mailarchive/linux-kernel/2007/11/25/445094 is still there. I have compiled 2.6.24-rc7 kernel and booted my PC with it just to find out that my SATA DVD-RW is sr0: scsi3-mmc drive: 0x/0x caddy as it was before with 2.6.23.12 and earlier 2.6 kernels compiled for x86_64. Trying to use sr0 after this results in dead hang or reboot. When I put sata_nv.adma=0 or mem=4096M then it's all ok: Can you (or others experiencing this problem) test the latest patch attached to the RH Bugzilla entry here: https://bugzilla.redhat.com/show_bug.cgi?id=351451 and see if it resolves the problem? I have one report of success so far. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
On Mon, 2008-01-14 at 19:41 -0600, Robert Hancock wrote: > James Bottomley wrote: > > On Sun, 2008-01-13 at 16:29 +, Alan Cox wrote: > >>> Yes, I concur for the short term. The other two possible courses of > >>> action either involve long discussions (the different device one) or > >>> you'll never quite be sure you got all the paths (the GFP_DMA32 one). > >>> At least with this one, you know everything will work. > >> The different device one is tricky because the PCI layer is involved in > >> mapping on some systems so you can't just magic up a platform device for > >> it. Putting a mask on the block queue might perhaps work as a model > >> which avoids breaking stuff by suprise, with the device left at 32bit > >> masking. > > > > Actually, you might be able to ... that's why I'm suggesting it. There > > are two pieces of information the arch layer needs to know: what is the > > dma_mask and where is the iommu/bridge/whatever. When we went to the > > generic dma_map_ API on parisc, we found you simply get the one from > > struct device and for the other you walk up the device tree until you > > find what you're looking for. > > > > I'm not suggesting we invent a dummy pci_device ... I'm suggesting we > > dma_map on the existing scsi_device, which is properly parented to the > > pci_device. The problem with this approach will be any architecture > > which blindly expects dma_map converts to pci_dma_map; however, I'm not > > sure we have any of those left. > > I've tried the dumb solution of setting the mask on the PCI device (for > both ports) whenever an ATAPI device is detected, and ran into problems > with that. If we really need to keep the block queue bounce limit and > DMA mask the same, then we then have to set the bounce limit on both > ports as well. If you blindly do that from slave_config, though, then > you blow up since on the first port's initial slave_config the block > queue for the second port isn't allocated yet, so you'd have to detect > that case somehow. And if it's done via hotplug after the other port is > already in use, it'll be changing the limits on a port that's in active > use, which seems like it could be a bit racy. > > So, any ideas? Maybe using the separate struct device is the easiest > solution, if it'll work.. Right, and the separate struct device exists already in the scsi_device ... the problem currently is that this isn't the device we map with, but it could easily become so ... provided the architectures support it. This isn't a quick fix solution ... it will involve quite a bit of device use rethreading through both scsi and ata, so it might be wise to get linux-arch buy in first. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
James Bottomley wrote: On Sun, 2008-01-13 at 16:29 +, Alan Cox wrote: Yes, I concur for the short term. The other two possible courses of action either involve long discussions (the different device one) or you'll never quite be sure you got all the paths (the GFP_DMA32 one). At least with this one, you know everything will work. The different device one is tricky because the PCI layer is involved in mapping on some systems so you can't just magic up a platform device for it. Putting a mask on the block queue might perhaps work as a model which avoids breaking stuff by suprise, with the device left at 32bit masking. Actually, you might be able to ... that's why I'm suggesting it. There are two pieces of information the arch layer needs to know: what is the dma_mask and where is the iommu/bridge/whatever. When we went to the generic dma_map_ API on parisc, we found you simply get the one from struct device and for the other you walk up the device tree until you find what you're looking for. I'm not suggesting we invent a dummy pci_device ... I'm suggesting we dma_map on the existing scsi_device, which is properly parented to the pci_device. The problem with this approach will be any architecture which blindly expects dma_map converts to pci_dma_map; however, I'm not sure we have any of those left. I've tried the dumb solution of setting the mask on the PCI device (for both ports) whenever an ATAPI device is detected, and ran into problems with that. If we really need to keep the block queue bounce limit and DMA mask the same, then we then have to set the bounce limit on both ports as well. If you blindly do that from slave_config, though, then you blow up since on the first port's initial slave_config the block queue for the second port isn't allocated yet, so you'd have to detect that case somehow. And if it's done via hotplug after the other port is already in use, it'll be changing the limits on a port that's in active use, which seems like it could be a bit racy. So, any ideas? Maybe using the separate struct device is the easiest solution, if it'll work.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
James Bottomley wrote: On Sun, 2008-01-13 at 16:29 +, Alan Cox wrote: Yes, I concur for the short term. The other two possible courses of action either involve long discussions (the different device one) or you'll never quite be sure you got all the paths (the GFP_DMA32 one). At least with this one, you know everything will work. The different device one is tricky because the PCI layer is involved in mapping on some systems so you can't just magic up a platform device for it. Putting a mask on the block queue might perhaps work as a model which avoids breaking stuff by suprise, with the device left at 32bit masking. Actually, you might be able to ... that's why I'm suggesting it. There are two pieces of information the arch layer needs to know: what is the dma_mask and where is the iommu/bridge/whatever. When we went to the generic dma_map_ API on parisc, we found you simply get the one from struct device and for the other you walk up the device tree until you find what you're looking for. I'm not suggesting we invent a dummy pci_device ... I'm suggesting we dma_map on the existing scsi_device, which is properly parented to the pci_device. The problem with this approach will be any architecture which blindly expects dma_map converts to pci_dma_map; however, I'm not sure we have any of those left. I've tried the dumb solution of setting the mask on the PCI device (for both ports) whenever an ATAPI device is detected, and ran into problems with that. If we really need to keep the block queue bounce limit and DMA mask the same, then we then have to set the bounce limit on both ports as well. If you blindly do that from slave_config, though, then you blow up since on the first port's initial slave_config the block queue for the second port isn't allocated yet, so you'd have to detect that case somehow. And if it's done via hotplug after the other port is already in use, it'll be changing the limits on a port that's in active use, which seems like it could be a bit racy. So, any ideas? Maybe using the separate struct device is the easiest solution, if it'll work.. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
On Mon, 2008-01-14 at 19:41 -0600, Robert Hancock wrote: James Bottomley wrote: On Sun, 2008-01-13 at 16:29 +, Alan Cox wrote: Yes, I concur for the short term. The other two possible courses of action either involve long discussions (the different device one) or you'll never quite be sure you got all the paths (the GFP_DMA32 one). At least with this one, you know everything will work. The different device one is tricky because the PCI layer is involved in mapping on some systems so you can't just magic up a platform device for it. Putting a mask on the block queue might perhaps work as a model which avoids breaking stuff by suprise, with the device left at 32bit masking. Actually, you might be able to ... that's why I'm suggesting it. There are two pieces of information the arch layer needs to know: what is the dma_mask and where is the iommu/bridge/whatever. When we went to the generic dma_map_ API on parisc, we found you simply get the one from struct device and for the other you walk up the device tree until you find what you're looking for. I'm not suggesting we invent a dummy pci_device ... I'm suggesting we dma_map on the existing scsi_device, which is properly parented to the pci_device. The problem with this approach will be any architecture which blindly expects dma_map converts to pci_dma_map; however, I'm not sure we have any of those left. I've tried the dumb solution of setting the mask on the PCI device (for both ports) whenever an ATAPI device is detected, and ran into problems with that. If we really need to keep the block queue bounce limit and DMA mask the same, then we then have to set the bounce limit on both ports as well. If you blindly do that from slave_config, though, then you blow up since on the first port's initial slave_config the block queue for the second port isn't allocated yet, so you'd have to detect that case somehow. And if it's done via hotplug after the other port is already in use, it'll be changing the limits on a port that's in active use, which seems like it could be a bit racy. So, any ideas? Maybe using the separate struct device is the easiest solution, if it'll work.. Right, and the separate struct device exists already in the scsi_device ... the problem currently is that this isn't the device we map with, but it could easily become so ... provided the architectures support it. This isn't a quick fix solution ... it will involve quite a bit of device use rethreading through both scsi and ata, so it might be wise to get linux-arch buy in first. James -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
On Sun, 2008-01-13 at 16:29 +, Alan Cox wrote: > > Yes, I concur for the short term. The other two possible courses of > > action either involve long discussions (the different device one) or > > you'll never quite be sure you got all the paths (the GFP_DMA32 one). > > At least with this one, you know everything will work. > > The different device one is tricky because the PCI layer is involved in > mapping on some systems so you can't just magic up a platform device for > it. Putting a mask on the block queue might perhaps work as a model > which avoids breaking stuff by suprise, with the device left at 32bit > masking. Actually, you might be able to ... that's why I'm suggesting it. There are two pieces of information the arch layer needs to know: what is the dma_mask and where is the iommu/bridge/whatever. When we went to the generic dma_map_ API on parisc, we found you simply get the one from struct device and for the other you walk up the device tree until you find what you're looking for. I'm not suggesting we invent a dummy pci_device ... I'm suggesting we dma_map on the existing scsi_device, which is properly parented to the pci_device. The problem with this approach will be any architecture which blindly expects dma_map converts to pci_dma_map; however, I'm not sure we have any of those left. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
> Yes, I concur for the short term. The other two possible courses of > action either involve long discussions (the different device one) or > you'll never quite be sure you got all the paths (the GFP_DMA32 one). > At least with this one, you know everything will work. The different device one is tricky because the PCI layer is involved in mapping on some systems so you can't just magic up a platform device for it. Putting a mask on the block queue might perhaps work as a model which avoids breaking stuff by suprise, with the device left at 32bit masking. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
On Sun, 2008-01-13 at 13:33 +, Alan Cox wrote: > > Other than that, I guess the solutions would be to just set a 32-bit > > mask on the device if either port has an ATAPI device connected (which > > is fairly ugly, considering that you could do things like hotplug an > > ATAPI device when the other port was in use, for example), or do > > something to prevent requests from reaching this point with >4GB > > addresses in the first place.. > > With 2.6.24 almost released I think that is a must do for the moment and > since we also have hotplugging fo devices it might be easier for .24 to > just set a 32bit DMA mask and be done with it, then fix it later. Yes, I concur for the short term. The other two possible courses of action either involve long discussions (the different device one) or you'll never quite be sure you got all the paths (the GFP_DMA32 one). At least with this one, you know everything will work. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
> Other than that, I guess the solutions would be to just set a 32-bit > mask on the device if either port has an ATAPI device connected (which > is fairly ugly, considering that you could do things like hotplug an > ATAPI device when the other port was in use, for example), or do > something to prevent requests from reaching this point with >4GB > addresses in the first place.. With 2.6.24 almost released I think that is a must do for the moment and since we also have hotplugging fo devices it might be easier for .24 to just set a 32bit DMA mask and be done with it, then fix it later. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
Other than that, I guess the solutions would be to just set a 32-bit mask on the device if either port has an ATAPI device connected (which is fairly ugly, considering that you could do things like hotplug an ATAPI device when the other port was in use, for example), or do something to prevent requests from reaching this point with 4GB addresses in the first place.. With 2.6.24 almost released I think that is a must do for the moment and since we also have hotplugging fo devices it might be easier for .24 to just set a 32bit DMA mask and be done with it, then fix it later. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
On Sun, 2008-01-13 at 13:33 +, Alan Cox wrote: Other than that, I guess the solutions would be to just set a 32-bit mask on the device if either port has an ATAPI device connected (which is fairly ugly, considering that you could do things like hotplug an ATAPI device when the other port was in use, for example), or do something to prevent requests from reaching this point with 4GB addresses in the first place.. With 2.6.24 almost released I think that is a must do for the moment and since we also have hotplugging fo devices it might be easier for .24 to just set a 32bit DMA mask and be done with it, then fix it later. Yes, I concur for the short term. The other two possible courses of action either involve long discussions (the different device one) or you'll never quite be sure you got all the paths (the GFP_DMA32 one). At least with this one, you know everything will work. James -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
Yes, I concur for the short term. The other two possible courses of action either involve long discussions (the different device one) or you'll never quite be sure you got all the paths (the GFP_DMA32 one). At least with this one, you know everything will work. The different device one is tricky because the PCI layer is involved in mapping on some systems so you can't just magic up a platform device for it. Putting a mask on the block queue might perhaps work as a model which avoids breaking stuff by suprise, with the device left at 32bit masking. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
On Sun, 2008-01-13 at 16:29 +, Alan Cox wrote: Yes, I concur for the short term. The other two possible courses of action either involve long discussions (the different device one) or you'll never quite be sure you got all the paths (the GFP_DMA32 one). At least with this one, you know everything will work. The different device one is tricky because the PCI layer is involved in mapping on some systems so you can't just magic up a platform device for it. Putting a mask on the block queue might perhaps work as a model which avoids breaking stuff by suprise, with the device left at 32bit masking. Actually, you might be able to ... that's why I'm suggesting it. There are two pieces of information the arch layer needs to know: what is the dma_mask and where is the iommu/bridge/whatever. When we went to the generic dma_map_ API on parisc, we found you simply get the one from struct device and for the other you walk up the device tree until you find what you're looking for. I'm not suggesting we invent a dummy pci_device ... I'm suggesting we dma_map on the existing scsi_device, which is properly parented to the pci_device. The problem with this approach will be any architecture which blindly expects dma_map converts to pci_dma_map; however, I'm not sure we have any of those left. James -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
On Sat, 2008-01-12 at 19:38 -0600, Robert Hancock wrote: > James Bottomley wrote: > > On Sat, 2008-01-12 at 17:04 -0600, Robert Hancock wrote: > >> I don't think the problem is that there's some buffer which is getting > >> allocated above 4GB and never bounced, since the problem goes away if > >> ADMA is disabled entirely and the DMA mask remains 32-bit always. My > >> guess is something is basing its decision on whether to bounce or not on > >> the device DMA mask. That can't possibly work properly for sata_nv since > >> the same PCI device has 2 ports, one of which can be in ADMA mode and > >> 64-bit capable and the other can be in legacy mode and only 32-bit capable. > > > > Erm, well, you can't decouple them. Having a differing blk queue bounce > > mask and device mask is going to cause huge trouble. The reason is this > > insidious nasty called swiotlb. Basically, with it enabled (and again, > > it can be on ia64 or x86_64), the kernel can bypass the bounce limit > > safe in the knowledge that swiotlb will fix up behind in the dma_map_ > > Unfortunately, if the device mask doesn't match the queue mask then > > swiotlb will never kick in and you'll end up with mapped pages beyond > > the 4GB limit. > > Yuck.. All the IOMMU DMA mapping code checks against the device DMA > mask, so it looks like if we get to the point of doing the DMA mapping > on >4GB addresses in libata we're screwed with this approach. > > The key problem is that both ata_ports share the same struct device with > one DMA mask which really doesn't match what this controller wants. I > wonder if we could do a different struct device for each port? > > Other than that, I guess the solutions would be to just set a 32-bit > mask on the device if either port has an ATAPI device connected (which > is fairly ugly, considering that you could do things like hotplug an > ATAPI device when the other port was in use, for example), or do > something to prevent requests from reaching this point with >4GB > addresses in the first place.. Well ... assuming this is the problem (and perhaps we'd better get the traces to confirm) there are at least three possible solutions: 1. As you say, just take the pci device mask down to 32 bits. 2. Find the problematic allocations and add GFP_DMA32 3. set the mask on the actual SCSI device rather than the PCI device and pass that into dma_map_ (this approach would have to get signoff from the arch people; I know it will work on parisc and x86 but I'm not sure about any other arch). > >> Tejun, I believe you had a patch that was printing warnings when libata > >> tried to program a legacy PRD with an address over 4GB. Could we change > >> that to WARN_ON and get someone experiencing this to try it and > >> see what the stack trace points to? > > > > Unfortunately, the stack trace probably won't help, since the command > > likely gets issued from the block request function, so the trace won't > > go back to the culpable initiator; that's why the command would be > > helpful. > > Well, dumping the ATA command surely isn't helpful, as I'm sure it will > be PACKET. I guess we'd have to dump out the actual CDB.. Sorry, when a SCSI person says dump the command, they mean the CDB. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
James Bottomley wrote: On Sat, 2008-01-12 at 17:04 -0600, Robert Hancock wrote: I don't think the problem is that there's some buffer which is getting allocated above 4GB and never bounced, since the problem goes away if ADMA is disabled entirely and the DMA mask remains 32-bit always. My guess is something is basing its decision on whether to bounce or not on the device DMA mask. That can't possibly work properly for sata_nv since the same PCI device has 2 ports, one of which can be in ADMA mode and 64-bit capable and the other can be in legacy mode and only 32-bit capable. Erm, well, you can't decouple them. Having a differing blk queue bounce mask and device mask is going to cause huge trouble. The reason is this insidious nasty called swiotlb. Basically, with it enabled (and again, it can be on ia64 or x86_64), the kernel can bypass the bounce limit safe in the knowledge that swiotlb will fix up behind in the dma_map_ Unfortunately, if the device mask doesn't match the queue mask then swiotlb will never kick in and you'll end up with mapped pages beyond the 4GB limit. Yuck.. All the IOMMU DMA mapping code checks against the device DMA mask, so it looks like if we get to the point of doing the DMA mapping on >4GB addresses in libata we're screwed with this approach. The key problem is that both ata_ports share the same struct device with one DMA mask which really doesn't match what this controller wants. I wonder if we could do a different struct device for each port? Other than that, I guess the solutions would be to just set a 32-bit mask on the device if either port has an ATAPI device connected (which is fairly ugly, considering that you could do things like hotplug an ATAPI device when the other port was in use, for example), or do something to prevent requests from reaching this point with >4GB addresses in the first place.. Tejun, I believe you had a patch that was printing warnings when libata tried to program a legacy PRD with an address over 4GB. Could we change that to WARN_ON and get someone experiencing this to try it and see what the stack trace points to? Unfortunately, the stack trace probably won't help, since the command likely gets issued from the block request function, so the trace won't go back to the culpable initiator; that's why the command would be helpful. Well, dumping the ATA command surely isn't helpful, as I'm sure it will be PACKET. I guess we'd have to dump out the actual CDB.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
On Sat, 2008-01-12 at 17:04 -0600, Robert Hancock wrote: > I don't think the problem is that there's some buffer which is getting > allocated above 4GB and never bounced, since the problem goes away if > ADMA is disabled entirely and the DMA mask remains 32-bit always. My > guess is something is basing its decision on whether to bounce or not on > the device DMA mask. That can't possibly work properly for sata_nv since > the same PCI device has 2 ports, one of which can be in ADMA mode and > 64-bit capable and the other can be in legacy mode and only 32-bit capable. Erm, well, you can't decouple them. Having a differing blk queue bounce mask and device mask is going to cause huge trouble. The reason is this insidious nasty called swiotlb. Basically, with it enabled (and again, it can be on ia64 or x86_64), the kernel can bypass the bounce limit safe in the knowledge that swiotlb will fix up behind in the dma_map_ Unfortunately, if the device mask doesn't match the queue mask then swiotlb will never kick in and you'll end up with mapped pages beyond the 4GB limit. > Tejun, I believe you had a patch that was printing warnings when libata > tried to program a legacy PRD with an address over 4GB. Could we change > that to WARN_ON and get someone experiencing this to try it and > see what the stack trace points to? Unfortunately, the stack trace probably won't help, since the command likely gets issued from the block request function, so the trace won't go back to the culpable initiator; that's why the command would be helpful. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
James Bottomley wrote: With mem<=4098M or sata_nv.adma=0 it still mounts and works ok. As I wrote, it would appear that somehow the blk_queue_bounce_limit setting that the driver has made is not being respected and the block layer is still trying to feed it addresses over 4GB. Any ideas anyone? Actually, I'd be very sceptical that the blk_queue_bounce_limit isn't working as advertised; there'd be a large number of failures if it were not. However, the "as advertised" part doesn't seem to be generally well understood. The point being that block commands are only bounced if they come from the filesystem or the user, not if they're generated directly inside the kernel. Since the fault occurs before mount, it's suggestive of the latter. A long time ago, GFP_KERNEL allocations meant that the memory allocated was physically under 4GB. Then x86_64 (and before it ia64) wanted to break this. So they introduced a new flag: GFP_DMA32 that behaved like the old GFP_KERNEL and then changed GFP_KERNEL on their architectures to return memory from anywhere. I'd strongly suggest some piece of kernel memory was allocated for a transfer buffer without GFP_DMA32 and then passed in to the driver. Unfortunately, that could be anywhere inside cdrom or sr. Knowing what the actual command is might help ... some of the distinctive MMC media ones only have a single source. Just to give some background on what sata_nv is trying to do: There are two sets of static DMA memory allocations that sata_nv does, the legacy ATA PRD and padding buffer which need to be in the lower 4GB, and the ADMA APRD and CPB areas which can be anywhere in 64-bit memory. With this patch, this is done by setting a 32-bit DMA mask before allocating the legacy areas and setting a 64-bit DMA mask before allocating the ADMA areas. Previously the driver just set a 64-bit mask before the legacy PRD got allocated so it could end up above 4GB, in which case legacy DMA couldn't possibly work. That part of the problem appears to be successfully fixed by the patch in question. There's a further problem with runtime DMA mapping, however. Normally when ADMA is enabled the controller can reach anywhere in 64-bit memory. However, if an ATAPI device is connected, since ADMA doesn't work with ATAPI commands we have to switch it off on that port and use legacy DMA, which is limited to 32-bit. This is where the blk_queue_bounce_limit call comes in, it's trying to make the block layer bounce requests above 4GB when legacy DMA is in use. I don't think the problem is that there's some buffer which is getting allocated above 4GB and never bounced, since the problem goes away if ADMA is disabled entirely and the DMA mask remains 32-bit always. My guess is something is basing its decision on whether to bounce or not on the device DMA mask. That can't possibly work properly for sata_nv since the same PCI device has 2 ports, one of which can be in ADMA mode and 64-bit capable and the other can be in legacy mode and only 32-bit capable. Tejun, I believe you had a patch that was printing warnings when libata tried to program a legacy PRD with an address over 4GB. Could we change that to WARN_ON and get someone experiencing this to try it and see what the stack trace points to? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
On Sat, 2008-01-12 at 13:25 -0600, Robert Hancock wrote: > Alexander wrote: > > Robert Hancock wrote: > >> There's this patch which was intended to fix it: > >> > >> http://lkml.org/lkml/2007/11/22/148 > > > > I applied this patch to 2.6.24-rc7. Now at boot time my DVD-RW is > > normaly detected as: > > > > sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray > > > > But I cannot mount it. All my attempts failed with > > > > ISOFS: Unable to identify CD-ROM format. > > > > With mem<=4098M or sata_nv.adma=0 it still mounts and works ok. > > As I wrote, it would appear that somehow the blk_queue_bounce_limit > setting that the driver has made is not being respected and the block > layer is still trying to feed it addresses over 4GB. Any ideas anyone? Actually, I'd be very sceptical that the blk_queue_bounce_limit isn't working as advertised; there'd be a large number of failures if it were not. However, the "as advertised" part doesn't seem to be generally well understood. The point being that block commands are only bounced if they come from the filesystem or the user, not if they're generated directly inside the kernel. Since the fault occurs before mount, it's suggestive of the latter. A long time ago, GFP_KERNEL allocations meant that the memory allocated was physically under 4GB. Then x86_64 (and before it ia64) wanted to break this. So they introduced a new flag: GFP_DMA32 that behaved like the old GFP_KERNEL and then changed GFP_KERNEL on their architectures to return memory from anywhere. I'd strongly suggest some piece of kernel memory was allocated for a transfer buffer without GFP_DMA32 and then passed in to the driver. Unfortunately, that could be anywhere inside cdrom or sr. Knowing what the actual command is might help ... some of the distinctive MMC media ones only have a single source. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
Alexander wrote: Robert Hancock wrote: There's this patch which was intended to fix it: http://lkml.org/lkml/2007/11/22/148 I applied this patch to 2.6.24-rc7. Now at boot time my DVD-RW is normaly detected as: sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray But I cannot mount it. All my attempts failed with ISOFS: Unable to identify CD-ROM format. With mem<=4098M or sata_nv.adma=0 it still mounts and works ok. As I wrote, it would appear that somehow the blk_queue_bounce_limit setting that the driver has made is not being respected and the block layer is still trying to feed it addresses over 4GB. Any ideas anyone? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
Robert Hancock wrote: > There's this patch which was intended to fix it: > > http://lkml.org/lkml/2007/11/22/148 I applied this patch to 2.6.24-rc7. Now at boot time my DVD-RW is normaly detected as: sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray But I cannot mount it. All my attempts failed with ISOFS: Unable to identify CD-ROM format. With mem<=4098M or sata_nv.adma=0 it still mounts and works ok. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
Robert Hancock wrote: There's this patch which was intended to fix it: http://lkml.org/lkml/2007/11/22/148 I applied this patch to 2.6.24-rc7. Now at boot time my DVD-RW is normaly detected as: sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray But I cannot mount it. All my attempts failed with ISOFS: Unable to identify CD-ROM format. With mem=4098M or sata_nv.adma=0 it still mounts and works ok. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
Alexander wrote: Robert Hancock wrote: There's this patch which was intended to fix it: http://lkml.org/lkml/2007/11/22/148 I applied this patch to 2.6.24-rc7. Now at boot time my DVD-RW is normaly detected as: sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray But I cannot mount it. All my attempts failed with ISOFS: Unable to identify CD-ROM format. With mem=4098M or sata_nv.adma=0 it still mounts and works ok. As I wrote, it would appear that somehow the blk_queue_bounce_limit setting that the driver has made is not being respected and the block layer is still trying to feed it addresses over 4GB. Any ideas anyone? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
On Sat, 2008-01-12 at 13:25 -0600, Robert Hancock wrote: Alexander wrote: Robert Hancock wrote: There's this patch which was intended to fix it: http://lkml.org/lkml/2007/11/22/148 I applied this patch to 2.6.24-rc7. Now at boot time my DVD-RW is normaly detected as: sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray But I cannot mount it. All my attempts failed with ISOFS: Unable to identify CD-ROM format. With mem=4098M or sata_nv.adma=0 it still mounts and works ok. As I wrote, it would appear that somehow the blk_queue_bounce_limit setting that the driver has made is not being respected and the block layer is still trying to feed it addresses over 4GB. Any ideas anyone? Actually, I'd be very sceptical that the blk_queue_bounce_limit isn't working as advertised; there'd be a large number of failures if it were not. However, the as advertised part doesn't seem to be generally well understood. The point being that block commands are only bounced if they come from the filesystem or the user, not if they're generated directly inside the kernel. Since the fault occurs before mount, it's suggestive of the latter. A long time ago, GFP_KERNEL allocations meant that the memory allocated was physically under 4GB. Then x86_64 (and before it ia64) wanted to break this. So they introduced a new flag: GFP_DMA32 that behaved like the old GFP_KERNEL and then changed GFP_KERNEL on their architectures to return memory from anywhere. I'd strongly suggest some piece of kernel memory was allocated for a transfer buffer without GFP_DMA32 and then passed in to the driver. Unfortunately, that could be anywhere inside cdrom or sr. Knowing what the actual command is might help ... some of the distinctive MMC media ones only have a single source. James -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
James Bottomley wrote: With mem=4098M or sata_nv.adma=0 it still mounts and works ok. As I wrote, it would appear that somehow the blk_queue_bounce_limit setting that the driver has made is not being respected and the block layer is still trying to feed it addresses over 4GB. Any ideas anyone? Actually, I'd be very sceptical that the blk_queue_bounce_limit isn't working as advertised; there'd be a large number of failures if it were not. However, the as advertised part doesn't seem to be generally well understood. The point being that block commands are only bounced if they come from the filesystem or the user, not if they're generated directly inside the kernel. Since the fault occurs before mount, it's suggestive of the latter. A long time ago, GFP_KERNEL allocations meant that the memory allocated was physically under 4GB. Then x86_64 (and before it ia64) wanted to break this. So they introduced a new flag: GFP_DMA32 that behaved like the old GFP_KERNEL and then changed GFP_KERNEL on their architectures to return memory from anywhere. I'd strongly suggest some piece of kernel memory was allocated for a transfer buffer without GFP_DMA32 and then passed in to the driver. Unfortunately, that could be anywhere inside cdrom or sr. Knowing what the actual command is might help ... some of the distinctive MMC media ones only have a single source. Just to give some background on what sata_nv is trying to do: There are two sets of static DMA memory allocations that sata_nv does, the legacy ATA PRD and padding buffer which need to be in the lower 4GB, and the ADMA APRD and CPB areas which can be anywhere in 64-bit memory. With this patch, this is done by setting a 32-bit DMA mask before allocating the legacy areas and setting a 64-bit DMA mask before allocating the ADMA areas. Previously the driver just set a 64-bit mask before the legacy PRD got allocated so it could end up above 4GB, in which case legacy DMA couldn't possibly work. That part of the problem appears to be successfully fixed by the patch in question. There's a further problem with runtime DMA mapping, however. Normally when ADMA is enabled the controller can reach anywhere in 64-bit memory. However, if an ATAPI device is connected, since ADMA doesn't work with ATAPI commands we have to switch it off on that port and use legacy DMA, which is limited to 32-bit. This is where the blk_queue_bounce_limit call comes in, it's trying to make the block layer bounce requests above 4GB when legacy DMA is in use. I don't think the problem is that there's some buffer which is getting allocated above 4GB and never bounced, since the problem goes away if ADMA is disabled entirely and the DMA mask remains 32-bit always. My guess is something is basing its decision on whether to bounce or not on the device DMA mask. That can't possibly work properly for sata_nv since the same PCI device has 2 ports, one of which can be in ADMA mode and 64-bit capable and the other can be in legacy mode and only 32-bit capable. Tejun, I believe you had a patch that was printing warnings when libata tried to program a legacy PRD with an address over 4GB. Could we change that to WARN_ON and get someone experiencing this to try it and see what the stack trace points to? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
On Sat, 2008-01-12 at 17:04 -0600, Robert Hancock wrote: I don't think the problem is that there's some buffer which is getting allocated above 4GB and never bounced, since the problem goes away if ADMA is disabled entirely and the DMA mask remains 32-bit always. My guess is something is basing its decision on whether to bounce or not on the device DMA mask. That can't possibly work properly for sata_nv since the same PCI device has 2 ports, one of which can be in ADMA mode and 64-bit capable and the other can be in legacy mode and only 32-bit capable. Erm, well, you can't decouple them. Having a differing blk queue bounce mask and device mask is going to cause huge trouble. The reason is this insidious nasty called swiotlb. Basically, with it enabled (and again, it can be on ia64 or x86_64), the kernel can bypass the bounce limit safe in the knowledge that swiotlb will fix up behind in the dma_map_ Unfortunately, if the device mask doesn't match the queue mask then swiotlb will never kick in and you'll end up with mapped pages beyond the 4GB limit. Tejun, I believe you had a patch that was printing warnings when libata tried to program a legacy PRD with an address over 4GB. Could we change that to WARN_ON and get someone experiencing this to try it and see what the stack trace points to? Unfortunately, the stack trace probably won't help, since the command likely gets issued from the block request function, so the trace won't go back to the culpable initiator; that's why the command would be helpful. James -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
James Bottomley wrote: On Sat, 2008-01-12 at 17:04 -0600, Robert Hancock wrote: I don't think the problem is that there's some buffer which is getting allocated above 4GB and never bounced, since the problem goes away if ADMA is disabled entirely and the DMA mask remains 32-bit always. My guess is something is basing its decision on whether to bounce or not on the device DMA mask. That can't possibly work properly for sata_nv since the same PCI device has 2 ports, one of which can be in ADMA mode and 64-bit capable and the other can be in legacy mode and only 32-bit capable. Erm, well, you can't decouple them. Having a differing blk queue bounce mask and device mask is going to cause huge trouble. The reason is this insidious nasty called swiotlb. Basically, with it enabled (and again, it can be on ia64 or x86_64), the kernel can bypass the bounce limit safe in the knowledge that swiotlb will fix up behind in the dma_map_ Unfortunately, if the device mask doesn't match the queue mask then swiotlb will never kick in and you'll end up with mapped pages beyond the 4GB limit. Yuck.. All the IOMMU DMA mapping code checks against the device DMA mask, so it looks like if we get to the point of doing the DMA mapping on 4GB addresses in libata we're screwed with this approach. The key problem is that both ata_ports share the same struct device with one DMA mask which really doesn't match what this controller wants. I wonder if we could do a different struct device for each port? Other than that, I guess the solutions would be to just set a 32-bit mask on the device if either port has an ATAPI device connected (which is fairly ugly, considering that you could do things like hotplug an ATAPI device when the other port was in use, for example), or do something to prevent requests from reaching this point with 4GB addresses in the first place.. Tejun, I believe you had a patch that was printing warnings when libata tried to program a legacy PRD with an address over 4GB. Could we change that to WARN_ON and get someone experiencing this to try it and see what the stack trace points to? Unfortunately, the stack trace probably won't help, since the command likely gets issued from the block request function, so the trace won't go back to the culpable initiator; that's why the command would be helpful. Well, dumping the ATA command surely isn't helpful, as I'm sure it will be PACKET. I guess we'd have to dump out the actual CDB.. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
On Sat, 2008-01-12 at 19:38 -0600, Robert Hancock wrote: James Bottomley wrote: On Sat, 2008-01-12 at 17:04 -0600, Robert Hancock wrote: I don't think the problem is that there's some buffer which is getting allocated above 4GB and never bounced, since the problem goes away if ADMA is disabled entirely and the DMA mask remains 32-bit always. My guess is something is basing its decision on whether to bounce or not on the device DMA mask. That can't possibly work properly for sata_nv since the same PCI device has 2 ports, one of which can be in ADMA mode and 64-bit capable and the other can be in legacy mode and only 32-bit capable. Erm, well, you can't decouple them. Having a differing blk queue bounce mask and device mask is going to cause huge trouble. The reason is this insidious nasty called swiotlb. Basically, with it enabled (and again, it can be on ia64 or x86_64), the kernel can bypass the bounce limit safe in the knowledge that swiotlb will fix up behind in the dma_map_ Unfortunately, if the device mask doesn't match the queue mask then swiotlb will never kick in and you'll end up with mapped pages beyond the 4GB limit. Yuck.. All the IOMMU DMA mapping code checks against the device DMA mask, so it looks like if we get to the point of doing the DMA mapping on 4GB addresses in libata we're screwed with this approach. The key problem is that both ata_ports share the same struct device with one DMA mask which really doesn't match what this controller wants. I wonder if we could do a different struct device for each port? Other than that, I guess the solutions would be to just set a 32-bit mask on the device if either port has an ATAPI device connected (which is fairly ugly, considering that you could do things like hotplug an ATAPI device when the other port was in use, for example), or do something to prevent requests from reaching this point with 4GB addresses in the first place.. Well ... assuming this is the problem (and perhaps we'd better get the traces to confirm) there are at least three possible solutions: 1. As you say, just take the pci device mask down to 32 bits. 2. Find the problematic allocations and add GFP_DMA32 3. set the mask on the actual SCSI device rather than the PCI device and pass that into dma_map_ (this approach would have to get signoff from the arch people; I know it will work on parisc and x86 but I'm not sure about any other arch). Tejun, I believe you had a patch that was printing warnings when libata tried to program a legacy PRD with an address over 4GB. Could we change that to WARN_ON and get someone experiencing this to try it and see what the stack trace points to? Unfortunately, the stack trace probably won't help, since the command likely gets issued from the block request function, so the trace won't go back to the culpable initiator; that's why the command would be helpful. Well, dumping the ATA command surely isn't helpful, as I'm sure it will be PACKET. I guess we'd have to dump out the actual CDB.. Sorry, when a SCSI person says dump the command, they mean the CDB. James -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
Alexander wrote: Hello! The problem described at https://bugzilla.redhat.com/show_bug.cgi?id=351451 and at http://ubuntuforums.org/showthread.php?t=655772 and supposedly fixed by the patch http://kerneltrap.org/mailarchive/linux-kernel/2007/11/25/445094 is still there. I have compiled 2.6.24-rc7 kernel and booted my PC with it just to find out that my SATA DVD-RW is There's this patch which was intended to fix it: http://lkml.org/lkml/2007/11/22/148 which hasn't been merged yet. I see now that there was some further discussion from someone saying that didn't fix the problem for them, which I wasn't CCed on.. It looks like in their case, libata is receiving SGs with DMA addresses above 4GB even though the block layer bounce limit is set to 32-bit. That's the mechanism that sata_nv depends on to ensure that it gets proper addresses when accessing ATAPI devices where it is limited to 32-bit DMA.. Could that be breaking or insufficient somehow? -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM
Alexander wrote: Hello! The problem described at https://bugzilla.redhat.com/show_bug.cgi?id=351451 and at http://ubuntuforums.org/showthread.php?t=655772 and supposedly fixed by the patch http://kerneltrap.org/mailarchive/linux-kernel/2007/11/25/445094 is still there. I have compiled 2.6.24-rc7 kernel and booted my PC with it just to find out that my SATA DVD-RW is There's this patch which was intended to fix it: http://lkml.org/lkml/2007/11/22/148 which hasn't been merged yet. I see now that there was some further discussion from someone saying that didn't fix the problem for them, which I wasn't CCed on.. It looks like in their case, libata is receiving SGs with DMA addresses above 4GB even though the block layer bounce limit is set to 32-bit. That's the mechanism that sata_nv depends on to ensure that it gets proper addresses when accessing ATAPI devices where it is limited to 32-bit DMA.. Could that be breaking or insufficient somehow? -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
