Re: PCI arbiter crash on last qemu image

From	Damien Zammit <damien@zamaudio.com>
Newsgroups	gnu.hurd.bug
Subject	Re: PCI arbiter crash on last qemu image
Date	2020-08-17 09:51 +1000
Message-ID	<mailman.2373.1597621896.2739.bug-hurd@gnu.org> (permalink)
References	<78d17df2-64dd-692e-4151-ad14e25a97d6@mailfence.com> <2f03cf83-9dff-1b92-a6e0-96ae20bfda49@zamaudio.com> <e3d57b71-af84-c035-7799-0c4dc6bfdae4@mailfence.com> <c5ae2597-dd25-58f6-8aa2-18b60b91fe5f@zamaudio.com>

Show all headers | View raw

Hi there,

On 17/8/20 1:04 am, Joan Lledó wrote:
> I found the same issue, investigating a bit more I found that in
> func_files.c:201[1], the value of region->memory is 0x0, so reading from
> there raises a segfault. That pointer should be filled in libpciacces,
> at x86_pci.c:601[2] during the startup, but for some reason it seems it
> doesn't. Regrettably I don't have the time to go further right know.
> 
> Could it be some issue with /dev/mem?

It's probably due to this patch:

https://gitlab.freedesktop.org/xorg/lib/libpciaccess/-/merge_requests/12/diffs?commit_id=952f4553f91da3f3eb8615a8d53a6da7f7bc0080

(We are not using master of pciaccess).

I removed the mapping and set it to NULL because there was a bug that caused
the initial mapping within "probe" to prevent further mappings of the same region later on.

Perhaps a better way to fix the mapping problem I encountered
is by removing the check for previous mappings when trying to map regions,
but no one commented on my PR upstream (yet).

Damien

Back to gnu.hurd.bug | Previous | Next | Find similar

Thread

Re: PCI arbiter crash on last qemu image Damien Zammit <damien@zamaudio.com> - 2020-08-17 09:51 +1000

csiph-web