Recent vt(4) broke moused when hw.vga.textmode=1
Hi, I have seen this panic via serial console, but the console is completely unusable at the time. VGA console is full of '?'. Booting single user mode, I can provoke the panic with '/etc/rc.d/moused start ums0'. === Fatal trap 12: page fault while in kernel mode cpuid = 7; apic id = 0e Fatal trap 12: page fault while in kernel mode fault virtual address = 0x2c cpuid = 6; fault code = supervisor read data, page not present apic id = 0c instruction pointer = 0x20:0x803abcf7 fault virtual address = 0x2c stack pointer = 0x28:0xfe085f1b3880 fault code = supervisor read data, page not present frame pointer = 0x28:0xfe085f1b38e0 instruction pointer = 0x20:0x803ae562 code segment= base 0x0, limit 0xf, type 0x1b stack pointer = 0x28:0xfe083c9b9950 = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, frame pointer = 0x28:0xfe083c9b9a10 IOPL = 0 current process = code segment = base 0x0, limit 0xf, type 0x1b The instruction pointer is Line 831 of /usr/src/sys/dev/vt/vt_core.c. Reverting /sys/dev/vt to r270269 would solve the panic, but I haven't investigated further. Cheers, ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Recent vt(4) broke moused when hw.vga.textmode=1
On 23.08.2014 08:38, Xin Li wrote: Hi, Hello! I have seen this panic via serial console, but the console is completely unusable at the time. VGA console is full of '?'. Oh crap, sorry for the breakage... I look into this right now. -- Jean-Sébastien Pédron ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CURRENT]: r270386: unusable console (question marks filling scrren) in vt(), crash/freeze
On 23.08.2014 07:16, O. Hartmann wrote: I expect at least the vga textmode console in vt() working. Can the inventor of this mess plaese revert the code to a working version? Hello! I'm responsible for that and currently working on fixing it. Sorry for the breakage :-/ -- Jean-Sébastien Pédron ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Boot loader too large with Aug-11 FreeBSD/i386 11-CURRENT snapshot
Hi, Today I installed 11-CURRENT from the 20140811 FreeBSD/i386 snapshot on my IBM T43 laptop but encountered some problems. The memstick installation went fine and I pretty much used default values everywhere, but upon reboot I got ”Boot loader too large”. Nothing more. Any ideas? Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CURRENT]: r270386: unusable console (question marks filling scrren) in vt(), crash/freeze
On 23.08.2014 07:16, O. Hartmann wrote: On different platforms with different graphics hardware, recent CURRENT r 270386 shows a screen filled with question marks when booting, The '?' filling screen issue is fixed in HEAD as of r270388. Again, sorry for that. Thank you for reporting the problem! -- Jean-Sébastien Pédron ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Boot loader too large with Aug-11 FreeBSD/i386 11-CURRENT snapshot
On Sat, Aug 23, 2014 at 09:02:10AM +0200 I heard the voice of Joel Dahl, and lo! it spake thus: Today I installed 11-CURRENT from the 20140811 FreeBSD/i386 snapshot on my IBM T43 laptop but encountered some problems. The memstick installation went fine and I pretty much used default values everywhere, but upon reboot I got ”Boot loader too large”. Nothing more. Any ideas? The freebsd-boot partition is bigger than five hundred twenty-mumble k. It'll be OK if you squeeze it down to 512. Somthing like 'gpart resize -i 1 -s 512k ada23' (untested, sub your disk). -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Recent vt(4) broke moused when hw.vga.textmode=1
On 23.08.2014 08:38, Xin Li wrote: Fatal trap 12: page fault while in kernel mode And the crash is fixed in r270390. Thank you for reporting this! -- Jean-Sébastien Pédron ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Recent vt(4) broke moused when hw.vga.textmode=1
On 8/23/14 12:42 AM, Jean-Sébastien Pédron wrote: On 23.08.2014 08:38, Xin Li wrote: Fatal trap 12: page fault while in kernel mode And the crash is fixed in r270390. Thank you for reporting this! I have verified and r270390 have fixed the crash, thanks for the prompt fix! Cheers, ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Boot loader too large with Aug-11 FreeBSD/i386 11-CURRENT snapshot
23 aug 2014 kl. 09:17 skrev Matthew D. Fuller fulle...@over-yonder.net: On Sat, Aug 23, 2014 at 09:02:10AM +0200 I heard the voice of Joel Dahl, and lo! it spake thus: Today I installed 11-CURRENT from the 20140811 FreeBSD/i386 snapshot on my IBM T43 laptop but encountered some problems. The memstick installation went fine and I pretty much used default values everywhere, but upon reboot I got ”Boot loader too large”. Nothing more. Any ideas? The freebsd-boot partition is bigger than five hundred twenty-mumble k. It'll be OK if you squeeze it down to 512. Somthing like 'gpart resize -i 1 -s 512k ada23' (untested, sub your disk). Yes, gpart fixed it. Thanks. But it’s annoying. Why is manual tinkering required here? Why isn’t it set to 512k by default? I checked the handbook (2.6.3), and it says ”the freebsd-boot partition should be no larger than 512K due to current boot code limitations” ... Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Boot loader too large with Aug-11 FreeBSD/i386 11-CURRENT snapshot
I thought there was a recent discussion about this. Would you mind filing a bug so this gets looked at? -a On 23 August 2014 02:42, Joel Dahl j...@vnode.se wrote: 23 aug 2014 kl. 09:17 skrev Matthew D. Fuller fulle...@over-yonder.net: On Sat, Aug 23, 2014 at 09:02:10AM +0200 I heard the voice of Joel Dahl, and lo! it spake thus: Today I installed 11-CURRENT from the 20140811 FreeBSD/i386 snapshot on my IBM T43 laptop but encountered some problems. The memstick installation went fine and I pretty much used default values everywhere, but upon reboot I got ”Boot loader too large”. Nothing more. Any ideas? The freebsd-boot partition is bigger than five hundred twenty-mumble k. It'll be OK if you squeeze it down to 512. Somthing like 'gpart resize -i 1 -s 512k ada23' (untested, sub your disk). Yes, gpart fixed it. Thanks. But it’s annoying. Why is manual tinkering required here? Why isn’t it set to 512k by default? I checked the handbook (2.6.3), and it says ”the freebsd-boot partition should be no larger than 512K due to current boot code limitations” ... Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: mkimg used to create gpt image, problem booting
On Fri, Aug 22, 2014 at 1:45 PM, Marcel Moolenaar mar...@xcllnt.net wrote: If I mdconfig the foo1.img disk image, and do a gpart show, I see: = 3 1784944 md0 GPT (872M) 3 321 freebsd-boot (16K) 35 17849122 freebsd-ufs (872M) Any idea what I am doing wrong? To the best of my knowledge, qemu is the thing you're doing wrong :-) Hi, I transferred foo1.img to a Mac with VirtualBox, converted it to VMDK with VBoxManage convertfromraw --format VMDK, and tried to boot it in VirtualBox. I got the same error as in QEMU. It looks like /boot/loader runs, but I cannot do ls to see the root file system. I created another disk image with a GPT layout, but this time using the FreeBSD bsdinstall inside a bhyve VM. I noticed the following: WORKING IMAGE BOOTS IN QEMU, CREATED WITH BSDINSTALL = = 34 10485693 md0 GPT (5.0G) 34 1281 83bd6b9d-7f41-11dc-be0b-001560b84f0f (64K) 162 99592962 516e7cb6-6ecf-11d6-8ff8-00022d09712b (4.7G) 99594585242883 516e7cb5-6ecf-11d6-8ff8-00022d09712b (256M) 10483746 1981 - free - (991K) DOES NOT BOOT IN QEMU, CREATED WITH MKIMG === = 3 1784944 md1 GPT (872M) 3 321 83bd6b9d-7f41-11dc-be0b-001560b84f0f (16K) 35 17849122 516e7cb6-6ecf-11d6-8ff8-00022d09712b (872M) I ran the following crazy experiment, just to see what would happen: dd if=/dev/md1s2 of=/dev/md0s2 bs=8192 I then tried to boot the first image with QEMU, and it booted successfully, with my UFS file system that I had previously created with makefs. I'm not sure where to look for the problem. I notice that in the non-working image, the offset starts at block 3, while in the working image, the offset starts at block 34. Is that enough to make things not boot? -- Craig ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: mkimg used to create gpt image, problem booting
On Aug 23, 2014, at 12:00 PM, Craig Rodrigues rodr...@freebsd.org wrote: I ran the following crazy experiment, just to see what would happen: dd if=/dev/md1s2 of=/dev/md0s2 bs=8192 I then tried to boot the first image with QEMU, and it booted successfully, with my UFS file system that I had previously created with makefs. I'm not sure where to look for the problem. I notice that in the non-working image, the offset starts at block 3, while in the working image, the offset starts at block 34. Is that enough to make things not boot? Could be. Try the -P option to mkimg. It sets the underlying (unexposed) physical sector size while still working with the visible 512 bytes sectors. The net effect is that for the GPT scheme things get aligned to the physical sector size and that it also causes the image size to be rounded. You can also try emitting vmdk directly to see if that makes a difference. vmdk also has the side- effect of rounding the image to the grain size. -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: mkimg used to create gpt image, problem booting
On Sat, Aug 23, 2014 at 12:11 PM, Marcel Moolenaar mar...@xcllnt.net wrote: Could be. Try the -P option to mkimg. It sets the underlying (unexposed) physical sector size while still working with the visible 512 bytes sectors. The net effect is that for the GPT scheme things get aligned to the physical sector size and that it also causes the image size to be rounded. You can also try emitting vmdk directly to see if that makes a difference. vmdk also has the side- effect of rounding the image to the grain size. I tried the following experiments: mkimg -v -f vmdk -s gpt -b test1/boot/pmbr -p freebsd-boot:=test1/boot/gptboot -p freebsd-ufs:=/tmp/file.img -o /tmp/foo1.vmdk When I tried to boot the image in QEMU, I had the same problem as before. It looks like it started writing the image on block 3, same as before. I also tried adding the -P flag, with different values like 2048 and 4096. I ran into the same problem. Hmm. -- Craig ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gbde destroy doesn't match man page?
In message 20140820215522.ga92...@bewilderbeast.blackhelicopters.org, Michae l W. Lucas writes: Playing with GBDE for my FreeBSD disk book, on: # uname -a FreeBSD storm 11.0-CURRENT FreeBSD 11.0-CURRENT #6 r269010: Wed Jul 23 11:13:17 EDT 2014 mwlucas@storm:/usr/obj/usr/src/sys/GENERIC amd64 According to the man page, I should be able to destroy all copies of the key with gbde destroy device -n -1. It's in the examples. When I try it I get: I think that is an oversight in the code. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: mkimg used to create gpt image, problem booting
Hi,
I did some more experiments, and found that after /boot/loader runs,
if I break into the loader prompt and type lsdev, I would get this:
(1) GPT Disk image which boots under QEMU, made by bsdinstall
==
View from loader
OK lsdev
cd devices:
disk devices:
disk0:BIOS drive A:
disk1:BIOS drive C:
disk1p1: FreeBSD boot
disk1p2: FreeBSD UFS
disk1p3: FreeBSD swap
pxe devices:
View from gpart, after we mdconfig the disk image
= 34 10485693 md0 GPT (5.0G)
34 1281 freebsd-boot (64K)
162 99592962 freebsd-ufs (4.7G)
99594585242883 freebsd-swap (256M)
10483746 1981 - free - (991K)
(2) GPT Disk image which fails to boot under QEMU, made by mkimg
===
View from loader
OK lsdev
cd devices:
disk devices:
disk0:BIOS drive A:
disk1:BIOS drive C:
pxe devices:
View from gpart, after we mdconfig the disk image
= 3 1784944 md1 GPT (872M)
3 321 freebsd-boot (16K)
35 17849122 freebsd-ufs (872M)
This leads me to believe that there is logic in /boot/loader,
which is not in GEOM, that fails to parse the GPT produced by mkimg.
I did some further debugging inside the loader by doing the following.
- I added CFLAGS += -DPART_DEBUG to sys/boot/common/Makefile.inc
- I added DEBUG() statements all over sys/boot/common/part.c
I observed that in sys/boot/common/part.c in the ptbl_gptread() function,
that in this section:
305 ent = (struct gpt_ent *)tbl;
306 size = MIN(hdr.hdr_entries * hdr.hdr_entsz,
307 MAXTBLSZ * table-sectorsize);
308 for (i = 0; i size / hdr.hdr_entsz; i++, ent++) {
309 if (uuid_equal(ent-ent_type, gpt_uuid_unused, NULL))
310 continue;
ent-ent_type is all 0's, which matches gpt_uuid_unused, so it bails
out of the loop and never adds the gpt partitions to the list of partitions
that the loader can access.
I'm not familiar with the GPT format, nor am I familiar with the
gpt code inside the loader, and how it differs from GEOM.
Do you have any further ideas of where to hunt for the root cause of
the problem?
Thanks.
--
Craig
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
