Bug 110931
| Summary: | parport cannot get buffer for DMA | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Mark (mark_k) |
| Component: | Parallel | Assignee: | drivers_parallel |
| Status: | NEW --- | ||
| Severity: | normal | CC: | bp, joro, mark_k, sudipm.mukherjee, szg00000 |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 4.4.0-040400-generic | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
patch
lspci -vvv lspci -n -vvv |
||
|
Description
Mark
2016-01-17 15:04:26 UTC
Based on installing various 4.4-rcX kernels, it seems this problem appeared at some point between 4.4-rc7 and 4.4-rc8. Created attachment 200441 [details] patch There was no change in parport between v4.3 and v4.4. But there were some other changes, you can find them at https://lkml.org/lkml/2015/6/8/76 I do not know anything about swiotlb.c but just for testing, can you please try the attached patch and see if the problem is solved. It will apply on v4.4.0 regards sudip I applied your patch but it didn't fix the problem. I guess "Parallel" isn't actually the most relevant bugzilla component for this issue, but I'm not sure what is. Maybe someone could add Joerg Roedel to the cc list since his changes were given in the lkml post you linked to? A couple of points only:
If you mean this patch:
186dfc9d69b9 ("x86/swiotlb: Try coherent allocations with __GFP_NOWARN")
it went in in 4.2 and so it was already in 4.3. So I'm sceptical is the
it culprit.
Looking at the code, we're in here:
/* Confirm address can be DMA'd by device */
if (dev_addr + size - 1 > dma_mask) {
printk("hwdev DMA mask = 0x%016Lx, dev_addr = 0x%016Lx\n",
(unsigned long long)dma_mask,
(unsigned long long)dev_addr);
/* DMA_TO_DEVICE to avoid memcpy in unmap_single */
swiotlb_tbl_unmap_single(hwdev, paddr,
size, DMA_TO_DEVICE);
goto err_warn;
}
and dev_addr overshot the DMA mask, so we can't DMA to that device. We
agot that ddress from map_single() ... I'll let Joerg decipher this
afurther.
The only suggestion I would have is to bisect this, if you can reproduce
it reliably and if you're sure it started appearing between 4.3 and 4.4.
Mark, feel free to ask if anything is not clear on how to bisect.
HTH.
(In reply to Mark from comment #0) > [ 1.912394] hwdev DMA mask = 0x0000000000ffffff, dev_addr = > 0x00000000dbe5b000 The dma-mask indicates that the device can only access the first 16MB of memory (24bit DMA mask). But the swiotlb aperture is somewhere above this address, so the code has no chance to allocate something that fits into the mask. My guess is that the mask is wrong and a patch changed it from an 32 bit into a 24 bit mask, breaking parport for you. Bisecting will show which patch is was. Can you please also upload the output of 'lspci -vvv' and 'lspci -n -vvv'? Thanks, Joerg The (In reply to Joerg Roedel from comment #5) > (In reply to Mark from comment #0) > > > [ 1.912394] hwdev DMA mask = 0x0000000000ffffff, dev_addr = > > 0x00000000dbe5b000 > > The dma-mask indicates that the device can only access the first 16MB of > memory (24bit DMA mask). But the swiotlb aperture is somewhere above this > address, so the code has no chance to allocate something that fits into the > mask. > > My guess is that the mask is wrong and a patch changed it from an 32 bit > into a 24 bit mask. The mask has always been 24 bit. Introduced with dfa7c4d869b7 ("parport_pc: set properly the dma_mask for parport_pc device") regards sudip (In reply to Sudip from comment #6) > The mask has always been 24 bit. Introduced with dfa7c4d869b7 ("parport_pc: > set properly the dma_mask for parport_pc device") Okay, then we need the bisect result to find out what broke it. I wonder... could it be that a change between 4.4-rc7 and 4.4-rc8 introduced the "coherent allocation failed..." diagnostic message, but that the allocation just failed silently on 4.4-rc7 and earlier kernels??? [However, wouldn't the message "parport0: cannot get buffer for DMA, resorting to PIO operation" have been printed on 4.4-rc7 & earlier too, if the allocation did fail there?] Anyway, I can try bisecting. Any suggestions as to the earliest kernel to cover in the bisection? Created attachment 200571 [details]
lspci -vvv
Created attachment 200581 [details]
lspci -n -vvv
(In reply to Mark from comment #8) > [However, wouldn't the message "parport0: cannot get buffer for DMA, > resorting to PIO operation" have been printed on 4.4-rc7 & earlier too, if > the allocation did fail there?] Looks like it, parport_pc_probe_port() which issues that warning hasn't been changed around that timeframe. So you either get the DMA buffer and no message at all or no DMA buffer but message gets printed. > Anyway, I can try bisecting. Any suggestions as to the earliest kernel to > cover in the bisection? What I'd do is try 4.3 and if the message doesn't appear, try all the -rc's since then: 4.4-rc1, 4.4-rc2, ... and see where it appears. If it really appears between -rc7 and -rc8, then the bisection would be a lot less work. Thanks. I think I have found the cause of this problem. It's probably down to a change in the Ubuntu kernel configs, not a kernel bug after all. $ diff config-4.4.0-040400rc7-generic config-4.4.0-040400rc8-generic ... 393c393 < CONFIG_ZONE_DMA=y --- > # CONFIG_ZONE_DMA is not set 517,518c517 < CONFIG_ZONE_DMA_FLAG=1 < CONFIG_BOUNCE=y --- > CONFIG_ZONE_DMA_FLAG=0 545a545 > CONFIG_ZONE_DEVICE=y ... Googling CONFIG_ZONE_DMA gave: "DMA memory allocation support allows devices with less than 32-bit addressing to allocate within the first 16MB of address space. Disable if no such devices will be used." So I'll file a bug with Ubuntu, and this bug should be marked as invalid. Launchpad.net bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1536813 So how did that config-4.4.0-040400rc8-generic get created even? CONFIG_ZONE_DMA is enabled by default so why is it off in that rc8 config? (In reply to Mark from comment #12) > < CONFIG_ZONE_DMA=y > --- > > # CONFIG_ZONE_DMA is not set That makes sense as the root cause. ZONE_DMA on x86 includes the first 16MB of physical memory. It is used to allocate memory which is guaranteed below 16MB, and if it is disabled your allocated memory could be above 16MB and trigger the warning in the parport code. This looks similar to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1534647 Aha, there it is: 033fbae988fc ("mm: ZONE_DEVICE for "device memory"")
which is pmem. And I can imagine why ubuntu enable it and I can also
imagine other distros wanting to enable support for pmem too.
We probably should have a discussion upstream whether enabling
CONFIG_ZONE_DEVICE and breaking devices which need ZONE_DMA allocations
is fine.
Sudip, if you CC everyone from the bug and the commit above and lkml, it
would probably be a good start for figuring out this.
Thanks.
Parallel ports are probably the most common affected device. 2016-model Dell laptops (still) have a dock port so can use native parallel & serial ports. Maybe the situation with HP & Lenovo machines is similar? And there are (probably) current desktop motherboards with parallel port. Apart from that though, perhaps no ZONE_DMA means ISA sound & SCSI cards break. [There are a few current-model motherboards with an ISA slot, though I'm guessing most are used for legacy applications.] I guess PCMCIA devices (including passive CompactFlash-to-PCMCIA adapters) could be impacted too? |