Re: Problems with twa
Giulio Ferro wrote: > I've installed a 3ware 9500 sata controller with 4 1TB disks > in raid 5. > Apart from the usual wrong geometry warning the starting configuration > is ok: I create a single partition with the default labels plus a /usr/home > label with takes most of the disk space (about 2.7TB). > > When I reboot the system the /usr/home partition size drops unexplainably > to about 640GB. > > In order to try to understand what happens I've installed freebsd anew, > this > time creating 2 partitions: the first one 50GB, the second about 2.7TB (the > remaining space). Everything seems to work correctly. > I reboot the system and lo! the second partitions shrinks to about 640GB > and > the partitioner (using sysinstall) tells me that there are 2048GB free! > > This happens both with freebsd 7 and 8 current amd64. > > Thanks for any help. It's probably because you cannot create bsdlabels or fdisk partitions larger than 2 TB. The sizes you're seeing are probably because of overflows in calculations. It's not that the OS doesn't support larger drives, the problem is the partition formats. You might succeed by creating two large partitions, one ending just before the 2 TB limit and one stretching the rest of the space, but a more robust way would be to either create two smaller volumes (if the controller supports creating them on the array) or you'll need to install FreeBSD on a separate, smaller array and partition the large array with GPT (or use ZFS). signature.asc Description: OpenPGP digital signature
Problems with twa
I've installed a 3ware 9500 sata controller with 4 1TB disks in raid 5. Apart from the usual wrong geometry warning the starting configuration is ok: I create a single partition with the default labels plus a /usr/home label with takes most of the disk space (about 2.7TB). When I reboot the system the /usr/home partition size drops unexplainably to about 640GB. In order to try to understand what happens I've installed freebsd anew, this time creating 2 partitions: the first one 50GB, the second about 2.7TB (the remaining space). Everything seems to work correctly. I reboot the system and lo! the second partitions shrinks to about 640GB and the partitioner (using sysinstall) tells me that there are 2048GB free! This happens both with freebsd 7 and 8 current amd64. Thanks for any help. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb keyboard dying at loader prompt
[forwarded to the lists] on 28/11/2008 15:48 Luigi Rizzo said the following: > just as a test, can you check if /boot/loader from 6.2 (or sometime > before jan.2008 - e.g. you could take one from a 6.3 CD) which you > can also find at > > http://info.iet.unipi.it/~luigi/doc/20081128-freebsd-6.3-boot-loader > > gives the same behaviour ? > > I was seeing bugs related to the loader with pxeboot and > the behaviour that you mention below sounds related. > > It also sounds related to a problem that i a started having > recently with an usb keyboard after i upgraded to 7.x > in fact i am going to try this old loader myself! > > let me know how the old loader works and if it fixes the > problem i will relate the two issues and bring them up > on the lists for discussion Luigi, thank you very much for this! With your loader the things are much much better. The keyboard doesn't die anymore at the loader prompt! All in all, it seems that this is right direction. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
MAXFILES in subr_param.c
Hi,
I'm looking at kern/subr_param.c:
72 #ifndef MAXFILES
73 #define MAXFILES (maxproc * 2)
74 #endif
Shouldn't this be at least maxproc*3, for stdin,out,err for every proc?
Also, it looks like MAXFILES is used only once, and in a bit funny way:
238 maxfiles = MAXFILES;
239 TUNABLE_INT_FETCH("kern.maxfiles", &maxfiles);
240 maxprocperuid = (maxproc * 9) / 10;
241 maxfilesperproc = (maxfiles * 9) / 10;
Historical reasons?
signature.asc
Description: OpenPGP digital signature
Re: crypto(9) choose another driver if we cannot open a session on it
On 2008-12-07 22:45:51 (+0100), Patrick Lamaizière <[EMAIL PROTECTED]> wrote: > I wrote a small patch to allow the crypto framework to choose another > cryptographic driver if we cannot open a session on the driver. Very cool. :-) I've been hacking on this too, mainly to get rid of the code duplication that currently exists. > That should not break anything. It would be nice to test it on a box with a > Geode LX CPU and a crypto device like a VPN1411 card. I don't have the > hardware but I've checked that we revert to the cryptosoft driver when using > ipsec and glxsb with AES key's length != 128 bits. I'll test that tonight. I think I've got a hifn card hiding somewhere near a soekris. Thanks! - Philip -- Philip PaepsPlease don't Cc me, I am [EMAIL PROTECTED] subscribed to the list. "Maybe you should loosen her clothing or something." -- Gaspode the wonder dog (Terry Pratchett, Moving Pictures) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Why safe using msleep with timeout=0 but not tsleep?
On Sunday 07 December 2008 02:00:30 pm Marius Nünnerich wrote:
> See subject.
> Interesting commit:
> http://svn.freebsd.org/viewvc/base?view=revision&revision=77059
Lost wakeups. If you have code like so that doesn't use any locks:
int flag;
void
foo(void)
{
flag = 1;
wakeup(&flag);
}
void
bar(void)
{
if (flag == 0)
tsleep(&foo, ..., 0);
}
Then one CPU may run the 'foo' routine to completion after another CPU has
seen 'flag == 0' but before it has put the thread to sleep in tsleep(). Even
on UP systems with preemption you can still get this race if you get
preempted by an interrupt (which runs foo()) in between the 'flag == 0' test
and calling tsleep(). Using an interlock avoid this:
struct mtx lock;
int flag;
void
foo(void)
{
mtx_lock(&lock);
flag = 1;
mtx_unlock(&lock);
wakeup(&flag);
}
void
bar(void)
{
mtx_lock(&lock);
if (flag == 0)
mtx_sleep(&foo, &lock, ..., 0);
mtx_unlock(&lock);
}
In this case 'lock' closes the SMP/preemption races.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Enhancing cdboot [patch for review]
Hi, Below please find patch that enhances cdboot with two compile-time options: 1. CDBOOT_SILENT. When this option is set, the cdboot doesn't produce any messages except "Loading, please wait..." and it also passes RBX_MUTE flag to the next stage to silence it as well. This is intended for custom installations where end-user is not required to see any messages or interfere with the boot process. 2. CDBOOT_PROMPT. When this option is enabled the cdboot behaves like windows xp or vista cd loader, that is it reads MBR from the first hard drive in the system and if the MBR is bootable (i.e. drive has some other operating system installed on it) then it presents user with "Press any key to boot from CD" prompt and waits 20 seconds. If key is not pressed then the control is passed to the MBR, otherwise CD is booted. This is intended for installation CD to allow unattended mode and also helps when installation CD is unintentionally left in the drive of the machine that is set to boot off CD. Any comments/suggestions are appreciated. If there are no objections I would like to commit the change. The long-term goal is to make CDBOOT_PROMPT default mode for installation CD. http://sobomax.sippysoft.com/~sobomax/cdboot.diff -Maxim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Enhancing cdboot [patch for review]
Hi, Below please find patch that enhances cdboot with two compile-time options: 1. CDBOOT_SILENT. When this option is set, the cdboot doesn't produce any messages except "Loading, please wait..." and it also passes RBX_MUTE flag to the next stage to silence it as well. This is intended for custom installations where end-user is not required to see any messages or interfere with the boot process. 2. CDBOOT_PROMPT. When this option is enabled the cdboot behaves like windows xp or vista cd loader, that is it reads MBR from the first hard drive in the system and if the MBR is bootable (i.e. drive has some other operating system installed on it) then it presents user with "Press any key to boot from CD" prompt and waits 20 seconds. If key is not pressed then the control is passed to the MBR, otherwise CD is booted. This is intended for installation CD to allow unattended mode and also helps when installation CD is unintentionally left in the drive of the machine that is set to boot off CD. Any comments/suggestions are appreciated. If there are no objections I would like to commit the change. The long-term goal is to make CDBOOT_PROMPT default mode for installation CD. http://sobomax.sippysoft.com/~sobomax/cdboot.diff -Maxim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Why safe using msleep with timeout=0 but not tsleep?
On Mon, Dec 8, 2008 at 9:17 PM, John Baldwin <[EMAIL PROTECTED]> wrote:
> On Sunday 07 December 2008 02:00:30 pm Marius Nünnerich wrote:
>> See subject.
>> Interesting commit:
>> http://svn.freebsd.org/viewvc/base?view=revision&revision=77059
>
> Lost wakeups. If you have code like so that doesn't use any locks:
>
> int flag;
>
> void
> foo(void)
> {
>
>flag = 1;
>wakeup(&flag);
> }
>
> void
> bar(void)
> {
>
>if (flag == 0)
>tsleep(&foo, ..., 0);
> }
>
> Then one CPU may run the 'foo' routine to completion after another CPU has
> seen 'flag == 0' but before it has put the thread to sleep in tsleep(). Even
> on UP systems with preemption you can still get this race if you get
> preempted by an interrupt (which runs foo()) in between the 'flag == 0' test
> and calling tsleep(). Using an interlock avoid this:
>
> struct mtx lock;
> int flag;
>
> void
> foo(void)
> {
>
>mtx_lock(&lock);
>flag = 1;
>mtx_unlock(&lock);
>wakeup(&flag);
> }
>
> void
> bar(void)
> {
>
>mtx_lock(&lock);
>if (flag == 0)
>mtx_sleep(&foo, &lock, ..., 0);
>mtx_unlock(&lock);
> }
>
> In this case 'lock' closes the SMP/preemption races.
>
> --
> John Baldwin
>
Thank you for the explanation, John!
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Enhancing cdboot [patch for review]
On Mon, Dec 08, 2008 at 02:40:41PM -0800, Maxim Sobolev wrote: > Hi, > > Below please find patch that enhances cdboot with two compile-time options: ... > Any comments/suggestions are appreciated. If there are no objections I > would like to commit the change. The long-term goal is to make > CDBOOT_PROMPT default mode for installation CD. > > http://sobomax.sippysoft.com/~sobomax/cdboot.diff Looks good. Some comments: 1. since there is plenty of space in the cdboot sector, why don't you make the two option always compiled in, controlling which one to activate through flags in the bootsector itself, to be set patching the binary sector itself using a mechanism similar to boot0cfg. Of course you cannot alter a cdrom after you burn it, but it makes it easier to build CDs with one or the other defaults, patching cdboot or the iso image itself before creating/burning it. 2. in fact, the 'silent' option could be disabled at runtime by pressing some key (e.g. adding a short wait loop before proceeding; if this is meant for custom, unattended CDs the extra delay should not matter much); 3. one nitpick -- in one of the first chunks you replace $start with $LOAD, but if i am not mistaken operation depends on $LOAD = $start, so why don't you always use the same ? Also in terms of relocation size, wouldn't it be the case of hardwiring the size of the cd boot sector: - mov $((end_init - start)/2),%cx + mov 1024,%cx 4. another nitpick -- the value you pass in %si to the MBR does not seem to point to anything useful. As discussed about boot0.S and the followup in the mailing lists, there seems to be no standard but at least some MBR expect %si to point to a partition entry, so you should probably initialize one in a way similar way to that used by boot0.S cheers luigi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Enhancing cdboot [patch for review]
Luigi Rizzo wrote: On Mon, Dec 08, 2008 at 02:40:41PM -0800, Maxim Sobolev wrote: Hi, Below please find patch that enhances cdboot with two compile-time options: ... Any comments/suggestions are appreciated. If there are no objections I would like to commit the change. The long-term goal is to make CDBOOT_PROMPT default mode for installation CD. http://sobomax.sippysoft.com/~sobomax/cdboot.diff Looks good. Some comments: Thank you for the review and comments. Please see my answers below. 1. since there is plenty of space in the cdboot sector, why don't you make the two option always compiled in, controlling which one to activate through flags in the bootsector itself, to be set patching the binary sector itself using a mechanism similar to boot0cfg. Of course you cannot alter a cdrom after you burn it, but it makes it easier to build CDs with one or the other defaults, patching cdboot or the iso image itself before creating/burning it. 2. in fact, the 'silent' option could be disabled at runtime by pressing some key (e.g. adding a short wait loop before proceeding; if this is meant for custom, unattended CDs the extra delay should not matter much); Good idea, I will see if I can put that in. In fact this behavior should have to be optional as well, since one of the uses for the "silent" option here is to provide tamper-resistant boot process on custom hardware. 3. one nitpick -- in one of the first chunks you replace $start with $LOAD, but if i am not mistaken operation depends on $LOAD = $start, so why don't you always use the same ? No, they are not the same. $LOAD is address where BIOS loads boot sector, which is 0x7c00 by default (you can configure it when building CD-ROM, which is why it's an option). On the other hand, $start is address where code is compiled to be located, which is 0x0600. Also in terms of relocation size, wouldn't it be the case of hardwiring the size of the cd boot sector: - mov $((end_init - start)/2),%cx + mov 1024,%cx Well, I don't see the reason to hardwire this. CDROM boot code can be of different size (within certain limits of course, to be selected when building ISO), it's not limited to fixed number of sectors like boot[012]. 4. another nitpick -- the value you pass in %si to the MBR does not seem to point to anything useful. As discussed about boot0.S and the followup in the mailing lists, there seems to be no standard but at least some MBR expect %si to point to a partition entry, so you should probably initialize one in a way similar way to that used by boot0.S Hmm, maybe I misunderstood it then. What do you mean by "point to partition entry exactly"? Right now it points to the beginning on MBR. -Maxim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Enhancing cdboot [patch for review]
On Mon, 08 Dec 2008 16:29:04 -0800, Maxim Sobolev <[EMAIL PROTECTED]> wrote:
> Luigi Rizzo wrote:
>> On Mon, Dec 08, 2008 at 02:40:41PM -0800, Maxim Sobolev wrote:
>>> Hi,
>>> Below please find patch that enhances cdboot with two compile-time options:
>> ...
>>> Any comments/suggestions are appreciated. If there are no objections I
>>> would like to commit the change. The long-term goal is to make
>>> CDBOOT_PROMPT default mode for installation CD.
>>>
>>> http://sobomax.sippysoft.com/~sobomax/cdboot.diff
>>
>> Looks good. Some comments:
>
> Thank you for the review and comments. Please see my answers below.
>
>> 1. since there is plenty of space in the cdboot sector, why don't you
>>make the two option always compiled in, controlling which one to
>>activate through flags in the bootsector itself, to be set
>>patching the binary sector itself using a mechanism similar to
>>boot0cfg.
>> Of course you cannot alter a cdrom after you burn it,
>>but it makes it easier to build CDs with one or the other defaults,
>>patching cdboot or the iso image itself before creating/burning it.
>>
>> 2. in fact, the 'silent' option could be disabled at runtime by
>>pressing some key (e.g. adding a short wait loop before proceeding;
>>if this is meant for custom, unattended CDs the extra delay should not
>>matter much);
>
> Good idea, I will see if I can put that in. In fact this behavior should
> have to be optional as well, since one of the uses for the "silent"
> option here is to provide tamper-resistant boot process on custom
> hardware.
Nice pair of features :-)
If there are no pressing space constraints maybe we can build both
options in by default, but still make them opt-out when necessary?
With a bit of makefile glue we can make it possible to compile with an
`src.conf' that includes:
WITH_CDBOOT_SILENT=1
WITHOUT_CDBOOT_PROMPT=1
This way the defaults can include support for both options, but we can
conditionally compile *out* the bits that are not needed for some custom
installation.
Something like this can define one or both of these options in CFLAGS,
depending on what `src.conf' contains:
# When CDBOOT_SILENT is set, the cdboot doesn't produce any messages except
# "Loading, please wait..." and it also passes RBX_MUTE flag to the next
# stage to silence it as well. This is intended for custom installations
# where end-user is not required to see any messages or interfere with the
# boot process.
.if ${MK_CDBOOT_SILENT} != "no"
CFLAGS+= -DCDBOOT_SILENT
.endif
# When CDBOOT_PROMPT is enabled the cdboot behaves like windows xp or vista
# cd loader, that is it reads MBR from the first hard drive in the system
# and if the MBR is bootable (i.e. drive has some other operating system
# installed on it) then it presents user with "Press any key to boot from
# CD" prompt and waits for 20 seconds. If key is not pressed then the
# control is passed to the MBR, otherwise CD is booted. This is intended for
# installation CD to allow unattended mode and also helps when installation
# CD has been unintentionally left in the drive of the machine that is set
# to boot off CD.
.if ${MK_CDBOOT_PROMPT} != "no"
CFLAGS+= -DCDBOOT_PROMPT
.endif
The defaults for ${MK_CDBOOT_XXX} will have to be explicitly set in
`src/share/mk/bsd.own.mk', near line 281:
281 #
282 # MK_* options which default to "yes".
283 #
284 .for var in \
...
But that shouldn't be a problem, AFAICT :-)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Enhancing cdboot [patch for review]
On Mon, Dec 08, 2008 at 04:29:04PM -0800, Maxim Sobolev wrote: > Luigi Rizzo wrote: ... > >4. another nitpick -- the value you pass in %si to the MBR does not > > seem to point to anything useful. As discussed about boot0.S and > > the followup in the mailing lists, there seems to be no standard > > but at least some MBR expect %si to point to a partition entry, > > so you should probably initialize one in a way similar way to that > > used by boot0.S > > Hmm, maybe I misunderstood it then. What do you mean by "point to > partition entry exactly"? Right now it points to the beginning on MBR. ok, so here is what I know. Even though there is no standard, at least ldlinux.sys and perhaps other bootloaders expect %si to point to a 16-byte record containing the partition descriptor (same structure as one of the 4 records at 0x1be in the MBR) for the partition they were loaded from. ldlinux.sys uses this info to "relocate": it knows the location of the other sectors of ldlinux.sys relative to the beginning of the partition, and uses the start-of-partition from the record at %si to compute these locations in terms of absolute disk positions. Note that in principle a MBR does not need this info -- even if it is a multi-sector boot code such as boot0ext, it may well assume to be located at offset 0. On the other hand if the code on the MBR uses %si, then you should set the entry so that at least the starting CHS and LBA info point to the first sector on disk, i.e. CHS=0,0,1 and LBA=0. In practical terms -- make %si point to a 16-byte area of memory containing all 0's except for the byte representing the sector number for the start of the partition. See the code in a recent sys/boot/i386/boot0/boot0.S which gives some details on this. cheers luigi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Enhancing cdboot [patch for review]
Luigi Rizzo wrote: On Mon, Dec 08, 2008 at 04:29:04PM -0800, Maxim Sobolev wrote: Luigi Rizzo wrote: ... 4. another nitpick -- the value you pass in %si to the MBR does not seem to point to anything useful. As discussed about boot0.S and the followup in the mailing lists, there seems to be no standard but at least some MBR expect %si to point to a partition entry, so you should probably initialize one in a way similar way to that used by boot0.S Hmm, maybe I misunderstood it then. What do you mean by "point to partition entry exactly"? Right now it points to the beginning on MBR. ok, so here is what I know. Even though there is no standard, at least ldlinux.sys and perhaps other bootloaders expect %si to point to a 16-byte record containing the partition descriptor (same structure as one of the 4 records at 0x1be in the MBR) for the partition they were loaded from. ldlinux.sys uses this info to "relocate": it knows the location of the other sectors of ldlinux.sys relative to the beginning of the partition, and uses the start-of-partition from the record at %si to compute these locations in terms of absolute disk positions. Note that in principle a MBR does not need this info -- even if it is a multi-sector boot code such as boot0ext, it may well assume to be located at offset 0. On the other hand if the code on the MBR uses %si, then you should set the entry so that at least the starting CHS and LBA info point to the first sector on disk, i.e. CHS=0,0,1 and LBA=0. In practical terms -- make %si point to a 16-byte area of memory containing all 0's except for the byte representing the sector number for the start of the partition. See the code in a recent sys/boot/i386/boot0/boot0.S which gives some details on this. I see, thank you for the explanation. It looks like it only makes sense for multi-stage boot loaders, when the stage has been loaded from some location within the disk and it needs some clue to determine where it has came from. In this case we simply emulate BIOS loading MBR, and from what I've read here MBR code should make no assumptions with regard to %si, so that I would just set it to zero. Do you think it could create any issues? -Maxim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
