Re: panic: invalid bcd xxx

[Oleksandr Tymoshenko]

Eric van Gyzen (vangy...@freebsd.org) wrote:
> On 03/04/2017 11:44, Oleksandr Tymoshenko wrote:
> > Adrian Chadd (adrian.ch...@gmail.com) wrote:
> >> We're not; we need to cope with crappy BIOS emulations and not crash :)
> >>
> >> What's Linux doing instead? Ignoring the RTC?
> >
> > I believe I saw the same problem on either my NUC or Minnowboard.
> > I just hacked around it to work on something else and didn't
> > have time to get back to the device since then. But it's not
> > just emulation BIOS. I think the right way to go is to perform sanity
> > check on RTC data and refuse to use it if it's not valid.
> 
> cem@ posted this patch:
> 
>   http://dpaste.com/1K2W05E
> 
> If someone can test it, I'll gladly commit it.  The real-time clock will 
> likely be wrong, but it won't panic with INVARIANTS.

I can not reproduce crash any more. Probably RTC battery got charged
again. I tested this patch with working RTC - there is no regression
and patch looks OK functional-wise. 

-- 
gonzo
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: invalid bcd xxx

[Eric van Gyzen]

On 03/04/2017 11:44, Oleksandr Tymoshenko wrote:

Adrian Chadd (adrian.ch...@gmail.com) wrote:

We're not; we need to cope with crappy BIOS emulations and not crash :)

What's Linux doing instead? Ignoring the RTC?


I believe I saw the same problem on either my NUC or Minnowboard.
I just hacked around it to work on something else and didn't
have time to get back to the device since then. But it's not
just emulation BIOS. I think the right way to go is to perform sanity
check on RTC data and refuse to use it if it's not valid.


cem@ posted this patch:

http://dpaste.com/1K2W05E

If someone can test it, I'll gladly commit it.  The real-time clock will 
likely be wrong, but it won't panic with INVARIANTS.


Eric
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: invalid bcd xxx

[Oleksandr Tymoshenko]

Adrian Chadd (adrian.ch...@gmail.com) wrote:
> On 2 March 2017 at 01:31, Matthias Apitz  wrote:
> > On Thursday, 2 March 2017 00:37:35 CET, Michael Gmelin 
> > wrote:
> >>
> >>
> >>
> >>> On 2 Mar 2017, at 00:35, Adrian Chadd  wrote:
> >>>
> >>> This is an emulated BIOS though, right?
> >>>
> >>> I don't know if we're going to get the RTC 'bugfixed'...
> >>>
> >>
> >>
> >> It's SeaBIOS, yes. I feel like this might end up in another
> >> quirk/workaround solution.
> >>
> >
> > I'm one of the C720 owners and  apart of Michael, I only know two users more
> > running FreeBSD. The SeaBIOS in our devices. is outdated, mine from 2013
> > IIRC. I dont know if there is an easy way to update this.
> 
> We're not; we need to cope with crappy BIOS emulations and not crash :)
> 
> What's Linux doing instead? Ignoring the RTC?

I believe I saw the same problem on either my NUC or Minnowboard.
I just hacked around it to work on something else and didn't
have time to get back to the device since then. But it's not
just emulation BIOS. I think the right way to go is to perform sanity
check on RTC data and refuse to use it if it's not valid.

-- 
gonzo
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: invalid bcd xxx

[Adrian Chadd]

On 2 March 2017 at 01:31, Matthias Apitz  wrote:
> On Thursday, 2 March 2017 00:37:35 CET, Michael Gmelin 
> wrote:
>>
>>
>>
>>> On 2 Mar 2017, at 00:35, Adrian Chadd  wrote:
>>>
>>> This is an emulated BIOS though, right?
>>>
>>> I don't know if we're going to get the RTC 'bugfixed'...
>>>
>>
>>
>> It's SeaBIOS, yes. I feel like this might end up in another
>> quirk/workaround solution.
>>
>
> I'm one of the C720 owners and  apart of Michael, I only know two users more
> running FreeBSD. The SeaBIOS in our devices. is outdated, mine from 2013
> IIRC. I dont know if there is an easy way to update this.

We're not; we need to cope with crappy BIOS emulations and not crash :)

What's Linux doing instead? Ignoring the RTC?



-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: invalid bcd xxx

[Matthias Apitz]

On Thursday, 2 March 2017 00:37:35 CET, Michael Gmelin  
wrote:




On 2 Mar 2017, at 00:35, Adrian Chadd  wrote:

This is an emulated BIOS though, right?

I don't know if we're going to get the RTC 'bugfixed'...




It's SeaBIOS, yes. I feel like this might end up in another 
quirk/workaround solution.




I'm one of the C720 owners and  apart of Michael, I only know two users 
more running FreeBSD. The SeaBIOS in our devices. is outdated, mine from 
2013 IIRC. I dont know if there is an easy way to update this.


matthias



--
Sent from my Ubuntu phone
http://www.unixarea.de/
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: invalid bcd xxx

[Michael Gmelin]

> On 2 Mar 2017, at 00:35, Adrian Chadd  wrote:
> 
> This is an emulated BIOS though, right?
> 
> I don't know if we're going to get the RTC 'bugfixed'...
> 


It's SeaBIOS, yes. I feel like this might end up in another quirk/workaround 
solution.

-m


> 
> -adrian
> 
>> On 28 February 2017 at 15:26, Michael Gmelin  wrote:
>> On Tue, 28 Feb 2017 17:16:02 -0600
>> Eric van Gyzen  wrote:
>> 
 On 02/28/2017 16:57, Conrad Meyer wrote:
 On Tue, Feb 28, 2017 at 2:31 PM, Eric van Gyzen
  wrote:
> Your system's real-time clock is returning garbage.  r312702 added
> some input validation a few weeks ago.  Previously, the kernel was
> reading beyond the end of an array and either complaining about
> the clock or setting it to the wrong time based on whatever was in
> the memory beyond the array.
> 
> The added validation shouldn't be an assertion because it operates
> on data beyond the kernel's control.  Try this:
> 
> --- sys/libkern.h   (revision 314424)
> +++ sys/libkern.h   (working copy)
> @@ -57,8 +57,10 @@
> bcd2bin(int bcd)
> {
> 
> -   KASSERT(bcd >= 0 && bcd < LIBKERN_LEN_BCD2BIN,
> -   ("invalid bcd %d", bcd));
> +   if (bcd < 0 || bcd >= LIBKERN_LEN_BCD2BIN) {
> +   printf("invalid bcd %d\n", bcd);
> +   return (0);
> +   }
>return (bcd2bin_data[bcd]);
> }
 
 I don't think removing this assertion and truncating to zero is the
 right thing to do.  Adding an error return to this routine is a
 little much, though.  I think probably the caller should perform
 input validation between the broken device and this routine.
>>> 
>>> Either of those would be a much better solution.  This was just a
>>> quick hack to get the memstick to boot.
>>> 
>> 
>> Thanks for your response.
>> 
>> I'm not in a hurry, so I can wait for a proper solution. Let me know if
>> I should test anything or can help in some other way.
>> 
>> -m
>> 
>> 
>> --
>> Michael Gmelin
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: invalid bcd xxx

[Adrian Chadd]

This is an emulated BIOS though, right?

I don't know if we're going to get the RTC 'bugfixed'...


-adrian

On 28 February 2017 at 15:26, Michael Gmelin  wrote:
> On Tue, 28 Feb 2017 17:16:02 -0600
> Eric van Gyzen  wrote:
>
>> On 02/28/2017 16:57, Conrad Meyer wrote:
>> > On Tue, Feb 28, 2017 at 2:31 PM, Eric van Gyzen
>> >  wrote:
>> >> Your system's real-time clock is returning garbage.  r312702 added
>> >> some input validation a few weeks ago.  Previously, the kernel was
>> >> reading beyond the end of an array and either complaining about
>> >> the clock or setting it to the wrong time based on whatever was in
>> >> the memory beyond the array.
>> >>
>> >> The added validation shouldn't be an assertion because it operates
>> >> on data beyond the kernel's control.  Try this:
>> >>
>> >> --- sys/libkern.h   (revision 314424)
>> >> +++ sys/libkern.h   (working copy)
>> >> @@ -57,8 +57,10 @@
>> >>  bcd2bin(int bcd)
>> >>  {
>> >>
>> >> -   KASSERT(bcd >= 0 && bcd < LIBKERN_LEN_BCD2BIN,
>> >> -   ("invalid bcd %d", bcd));
>> >> +   if (bcd < 0 || bcd >= LIBKERN_LEN_BCD2BIN) {
>> >> +   printf("invalid bcd %d\n", bcd);
>> >> +   return (0);
>> >> +   }
>> >> return (bcd2bin_data[bcd]);
>> >>  }
>> >
>> > I don't think removing this assertion and truncating to zero is the
>> > right thing to do.  Adding an error return to this routine is a
>> > little much, though.  I think probably the caller should perform
>> > input validation between the broken device and this routine.
>>
>> Either of those would be a much better solution.  This was just a
>> quick hack to get the memstick to boot.
>>
>
> Thanks for your response.
>
> I'm not in a hurry, so I can wait for a proper solution. Let me know if
> I should test anything or can help in some other way.
>
> -m
>
>
> --
> Michael Gmelin
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: invalid bcd xxx

[Michael Gmelin]

On Tue, 28 Feb 2017 17:16:02 -0600
Eric van Gyzen  wrote:

> On 02/28/2017 16:57, Conrad Meyer wrote:
> > On Tue, Feb 28, 2017 at 2:31 PM, Eric van Gyzen
> >  wrote:  
> >> Your system's real-time clock is returning garbage.  r312702 added
> >> some input validation a few weeks ago.  Previously, the kernel was
> >> reading beyond the end of an array and either complaining about
> >> the clock or setting it to the wrong time based on whatever was in
> >> the memory beyond the array.
> >>
> >> The added validation shouldn't be an assertion because it operates
> >> on data beyond the kernel's control.  Try this:
> >>
> >> --- sys/libkern.h   (revision 314424)
> >> +++ sys/libkern.h   (working copy)
> >> @@ -57,8 +57,10 @@
> >>  bcd2bin(int bcd)
> >>  {
> >>
> >> -   KASSERT(bcd >= 0 && bcd < LIBKERN_LEN_BCD2BIN,
> >> -   ("invalid bcd %d", bcd));
> >> +   if (bcd < 0 || bcd >= LIBKERN_LEN_BCD2BIN) {
> >> +   printf("invalid bcd %d\n", bcd);
> >> +   return (0);
> >> +   }
> >> return (bcd2bin_data[bcd]);
> >>  }  
> >
> > I don't think removing this assertion and truncating to zero is the
> > right thing to do.  Adding an error return to this routine is a
> > little much, though.  I think probably the caller should perform
> > input validation between the broken device and this routine.  
> 
> Either of those would be a much better solution.  This was just a
> quick hack to get the memstick to boot.
> 

Thanks for your response.

I'm not in a hurry, so I can wait for a proper solution. Let me know if
I should test anything or can help in some other way.

-m


-- 
Michael Gmelin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: invalid bcd xxx

[Eric van Gyzen]

On 02/28/2017 16:57, Conrad Meyer wrote:

On Tue, Feb 28, 2017 at 2:31 PM, Eric van Gyzen  wrote:

Your system's real-time clock is returning garbage.  r312702 added some
input validation a few weeks ago.  Previously, the kernel was reading beyond
the end of an array and either complaining about the clock or setting it to
the wrong time based on whatever was in the memory beyond the array.

The added validation shouldn't be an assertion because it operates on data
beyond the kernel's control.  Try this:

--- sys/libkern.h   (revision 314424)
+++ sys/libkern.h   (working copy)
@@ -57,8 +57,10 @@
 bcd2bin(int bcd)
 {

-   KASSERT(bcd >= 0 && bcd < LIBKERN_LEN_BCD2BIN,
-   ("invalid bcd %d", bcd));
+   if (bcd < 0 || bcd >= LIBKERN_LEN_BCD2BIN) {
+   printf("invalid bcd %d\n", bcd);
+   return (0);
+   }
return (bcd2bin_data[bcd]);
 }


I don't think removing this assertion and truncating to zero is the
right thing to do.  Adding an error return to this routine is a little
much, though.  I think probably the caller should perform input
validation between the broken device and this routine.


Either of those would be a much better solution.  This was just a quick 
hack to get the memstick to boot.


Eric
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: invalid bcd xxx

[Conrad Meyer]

On Tue, Feb 28, 2017 at 2:31 PM, Eric van Gyzen  wrote:
> Your system's real-time clock is returning garbage.  r312702 added some
> input validation a few weeks ago.  Previously, the kernel was reading beyond
> the end of an array and either complaining about the clock or setting it to
> the wrong time based on whatever was in the memory beyond the array.
>
> The added validation shouldn't be an assertion because it operates on data
> beyond the kernel's control.  Try this:
>
> --- sys/libkern.h   (revision 314424)
> +++ sys/libkern.h   (working copy)
> @@ -57,8 +57,10 @@
>  bcd2bin(int bcd)
>  {
>
> -   KASSERT(bcd >= 0 && bcd < LIBKERN_LEN_BCD2BIN,
> -   ("invalid bcd %d", bcd));
> +   if (bcd < 0 || bcd >= LIBKERN_LEN_BCD2BIN) {
> +   printf("invalid bcd %d\n", bcd);
> +   return (0);
> +   }
> return (bcd2bin_data[bcd]);
>  }

I don't think removing this assertion and truncating to zero is the
right thing to do.  Adding an error return to this routine is a little
much, though.  I think probably the caller should perform input
validation between the broken device and this routine.

Thanks,
Conrad
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: invalid bcd xxx

[Eric van Gyzen]

On 02/28/2017 15:47, Michael Gmelin wrote:

Booting r313561[0] I get the following panic:

mountroot: waiting for device /dev/ufs/FreeBSD_install
panic: invalid bcd 177 (also 254, 255 etc.)
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper...
vpanic()...
kassert_panic()...
atrtc_gettime()...
inittodr()...
vfs_mountroot()...
start_init()...
fork_exit()...
fork_trampoline()...
(copied from a screenshot, hence the ellipsis)

This is on an Acer C720 Chromebook, confirmed on two devices (one with
cyapa touchpad, one with elan touchpad). Same problem happened with a
CURRENT checked out about 10 hours ago. Previous versions of 12-CURRENT
worked ok (last version I tested personally was back in
November/December though).


Your system's real-time clock is returning garbage.  r312702 added some 
input validation a few weeks ago.  Previously, the kernel was reading 
beyond the end of an array and either complaining about the clock or 
setting it to the wrong time based on whatever was in the memory beyond 
the array.


The added validation shouldn't be an assertion because it operates on 
data beyond the kernel's control.  Try this:


--- sys/libkern.h   (revision 314424)
+++ sys/libkern.h   (working copy)
@@ -57,8 +57,10 @@
 bcd2bin(int bcd)
 {

-   KASSERT(bcd >= 0 && bcd < LIBKERN_LEN_BCD2BIN,
-   ("invalid bcd %d", bcd));
+   if (bcd < 0 || bcd >= LIBKERN_LEN_BCD2BIN) {
+   printf("invalid bcd %d\n", bcd);
+   return (0);
+   }
return (bcd2bin_data[bcd]);
 }

Eric
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: panic: invalid bcd xxx

[Konstantin Belousov]

On Tue, Feb 28, 2017 at 10:47:39PM +0100, Michael Gmelin wrote:
> Booting r313561[0] I get the following panic:
> 
> mountroot: waiting for device /dev/ufs/FreeBSD_install
> panic: invalid bcd 177 (also 254, 255 etc.)
> cpuid = 1
> KDB: stack backtrace:
> db_trace_self_wrapper...
> vpanic()...
> kassert_panic()...
> atrtc_gettime()...
> inittodr()...
> vfs_mountroot()...
> start_init()...
> fork_exit()...
> fork_trampoline()...
> (copied from a screenshot, hence the ellipsis)
> 
> This is on an Acer C720 Chromebook, confirmed on two devices (one with
> cyapa touchpad, one with elan touchpad). Same problem happened with a
> CURRENT checked out about 10 hours ago. Previous versions of 12-CURRENT
> worked ok (last version I tested personally was back in
> November/December though).
> 
> -m
> 
> 
> [0]
> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20170210-r313561-memstick.img
> 

This is most likely due to r312702.  But then it means that your RTC
returns garbage.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"