Re: Crash on xen/amd64
On Sun, Aug 24, 2014 at 8:47 PM, Allan Jude wrote: > On 2014-08-24 20:28, Shawn Webb wrote: > > I've been getting these occasional kernel panics in my VM: > > http://imgur.com/BYes0gj,Ay8iDar > > This time around pkg-static seemed to cause the crash. > > > > Thanks, > > > > Shawn > > ___ > > 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" > > > > How big is your disk? Is the LBA range listed before the panic the very > end of the disk? Paste of `gpart list`: http://ix.io/e0X I'm a little unsure how to answer your second question. And I'm unsure if the disk error is related, but it might be. For what it's worth, this is a brand new VPS instance on RootBSD. Thanks, Shawn ___ 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: Crash on xen/amd64
On 2014-08-24 20:28, Shawn Webb wrote: > I've been getting these occasional kernel panics in my VM: > http://imgur.com/BYes0gj,Ay8iDar > This time around pkg-static seemed to cause the crash. > > Thanks, > > Shawn > ___ > 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" > How big is your disk? Is the LBA range listed before the panic the very end of the disk? -- Allan Jude signature.asc Description: OpenPGP digital signature
Crash on xen/amd64
I've been getting these occasional kernel panics in my VM: http://imgur.com/BYes0gj,Ay8iDar This time around pkg-static seemed to cause the crash. Thanks, Shawn ___ 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 24, 2014, at 4:31 PM, John-Mark Gurney wrote: >> >> With mkimg, you know exactly how many partitions you are creating >> , so you don't need to specify 128 as the number of partitions. > > Though, w/ people dd'ing images onto disks, and using growfs to grow > as necessary, we might want to allocate a few more more than the > minimum... I do agree that we want to keep sizes to a minimum... One thing I can maybe do is simply fill the empty sectors that are there because of alignment. If you add -P 4K to mkimg, then the first partition will by 4K aligned and you have about 5 sectors unused between the end of the GPT table and the first sector of the first partition. I may as well extend the table to cover those unued sectors. However, this is a pretty side-ways way to end up with a GPT table that has some extra room. Maybe having scheme- specific options for this kind of thing is not bad. At least EBR and APM have the same "problem" and the BSD disk label can also be created with more than just 8 partitions. Related: o Is there a need to create images with empty space at the end of in between partitions? o Is there a need to create partitions with specific indices (i.e. index 6 for a typical 'f' partition)? Answers to these questions could help figure this out... -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: ktrace -c behavior
Eric van Gyzen wrote this message on Fri, Aug 22, 2014 at 15:26 -0400: > On 08/22/2014 15:20, John-Mark Gurney wrote: > > Eric van Gyzen wrote this message on Fri, Aug 22, 2014 at 15:16 -0400: > >> What behavior would you expect from this sequence of commands? > >> > >> ktrace -tw -p 1234 > >> ktrace -c -p 1234 > >> > >> Based on this... > >> > >> -c Clear the trace points associated with the specified file > >> or processes. > > and/or just add specified: > > Clear the specified trace points ... > > But what if I didn't specify them? You specified the default by not specificly specifing any different ones.. :) Confused? :) or maybe selected? > >> ...I would expect the second command to clear the trace point for > >> context switches. It doesn't. I have to specify -tw with the -c to get > >> that behavior. This makes sense; it's just not what I was expecting. > >> > >> Assuming we want to keep this behavior, can we clarify the -c flag in > >> man page? I would suggest: > >> > >> If the -t flag is not specified, clear the default set of trace points. > > Maybe we should add a new trace point string that is a (for all).. so > > you can do ktrace -ta -c? > > That would be handy. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ 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
Craig Rodrigues wrote this message on Sun, Aug 24, 2014 at 15:37 -0700: > On Sun, Aug 24, 2014 at 12:05 PM, Marcel Moolenaar wrote: > > > > On Aug 24, 2014, at 9:59 AM, Craig Rodrigues wrote: > > > >> On Sun, Aug 24, 2014 at 2:11 AM, Andrey V. Elsukov > >> wrote: > >>> > >>> Yes, the problem is in the ptable_gptread() function. I'll commit the fix. > >> > > > >> Should mkimg be changed to create a partition table with 128 entries > >> by default, to match older versions of FreeBSD which do not have this fix? > > > > Maybe. 128 is the suggested default. It's not a hard lower > > limit. Technically speaking, it's perfectly fine to create > > just enough entries to fill a single sector. Then again, > > code makes all kinds of assumptions or has all kinds of > > bugs -- just like the logic in the loader apparently. > > > > By having mkimg create a large table, even if it's knows > > up front that it doesn't have to may prevent broken code > > from tripping over, bit it surely bloats the image for > > no reason. > > I see what you are saying. If you have a new device > and do "gpart create -s GPT", then this value in sys/geom/part/g_part_gpt.c: > > .gps_minent = 128, > > causes the logic in the g_part_ctl_create() function in sys/geom/part/g_part.c > to set the number of partitions to 128, and then it calls g_part_ctl_create() > which creates the partition table with 128 empty entries. > > "gpart create" doesn't know how many partitions you want, so it > needs to allocate some space up front for the partition table, > and then you can do "gpart add" to add the partitions later. > > With mkimg, you know exactly how many partitions you are creating > , so you don't need to specify 128 as the number of partitions. Though, w/ people dd'ing images onto disks, and using growfs to grow as necessary, we might want to allocate a few more more than the minimum... I do agree that we want to keep sizes to a minimum... > Since only gpart was available for creating GPT partitions, the side-effect > of always having 128 partitions hid the bug in the loader. > > Hopefully Andrey's fix can be backported to at least stable/9, because > the loader bug seems to have been there since at least 2012. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ 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"
"make installworld" commands used to generate manifest for makefs?
Hi, Is there an easy way to take most of the commands performed during "make installworld" and create a manifest file which is compatible with makefs? That would be very handy for creating file system images. -- 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 Sun, Aug 24, 2014 at 12:05 PM, Marcel Moolenaar wrote: > > On Aug 24, 2014, at 9:59 AM, Craig Rodrigues wrote: > >> On Sun, Aug 24, 2014 at 2:11 AM, Andrey V. Elsukov wrote: >>> >>> Yes, the problem is in the ptable_gptread() function. I'll commit the fix. >> > >> Should mkimg be changed to create a partition table with 128 entries >> by default, to match older versions of FreeBSD which do not have this fix? > > Maybe. 128 is the suggested default. It's not a hard lower > limit. Technically speaking, it's perfectly fine to create > just enough entries to fill a single sector. Then again, > code makes all kinds of assumptions or has all kinds of > bugs -- just like the logic in the loader apparently. > > By having mkimg create a large table, even if it's knows > up front that it doesn't have to may prevent broken code > from tripping over, bit it surely bloats the image for > no reason. I see what you are saying. If you have a new device and do "gpart create -s GPT", then this value in sys/geom/part/g_part_gpt.c: .gps_minent = 128, causes the logic in the g_part_ctl_create() function in sys/geom/part/g_part.c to set the number of partitions to 128, and then it calls g_part_ctl_create() which creates the partition table with 128 empty entries. "gpart create" doesn't know how many partitions you want, so it needs to allocate some space up front for the partition table, and then you can do "gpart add" to add the partitions later. With mkimg, you know exactly how many partitions you are creating , so you don't need to specify 128 as the number of partitions. Since only gpart was available for creating GPT partitions, the side-effect of always having 128 partitions hid the bug in the loader. Hopefully Andrey's fix can be backported to at least stable/9, because the loader bug seems to have been there since at least 2012. -- 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: KQueue 0-length UDP packet
Hello again! I just realized that the wording was probably a bit off. What I wanted to ask is: why does FreeBSD kqueue implementation treat `SO_RCVLOWAT` as a raw packet size watermark, and not using the actual data size for filtering out events? I am totally fine with the fact that it triggers event on 0-size udp packets, but the behavior itself seems a bit odd, right? Please let me know if this is a bug, and I'll submit a patch. Cheers, Fedor. On Sat, Aug 2, 2014 at 2:57 PM, Fedor Indutny wrote: > After reading that line more carefully, I wonder if this behavior is > really intentional here. > > It seems to me that `SO_RCVLOWAT` is supposed to set watermark value in > terms of > packet data bytes, not just raw packet size. And this is how `NOTE_LOWAT` > actually > works there, right? > > Could anyone please comment on this? Is it a bug? > > -- > > Regarding OSX: > > Submitted Apple Bug # 17894467 , with a patch. > > If anyone has friends at Apple who could help getting this in, please let > me know! > > Cheers, > Fedor. > > > On Sat, Aug 2, 2014 at 2:41 PM, Fedor Indutny wrote: > >> Guess I know the answer: >> >> https://cloudup.com/cCkjLhI4M2r >> >> Basically, OSX is checking `kn_data` and FreeBSD is using >> `so->so_rcv.sb_cc`. >> >> Thank you anyway! >> >> >> On Sat, Aug 2, 2014 at 1:39 PM, Fedor Indutny wrote: >> >>> Hello! >>> >>> I'm trying to figure out, why this code: >>> >>> https://github.com/indutny/0-udp >>> >>> Which basically sends a 0-length UDP packet to a server and polls >>> kqueue events on the server fd. >>> >>> Return 1 kevent on FreeBSD, and blocks indefinitely without >>> returning any events on OSX. >>> >>> So far I could see that FreeBSD and OSX are treating NOTE_LOWAT >>> differently: >>> >>> * >>> https://github.com/opensource-apple/xnu/blob/2fa84067f6cdeb23267f877ca4fd26201316da1b/bsd/kern/uipc_socket.c#L4461 >>> * >>> https://github.com/freebsd/freebsd/blob/6901832d8588537c81afbdb91d1a22deb5582c47/sys/kern/uipc_socket.c#L3163-L3164 >>> >>> FreeBSD's NOTE_LOWAT is overriding SO_RCVLOWAT, and OSX is using >>> SO_RVCLOWAT as a minimum value. But, since NOTE_LOWAT is not >>> involved here by default, I'm failing to see where exactly this >>> event could pass through kqueue filter. >>> >>> Could anyone with UDP and/or KQueue implementation knowledge >>> share some insights with me? >>> >>> Thank you very much! >>> Fedor. >>> >>> (NOTE: Duplicate, first email wasn't posted, because I wasn't subscribed >>> to the ML) >>> >> >> > ___ 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
Thanks! -a On 24 August 2014 02:21, Joel Dahl wrote: > > 23 aug 2014 kl. 20:45 skrev Adrian Chadd : > >> I thought there was a recent discussion about this. >> >> Would you mind filing a bug so this gets looked at? > > Done. See Bug 192962. > > 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: mkimg used to create gpt image, problem booting
On Aug 24, 2014, at 9:59 AM, Craig Rodrigues wrote: > On Sun, Aug 24, 2014 at 2:11 AM, Andrey V. Elsukov wrote: >> >> Yes, the problem is in the ptable_gptread() function. I'll commit the fix. > > Should mkimg be changed to create a partition table with 128 entries > by default, to match older versions of FreeBSD which do not have this fix? Maybe. 128 is the suggested default. It's not a hard lower limit. Technically speaking, it's perfectly fine to create just enough entries to fill a single sector. Then again, code makes all kinds of assumptions or has all kinds of bugs -- just like the logic in the loader apparently. By having mkimg create a large table, even if it's knows up front that it doesn't have to may prevent broken code from tripping over, bit it surely bloats the image for no reason. -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: mkimg used to create gpt image, problem booting
On Sun, Aug 24, 2014 at 8:23 AM, Marcel Moolenaar wrote:
>
> On Aug 24, 2014, at 2:11 AM, Andrey V. Elsukov wrote:
>
>> On 24.08.2014 06:14, Craig Rodrigues wrote:
>
>>> 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.
>>
>> Yes, the problem is in the ptable_gptread() function. I'll commit the fix.
>>
>
> Actually, no. There is *a* problem in that function:
> The function does not respect hdr.hdr_entsz when it
> needs the next entry. It simply uses "ent++", which
> is fixed our definition of struct gpt_ent and may
> not match the definition of the writer.
Yes, you are correct. I looked at the GPT format here:
http://en.wikipedia.org/wiki/GUID_Partition_Table
Although the default size in the specification for a gpt entry is 128 bytes,
which matches the size of our "struct gpt_entry",
technically, the gpt header could specify a gpt entry size that is something
other than 128 bytes. I guess the only restriction seems to be that
you cannot have variable sized gpt entries.they have to match the
size of the gpt entry specified in the gpt header.
I guess we haven't hit this yet because there are probably very few
peopel creating gpt tables with entry sizes other than 128, but in the
future, who knows?
--
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 Sun, Aug 24, 2014 at 2:11 AM, Andrey V. Elsukov wrote:
>
> Yes, the problem is in the ptable_gptread() function. I'll commit the fix.
Index: head/sys/boot/common/part.c
===
--- head/sys/boot/common/part.c (revision 270444)
+++ head/sys/boot/common/part.c (revision 270445)
@@ -254,8 +254,8 @@
table->sectorsize);
if (phdr != NULL) {
/* Read the primary GPT table. */
- size = MIN(MAXTBLSZ,
- phdr->hdr_entries * phdr->hdr_entsz / table->sectorsize);
+ size = MIN(MAXTBLSZ, (phdr->hdr_entries * phdr->hdr_entsz +
+ table->sectorsize - 1) / table->sectorsize);
if (dread(dev, tbl, size, phdr->hdr_lba_table) == 0 &&
gpt_checktbl(phdr, tbl, size * table->sectorsize,
table->sectors - 1) == 0) {
I can confirm that r270445 fixes the problem for me, where I can
now QEMU boot a GPT partitioned image created with mkimg.
I put some more debugging in the code, and found this:
(1) GPT IMAGE CREATED WITH MKIMG
===
phdr->hdr_entries = 2, phdr->hdr_entsz = 128, table->sectorsize = 512
(2) GPT IMAGE CREATED WITH BSDINSTALL
===
phdr->hdr_entries = 128, phdr->hdr_entsz = 128, table->sectorsize = 512
Does gpart create a fixed partition table with 128 entries?
That would explain a lot.
Also, in the gptboot man page, it mentions that gptboot can only boot
on systems with 128 partitions or less. This seems like an artificial
restriction.
Does the gptboot code really enforce this? Not that I have a system with more
than 128 partitions. :)
Should mkimg be changed to create a partition table with 128 entries
by default, to match older versions of FreeBSD which do not have this fix?
Thanks for the fix!
--
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 24, 2014, at 2:11 AM, Andrey V. Elsukov wrote:
> On 24.08.2014 06:14, Craig Rodrigues wrote:
>> 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.
>
> Yes, the problem is in the ptable_gptread() function. I'll commit the fix.
>
Actually, no. There is *a* problem in that function:
The function does not respect hdr.hdr_entsz when it
needs the next entry. It simply uses "ent++", which
is fixed our definition of struct gpt_ent and may
not match the definition of the writer.
I don't see how the loader is responsible for *the*
problem. All I see in qemu is that the loader, when
it reads a sector, isn't getting the actual sector
data that's in the image.
Just do a ktrace on qemu and you'll see what I mean.
YMMV of course,
--
Marcel Moolenaar
mar...@xcllnt.net
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: Boot loader too large with Aug-11 FreeBSD/i386 11-CURRENT snapshot
23 aug 2014 kl. 20:45 skrev Adrian Chadd : > I thought there was a recent discussion about this. > > Would you mind filing a bug so this gets looked at? Done. See Bug 192962. 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: mkimg used to create gpt image, problem booting
On 24.08.2014 06:14, Craig Rodrigues wrote:
> 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?
Yes, the problem is in the ptable_gptread() function. I'll commit the fix.
--
WBR, Andrey V. Elsukov
signature.asc
Description: OpenPGP digital signature
