Lev Serebryakov
2018-Oct-23 10:53 UTC
loader lsdev crashes loader (Was: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated)
On 22.10.2018 12:27, Toomas Soome wrote:> It would help to get output from loader lsdev -v command.current loader crashes on "lsdev" for me: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232483 (it is not threadripper-related, my hardware is Intel Atom). -- // Lev Serebryakov -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: OpenPGP digital signature URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20181023/701bfc4e/attachment.sig>
Toomas Soome
2018-Oct-23 11:54 UTC
loader lsdev crashes loader (Was: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated)
> On 23 Oct 2018, at 13:53, Lev Serebryakov <lev at FreeBSD.org> wrote: > > On 22.10.2018 12:27, Toomas Soome wrote: > >> It would help to get output from loader lsdev -v command. > current loader crashes on "lsdev" for me: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232483 (it is not > threadripper-related, my hardware is Intel Atom). > > -- > // Lev Serebryakov >That error means something is corrupting the memory, it is hard to guess what exactly and debugging it is nasty - it means we would need to track down what was allocated before this memory block (guard1 is marker inserted in front of the allocated memory block). Fortunately the code to print the partition table is in stand/common/disk.c and the partition code is just next to it and so it should be relatively easy to find the guilty one? I will try to see if I can replicate the issue. rgds, toomas