Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > gnu.hurd.bug > #12026

Re: PCI arbiter crash on last qemu image

Show all headers | View raw

El 16/8/20 a les 4:46, Damien Zammit ha escrit:
> Hi there,
> 
> On 15/8/20 9:49 pm, Joan Lledó wrote
>> I downloaded and tried the last qemu image "debian-hurd-20200731.img".
>> When I try to read the memory mapped content of region files in the
>> arbiter, it crashes and shows the message "Real-time signal 0".
> 
> I am also getting this on my latest hurd system that I have been working on.
> 
> I ran gdb on pci-arbiter pid, put breakpoints on S_pci_conf_read and S_pci_dev_get_regions
> but seemed to have no effect, and when I continue and then run the hexdump,
> I get no useful backtrace, could it be a recursion problem with stack overflow?
> 
> Thread 1 received signal ?, Unknown signal.
> memcpy () at ../sysdeps/i386/i686/memcpy.S:71
> 71      ../sysdeps/i386/i686/memcpy.S: No such file or directory.
> (gdb) bt
> #0  memcpy () at ../sysdeps/i386/i686/memcpy.S:71
> #1  0x08059588 in ?? ()
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> 
> Any ideas?
> 
> Damien
> 

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?

-------------------
[1]
http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/pci-arbiter/func_files.c#n201
[2]
https://gitlab.freedesktop.org/xorg/lib/libpciaccess/-/blob/master/src/x86_pci.c#L601

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

Thread

Re: PCI arbiter crash on last qemu image Joan Lledó <jlledom@mailfence.com> - 2020-08-16 17:04 +0200

csiph-web