Re: gnumach 1.7 issue
Richard Braun, on Tue 07 Jun 2016 15:48:32 +0200, wrote: > On Sat, Jun 04, 2016 at 05:08:34PM +0100, James Clarke wrote: > > Reverting 1db202e indeed fixes it. I also rebuilt the same source tree with > > the patch commented out in d/p/series just to be sure there wasn’t a > > toolchain issue, and that build *doesn’t* work, so 1db202e is either buggy > > or exposing other bugs. > > I've just pushed c89365 which fixes the issue. Cool :) It's now uploaded to Debian. Samuel
Re: gnumach 1.7 issue
On Sat, Jun 04, 2016 at 05:08:34PM +0100, James Clarke wrote: > Reverting 1db202e indeed fixes it. I also rebuilt the same source tree with > the patch commented out in d/p/series just to be sure there wasn’t a > toolchain issue, and that build *doesn’t* work, so 1db202e is either buggy > or exposing other bugs. I've just pushed c89365 which fixes the issue. -- Richard Braun
Re: gnumach 1.7 issue
Adam Richards, on Sun 05 Jun 2016 11:35:17 +0100, wrote: > However, in my case I was not running X. > The issue was with hurd-console > Both mouse and keyboard queues would fill up and the system would freeze. That's the same driver :) Samuel
Re: gnumach 1.7 issue
On 4 June 2016 at 17:08, James Clarke wrote: > > Reverting 1db202e indeed fixes it. I also rebuilt the same source tree with > the patch commented out in d/p/series just to be sure there wasn’t a > toolchain issue, and that build *doesn’t* work, so 1db202e is either buggy > or exposing other bugs. > > Thanks Samuel and James. This fixed it for me also. However, in my case I was not running X. The issue was with hurd-console Both mouse and keyboard queues would fill up and the system would freeze. Cheers, adam
Re: gnumach 1.7 issue
> On 4 Jun 2016, at 15:04, James Clarke wrote: > >> On 3 Jun 2016, at 19:36, Samuel Thibault wrote: >> >> Samuel Thibault, on Fri 03 Jun 2016 20:35:13 +0200, wrote: >>> Adam Richards, on Fri 03 Jun 2016 19:30:40 +0100, wrote: On rebooting and reverting to gnumach-1.6-486.gz this is not an issue. >>> >>> It could be worth bisecting the issue on the upstream git repository. >> >> (there are really not much difference between the last 1.6 snapshot >> 2:1.6+git20160502-1 and the 1.7 snapshot 2:1.7+git20160522-1) > > 1.7 seems to break running Xorg for me (running latest MATE). I can’t > move the mouse, opening htop via ssh hangs at a black screen, and then > subsequent ssh attempts can’t connect, so I have to perform a hard > reboot. If I don’t send *any* mouse events, htop loads, but locks up > as soon as I move the mouse. MATE’s clock does continue to update every > second, so some things still work. Booting 1.6+git20160502 instead works > fine. > > Looking at the changes[1], some variables types have been changed (many > int -> unsigned, and a few int -> dev_t in xen/console.{c,h}), but I > doubt that’s it. My guess is that it’s one of: > > * b4d07d3 Fix pageout deadlock > * 1db202e vm_map: back allocations with a red-black tree > > I shall try building a kernel with 1db202e reverted. Reverting 1db202e indeed fixes it. I also rebuilt the same source tree with the patch commented out in d/p/series just to be sure there wasn’t a toolchain issue, and that build *doesn’t* work, so 1db202e is either buggy or exposing other bugs. James signature.asc Description: Message signed with OpenPGP using GPGMail
Re: gnumach 1.7 issue
> On 3 Jun 2016, at 19:36, Samuel Thibault wrote: > > Samuel Thibault, on Fri 03 Jun 2016 20:35:13 +0200, wrote: >> Adam Richards, on Fri 03 Jun 2016 19:30:40 +0100, wrote: >>> On rebooting and reverting to gnumach-1.6-486.gz this is not an issue. >> >> It could be worth bisecting the issue on the upstream git repository. > > (there are really not much difference between the last 1.6 snapshot > 2:1.6+git20160502-1 and the 1.7 snapshot 2:1.7+git20160522-1) 1.7 seems to break running Xorg for me (running latest MATE). I can’t move the mouse, opening htop via ssh hangs at a black screen, and then subsequent ssh attempts can’t connect, so I have to perform a hard reboot. If I don’t send *any* mouse events, htop loads, but locks up as soon as I move the mouse. MATE’s clock does continue to update every second, so some things still work. Booting 1.6+git20160502 instead works fine. Looking at the changes[1], some variables types have been changed (many int -> unsigned, and a few int -> dev_t in xen/console.{c,h}), but I doubt that’s it. My guess is that it’s one of: * b4d07d3 Fix pageout deadlock * 1db202e vm_map: back allocations with a red-black tree I shall try building a kernel with 1db202e reverted. James [1] https://anonscm.debian.org/cgit/pkg-hurd/gnumach.git/commit/?id=8d63d9c0d3b84e8496248093ce333c959fe985c9 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: gnumach 1.7 issue
Samuel Thibault, on Fri 03 Jun 2016 20:35:13 +0200, wrote: > Adam Richards, on Fri 03 Jun 2016 19:30:40 +0100, wrote: > > On rebooting and reverting to gnumach-1.6-486.gz this is not an issue. > > It could be worth bisecting the issue on the upstream git repository. (there are really not much difference between the last 1.6 snapshot 2:1.6+git20160502-1 and the 1.7 snapshot 2:1.7+git20160522-1) Samuel
Re: gnumach 1.7 issue
Adam Richards, on Fri 03 Jun 2016 19:30:40 +0100, wrote: > On rebooting and reverting to gnumach-1.6-486.gz this is not an issue. It could be worth bisecting the issue on the upstream git repository. Samuel
gnumach 1.7 issue
Hi, I'm running Hurd in VirtualBox. If I run the latest versions (gnumach-1.7-486.gz) with the reverted findutils (as per James' email), then on scrolling the mouse a few times the system freezes with: mouse: queue full On rebooting and reverting to gnumach-1.6-486.gz this is not an issue. Cheers, adam