Hannes,
I am getting this panic with an Adaptec AHA-2740/2742 controller on
the 5.0.5 kernel (and earlier). I can gladly apply any proposed
patches and test.
- Matthew
[5.813519] eisa 00:00: EISA: Mainboard INT3089 detected
[5.820624] eisa 00:03: EISA: slot 3: ADP7771 detected
[5.83
On Wed, Apr 17, 2019 at 2:35 AM Christoph Hellwig wrote:
>
> On Tue, Apr 16, 2019 at 02:56:36PM -0400, tedheadster wrote:
> > Hannes,
> > I am getting this panic with an Adaptec AHA-2740/2742 controller on
> > the 5.0.5 kernel (and earlier). I can gladly apply any propo
On Sat, Oct 13, 2018 at 11:26 AM tedheadster wrote:
>
> > it seems like we do for some reason never actually enable swiotlb
> > for 32-bit x86. Before my commit the block bounce buffering papered
> > over that for networking, Please try this patch:
> >
> >
On Thu, Apr 18, 2019 at 12:16 PM Christoph Hellwig wrote:
>
> On Wed, Apr 17, 2019 at 02:05:29PM -0400, tedheadster wrote:
> > > Christoph,
> > > your patch fixed it nicely. No more error messages when I boot with
> > > 16GiB enabled on a 32-bit PAE-enabled sys
Christoph,
On the same hardware (reboot with different kernel) I am getting
_horrible_ disk I/O performance on the 5.1.1. kernel compiled on a
32-bit platform using HIGHMEM64G (PAE) to access 32GiB of physical
memory.
The numbers are truly terrible to copy a 16GiB file from one disk to a
differe
On Mon, May 13, 2019 at 3:02 AM Christoph Hellwig wrote:
>
> On Sun, May 12, 2019 at 02:55:48PM -0400, tedheadster wrote:
> > Christoph,
> > On the same hardware (reboot with different kernel) I am getting
> > _horrible_ disk I/O performance on the 5.1.1. kernel
On Mon, May 13, 2019 at 8:29 AM Christoph Hellwig wrote:
>
> On Mon, May 13, 2019 at 08:20:03AM -0400, tedheadster wrote:
> > On Mon, May 13, 2019 at 3:02 AM Christoph Hellwig
> > wrote:
> > >
> > > On Sun, May 12, 2019 at 02:55:48PM -0400, tedheadster wrote:
On Thu, May 16, 2019 at 2:58 AM Christoph Hellwig wrote:
>
> Can you still send me the dmesg output with the AHCI debug patch?
> I'm curious why we can't do 64-bit DMA to your device.
Christoph,
here is the dmesg output with your patch. 64-bit mode is not enabled.
ahci :00:11.4: version 3.
> That isn't a limit, just a reporting clause - the real check is this
> line a little above:
>
> if (unlikely(dev && !dma_capable(dev, dma_addr, size))) {
>
> which is purely based on the dma mask. So for some reason we must
> be in 32-bit only mode for the dma-mask, and not actually enab
Christoph,
here is all of the newly patched dmesg output. I also added
'aic7xxx.a9c7xxx=verbose' for extra information.
Matthew
[0.00] Linux version 4.18.12.pentium4-xeon-christoph+
(root@pentium4) (gcc version 5.4.0 (Gentoo 5.4.0-r4 p1.8, pie-0.6.5))
#525 SMP PREEMPT Sat Oct 13 09:49:3
> it seems like we do for some reason never actually enable swiotlb
> for 32-bit x86. Before my commit the block bounce buffering papered
> over that for networking, Please try this patch:
>
> diff --git a/arch/x86/kernel/pci-swiotlb.c b/arch/x86/kernel/pci-swiotlb.c
> index 661583662430..71c0b01
Hannes,
I'm getting the following error in a custom configured 4.18 32-bit
x86 kernel supporting PAE, with 16GiB physical memory. It loops
infinitely on the error.
aic7xxx :00:03.0: dma_direct_map_sg: overflow
0x0003ff80+65536 of device mask
I have tried enabling the follow
Christoph,
I was able to bisect this to your patch "scsi: reduce use of block
bounce buffers". I am getting the error on a 32-bit Dell PowerEdge
6650. It has the aic7xxx integrated onto the motherboard.
Again, here is the error:
aic7xxx :00:03.0: dma_direct_map_sg: overflow
0x0003ff8000
13 matches
Mail list logo
