[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PCI arbiter crash on last qemu image
From: |
Samuel Thibault |
Subject: |
Re: PCI arbiter crash on last qemu image |
Date: |
Thu, 10 Sep 2020 00:29:30 +0200 |
User-agent: |
NeoMutt/20170609 (1.8.3) |
Samuel Thibault, le mer. 09 sept. 2020 23:45:48 +0200, a ecrit:
> Damien Zammit, le lun. 07 sept. 2020 11:16:13 +1000, a ecrit:
> > On 6/9/20 11:17 pm, Samuel Thibault wrote:
> > > One issue remains, however: Xorg's vesa driver produces
> > >
> > > [1669282.478] (II) VESA(0): initializing int10
> > > [1669282.478] (EE) VESA(0): Cannot read int vect
> > >
> > > which comes from hw/xfree86/int10/generic.c xf86ExtendedInitInt10:
> > >
> > > if (!sysMem)
> > > pci_device_map_legacy(pInt->dev, V_BIOS, BIOS_SIZE + SYS_BIOS -
> > > V_BIOS,
> > > PCI_DEV_MAP_FLAG_WRITABLE, &sysMem);
> >
> > It appears that it's trying to map more than BIOS_SIZE, which probably
> > fails under the current scheme.
> > Perhaps we need to make overreads return zeroes instead of failure?
>
> No, that part of the code works fine.
>
> Looking closer, I noticed that in
>
> if (!readIntVec(pInt->dev, base, LOW_PAGE_SIZE)) {
>
> LOW_PAGE_SIZE is 0x600, that's what is passed as len in
>
> if (pci_device_map_legacy(dev, 0, len, 0, &map))
>
> So I guess that the problem is that gnu's version of map_dev_mem is
> missing rounding up the len like mmap does.
That was not the only error, also a bogus anywhere parameter in vm_map
call, and bogus size parameter in device_map call. Now fixed in
libpciaccess 0.16-1+hurd.6 and upstream.
Samuel