Re: document 'machine boot' on i386/amd64
They found it... :) -Toby. On Wed, Nov 6, 2013 at 9:08 AM, Brynet bry...@gmail.com wrote: It seems boot(8) on i386/amd64 has an undocumented feature that is occasionally handy. This adds a small blurb to the man pages for both so that people can find it. -Bryan. Index: i386/stand/boot/boot.8 === RCS file: /cvs/src/sys/arch/i386/stand/boot/boot.8,v retrieving revision 1.58 diff -u -p -u -r1.58 boot.8 --- i386/stand/boot/boot.8 28 Oct 2013 15:15:08 - 1.58 +++ i386/stand/boot/boot.8 6 Nov 2013 16:54:05 - @@ -204,6 +204,18 @@ commands, if any. Issues machine-dependent commands. These are defined for i386 architecture: .Bl -tag -width diskinfo +.It Nm boot +Boots the specified partition boot block in place of the original (MBR) boot +block: +.Bd -unfilled -offset indent +machine boot hd0a +.Ed +.Pp +Where +.Ar a +is the first MBR partition table entry, and +.Ar d +the last. .It Nm comaddr Set the I/O base address for the serial port to be used as serial console. .It Nm diskinfo Index: amd64/stand/boot/boot.8 === RCS file: /cvs/src/sys/arch/amd64/stand/boot/boot.8,v retrieving revision 1.21 diff -u -p -u -r1.21 boot.8 --- amd64/stand/boot/boot.8 28 Oct 2013 15:15:08 - 1.21 +++ amd64/stand/boot/boot.8 6 Nov 2013 16:54:19 - @@ -204,6 +204,18 @@ commands, if any. Issues machine-dependent commands. These are defined for amd64 architecture: .Bl -tag -width diskinfo +.It Nm boot +Boots the specified partition boot block in place of the original (MBR) boot +block: +.Bd -unfilled -offset indent +machine boot hd0a +.Ed +.Pp +Where +.Ar a +is the first MBR partition table entry, and +.Ar d +the last. .It Nm comaddr Set the I/O base address for the serial port to be used as serial console. .It Nm diskinfo
Re: Configure ttys and console.
A single user shell is the shell you get if you boot with the -s flag, not the way your system is usually running. -Toby. On Fri, Aug 2, 2013 at 9:02 AM, sven falempin sven.falem...@gmail.com wrote: Hello, For obscure reason i would like to have a root shell with no login on the com port. I of course get through man ttys, getty, termcap, login ... Currently i have a working solution by modifying gettytab and specifying lo string there. Still, i have to enter root\n before getting the prompt. But the mail is more about this configuration : # cat /etc/ttys console /usr/libexec/getty std.9600 vt220 on secure # cat /etc/boot.conf stty com0 9600 set tty com0 given my poor english I was expecting a prompt on my serial port, but this is not working at all, while this: # cat /etc/ttys tty00 /usr/libexec/getty std.9600 vt220 on secure gives a login prompt as expected. Is the manual unclear (or not clear enough for me...) or ??? something else is missing ? (like saying console is on tty00) secure If on is also specified, allows users with a UID of 0 to log in on this line. If set for the console entry, then init(8) will start a single-user shell without asking for the superuser password. this is done on 5.3 stable -- - () ascii ribbon campaign - against html e-mail /\
Re: Security and ignorance from the major ISPs
There is really only one know good firewall that works 100% of the time... -Toby.
Re: Pipe text from mg to external command
irrespective of all the talk going on here... :) -Toby.
Re: Scheduler improvements
I like what I see. It could be the start for the means of managing a single socket's queue of processes. You do mention that this won't really scale beyond roughly 8 cores. I would love to see you extend this with a 2D array of weights that can be populated by various means (run-time testing, or ACPI tables, etc) with the relative costs of moving a process from one core to another (or one scheduling queue to another, if queue's are assigned to a set of cores, say a socket full of cores). In this way, we may be able to have cores shut down by modifying these weights based on demand/load. While I agree with your comments that OpenBSD was not originally made for lots of cpu/cores, I don't really wish to entertain huge steps backwards on that front. The rthreads work (amoung other work) has been done with an eye towards more efficiently using MP systems. Again, I like this, looks simpler. Let's see you try and solve more of the MP parts as well. :) -Toby.
Re: two minor carp and pfsync fixes
I'm sure you did. Did you test it with one patched and one not?
-Toby.
On Wed, Jun 22, 2011 at 1:37 AM, Stefan Rinkes
stefan.rin...@googlemail.com wrote:
On Tue, Jun 21, 2011 at 9:42 PM, Tobias Weingartner weing...@tepid.org
wrote:
On Tue, Jun 21, 2011 at 11:52 AM, Stefan Rinkes
stefan.rin...@googlemail.com wrote:
while playing around with carp and pfsync I spotted
two minor bugs.
1. Not all pfstate flags are synced, cause pfsync uses
u_int8_t, while pf uses u_int16_t for state_flags.
Currently that means PFSTATE_SCRUB_TCP flags don't
get synced.
retrieving revision 1.333
diff -u -p -r1.333 pfvar.h
--- sys/net/pfvar.h 20 Jun 2011 19:03:41 - 1.333
+++ sys/net/pfvar.h 21 Jun 2011 17:33:31 -
@@ -892,13 +892,13 @@ struct pfsync_state {
u_int8_t proto;
u_int8_t direction;
u_int8_t log;
- u_int8_t state_flags;
+ u_int16_tstate_flags;
u_int8_t timeout;
u_int8_t sync_flags;
u_int8_t updates;
u_int8_t min_ttl;
u_int8_t set_tos;
- u_int8_t pad[4];
+ u_int8_t pad[3];
} __packed;
Does this change the on-wire format? Also, would the state_flags need to
have htons/ntohs done to it?
-Toby.
Hi,
I tested this diff quite carefully and used it for over a week now and
checked that all
state_flags are synced by adding a new flag which triggered a printf in
pf(4) :)
No issues/crashes have been seen so far.
Stefan
Re: two minor carp and pfsync fixes
On Tue, Jun 21, 2011 at 11:52 AM, Stefan Rinkes
stefan.rin...@googlemail.com wrote:
while playing around with carp and pfsync I spotted
two minor bugs.
1. Not all pfstate flags are synced, cause pfsync uses
u_int8_t, while pf uses u_int16_t for state_flags.
Currently that means PFSTATE_SCRUB_TCP flags don't
get synced.
retrieving revision 1.333
diff -u -p -r1.333 pfvar.h
--- sys/net/pfvar.h 20 Jun 2011 19:03:41 - 1.333
+++ sys/net/pfvar.h 21 Jun 2011 17:33:31 -
@@ -892,13 +892,13 @@ struct pfsync_state {
u_int8_t proto;
u_int8_t direction;
u_int8_t log;
- u_int8_t state_flags;
+ u_int16_tstate_flags;
u_int8_t timeout;
u_int8_t sync_flags;
u_int8_t updates;
u_int8_t min_ttl;
u_int8_t set_tos;
- u_int8_t pad[4];
+ u_int8_t pad[3];
} __packed;
Does this change the on-wire format? Also, would the state_flags need to
have htons/ntohs done to it?
-Toby.
Re: horribly slow fsck_ffs pass1 performance
On Saturday, April 2, Amit Kulkarni wrote: FreeBSD which is the origin of FFS does a background fsck, and if Kirk McCusick feels so strongly I will do it too. FreeBSD was not the origin of the FFS code. Background fsck in freebsd is mainly meant to reduce the amount of time it takes to get to a useable system at boot (after an unclean shutdown). -Toby.
Re: top, systat and hw.cpuspeed
On Wednesday, March 23, David Vasek wrote: As majority of current hardware use some form of dynamic CPU frequency scaling and it is frequently controlled by ampd, wouldn't it be good to have the current hw.cpuspeed displayed somewhere in the header lines of systat(1) and top(1)? Just to know the scale for other performace figures on the display. Is it safe to plan for 9.999 GHz maximum CPU frequency? For each core? -Toby.
Re: top, systat and hw.cpuspeed
On Wednesday, March 23, Amit Kulkarni wrote: Never know what they can do. But the current max is 6 GHz by IBM for any core, right? :) The majority of current hardware do per core frequency scaling (or bursting), but hw.cpuspeed is reporting the BIOS CPU speed (considering over and under clocking) for each core before the scaling happens, right? So going forward with such complicated CPU designs, top will lie or be misleading. What about 64+ cores (OpenBSD supports 64 cores!) and many of them idle with low frequencies? How do you display them? I tried it and like it as end user, its cool. Wait for other gurus to chime i n. What I mean, is should you be adding the current frequency of each core and display it as a total, only show the max(freq(cpu(N))), or the avg(freq(cpu(N))), or some other metric? -Toby.
Re: carp shutdown in /etc/rc
On Friday, February 4, Henning Brauer wrote: i don't think there is is special treatment for the carp group. but memory is fuzzy. we might very well forget to clean up when a group becomes empty. There is a bit of an inconsistency when it comes to 'ifconfig foo' style of the ifconfig command. You can do 'ifconfig groupname', and it will show all interfaces in group groupname. You can also do 'ifconfig dev-prefix', which seems to show all the interfaces with the particular device prefix. For example, on my box, if I do 'ifconfig bge', it will show me all bge* interfaces, even if none of them are in a group called 'bge'. So the shutdown could be correct using 'ifconfig carp', if that command would return all carp interfaces because carp is the dev-prefix. However, since we have a carp group, it uses that instead... --Toby.
Re: Allegations regarding OpenBSD IPSEC
On Wednesday, December 15, Kevin Chadwick wrote: The real work on OCF did not begin in earnest until February 2000. I can't see how this gives you credibility but maybe the people who worked with you at the time can understand how your evidence supports what you say. I've known Jason for quite a while, and nothing has ever let me believe that I should question his character, motives or otherwise make me believe he was not a straightforward and honest person. I think even in the USA a person is INNOCENT, until PROVEN guilty. So in this case, you're the one that is out of line. You're the one the onus of proof is on. Jason has no need to give you evidence. Quite frankly, dragging Jason (or anyone else) through the mud in this fashion is completely disgusting, deplorable, and stinks. This will be the last I say on this subject. --Toby.
Re: better matching of boot devices on amd64
On Thursday, December 2, David Gwynne wrote:
the boot loader passes a variable that identifies the disk its
booting off made up of a bunch of fields like adapter, controller,
disk, and partition offsets, plus a table of all the disks it can
see which includes this id and a checksum.
Unfortunately, on the PC there is no 100% reliable mapping between the
BIOS disk number (which is used for booting), and the device path used
on the obsd side. So in essence, we need to find the device we booted
from. This was/is the point to the checksums. At the point where the
checksum stuff was implemented, I seriously thought about sending the
checksum of the boot device through the bootdev var during boot. With
a few special cases to signify network/etc style boots. This seemed
somewhat hackish...
I've always wondered why the B_* defines in reboot.h were MI, as opposed
to MD. Booting is inherantly a very MD stype of thing. Something that
makes 100% sense on the VAX will likley map poorly or not at all to a PC
or a Sun box. Anyways, that all aside...
the kernel goes through and checksums the disks and then maps that
back to the id associated with that disk, and then compares some
of the fields in those ids against the boot disks id to figure out
which disk its on.
Yup, and this works most of the time... unless you happen to have all
the disks zero'd or otherwise bit-identical. :)
the problem is we overflow one of those fields (the disk id one).
since the other fields are set to 0 by the boot loader, this doesnt
really matter that much. however, since those fields are now
significant because of the overflow, we should compare them too.
this prevents sd16 being matched as the boot disk after sd0 on my
system with 25 disks attached.
sorry if this explanation sucks.
Nope, no suck. Makes sense. Hackish solution, but likely the best one
for right now. A quick egrep through /usr/src seems to indicate that
the only parts of the kernel that really care are MD parts, and nothing
really uses it in userland. Prime candidate to re-factor someday.
ok?
Index: dkcsum.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/dkcsum.c,v
retrieving revision 1.15
diff -u -p -r1.15 dkcsum.c
--- dkcsum.c 10 Dec 2008 23:41:19 - 1.15
+++ dkcsum.c 2 Dec 2010 05:08:25 -
@@ -71,10 +71,13 @@ dkcsumattach(void)
#ifdef DEBUG
printf(dkcsum: bootdev=%#x\n, bootdev);
- for (bdi = bios_diskinfo; bdi-bios_number != -1; bdi++)
- if (bdi-bios_number 0x80)
- printf(dkcsum: BIOS drive %#x checksum is %#x\n,
- bdi-bios_number, bdi-checksum);
+ for (bdi = bios_diskinfo; bdi-bios_number != -1; bdi++) {
+ if (bdi-bios_number 0x80) {
+ printf(dkcsum: BIOS drive %#x bsd_dev=%#x
+ checksum=%#x\n, bdi-bios_number, bdi-bsd_dev,
+ bdi-checksum);
+ }
+ }
#endif
pribootdev = altbootdev = 0;
@@ -180,7 +183,9 @@ dkcsumattach(void)
*/
/* B_TYPE dependent hd unit counting bootblocks */
- if ((B_TYPE(bootdev) == B_TYPE(hit-bsd_dev))
+ if ((B_ADAPTOR(bootdev) == B_ADAPTOR(hit-bsd_dev))
+ (B_CONTROLLER(bootdev) == B_CONTROLLER(hit-bsd_dev))
+ (B_TYPE(bootdev) == B_TYPE(hit-bsd_dev))
(B_UNIT(bootdev) == B_UNIT(hit-bsd_dev))) {
int type, ctrl, adap, part, unit;
I'm likely late to the party, but it looks ok. And if it works, I really
can't test this... then it's ok by me.
--Toby.
Re: AES-GCM Part 1: AES-GCM implementation
Not sure if anyone has responded yet... been a while since I've actually had time to read any of these lists. :( Anyways, comments inline On Friday, August 20, Mike Belopuhov wrote: Index: crypto/cryptodev.h === RCS file: /home/cvs/src/sys/crypto/cryptodev.h,v retrieving revision 1.51 diff -u -p -r1.51 cryptodev.h --- crypto/cryptodev.h23 Jun 2010 09:26:32 - 1.51 +++ crypto/cryptodev.h28 Jul 2010 16:13:56 - @@ -105,7 +105,12 @@ #define CRYPTO_SHA2_512_HMAC 20 #define CRYPTO_AES_CTR 21 #define CRYPTO_AES_XTS 22 -#define CRYPTO_ALGORITHM_MAX 22 /* Keep updated */ +#define CRYPTO_AES_GCM_1623 +#define CRYPTO_AES_128_GMAC 24 +#define CRYPTO_AES_192_GMAC 25 +#define CRYPTO_AES_256_GMAC 26 +#define CRYPTO_AES_GMAC 27 +#define CRYPTO_ALGORITHM_MAX 28 /* Keep updated */ /* Algorithm flags */ #define CRYPTO_ALG_FLAG_SUPPORTED 0x01 /* Algorithm is supported */ Ok, the ..._MAX define was == to the last define before, now it's one more than the largest? Did you adjust the code to match? Not that I can see... -Toby.
Re: better cpu throttling
On Wednesday, June 30, Darrin Chandler wrote: What you're saying is true, but that's not the only use case. Streaming media may not benefit from 100% cpu but may not be able to work properly at 0%. The same goes for other common tasks as well. Running at 30% or 50% will indeed save power for those cases where running at 100% won't make what you're doing finish faster and running at 0% won't work. You're assuming that the switch is so slow that running at a constant average factor (of whatever) is better than simply switching to high mode when there are things to do (not in idle loop), and going back to low mode when there is nothing left to do (in idle loop/etc). The system could litteraly be switching high/low several thousand times a second... Try the diff, see if it works for you. --Toby.
Re: [BUG] Fix int 0x15, e820 call
On Wednesday, June 23, Daniel Dickman wrote:
Index: amd64/stand/libsa/memprobe.c
===
RCS file: /usr/cvs/src/sys/arch/amd64/stand/libsa/memprobe.c,v
retrieving revision 1.6
diff -u -r1.6 memprobe.c
--- amd64/stand/libsa/memprobe.c 30 Nov 2009 16:33:20 - 1.6
+++ amd64/stand/libsa/memprobe.c 24 Jun 2010 00:04:47 -
@@ -72,9 +72,9 @@
do {
BIOS_regs.biosr_es = ((u_int)(mp) 4);
__asm __volatile(DOINT(0x15) ; setc %b1
- : =a (sig), =d (rc), =b (off)
- : 0 (0xE820), 1 (0x534d4150), b (off),
- c (sizeof(*mp)), D (((u_int)mp) 0xF)
+ : =a (sig), =c (rc), =b (off)
+ : 0 (0xE820), d (0x534d4150), b (off),
+ 1 (sizeof(*mp)), D (((u_int)mp) 0xF)
: cc, memory);
off = BIOS_regs.biosr_bx;
If you notice, the asm part does a setc %b1. And in your
case, that would simply nuke %ecx. The original code did not
take into account the length returned, it ignored it as it
was asking for the max, some biosen always return the max,
and nothing should ever return more than what was asked for,
or less than 20 bytes.
I don't know how this fixes any bug off hand. The following
diff may. Compiled tested, but otherwise not tested. Similar
diff would need to be made for i386:
Index: memprobe.c
===
RCS file: /cvs/src/sys/arch/i386/stand/libsa/memprobe.c,v
retrieving revision 1.46
diff -u memprobe.c
--- memprobe.c 30 Nov 2009 16:33:20 - 1.46
+++ memprobe.c 24 Jun 2010 03:45:11 -
@@ -67,19 +67,19 @@
static __inline bios_memmap_t *
bios_E820(bios_memmap_t *mp)
{
- int rc, off = 0, sig, gotcha = 0;
+ int rc, off = 0, sig, gotcha = 0, size = 0;
do {
BIOS_regs.biosr_es = ((u_int)(mp) 4);
__asm __volatile(DOINT(0x15) ; setc %b1
- : =a (sig), =d (rc), =b (off)
+ : =a (sig), =d (rc), =b (off), =c (size)
: 0 (0xE820), 1 (0x534d4150), b (off),
- c (sizeof(*mp)), D (((u_int)mp) 0xF)
+ 3 (sizeof(*mp)), D (((u_int)mp) 0xF)
: cc, memory);
off = BIOS_regs.biosr_bx;
- if (rc 0xff || sig != 0x534d4150)
+ if (rc 0xff || sig != 0x534d4150 || size != 20)
break;
gotcha++;
if (!mp-type)
Chances are the diff will need to be applied by hand (just noticed
the space/tab isue with it).
--Toby.
Re: Source Overview
On Monday, April 19, Adam M. Dutko wrote: 1) Are there areas that are easier for relative newbies to start in versus other areas? I know this depends on a lot of things, to include experience. Hypothetically, someone that has some C experience, but not a lot of kernel (and subsystem) experience. Is it better to start from the bottom up like bootstrap to init? or is it better to start with memory management? network drivers? What is usually the best area from a learning and future utility perspective? Many a kernel hacker was suckered into the fold by writing a network driver. In general, drivers are fairly easy, in that there are lots to copy from, and they tend to be fairly self-contained. 2) Is there something like an openbsd janitors project where newbies can start contributing small patches? similar to the Linux janitors project? Well, there is the bug database. In general, people pick what they don't like, or otherwise causes them to itch in uncomfortable places, and they then scratch that itch until... well, you know, they're satisfied. :) Seriously, pick something, and start in. If it's too much, move to another area. Don't get discouraged, just keep trying. --Toby.
Re: Patch for boot for enabling gate A20 with BIOS
On Monday, March 1, Giuseppe Magnotta wrote:
+/*
+ * Author: Giuseppe Magnotta giuseppe.magno...@gmail.com
While I applaud your efforts to send in patches, I do have a
small niggle. Why do you feel the need to splatter your
authorship all over the code in comments? Why not just add
your name to the copyright statement and be done with it?
+ * Enable the gate A20 by using the INT 15/AX=2401h if the
+ * BIOS supports it.
+ *
+ * Returns 0 if ok or the error code fetched from AH register.
I did consider (and try) to use this BIOS function way back when
I wrote a good chunk of this code. Turns out that most BIOSen do
not implement this function. Also, I've yet to meet a BIOS/system
that needs this function (IE: has A20 off, and does not use one of
the two methods we have to turn it on).
+static __inline int
+enableA20Gate(void)
+{
+ char status;
+ short r;
+
+ __asm __volatile(DOINT(0x15) \n\t
+ setc %1\n\t
+ : =a (r), =r (status)
+ : 0 (0x2401)
+ : cc);
+
+ if (status)
+ return (r 8);
+ else
+ return 0;
+}
/*
* Probe-style routine (no parameters) to turn A20 on
@@ -58,7 +83,9 @@
void
gateA20(int on)
{
- if (ps2model == 0xf82 ||
+ if (enableA20Gate() == 0) {
+ /* gate A20 enabled! */
+ } else if (ps2model == 0xf82 ||
(inb(IO_KBD + KBSTATP) == 0xff inb(IO_KBD + KBDATAP) == 0xff))
{
int data;
Do you know of a system that benefits from this? In other words, does
this fix a system currently not working?
--Toby.
Re: Patch for boot for enabling gate A20 with BIOS
On Monday, March 1, Giuseppe Magnotta wrote: My question is, if this functionality is available in the BIOS, why can't we use it? The problem is having a broken BIOS out there that simply hangs because you're calling something that it does not support. When this stuff was written, there were many reports of systems that did not implement some part of some BIOS call, and would simply hang, or cause other issues further down the road. As such, I'm hesitant to add functionality such as this without at least one system that needs it, or one system that clearly benefits from such a change. If this was just after the release, and there was sufficient testing across different MB/BIOS combos, then I'd consider it. One MB does not a test make. I remember having several dozen *different* MB/BIOS combo's tested for each and every change that was made in this area. Trust me, the testing was not fun. So, if you think this is something that should go in, then I'd implore you to get more testing and test reports. I'd be wanting all the MB/BIOS/cpu combinations that were tested before this is committed. --Toby.
Re: enhancing i386 mbr.S
On Saturday, February 20, Giuseppe Magnotta wrote: The original source is $OpenBSD: mbr.S,v 1.21 2007/06/25 14:10:17 tom Exp $ fetched from 4.6 release. I hope this can be useful... Best Regards Giuseppe The patch is: diff mbr.S.orig mbr.S: Ugh... please send 'diff -u' instead. -Toby.
Re: enhancing i386 mbr.S
I like it... for the most part. On Saturday, February 20, Giuseppe Magnotta wrote: Index: mbr.S === RCS file: /cvs/src/sys/arch/i386/stand/mbr/mbr.S,v retrieving revision 1.21 diff -u -r1.21 mbr.S --- mbr.S 25 Jun 2007 14:10:17 - 1.21 +++ mbr.S 20 Feb 2010 15:40:04 - @@ -35,6 +35,13 @@ * with the other copyrights as long as you retain my pseudonym and * this copyright notice in the file. */ +/* Copyright (c) 2010 Giuseppe Magnotta giuseppe.magno...@gmail.com + * last edited 20 Feb 2010 + * Added the check for a single bootable partition. + * You may use this code or fragments thereof in a manner consistent + * with the other copyrights as long as you retain my pseudonym and + * this copyright notice in the file. + */ This can be achieved by simply adding your Copyright (C) line right below the other copyright lines in the file. The extra text is not necessary, or contains comments that should be in the commit message. .file mbr.S @@ -224,12 +231,26 @@ drive_ok: /* Find the first active partition. - * Note: this should be the only active partition. We currently - * don't check for that. + * Note: this should be the only active partition. We check for that. This can be shorter. Find first and check for only active partition. Thanks for updating comments to reflect reality. */ movw$pt, %si movw$NDOSPART, %cx + xorw%ax, %ax + xorw%bx, %bx + +test_pt: + movb(%si), %al + addw%ax, %bx + addw$PARTSZ, %si + looptest_pt + + cmpw$DOSACTIVE, %bx + jne no_part + + movw$pt, %si + movw$NDOSPART, %cx + Nice way to do this. When I wrote this I must have been out to lunch, considering the simple way to do this. find_active: DBGMSG(CHAR_L) movb(%si), %al @@ -533,7 +554,7 @@ efdmbr: .asciz MBR on floppy or old BIOS\r\n eread: .asciz \r\nRead error\r\n enoos: .asciz No O/S\r\n -enoboot: .ascii No active partition /* runs into crlf... */ +enoboot: .ascii Error selecting bootable partition /* runs in to crlf... */ crlf:.asciz \r\n I wish there was a shorter way to indicate this. Some MBRs I know simply say Corrupt Partition Table, which might be good enough and a bit shorter. Are you ok with the modification to your copyright/comment statement above? --Toby.
Re: enhancing i386 mbr.S
On Saturday, February 20, Ted Unangst wrote: Is this really an improvement? If I have two bootable partitions, at least one of them will boot now, letting me fix the problem. If you refuse to boot, now I need to dig around in my toy box for a floppy drive or something before I can fix it. I would prefer booting into the wrong OS over not booting any day. If that is the case, why not take the check for 55AA out as well? It would be better to complain about malformed/corrupted MBR's, rather than silently continuing. The question that would arise for me immediately, is how did it get messed up? Disk corruption? Or something else? --Toby.
Re: enhancing i386 mbr.S
On Saturday, February 20, Miod Vallat wrote: There's a huge difference between garbage in the mbr, and user error causing two partitions to be marked as active. From the point of view of the MBR, not really. They're both corruption. One just happens to be more likely to be survivable, but since we have no checksums/etc to doublecheck the validity of the MBR, they both amount to garbage. One just happens to be a tad more palatable. --Toby.
Re: enhancing i386 mbr.S
On Saturday, February 20, Kenneth R Westerback wrote: I vote with Ted. Booting, even the wrong partition, seems better to me than not booting anything. The MBR is not really supposed to boot if it is corrupted. There are plenty of MBR codes out there that check for this condition, and will abort if it exists. Even DOS33 did so. In the end, it's a bikeshed, and everyone will have an opinion... --Toby.
Re: [PATCH] i386: Disable the Pentium3 (model 8) serial number
On Friday, October 30, Remco wrote:
I don't know if this is still relevant but I noticed that the Pentium III
processor serial number isn't disabled for model 8 processors.
(patch was tested on 4.6-STABLE)
Index: sys/arch/i386/i386/machdep.c
===
RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
retrieving revision 1.453
diff -u -r1.453 machdep.c
--- sys/arch/i386/i386/machdep.c 15 Jun 2009 17:01:26 - 1.453
+++ sys/arch/i386/i386/machdep.c 30 Oct 2009 11:18:07 -
@@ -1489,7 +1489,8 @@
/*
* Disable the Pentium3 serial number.
*/
- if ((model == 7) (ci-ci_feature_flags CPUID_SER)) {
+ if ( ((model == 7) || (model == 8))
+ (ci-ci_feature_flags CPUID_SER) ) {
msr119 = rdmsr(MSR_BBL_CR_CTL);
msr119 |= 0x0020LL;
wrmsr(MSR_BBL_CR_CTL, msr119);
This does look right. However, I'm inclined not to bother.
The serial number will track me and invade my privacy lore
has largely died down (at least wrt CPUs). The chances of
this nuking an innocent model 8 that did not have the PSN
anymore, and re-tasked that un-documented bit as something
else makes me think that the risk (while low) is higher than
the benefit (which I believe is non-existant).
Your BIOS should have means to turn the PSN off, which is
the right place to be doing this.
--Toby.
