bug-hurd
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]