| Message ID | 1456238428-31774-1-git-send-email-thuth@redhat.com |
|---|---|
| State | Accepted |
| Headers | show |
On 23/02/2016 15:40, Thomas Huth wrote: > The "read" function of the dev-null device currently claims that > the same amount of bytes has been read as input bytes have been > requested. This causes grub to hang forever at the boot selection > menu, since grub then thinks that there's a continuous stream of input > data. If nothing has been read (which is always the case for the > dev-null device), the "read" function should simply return 0 instead. > Then grub also boots properly again after the typical short timeout. > > Reported-by: Laurent Vivier <lvivier@redhat.com> > Signed-off-by: Thomas Huth <thuth@redhat.com> Tested-by: Laurent Vivier <lvivier@redhat.com> > --- > board-qemu/slof/dev-null.fs | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/board-qemu/slof/dev-null.fs b/board-qemu/slof/dev-null.fs > index d0ffad6..9ac5169 100644 > --- a/board-qemu/slof/dev-null.fs > +++ b/board-qemu/slof/dev-null.fs > @@ -12,7 +12,7 @@ new-device > ; > > : read ( adr len -- actual ) > - nip > + 2drop 0 > ; > > : setup-alias >
On 02/24/2016 01:54 AM, Laurent Vivier wrote: > > > On 23/02/2016 15:40, Thomas Huth wrote: >> The "read" function of the dev-null device currently claims that >> the same amount of bytes has been read as input bytes have been >> requested. This causes grub to hang forever at the boot selection >> menu, since grub then thinks that there's a continuous stream of input >> data. If nothing has been read (which is always the case for the >> dev-null device), the "read" function should simply return 0 instead. >> Then grub also boots properly again after the typical short timeout. >> >> Reported-by: Laurent Vivier <lvivier@redhat.com> >> Signed-off-by: Thomas Huth <thuth@redhat.com> > > Tested-by: Laurent Vivier <lvivier@redhat.com> Thanks, applied. But how did you get this hang? How come that I've never seen that?
On Wed, Feb 24, 2016 at 11:39:40AM +1100, Alexey Kardashevskiy wrote: > On 02/24/2016 01:54 AM, Laurent Vivier wrote: > > > > > >On 23/02/2016 15:40, Thomas Huth wrote: > >>The "read" function of the dev-null device currently claims that > >>the same amount of bytes has been read as input bytes have been > >>requested. This causes grub to hang forever at the boot selection > >>menu, since grub then thinks that there's a continuous stream of input > >>data. If nothing has been read (which is always the case for the > >>dev-null device), the "read" function should simply return 0 instead. > >>Then grub also boots properly again after the typical short timeout. > >> > >>Reported-by: Laurent Vivier <lvivier@redhat.com> > >>Signed-off-by: Thomas Huth <thuth@redhat.com> > > > >Tested-by: Laurent Vivier <lvivier@redhat.com> > > Thanks, applied. > > But how did you get this hang? How come that I've never seen that? I believe it happens when you try to boot without a console, or only a console that SLOF doesn't understand like the virtio-console.
On 24.02.2016 03:49, David Gibson wrote: > On Wed, Feb 24, 2016 at 11:39:40AM +1100, Alexey Kardashevskiy wrote: >> On 02/24/2016 01:54 AM, Laurent Vivier wrote: >>> >>> >>> On 23/02/2016 15:40, Thomas Huth wrote: >>>> The "read" function of the dev-null device currently claims that >>>> the same amount of bytes has been read as input bytes have been >>>> requested. This causes grub to hang forever at the boot selection >>>> menu, since grub then thinks that there's a continuous stream of input >>>> data. If nothing has been read (which is always the case for the >>>> dev-null device), the "read" function should simply return 0 instead. >>>> Then grub also boots properly again after the typical short timeout. >>>> >>>> Reported-by: Laurent Vivier <lvivier@redhat.com> >>>> Signed-off-by: Thomas Huth <thuth@redhat.com> >>> >>> Tested-by: Laurent Vivier <lvivier@redhat.com> >> >> Thanks, applied. >> >> But how did you get this hang? How come that I've never seen that? > > I believe it happens when you try to boot without a console, or only a > console that SLOF doesn't understand like the virtio-console. Right, the problem has been found while trying to boot with a virtio-console only, something like: qemu-system-ppc64 -nographic -enable-kvm -nodefaults -hda hd.qcow2 \ -device virtio-serial -device virtconsole,chardev=vty \ -chardev pty,id=vty By the way, SLOF lacks a driver for virtio-consoles ... in case anybody wants to implement that, that would be great :-) Thomas
On 02/24/2016 01:49 PM, David Gibson wrote: > On Wed, Feb 24, 2016 at 11:39:40AM +1100, Alexey Kardashevskiy wrote: >> On 02/24/2016 01:54 AM, Laurent Vivier wrote: >>> >>> >>> On 23/02/2016 15:40, Thomas Huth wrote: >>>> The "read" function of the dev-null device currently claims that >>>> the same amount of bytes has been read as input bytes have been >>>> requested. This causes grub to hang forever at the boot selection >>>> menu, since grub then thinks that there's a continuous stream of input >>>> data. If nothing has been read (which is always the case for the >>>> dev-null device), the "read" function should simply return 0 instead. >>>> Then grub also boots properly again after the typical short timeout. >>>> >>>> Reported-by: Laurent Vivier <lvivier@redhat.com> >>>> Signed-off-by: Thomas Huth <thuth@redhat.com> >>> >>> Tested-by: Laurent Vivier <lvivier@redhat.com> >> >> Thanks, applied. >> >> But how did you get this hang? How come that I've never seen that? > > I believe it happens when you try to boot without a console, or only a > console that SLOF doesn't understand like the virtio-console. Oh. And how common is it to use virtio-console nowadays? Do I need to re-do the SLOF update for QEMU because of this?
On 24.02.2016 09:38, Alexey Kardashevskiy wrote: > On 02/24/2016 01:49 PM, David Gibson wrote: >> On Wed, Feb 24, 2016 at 11:39:40AM +1100, Alexey Kardashevskiy wrote: >>> On 02/24/2016 01:54 AM, Laurent Vivier wrote: >>>> >>>> >>>> On 23/02/2016 15:40, Thomas Huth wrote: >>>>> The "read" function of the dev-null device currently claims that >>>>> the same amount of bytes has been read as input bytes have been >>>>> requested. This causes grub to hang forever at the boot selection >>>>> menu, since grub then thinks that there's a continuous stream of input >>>>> data. If nothing has been read (which is always the case for the >>>>> dev-null device), the "read" function should simply return 0 instead. >>>>> Then grub also boots properly again after the typical short timeout. >>>>> >>>>> Reported-by: Laurent Vivier <lvivier@redhat.com> >>>>> Signed-off-by: Thomas Huth <thuth@redhat.com> >>>> >>>> Tested-by: Laurent Vivier <lvivier@redhat.com> >>> >>> Thanks, applied. >>> >>> But how did you get this hang? How come that I've never seen that? >> >> I believe it happens when you try to boot without a console, or only a >> console that SLOF doesn't understand like the virtio-console. > > Oh. And how common is it to use virtio-console nowadays? Do I need to > re-do the SLOF update for QEMU because of this? I guess hardly anybody uses this (otherwise this bug would have been noticed earlier) ... so IMHO no need to re-do the SLOF update now. But anyway, some users might try this in the future, so we should maybe have a virtio-console driver in SLOF one day... Thomas
diff --git a/board-qemu/slof/dev-null.fs b/board-qemu/slof/dev-null.fs index d0ffad6..9ac5169 100644 --- a/board-qemu/slof/dev-null.fs +++ b/board-qemu/slof/dev-null.fs @@ -12,7 +12,7 @@ new-device ; : read ( adr len -- actual ) - nip + 2drop 0 ; : setup-alias
The "read" function of the dev-null device currently claims that the same amount of bytes has been read as input bytes have been requested. This causes grub to hang forever at the boot selection menu, since grub then thinks that there's a continuous stream of input data. If nothing has been read (which is always the case for the dev-null device), the "read" function should simply return 0 instead. Then grub also boots properly again after the typical short timeout. Reported-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com> --- board-qemu/slof/dev-null.fs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)