Re: Sign fixes for disklabel(8)
On Sat, 16 Nov 2002, Tim Robbins wrote:
> On Fri, Nov 15, 2002 at 03:59:25PM -0800, Julian Elischer wrote:
>
> > Here are the diffs to allow disklabel to correctly create partitions >
> > 1TB (up to 2TB is useful with UFS2) pending a different partitionning
> > scheme. It also allows you to correctly make smaller partitions beyond
> > 1TB which is nice if you don't want to waste 800GB on an array :-)
> >
> >
> > permission to commit please?
> > (pending comments by others)
> >
> > (also the sysinstall changes posted before)
> > (also the bluetooth code)
> [...]
> > - v = atoi(tp);
> > + v = strtoul(tp, NULL, 0);
> > if (v <= 0 || (v % DEV_BSIZE) != 0) {
> > fprintf(stderr,
> > "line %d: %s: bad sector size\n",
>
> Should be == 0, not <= 0 since v is unsigned.
>
> [...]
> > - v = atoi(tp);
> > + v = strtoul(tp, NULL, 0);
> > if (v < 0) {
> > fprintf(stderr, "line %d: %s: bad %s\n",
> > lineno, tp, cp);
>
> v < 0 is impossible.
In the overflow case, strtoul returns ULONG_MAX. Or if you're interested
in catching invalid characters, use endptr.
-Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /dev/acd*t* no longer available in -current?
Thus spake Robert Watson <[EMAIL PROTECTED]>: > So one thing we could start doing is have sysinstall's adduser stuff offer > to place new users in the operator group, and set up the default > permissions on removable devices such that the operator group has > read/write access to them (or even just read-access). This would be > logically equivilent to placing users in an admin group at instlal on > Windows or Mac OS X. Operator access connotes the ability to shut down > the system in FreeBSD, as well as the ability to dump file systems, etc. > Another possibility would be to evolve our notion of console user based on > fbtab some for workstation configurations. I think putting new users in the operator group, even as a default-off option, is more liberal than necessary. Using fbtab to allow access to removable and audio devices seems like the right thing to do. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Sign fixes for disklabel(8)
On Fri, Nov 15, 2002 at 03:59:25PM -0800, Julian Elischer wrote:
> Here are the diffs to allow disklabel to correctly create partitions >
> 1TB (up to 2TB is useful with UFS2) pending a different partitionning
> scheme. It also allows you to correctly make smaller partitions beyond
> 1TB which is nice if you don't want to waste 800GB on an array :-)
>
>
> permission to commit please?
> (pending comments by others)
>
> (also the sysinstall changes posted before)
> (also the bluetooth code)
[...]
> - int v, lineno = 0, errors = 0;
> + unsigned int v;
> + int lineno = 0, errors = 0;
> int i;
[...]
> - v = atoi(tp);
> + v = strtoul(tp, NULL, 0);
> if ((unsigned)v >= DKMAXTYPES)
> fprintf(stderr, "line %d:%s %d\n", lineno,
> "Warning, unknown disk type", v);
This cast is redundant since v is already unsigned. The fprintf() format
string needs to use %u instead of %d. Use 10 as the base argument to
stroul(), not 0 otherwise numbers with leading zeros will be interpreted
as octal.
[...]
> - v = atoi(tp);
> + v = strtoul(tp, NULL, 0);
> if (v <= 0 || (v % DEV_BSIZE) != 0) {
> fprintf(stderr,
> "line %d: %s: bad sector size\n",
Should be == 0, not <= 0 since v is unsigned.
[...]
> - v = atoi(tp);
> + v = strtoul(tp, NULL, 0);
> if (v < 0) {
> fprintf(stderr, "line %d: %s: bad %s\n",
> lineno, tp, cp);
v < 0 is impossible.
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: rpc.lockd problems
On Fri, 15 Nov 2002, Martijn Pronk wrote: > However, I had some starting problems with rpc.lockd. > Aparently it requires that rpc.statd also is running. Hmmm, it shouldn't fail if rpc.statd isn't enabled, but it should probably complain loudly. Make sure you file a FreeBSD bug report on that, and I'll go take a look why. statd is used to recover locks when the server dies or to release locks when the client dies. I don't actually know if it is "required" by the specification, but I don't think I've ever seen NFS used without it. Can you produce a packet trace for Kris? This would give him a known good trace so that he can point out the differences from his particular configuration, or, alternatively, he could file a bug report with the Linux folks. Thanks for taking the time to try the configuration, -a To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI errors and then panic
On Sat, 5 Oct 2002, Mitsuru IWASAKI wrote: > From: Nate Lawson <[EMAIL PROTECTED]> > Subject: ACPI errors and then panic > Date: Fri, 4 Oct 2002 17:14:31 -0700 (PDT) > Message-ID: <[EMAIL PROTECTED]> > > > My laptop appears to work ok without ACPI but of course I don't get > > suspend, resume, etc. I have never been able to get ACPI to work with it, > > including with a -current as of 2 hours ago. If ACPI is enabled, I get a > > spew of: > > > > ACPI-0412 *** Error: NsSearchAndEnter: Bad character in ACPI name > > > > and then a panic from acpi_attach. I sent a reply including the requested traces on Oct 25. Do you need any more information? Thanks, -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DISABLE_PSE & DISABLE_PG_G still needed?
Wesley Morgan wrote: > Based on this, are you recommending that the DISABLE_* still be used? Will > I never see the problem with 512mb of ram? When Matt Dillon made some of the machdep.c allocation sizes dependent on the physical RAM size, it made the problem much less predictable, based on the amount of RAM, so without sitting down and doing some math to find out exactly where each byte of memory was going, I could not tell you for a given amount of RAM and CPU. What I will tell you is that there is a stair function involved in the amount of RAM you can install, and there is a following function that looks similar, for the allocations made by machdep.c now. The problem will occur when there is a gap between the stair and the follower, e.g.: RAM available | . | +.. | | . <-- bug triggered | `-+. |.+.. | | . <-- bug triggered | `-+. | .+.. || . <-- bug triggered V RAM used ---> > > Bosko understands the problem (I have explained it to him under > > non-disclosure), and he has a patch which avoids it without really > > disclosing the problem, which I'm OK with. Using the patch cranks > > So basically, there is a DEFECT in something that either Intel or AMD has > some me (you, everyone) and they will not disclose the defect, honor any > warranties, or provide fixes for the problem? No. The non-disclosure was mine. I am not an Intel/AMD employee; I discovered the defect independently. As far as I know, they are aware of the problem from Microsoft, but have no idea as to its root cause. It is likely that AMD licensed Intel designs, in order for AMD to have the same problem. You should be aware that Microsoft recommends a registry setting that disables the use of 4M pages to work around the problem on customer systems that have the problem. They don't have the PG_G problem that FreeBSD 5.x has, for the same reason that FreeBSD 4.3 didn't have it: serendipity. > How... crappy. Reminds me of the Redhat/DMCA suppressed patch. I think > consumers have a right to know about any defects in something they have > bought. Argue with your congressman; it was a U.S. law that suppressed the patch, in that case. > And I also think that the marketer should assume some liability > for selling defective hardware (even though software makers seem to be > able to get away with it). Even defects that haven't been discovered or characterized by them? Argue with the U.S. Supreme Court and the tobacco industry on that one. Degree of product liability is based on the prior knowledge of potential harm. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Sign fixes for disklabel(8)
On Fri, 15 Nov 2002, Julian Elischer wrote:
>
> Here are the diffs to allow disklabel to correctly create partitions >
> 1TB (up to 2TB is useful with UFS2) pending a different partitionning
> scheme. It also allows you to correctly make smaller partitions beyond
> 1TB which is nice if you don't want to waste 800GB on an array :-)
>
>
> permission to commit please?
> (pending comments by others)
>
> (also the sysinstall changes posted before)
> (also the bluetooth code)
The diff should not contain the following debug 'leftovers'
which will not be committed..
} else {
- off_t size;
+ u_int64_t size;
size = pp->p_size;
and
}
- if (pp->p_offset + pp->p_size > lp->d_secperunit) {
+ if ((pp->p_offset + pp->p_size) > lp->d_secperunit) {
fprintf(stderr,
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: DISABLE_PSE & DISABLE_PG_G still needed?
Based on this, are you recommending that the DISABLE_* still be used? Will I never see the problem with 512mb of ram? On Fri, 15 Nov 2002, Terry Lambert wrote: > The amount of RAM will also affect it. It can also happen on P3's > and AMD K6's. It is a CPU bug related to the use of 4M pages. Let's not dance around the issue. Software has bugs. Hardware has defects. > Bosko understands the problem (I have explained it to him under > non-disclosure), and he has a patch which avoids it without really > disclosing the problem, which I'm OK with. Using the patch cranks So basically, there is a DEFECT in something that either Intel or AMD has some me (you, everyone) and they will not disclose the defect, honor any warranties, or provide fixes for the problem? How... crappy. Reminds me of the Redhat/DMCA suppressed patch. I think consumers have a right to know about any defects in something they have bought. And I also think that the marketer should assume some liability for selling defective hardware (even though software makers seem to be able to get away with it). But this is getting way off topic :P -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DISABLE_PSE & DISABLE_PG_G still needed?
Robert Watson wrote: > On Fri, 15 Nov 2002, John Baldwin wrote: > > It only happens with P4's. I haven't seen it locally on a p4 test > > machine at work that I have built test releases on. Also, it would be > > nice to see if just adding one of the options fixed the problems. As > > for NOTES, those options should not be enabled in NOTES as they would > > defeat the purpose of LINT since they disable code. > > Does this apply generally to all P4's, or just a subset? If all, it may > be we want to add a P4-workaround to GENERIC so that P4's work better ouf > of the box. If it's a select few, I wonder if there's some way to test > for the problem early in the boot... > > One of the recurring themes here has (a) been P4 processors, and (b) been > a fear that because of timing changes introduced by the DISABLE_FOO flags, > the real bug is still there, but less visible in the tests people are > running. The amount of RAM will also affect it. It can also happen on P3's and AMD K6's. It is a CPU bug related to the use of 4M pages. Bosko understands the problem (I have explained it to him under non-disclosure), and he has a patch which avoids it without really disclosing the problem, which I'm OK with. Using the patch cranks the amount of base memory required for a minimal FreeBSD up to 16M, and loads the kernel at 4M, instead of 1M. This avoids the problem on purpose that the older FreeBSD locore.s used to avoid by accident. The alternative is to take up to a 15% performance hit by not using 4M and global pages, or to revert the locore.s code so that it does not tickle the hardware bug. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Sign fixes for disklabel(8)
Here are the diffs to allow disklabel to correctly create partitions >
1TB (up to 2TB is useful with UFS2) pending a different partitionning
scheme. It also allows you to correctly make smaller partitions beyond
1TB which is nice if you don't want to waste 800GB on an array :-)
permission to commit please?
(pending comments by others)
(also the sysinstall changes posted before)
(also the bluetooth code)
Index: disklabel.c
===
RCS file: /usr/cvs/src/sbin/disklabel/disklabel.c,v
retrieving revision 1.62
diff -u -r1.62 disklabel.c
--- disklabel.c 8 Oct 2002 12:13:19 - 1.62
+++ disklabel.c 15 Nov 2002 23:53:04 -
@@ -943,7 +943,8 @@
const char **cpp;
unsigned int part;
char *tp, line[BUFSIZ];
- int v, lineno = 0, errors = 0;
+ unsigned int v;
+ int lineno = 0, errors = 0;
int i;
lp->d_bbsize = BBSIZE; /* XXX */
@@ -973,7 +974,7 @@
}
if (cpp < &dktypenames[DKMAXTYPES])
continue;
- v = atoi(tp);
+ v = strtoul(tp, NULL, 0);
if ((unsigned)v >= DKMAXTYPES)
fprintf(stderr, "line %d:%s %d\n", lineno,
"Warning, unknown disk type", v);
@@ -1006,8 +1007,8 @@
}
continue;
}
- if (sscanf(cp, "%d partitions", &v) == 1) {
- if (v == 0 || (unsigned)v > MAXPARTITIONS) {
+ if (sscanf(cp, "%u partitions", &v) == 1) {
+ if (v == 0 || v > MAXPARTITIONS) {
fprintf(stderr,
"line %d: bad # of partitions\n", lineno);
lp->d_npartitions = MAXPARTITIONS;
@@ -1027,7 +1028,7 @@
continue;
}
if (streq(cp, "bytes/sector")) {
- v = atoi(tp);
+ v = strtoul(tp, NULL, 0);
if (v <= 0 || (v % DEV_BSIZE) != 0) {
fprintf(stderr,
"line %d: %s: bad sector size\n",
@@ -1038,7 +1039,7 @@
continue;
}
if (streq(cp, "sectors/track")) {
- v = atoi(tp);
+ v = strtoul(tp, NULL, 0);
if (v <= 0) {
fprintf(stderr, "line %d: %s: bad %s\n",
lineno, tp, cp);
@@ -1048,7 +1049,7 @@
continue;
}
if (streq(cp, "sectors/cylinder")) {
- v = atoi(tp);
+ v = strtoul(tp, NULL, 0);
if (v <= 0) {
fprintf(stderr, "line %d: %s: bad %s\n",
lineno, tp, cp);
@@ -1058,7 +1059,7 @@
continue;
}
if (streq(cp, "tracks/cylinder")) {
- v = atoi(tp);
+ v = strtoul(tp, NULL, 0);
if (v <= 0) {
fprintf(stderr, "line %d: %s: bad %s\n",
lineno, tp, cp);
@@ -1068,7 +1069,7 @@
continue;
}
if (streq(cp, "cylinders")) {
- v = atoi(tp);
+ v = strtoul(tp, NULL, 0);
if (v <= 0) {
fprintf(stderr, "line %d: %s: bad %s\n",
lineno, tp, cp);
@@ -1078,7 +1079,7 @@
continue;
}
if (streq(cp, "sectors/unit")) {
- v = atoi(tp);
+ v = strtoul(tp, NULL, 0);
if (v <= 0) {
fprintf(stderr, "line %d: %s: bad %s\n",
lineno, tp, cp);
@@ -1088,7 +1089,7 @@
continue;
}
if (streq(cp, "rpm")) {
- v = atoi(tp);
+ v = strtoul(tp, NULL, 0);
if (v <= 0) {
fprintf(stderr, "line %d: %s: bad %s\n",
lineno, tp, cp);
@@ -1098,7 +1099,7 @@
continue;
}
if (streq(cp, "interleave")) {
- v = atoi(tp);
+ v = strtoul(tp, NULL, 0);
if (v <= 0) {
fpr
Re: DISABLE_PSE & DISABLE_PG_G still needed?
Vallo Kallaste wrote: > > This may be a bit overstated. I removed those options from my kernel a few > > weeks ago and have no problems at all. Are you certain the problem is not > > specific to a particular CPU? > > Sorry, this can be CPU specific, but I'm not sure. I'll try to > reproduce it on my home P2 system and P3-SMP lying under my desk at > work. How much memory do these systems have? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
alpha tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Fri Nov 15 15:07:58 PST 2002 -- >>> Kernel build for GENERIC completed on Fri Nov 15 15:40:42 PST 2002 -- >>> Kernel build for LINT started on Fri Nov 15 15:40:42 PST 2002 -- ===> vinum "Makefile", line 4441: warning: duplicate script for target "geom_bsd.o" ignored cc1: warnings being treated as errors /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_in': /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1931: warning: unsigned int format, different type arg (arg 2) /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_out': /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, different type arg (arg 2) /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, different type arg (arg 4) /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, different type arg (arg 5) *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing /boot/modules from BSD.root.dist
In the last episode (Nov 15), Ruslan Ermilov said: > Yes, the standard search path is /boot/kernel;/boot/modules;/modules. > Nevertheless, we don't create /modules, why should we create /boot/modules? > When you say ``documented'', what do you mean? ``grep -r /boot/modules > doc/en_US.ISO8859-1'' returns nothing. Do you mean kldconfig(8) only? I think /modules is in the path because that's where 3rd-party modules went in 4.*, and is just there for compatibility. Putting them in /boot/modules lets you (theoretically) have a small /boot partition with just the files required to get the kernel booted and root mounted. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha tinderbox failure
John Baldwin wrote: > >> > > I'm getting tired of this email. Any objections to the patch below? > >> > > >> > aic7xxx is vendor-supported and changing it takes it off their p4 > >> > branch. I think gibbs@ has some patches to fix this but there are many > >> > more problems in other drivers that follow it in the build. > >> > > >> > DES, can you take LINT out temporarily from the alpha tinderbox? > >> > >> Can't that file just be marked nowerror for now? > > > > WERROR= you mean. :) > > He means 'nowerror' in sys/conf/files > > FWIW, the correct patch would be to use %j and uintmax_t, not longs. Thanks, I've adjusted the patch to use %jx and uintmax_t instead, in case we still want to commit it. I'll leave it uncommitted until there is general agreement to do so. Thanks, -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha tinderbox failure
On Fri, Nov 15, 2002 at 04:43:16PM -0500, John Baldwin wrote: > > On 15-Nov-2002 Nate Lawson wrote: > > On Fri, 15 Nov 2002, John Baldwin wrote: > >> He means 'nowerror' in sys/conf/files > > > > Since this doesn't generate errors on i386, would it be counterproductive > > to put it in the global files? > > Yes. Hence it has not been done. > > >> FWIW, the correct patch would be to use %j and uintmax_t, not longs. > > > > I believe this was not done due to Linux compat issues but I'm not sure. > > C99 is a bit recent I guess. We just started supporting it ourselves. > Guys, We understand this problem and apologize for not addressing it yet. As many of you know, we are coming off of a highly compressed and stressful developemnt cycle and just haven't had the time to push out fixes for this and many other things. Our plan is to address these driver next week. If you can't wait until then, just go ahead and disconnect the drivers from the alpha tinderbox and move on. As was pointed out though, this is only the tip of the iceberg of warnings in /sys/dev. Scott > -- > > John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -stable build on -current
On Fri Nov 15, 2002 at 10:10:13PM +0200, Ruslan Ermilov wrote: > On Thu, Nov 14, 2002 at 09:03:58PM -0500, The Anarcat wrote: > > Hello! > > > > Can 5.x properly cross-buildworld a 4.x source tree? > > > > Background info.. I have 3 machines at home: > > > > 1- graphic workstation 1Ghz, 1Gbyte of RAM dual Win2k/FreeBSD-stable > > 2- personal web/mail server P166 FreeBSD-stable > > 3- router 486 FreeBSD-stable > > > > My concern is that I won't be able to buildworld in 50 minutes as I > > can do now on the 1Ghz. > > > > Basically, I would turn my experiments machine (the workstation) in a > > real development machine, running -current and still a -stable world > > for the 2 other boxes. > > > > Anyone cares to share such experiences? > > > > Please CC me, I'm not on the list (yet). > > > It was possible some time ago -- I've spent a few hours today making > this possible again. You need to perform the following steps to do > this: > > 1. Install ports/lang/perl5 (I haven't tested with perl5.8). > 2. Make a symlink from /usr/local/bin/pod2man to /usr/bin. > 3. Make sure all the attached commits are in your /usr/src. > > With these fixes, I have successfully built RELENG_4 world on today's > morning 5.0-CURRENT: > > : ===> etc/sendmail > : rm -f freebsd.cf > : (cd /STABLE/usr/src/etc/sendmail && m4 >-D_CF_DIR_=/STABLE/usr/src/etc/sendmail/../../contrib/sendmail/cf/ >/STABLE/usr/src/etc/sendmail/../../contrib/sendmail/cf/m4/cf.m4 freebsd.mc) > >freebsd.cf > : chmod 444 freebsd.cf > > But I didn't test the buildkernel yet -- you're welcome to, or I will, > on Monday. This is great news! So in other words, a -stable build on a -current machine is not necessarly some dare-devil crazy thing to do, and should be perfecly workable, right? If that is so, I'm switching. I've been waiting way too long on -stable.. If I can help debugging the crossbuild in the way, it'll make things only better, I guess. :) Thanks, A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rpc.lockd problems
Martijn Pronk wrote: "My program" is just anything that attempts to obtain a lock on a file on the NFS filesystem. vi does this when opening an existing file, as does mutt when opening a mailbox. Well, that sure simplifies the problem of running your program. ;) Thanks for the info, I will try that tonight after I get back home from the first day of the EuroBSDcon. OK, I tested it with a Solaris 8 NFS server with -current as a client, and locking does indeed work. (At least, vi didn't show the word "UNLOCKED" in the bottom line after I enabled rpc.lockd) However, I had some starting problems with rpc.lockd. Aparently it requires that rpc.statd also is running. Since I didn't had these things enabled in rc.conf, I started them manually. rpc.lockd quits silently without logging anything about what happened. The manualpage does mention that rpc.lockd " typically runs in conjunction with rpc.statd" As I don't see a direct requirement in this line, I didn't realize it was required. HTH, Martijn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha tinderbox failure
On 15-Nov-2002 Nate Lawson wrote: > On Fri, 15 Nov 2002, John Baldwin wrote: >> He means 'nowerror' in sys/conf/files > > Since this doesn't generate errors on i386, would it be counterproductive > to put it in the global files? Yes. Hence it has not been done. >> FWIW, the correct patch would be to use %j and uintmax_t, not longs. > > I believe this was not done due to Linux compat issues but I'm not sure. C99 is a bit recent I guess. We just started supporting it ourselves. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
First cut at sysinstall 64bit changes
Here is a set of patches that alowed me to at least make a 1.5TB
partition on my raid set.
I am willing to bet that it breaks other platforms as I haven't
even compiled them but it's mainly mechanical editing.
is there a "Mr sysinstall" these days?
The set I posted for 4.7++ is different from this as I think that
the two are diverging with the addition of ufs2 to -current.
This is not complete but it did allow me to partition the
array with one big partition which is what I wanted (for testing UFS2).
Julian
Index: lib/libdisk/chunk.c
===
RCS file: /usr/cvs/src/lib/libdisk/chunk.c,v
retrieving revision 1.44
diff -u -r1.44 chunk.c
--- lib/libdisk/chunk.c 13 Nov 2002 05:31:32 - 1.44
+++ lib/libdisk/chunk.c 15 Nov 2002 18:56:50 -
@@ -44,7 +44,7 @@
}
static struct chunk *
-Find_Mother_Chunk(struct chunk *chunks, u_long offset, u_long end, chunk_e type)
+Find_Mother_Chunk(struct chunk *chunks, blk_cnt offset, blk_cnt end, chunk_e type)
{
struct chunk *c1,*c2,ct;
@@ -121,7 +121,7 @@
}
int
-Insert_Chunk(struct chunk *c2, u_long offset, u_long size, const char *name,
+Insert_Chunk(struct chunk *c2, blk_cnt offset, blk_cnt size, const char *name,
chunk_e type, int subtype, u_long flags, const char *sname)
{
struct chunk *ct,*cs;
@@ -204,11 +204,11 @@
}
int
-Add_Chunk(struct disk *d, long offset, u_long size, const char *name,
+Add_Chunk(struct disk *d, blk_cnt offset, blk_cnt size, const char *name,
chunk_e type, int subtype, u_long flags, const char *sname)
{
struct chunk *c1,*c2,ct;
- u_long end = offset + size - 1;
+ blk_cnt end = offset + size - 1;
ct.offset = offset;
ct.end = end;
ct.size = size;
@@ -381,7 +381,7 @@
for(; i < offset; i++) putchar('-');
putchar('>');
for(; i < 10; i++) putchar(' ');
- printf("%p %8ld %8lu %8lu %-8s %-16s %-8s 0x%02x %s",
+ printf("%p %12llu %12llu %12llu %-8s %-16s %-8s 0x%02x %s",
c1, c1->offset, c1->size, c1->end, c1->name, c1->sname,
chunk_name(c1->type), c1->subtype,
ShowChunkFlags(c1));
@@ -407,7 +407,7 @@
{
struct chunk *c1=0, *c2, *c3;
chunk_e type = c->type;
- u_long offset = c->offset;
+ blk_cnt offset = c->offset;
if(type == whole)
return 1;
Index: lib/libdisk/create_chunk.c
===
RCS file: /usr/cvs/src/lib/libdisk/create_chunk.c,v
retrieving revision 1.76
diff -u -r1.76 create_chunk.c
--- lib/libdisk/create_chunk.c 11 Nov 2002 04:46:39 - 1.76
+++ lib/libdisk/create_chunk.c 15 Nov 2002 19:24:48 -
@@ -171,10 +171,10 @@
}
int
-Create_Chunk(struct disk *d, u_long offset, u_long size, chunk_e type, int subtype,
u_long flags, const char *sname)
+Create_Chunk(struct disk *d, blk_cnt offset, blk_cnt size, chunk_e type, int subtype,
+u_long flags, const char *sname)
{
int i;
- u_long l;
+ blk_cnt l;
if(!(flags & CHUNK_FORCE_ALL)) {
#ifdef PC98
@@ -202,7 +202,8 @@
}
struct chunk *
-Create_Chunk_DWIM(struct disk *d, const struct chunk *parent , u_long size, chunk_e
type, int subtype, u_long flags)
+Create_Chunk_DWIM(struct disk *d, const struct chunk *parent , blk_cnt size,
+chunk_e type, int subtype, u_long flags)
{
int i;
struct chunk *c1;
Index: lib/libdisk/disk.c
===
RCS file: /usr/cvs/src/lib/libdisk/disk.c,v
retrieving revision 1.108
diff -u -r1.108 disk.c
--- lib/libdisk/disk.c 13 Nov 2002 05:31:32 - 1.108
+++ lib/libdisk/disk.c 15 Nov 2002 19:19:01 -
@@ -102,7 +102,7 @@
size_t txtsize;
int error, i;
char *p, *q, *r, *a, *b, *n, *t;
- off_t o, len, off;
+ blk_cnt o, len, off;
u_int l, s, ty, sc, hd, alt;
off_t lo[10];
@@ -152,7 +152,7 @@
d->name = strdup(name);
a = strsep(&p, " ");/* length in bytes */
- len = strtoimax(a, &r, 0);
+ len = strtoull(a, &r, 0);
if (*r) { printf("BARF %d <%d>\n", __LINE__, *r); exit (0); }
a = strsep(&p, " ");/* sectorsize */
@@ -162,7 +162,7 @@
d->sector_size = s;
len /= s; /* media size in number of sectors. */
- if (Add_Chunk(d, 0, len, name, whole, 0, 0, "-"))
+ if (Add_Chunk(d, 0LL, len, name, whole, 0, 0, "-"))
DPRINT(("Failed to add 'whole' chunk"));
for (;;) {
@@ -170,7 +170,7 @@
if (a == NULL)
break;
b = strsep(&p, " ");
- o = strtoul(b, &r, 0);
+ o = strtoull(b, &r, 0);
if (*r) { printf("BARF %d <%d>\n", __LINE
Re: alpha tinderbox failure
On Fri, 15 Nov 2002, John Baldwin wrote: > He means 'nowerror' in sys/conf/files Since this doesn't generate errors on i386, would it be counterproductive to put it in the global files? > FWIW, the correct patch would be to use %j and uintmax_t, not longs. I believe this was not done due to Linux compat issues but I'm not sure. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha tinderbox failure
On 15-Nov-2002 Nate Lawson wrote: > On Fri, 15 Nov 2002, Juli Mallett wrote: >> * De: Nate Lawson <[EMAIL PROTECTED]> [ Data: 2002-11-15 ] >> [ Subjecte: Re: alpha tinderbox failure ] >> > On Fri, 15 Nov 2002, Archie Cobbs wrote: >> > > Dag-Erling Smorgrav wrote: >> > > > ===> vinum >> > > > "Makefile", line 4441: warning: duplicate script for target "geom_bsd.o" >ignored >> > > > cc1: warnings being treated as errors >> > > > /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_in': >> > > > /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1931: warning: unsigned int format, >different >> > > > type arg (arg 2) >> > > > /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_out': >> > > > /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, >different >> > > > type arg (arg 2) >> > > > /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, >different >> > > > type arg (arg 4) >> > > > /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, >different >> > > > type arg (arg 5) >> > > > *** Error code 1 >> > > >> > > I'm getting tired of this email. Any objections to the patch below? >> > >> > aic7xxx is vendor-supported and changing it takes it off their p4 >> > branch. I think gibbs@ has some patches to fix this but there are many >> > more problems in other drivers that follow it in the build. >> > >> > DES, can you take LINT out temporarily from the alpha tinderbox? >> >> Can't that file just be marked nowerror for now? > > WERROR= you mean. :) He means 'nowerror' in sys/conf/files FWIW, the correct patch would be to use %j and uintmax_t, not longs. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha tinderbox failure
* De: Nate Lawson <[EMAIL PROTECTED]> [ Data: 2002-11-15 ] [ Subjecte: Re: alpha tinderbox failure ] > > > aic7xxx is vendor-supported and changing it takes it off their p4 > > > branch. I think gibbs@ has some patches to fix this but there are many > > > more problems in other drivers that follow it in the build. > > > > > > DES, can you take LINT out temporarily from the alpha tinderbox? > > > > Can't that file just be marked nowerror for now? > > WERROR= you mean. :) No, I'm referring to a flag in the files list to not include the WERROR var in that file's compilation line. -- Juli Mallett <[EMAIL PROTECTED]> OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel panic when booting with USB CF reader
Nate Lawson wrote: On Sat, 28 Sep 2002, Lars Eggert wrote: >I'm seeing a kernel panic on -current (9/26) when booting with a SanDisk >ImageMate II USB comact flash reader plugged in. The panic occurs after >the kernel has loaded when the first rc.d scripts execute (dumpon, >vinum, etc). Is this still a problem? Nope, the problem disappeared sometime in October. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: kernel panic when booting with USB CF reader
On Sat, 28 Sep 2002, Lars Eggert wrote: > I'm seeing a kernel panic on -current (9/26) when booting with a SanDisk > ImageMate II USB comact flash reader plugged in. The panic occurs after > the kernel has loaded when the first rc.d scripts execute (dumpon, > vinum, etc). > > If I boot with the device disconnected, I can plug it in and unplug it > without problems later. > > Attached is a boot trace and a gdb backtrace. (gdb crashed on me, so I > couldn't get more information.) Here's the relevant info from the trace: > > SMP: AP CPU #1 Launched! > Mounting root from ufs:/dev/da0s1a > Entropy harvesting: interrupts ethernet point_to_point. > kernel dumps on /dev/da1s1b > vinum: loaded > umass0: BBB reset failed, STALLED > da2 at umass-sim0 bus 0 target 0 lun 0 > da2: Removable Direct Access SCSI-2 device > da2: 1.000MB/s transfers > da2: Attempt to query device size failed: NOT READY, Medium not present > (da2:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (da2:umass-sim0:0:0:0): CAM Status: SCSI Status Error > (da2:umass-sim0:0:0:0): SCSI Status: Check Condition > (da2:umass-sim0:0:0:0): NOT READY asc:3a,0 > (da2:umass-sim0:0:0:0): Medium not present > (da2:umass-sim0:0:0:0): Unretryable error > > Fatal trap 18: integer divide fault while in kernel mode > cpuid = 1; lapic.id = 0200 > instruction pointer = 0x8:0xc0437608 > stack pointer = 0x10:0xeb484870 > frame pointer = 0x10:0xeb4848f8 > code segment = base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 67 (vinum) > kernel: type 18 trap, code=0 > Stopped at __qdivrem+0x38: divl%ecx,%eax Is this still a problem? Does it work if you have a flash card plugged into the reader while booting? Can you enable options DDB and type "tr" to get a backtrace after the panic? The problem appears to be that something is using the return value from READ CAP even though it is not set because there is no flash present (i.e. div by 0). -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha tinderbox failure
On Fri, 15 Nov 2002, Juli Mallett wrote: > * De: Nate Lawson <[EMAIL PROTECTED]> [ Data: 2002-11-15 ] > [ Subjecte: Re: alpha tinderbox failure ] > > On Fri, 15 Nov 2002, Archie Cobbs wrote: > > > Dag-Erling Smorgrav wrote: > > > > ===> vinum > > > > "Makefile", line 4441: warning: duplicate script for target "geom_bsd.o" >ignored > > > > cc1: warnings being treated as errors > > > > /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_in': > > > > /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1931: warning: unsigned int format, >different type arg (arg 2) > > > > /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_out': > > > > /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, >different type arg (arg 2) > > > > /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, >different type arg (arg 4) > > > > /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, >different type arg (arg 5) > > > > *** Error code 1 > > > > > > I'm getting tired of this email. Any objections to the patch below? > > > > aic7xxx is vendor-supported and changing it takes it off their p4 > > branch. I think gibbs@ has some patches to fix this but there are many > > more problems in other drivers that follow it in the build. > > > > DES, can you take LINT out temporarily from the alpha tinderbox? > > Can't that file just be marked nowerror for now? WERROR= you mean. :) -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha tinderbox failure
* De: Nate Lawson <[EMAIL PROTECTED]> [ Data: 2002-11-15 ] [ Subjecte: Re: alpha tinderbox failure ] > On Fri, 15 Nov 2002, Archie Cobbs wrote: > > Dag-Erling Smorgrav wrote: > > > ===> vinum > > > "Makefile", line 4441: warning: duplicate script for target "geom_bsd.o" ignored > > > cc1: warnings being treated as errors > > > /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_in': > > > /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1931: warning: unsigned int format, >different type arg (arg 2) > > > /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_out': > > > /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, >different type arg (arg 2) > > > /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, >different type arg (arg 4) > > > /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, >different type arg (arg 5) > > > *** Error code 1 > > > > I'm getting tired of this email. Any objections to the patch below? > > aic7xxx is vendor-supported and changing it takes it off their p4 > branch. I think gibbs@ has some patches to fix this but there are many > more problems in other drivers that follow it in the build. > > DES, can you take LINT out temporarily from the alpha tinderbox? Can't that file just be marked nowerror for now? -- Juli Mallett <[EMAIL PROTECTED]> OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha tinderbox failure
On Fri, 15 Nov 2002, Archie Cobbs wrote: > Dag-Erling Smorgrav wrote: > > ===> vinum > > "Makefile", line 4441: warning: duplicate script for target "geom_bsd.o" ignored > > cc1: warnings being treated as errors > > /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_in': > > /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1931: warning: unsigned int format, >different type arg (arg 2) > > /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_out': > > /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, >different type arg (arg 2) > > /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, >different type arg (arg 4) > > /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, >different type arg (arg 5) > > *** Error code 1 > > I'm getting tired of this email. Any objections to the patch below? aic7xxx is vendor-supported and changing it takes it off their p4 branch. I think gibbs@ has some patches to fix this but there are many more problems in other drivers that follow it in the build. DES, can you take LINT out temporarily from the alpha tinderbox? -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha tinderbox failure
Dag-Erling Smorgrav wrote:
> ===> vinum
> "Makefile", line 4441: warning: duplicate script for target "geom_bsd.o" ignored
> cc1: warnings being treated as errors
> /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_in':
> /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1931: warning: unsigned int format,
>different type arg (arg 2)
> /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_out':
> /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format,
>different type arg (arg 2)
> /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format,
>different type arg (arg 4)
> /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format,
>different type arg (arg 5)
> *** Error code 1
I'm getting tired of this email. Any objections to the patch below?
-Archie
__
Archie Cobbs * Packet Design * http://www.packetdesign.com
Index: aic79xx_osm.c
===
RCS file: /home/ncvs/src/sys/dev/aic7xxx/aic79xx_osm.c,v
retrieving revision 1.3
diff -u -r1.3 aic79xx_osm.c
--- aic79xx_osm.c 31 Aug 2002 06:51:15 - 1.3
+++ aic79xx_osm.c 15 Nov 2002 20:01:24 -
@@ -1927,7 +1927,7 @@
if (count <= 0)
count = 1;
while (--count >= 0) {
- db_printf("%04x (M)%x: \t", addr,
+ db_printf("%04lx (M)%x: \t", (u_long)addr,
ahd_inb(ahd_ddb_softc, MODE_PTR));
switch (size) {
case 1:
@@ -1986,9 +1986,9 @@
ahd_outl(ahd_ddb_softc, addr, new_value);
break;
}
- db_printf("%04x (M)%x: \t0x%x\t=\t0x%x",
- addr, ahd_inb(ahd_ddb_softc, MODE_PTR),
- old_value, new_value);
+ db_printf("%04lx (M)%x: \t0x%lx\t=\t0x%lx",
+ (u_long)addr, ahd_inb(ahd_ddb_softc, MODE_PTR),
+ (u_long)old_value, (u_long)new_value);
addr += size;
}
db_skip_to_eol();
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Fri Nov 15 20:03:41 GMT 2002 -- ===> ipfilter cc1: warnings being treated as errors /tinderbox/sparc64/src/sys/dev/gem/if_gem.c: In function `gem_start': /tinderbox/sparc64/src/sys/dev/gem/if_gem.c:1232: warning: passing arg 1 of `bpf_mtap' from incompatible pointer type /tinderbox/sparc64/src/sys/dev/gem/if_gem.c: In function `gem_rint': /tinderbox/sparc64/src/sys/dev/gem/if_gem.c:1457: warning: unused variable `eh' *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: POSIX AIO on FreeBSD question
* Craig Rodrigues <[EMAIL PROTECTED]> [021115 10:44] wrote: > Hi, > > Do you have any insight into the question that I recently posted > to -current and -standards? Sorry, I'm no longer subscribed to those lists. :( I do appreciate you contacting me about this, see below... > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=822605+0+current/freebsd-current > > Thanks. :) Try this patch, if you have time please either add whatever else _SC_FOOs to vfs_aio.c and return the diff to me, or at least suggest what other ones need to be set where I set them. This delta is untested, but should likely fix your problem. cd /usr/src/sys/kern ; patch < /path/to/this/attachment ; recompile and install kernel or just load the new module. Please let me know asap. Index: vfs_aio.c === RCS file: /home/ncvs/src/sys/kern/vfs_aio.c,v retrieving revision 1.143 diff -u -r1.143 vfs_aio.c --- vfs_aio.c 7 Nov 2002 20:46:37 - 1.143 +++ vfs_aio.c 15 Nov 2002 19:48:50 - @@ -47,6 +47,7 @@ #include #include +#include #include #include #include @@ -350,6 +351,7 @@ aiod_lifetime = AIOD_LIFETIME_DEFAULT; jobrefid = 1; async_io_version = _POSIX_VERSION; + p31b_setcfg(CTL_P1003_1B_AIO_LISTIO_MAX, AIO_LISTIO_MAX); } /* @@ -372,6 +374,7 @@ rm_at_exit(aio_proc_rundown); rm_at_exec(aio_proc_rundown); kqueue_del_filteropts(EVFILT_AIO); + p31b_setcfg(CTL_P1003_1B_AIO_LISTIO_MAX, 0); return (0); } thanks, -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DISABLE_PSE & DISABLE_PG_G still needed?
On Fri, Nov 15, 2002 at 11:45:16AM -0500, Robert Watson <[EMAIL PROTECTED]> wrote: > > It only happens with P4's. I haven't seen it locally on a p4 test > > machine at work that I have built test releases on. Also, it would be > > nice to see if just adding one of the options fixed the problems. As > > for NOTES, those options should not be enabled in NOTES as they would > > defeat the purpose of LINT since they disable code. > > Does this apply generally to all P4's, or just a subset? If all, it may > be we want to add a P4-workaround to GENERIC so that P4's work better ouf > of the box. If it's a select few, I wonder if there's some way to test > for the problem early in the boot... > > One of the recurring themes here has (a) been P4 processors, and (b) been > a fear that because of timing changes introduced by the DISABLE_FOO flags, > the real bug is still there, but less visible in the tests people are > running. To add even more variables into the mix, this particular machine seems to be running Celeron processor based on P4 core. The case has "Celeron Inside" sticker and althought I haven't opened the case I tend to believe what the sticker tells, because port/misc/cpuid agrees. The local PC assembly company is well known and trusted also. Kernel identifies the CPU as P4, no surprise because CPU core is P4 based. dmesg: Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Fri Nov 15 18:14:03 EET 2002 [EMAIL PROTECTED]:/usr/home/vallo/Vallo Preloaded elf kernel "/boot/kernel/kernel" at 0xc04f. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04f00a8. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 1699953860 Hz CPU: Pentium 4 (1699.95-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf13 Stepping = 3 Features=0x3febfbff real memory = 132382720 (126 MB) avail memory = 123219968 (117 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled VESA: v3.0, 832k memory, flags:0x1, mode table:0xc0421d20 (140) VESA: Brookdale-G Graphics Chip Accelerated VGA BIOS npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard Using $PIR table, 9 entries at 0xc00f3d20 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 initial configuration before setting priority for links before fixup boot-disabled links - after fixup boot-disabled links -- arbitrated configuration - pci0: on pcib0 agp0: mem 0xffa8-0xffaf,0xf000-0xf7ff irq 11 at device 2.0 on pci0 agp0: detected 892k stolen memory agp0: aperture size is 128M pci0: at device 29.0 (no driver attached) pci0: at device 29.1 (no driver attached) pci0: at device 29.2 (no driver attached) pcib1: at device 30.0 on pci0 initial configuration before setting priority for links before fixup boot-disabled links - after fixup boot-disabled links -- arbitrated configuration - pci1: on pcib1 fxp0: port 0xdc00-0xdc3f mem 0xff8ff000-0xff8f irq 11 at device 8.0 on pci1 fxp0: Ethernet address 00:03:47:29:85:a5 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf,0-0x3,0-0x7,0-0x3,0-0x7 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at device 31.3 (no driver attached) pcm0: port 0xe080-0xe0bf,0xe400-0xe4ff mem 0xffa7f800-0xffa7f8ff,0xffa7fc00-0xffa7fdff irq 5 at device 31.5 on pci0 acpi_button0: on acpi0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: port 0x3f7,0x3f4-0x3f5,0x3f2-0x3f3,0x3f0-0x3f1 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0 port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppi0: on ppbus0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 sc0: at flags 0x100 on isa0 sc0: VGA <5 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 1.000 msec acpi_cpu: CPU throttling enabled, 8 steps from 100% to 12.5% ata1-slave: timeout waiting for interrupt ata1-slave: ATAPI identify failed ad0: 19541MB [39703/16/63] at ata0-master UDMA100 acd0: CDROM at ata1-master UDMA33 Mounting root from ufs:/dev/ad0s3a ports/misc/cpuid: eax ineax ebx ecx edx 0002 756e6547 6c65746e 49
Re: mdconfig /tmp problem
On Thu, Nov 14, 2002 at 02:40:32AM -0800, Doug Barton wrote the words in effect of: > Folks, > > I have been using an mdconfig /tmp for quite a while. Today, running > -current from 11/14 I got the following errors while doing an > installworld after testing my bind 8.3.3-patched import stuff: > > kernel: swap_pager_strategy: bp 0xc2f34480 blk 0 size 0, not page > bounded > (plus lots more) > > During the installworld whatever binary was being read from the > /tmp/install.foo directory would segfault, and I'd get one or more of > those in my log. > > Here is my little script for creating the mem disk. It hasn't changed in > a long time. > > # Usually a noop, but just in case > mdconfig -d -u 10 2>/dev/null > > mdconfig -a -t swap -s 8M -u 10 > > disklabel -r -w md10 auto >/dev/null > newfs -U /dev/md10c >/dev/null > mount /dev/md10c /tmp > /bin/chmod 1777 /tmp > There is also another problem. mdconfig/md driver messes up when a 0 byte file is passed: # touch /tmp/tmp.fake; mdconfig -a -t vnode -f /tmp/tmp.fake I have not been able to collect debugging data, but when I have some, I will pass it on. FYI. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
When do you plan 5.0-RELEASE?
if i remember correctly, 5.0-release was supposed to ship somewhen in november, isn't it? any news on this? thank you p.s. i work for an italian magazine and we are planning a special issue dedicated to freebsd-5.0, a tiny manual (64pages) with an installation guide step-by-step, a prime-time configuration, etcetc so we need to know an approximate timetable. -- Paolo Italian FreeBSD User Group: http://www.gufi.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DISABLE_PSE & DISABLE_PG_G still needed?
On Fri, 15 Nov 2002, John Baldwin wrote: > On 15-Nov-2002 Wesley Morgan wrote: > > On Fri, 15 Nov 2002, Vallo Kallaste wrote: > > > >> Just finished '-j2 buildworld' and it did well with kernel which had > >> the options enabled. Therefore I suppose that those options are > >> still absolutely necessary to make use of -current system. These > > > > This may be a bit overstated. I removed those options from my kernel a few > > weeks ago and have no problems at all. Are you certain the problem is not > > specific to a particular CPU? > > It only happens with P4's. I haven't seen it locally on a p4 test > machine at work that I have built test releases on. Also, it would be > nice to see if just adding one of the options fixed the problems. As > for NOTES, those options should not be enabled in NOTES as they would > defeat the purpose of LINT since they disable code. Does this apply generally to all P4's, or just a subset? If all, it may be we want to add a P4-workaround to GENERIC so that P4's work better ouf of the box. If it's a select few, I wonder if there's some way to test for the problem early in the boot... One of the recurring themes here has (a) been P4 processors, and (b) been a fear that because of timing changes introduced by the DISABLE_FOO flags, the real bug is still there, but less visible in the tests people are running. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DISABLE_PSE & DISABLE_PG_G still needed?
On 15-Nov-2002 Wesley Morgan wrote: > On Fri, 15 Nov 2002, Vallo Kallaste wrote: > >> Just finished '-j2 buildworld' and it did well with kernel which had >> the options enabled. Therefore I suppose that those options are >> still absolutely necessary to make use of -current system. These > > This may be a bit overstated. I removed those options from my kernel a few > weeks ago and have no problems at all. Are you certain the problem is not > specific to a particular CPU? It only happens with P4's. I haven't seen it locally on a p4 test machine at work that I have built test releases on. Also, it would be nice to see if just adding one of the options fixed the problems. As for NOTES, those options should not be enabled in NOTES as they would defeat the purpose of LINT since they disable code. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /dev/acd*t* no longer available in -current?
On Fri, 15 Nov 2002, Sheldon Hearn wrote: > On (2002/11/15 09:48), Soeren Schmidt wrote: > > > > Don't you think it makes more sense for the kernel to start off with > > > more restrictive permissions, and have the administrator determine > > > whether more restrictive permissions are appropriate? > > > > Actually no I dont. > > The security aware admin will know (or should that be "should know" :) ) > > what to do to make a system secure. > > The avarage user that uses FreeBSD dont, and will get confused if the CDROM > > device doesn't appear to work (ie writeprotected). > > Well I think this goes against the grain of much of the work that's > happened recently. > > Look at how sysinstall now defaults to installing an inetd.conf with no > services enabled. Look at how sshd doesn't allow root login or empty > passwords by default. Look at how IPFW defaults to deny all. Look at > how the floppy drive is inaccessible to anyone but root by default. And > so on and so forth. So one thing we could start doing is have sysinstall's adduser stuff offer to place new users in the operator group, and set up the default permissions on removable devices such that the operator group has read/write access to them (or even just read-access). This would be logically equivilent to placing users in an admin group at instlal on Windows or Mac OS X. Operator access connotes the ability to shut down the system in FreeBSD, as well as the ability to dump file systems, etc. Another possibility would be to evolve our notion of console user based on fbtab some for workstation configurations. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DISABLE_PSE & DISABLE_PG_G still needed?
On Fri, Nov 15, 2002 at 09:55:52AM -0500, Wesley Morgan <[EMAIL PROTECTED]> wrote: > On Fri, 15 Nov 2002, Vallo Kallaste wrote: > > > Just finished '-j2 buildworld' and it did well with kernel which had > > the options enabled. Therefore I suppose that those options are > > still absolutely necessary to make use of -current system. These > > This may be a bit overstated. I removed those options from my kernel a few > weeks ago and have no problems at all. Are you certain the problem is not > specific to a particular CPU? Sorry, this can be CPU specific, but I'm not sure. I'll try to reproduce it on my home P2 system and P3-SMP lying under my desk at work. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DISABLE_PSE & DISABLE_PG_G still needed?
On Fri, 15 Nov 2002, Vallo Kallaste wrote: > Just finished '-j2 buildworld' and it did well with kernel which had > the options enabled. Therefore I suppose that those options are > still absolutely necessary to make use of -current system. These This may be a bit overstated. I removed those options from my kernel a few weeks ago and have no problems at all. Are you certain the problem is not specific to a particular CPU? > options should be uncommented in NOTES and added to GENERIC > otherwise new users will be trapped. All old -current users have > those options probably enabled for a while, that's because there are > no complaints. Actually, I'm not complaining, just testing out the > bad things I have encountered in the near past. This darn > 5.0-RELEASE is nearing way too fast considering the state of > -current today. While I am just a small, small voice among many... I must agree :/... The few things that remain broken for me would be enough to sour testing 5.0 if I wasnt used to working around it. -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[no subject]
subscribe freebsd-current To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sparc64 tinderbox failure
Mike Barcroft wrote: > -- > >>> Kernel build for GENERIC started on Fri Nov 15 14:04:21 GMT 2002 > -- > ===> ipfilter > cc1: warnings being treated as errors > /tinderbox/sparc64/src/sys/dev/gem/if_gem.c: In function `gem_start': > /tinderbox/sparc64/src/sys/dev/gem/if_gem.c:1232: warning: passing arg 1 of >`bpf_mtap' from incompatible pointer type > /tinderbox/sparc64/src/sys/dev/gem/if_gem.c: In function `gem_rint': > /tinderbox/sparc64/src/sys/dev/gem/if_gem.c:1457: warning: unused variable `eh' > *** Error code 1 I believe my last commit to if_gem.c fixed this. Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DISABLE_PSE & DISABLE_PG_G still needed?
On Fri, Nov 15, 2002 at 02:59:32AM -0800, Terry Lambert <[EMAIL PROTECTED]> wrote: > > The kernel compiled from yesterday sources and with the > > abovementioned options disabled will not finish make -j2 buildworld > > on P4. Dies with bus error: > > > > /usr/src/lib/libc/gen/termios.c: In function `tcgetpgrp': > > /usr/src/lib/libc/gen/termios.c:104: internal error: Bus error > > Please submit a full bug report, > > with preprocessed source if appropriate. > > See http://www.gnu.org/software/gcc/bugs.html> for instructions. > > > > Are those options still needed? They are commented out in NOTES and > > shouldn't be necessary, right? > > What happens if you add those options? Does it still crash? Just finished '-j2 buildworld' and it did well with kernel which had the options enabled. Therefore I suppose that those options are still absolutely necessary to make use of -current system. These options should be uncommented in NOTES and added to GENERIC otherwise new users will be trapped. All old -current users have those options probably enabled for a while, that's because there are no complaints. Actually, I'm not complaining, just testing out the bad things I have encountered in the near past. This darn 5.0-RELEASE is nearing way too fast considering the state of -current today. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing /boot/modules from BSD.root.dist
On Fri, 15 Nov 2002, Ruslan Ermilov wrote: RE>On Fri, Nov 15, 2002 at 01:51:57PM +, Gavin Atkinson wrote: RE>> On Fri, 15 Nov 2002, Ruslan Ermilov wrote: RE>> > On Fri, Nov 15, 2002 at 12:47:59PM +, Gavin Atkinson wrote: RE>> > > On Fri, 15 Nov 2002, Ruslan Ermilov wrote: RE>> > > RE>> > > > Anyone objects to this patch? RE>> > > RE>> > > Yes - this is the only place to put modules which are not built as part RE>> > > of the kernel, for example /usr/ports/comms/ltmdm. RE>> > > RE>> > This port puts it under /usr/local/share/ltmdm/ltmdm.ko. RE>> RE>> OK, it may have been a bad example, but I prefer having my kernel modules RE>> loaded via the standard loader.conf method rather than using kldload for RE>> modules which I always want to exist. /boot/modules has been documented as RE>> being in the search path for modules for ages now, it seems unnecessary to RE>> change this. I think that we do need somewhere on the root partition where RE>> modules can be kept, without them being lost on the next upgrade. RE>> RE>Yes, the standard search path is /boot/kernel;/boot/modules;/modules. RE>Nevertheless, we don't create /modules, why should we create /boot/modules? Because then Makefiles don't have to fiddle with creating directories. I don't have a rule for creating /usr/bin in every Makefile that installs into /usr/bin. Why should I have one for /boot/modules? harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Fri Nov 15 14:04:21 GMT 2002 -- ===> ipfilter cc1: warnings being treated as errors /tinderbox/sparc64/src/sys/dev/gem/if_gem.c: In function `gem_start': /tinderbox/sparc64/src/sys/dev/gem/if_gem.c:1232: warning: passing arg 1 of `bpf_mtap' from incompatible pointer type /tinderbox/sparc64/src/sys/dev/gem/if_gem.c: In function `gem_rint': /tinderbox/sparc64/src/sys/dev/gem/if_gem.c:1457: warning: unused variable `eh' *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing /boot/modules from BSD.root.dist
On Fri, Nov 15, 2002 at 03:35:18PM +0200, Ruslan Ermilov <[EMAIL PROTECTED]> wrote: > > > Anyone objects to this patch? > > > > Yes - this is the only place to put modules which are not built as part > > of the kernel, for example /usr/ports/comms/ltmdm. > > > This port puts it under /usr/local/share/ltmdm/ltmdm.ko. This is bad practice. The /boot/modules directory was discussed long time ago and meant to third-party modules as I remember. That's why I haven't discarded it locally. Even if ports have rules to install everything under ports-dir they should install kernel modules into /boot/modules. Otherwise it's a sphagetti to manage. The IMHO thing applies to this message also quite well. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing /boot/modules from BSD.root.dist
On Fri, Nov 15, 2002 at 01:51:57PM +, Gavin Atkinson wrote: > On Fri, 15 Nov 2002, Ruslan Ermilov wrote: > > On Fri, Nov 15, 2002 at 12:47:59PM +, Gavin Atkinson wrote: > > > On Fri, 15 Nov 2002, Ruslan Ermilov wrote: > > > > > > > Anyone objects to this patch? > > > > > > Yes - this is the only place to put modules which are not built as part > > > of the kernel, for example /usr/ports/comms/ltmdm. > > > > > This port puts it under /usr/local/share/ltmdm/ltmdm.ko. > > OK, it may have been a bad example, but I prefer having my kernel modules > loaded via the standard loader.conf method rather than using kldload for > modules which I always want to exist. /boot/modules has been documented as > being in the search path for modules for ages now, it seems unnecessary to > change this. I think that we do need somewhere on the root partition where > modules can be kept, without them being lost on the next upgrade. > Yes, the standard search path is /boot/kernel;/boot/modules;/modules. Nevertheless, we don't create /modules, why should we create /boot/modules? When you say ``documented'', what do you mean? ``grep -r /boot/modules doc/en_US.ISO8859-1'' returns nothing. Do you mean kldconfig(8) only? Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg46722/pgp0.pgp Description: PGP signature
Re: Removing /boot/modules from BSD.root.dist
On Fri, 15 Nov 2002, Ruslan Ermilov wrote: > On Fri, Nov 15, 2002 at 12:47:59PM +, Gavin Atkinson wrote: > > On Fri, 15 Nov 2002, Ruslan Ermilov wrote: > > > > > Anyone objects to this patch? > > > > Yes - this is the only place to put modules which are not built as part > > of the kernel, for example /usr/ports/comms/ltmdm. > > > This port puts it under /usr/local/share/ltmdm/ltmdm.ko. OK, it may have been a bad example, but I prefer having my kernel modules loaded via the standard loader.conf method rather than using kldload for modules which I always want to exist. /boot/modules has been documented as being in the search path for modules for ages now, it seems unnecessary to change this. I think that we do need somewhere on the root partition where modules can be kept, without them being lost on the next upgrade. Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing /boot/modules from BSD.root.dist
On Fri, Nov 15, 2002 at 12:47:59PM +, Gavin Atkinson wrote: > On Fri, 15 Nov 2002, Ruslan Ermilov wrote: > > > Anyone objects to this patch? > > Yes - this is the only place to put modules which are not built as part > of the kernel, for example /usr/ports/comms/ltmdm. > This port puts it under /usr/local/share/ltmdm/ltmdm.ko. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg46720/pgp0.pgp Description: PGP signature
Re: machdep.c problem
Thus spake Bruce Evans <[EMAIL PROTECTED]>: > > > > I retained the int 12h fallback just to be safe, but I > > > > think the bootinfo structure is initialized with a valid basemem > > > > for all loaders since at least 1998. (Maybe the fallbacks in the > > Since 1995, but not in boot2 since 2002/10/01. The bi_memsizes_valid > flag unfortunately covers both bi_basemem and bi_extmem, so it is still > set although bi_basemem is bogus. Also, boot2 and most (all?) other > places never checked for errors from int 0x12, so bi_basemem may be > pure garbage. That's easy enough to fix. Add fields bi_newbasemem and bi_newextmem, implement them correctly, and fall back to the present behavior if neither are present. This approach couldn't make things any worse than they already are. > IIRC, the main reason for making VM86 standard was to use it here. > vm86_intcall() still doesn't seem to be used much. It is used mainly for > the memsize calls and setting vesa modes. int 0x12 can be done just as > easily in the boot code. Setting vesa modes can be optional. Only the > memory map subcall of the int 0x15 is much easier to do like it is done > now (the maps are too large for the boot code to pass easily). Linux manages this by reserving a page for the int 15h:e820h map, I think. It doesn't look unreasonably difficult to pass the map to the kernel. Even if we have to resort to VM86 for this, we can at least deal with basemem in real mode. > > Are there any objections to the following? [...] > > - Remove the basemem calculation from machdep.c. > > machdep.c could probably do the real mode switch without much more > difficulty than boot2, etc. You think so? I would imagine that after paging is enabled, switching to real mode from a loaded kernel would be nontrivial. > I would prefer to fix int 0x12 (if BIOSes are so broken as to trap > even when it is set up correctly, then handle the trap and make int > 0x12 return 0; also return 0 if it fails. So basemem is 0 in broken > cases -- waste a whole 640K as a reward for being broken. Note that > the subsequent int 0x15 call(s) in machdep.c will still work, just as > if the BIOS ate the 640K -- we map it all r/w for the BIOS). Your idea sounds reasonable, although I would still prefer to fix the boot loader to reliably report the base memory size. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /dev/acd*t* no longer available in -current?
On (2002/11/15 14:45), Vallo Kallaste wrote: > Yes. For what it's worth, I think that system should be airtight out > of the box and the consequences for average desktop user (as I am) > clearly documented in handbook. Users who will not read the fine > documentation fully deserve the pain. Well, in the case of being able to write to the CDRW, that's only true because sysinstall doesn't ask you whether this is a multiuser or single-user machine. One day, when sysinstall makes that distinction, it can add more permissive rules to the file that devfs(8) reads on startup if the operator indicates that the installation is for a single-user workstation. By then, I'm sure we'll be running devfs(8) on startup. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel not booting....Immediate crash
Thus spake Bruce Evans <[EMAIL PROTECTED]>: > Perhaps the problem with int 0x12 is the same as the one with int 0x15. > Old implementations of int 0x12 just read the word at 0x40:0x13 in > real or vm86 mode. This only requires physical page 0 to be mapped > readable to work in vm86 calls. New implementations might want more. > They could reasonably expect all of the first MB of physical memory > to be mapped r/w into vm86 space. It's not clear that any BIOS call > works in vm86 mode. BIOS calls could unreasonably expect to access > all of memory as if in real mode (e.g., they could stash their variables > in extended memory and use the himem hack or a switch to protected > mode to access them). Could be. I would hope that mapping page 0, the BIOS data segment, and the EBDA would solve the problem, but there's still a chicken-and-egg problem with doing this in vm86 mode. I haven't heard any additional details from Iwasaki-san, but making the memory determination in vm86 mode seems fundamentally broken regardless. > > Also, you mentioneded earlier that Linux doesn't use int 12h > > anymore. But notice that they call 15:E820 in real mode, rather > > than turning on virtual memory and then temporarily mapping an > > arbitrary chunk of the first 640K of RAM. Why don't you just put > > the memory size detection code in locore.s? I'd be happy to help > > out with this, although my time is constrained after Monday. > > locore.s runs entirely in protected mode. It could switch between > real and protected mode like the boot code does, but that would defeat > the point of the (not very well designed) division of labour between > the boot code and locore -- the complications for real mode are > supposed to be limited to the boot code. Of course, they have been > replaced by larger complications and bugs for vm86 mode :-(. More > in another reply. That is why I'm surprised by your earlier post where you say that it's a bad idea to take the basemem value from the boot code. As it is, the kernel duplicates much of the memory determination code of the boot loader. I would think it could at least rely on bootinfo.bi_basemem when that field is nonzero. If these values in bootinfo are going to remain unused, they should be removed, but I think a far better solution is to start using them. In fact, the interface could be extended to pass the int 15h:e820h memory map to the kernel. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: machdep.c problem
On Sun, 10 Nov 2002, David Schultz wrote: > Thus spake Mitsuru IWASAKI <[EMAIL PROTECTED]>: > > > This approach is okay with me in the sense that it doesn't break > > > anything that wasn't already broken, but as you say, I think we > > > can do better. Below is a patch that merely extracts the basemem > > > size from the bootinfo structure for the purposes of mapping the > > > EBDA. Note that the int 0x12 call was removed from boot2, so the bi_basemem == 0 case can;t be trusted. > > > I retained the int 12h fallback just to be safe, but I > > > think the bootinfo structure is initialized with a valid basemem > > > for all loaders since at least 1998. (Maybe the fallbacks in the Since 1995, but not in boot2 since 2002/10/01. The bi_memsizes_valid flag unfortunately covers both bi_basemem and bi_extmem, so it is still set although bi_basemem is bogus. Also, boot2 and most (all?) other places never checked for errors from int 0x12, so bi_basemem may be pure garbage. > > > kernel should be removed entirely to avoid redundancy, or moved > > > from loader and boot2 to locore.s.) > > > > Yes, this idea was in my first patch actually, and this was not > > good solution as Bruce explained. Please see the archive at: > > >http://docs.freebsd.org/cgi/getmsg.cgi?fetch=94412+0+archive/2002/freebsd-current/20021006.freebsd-current > > It sounds like the basic objection is, ``We came up with this > feature in 1995 and never used it, so we shouldn't start using it > now.'' We did use it, at least in the non-VM86 case, until VM86 became standard in 1999. I didn't like making VM86 the default but got used to it. I now see that I was wrong :-). IIRC, the main reason for making VM86 standard was to use it here. vm86_intcall() still doesn't seem to be used much. It is used mainly for the memsize calls and setting vesa modes. int 0x12 can be done just as easily in the boot code. Setting vesa modes can be optional. Only the memory map subcall of the int 0x15 is much easier to do like it is done now (the maps are too large for the boot code to pass easily). > Fine, but I still maintain that determining the memory > size in real mode like everyone else is the right thing to do. I agree. > Are there any objections to the following? > > - Remove the redundant and unused memory detection code > from boot2, loader, and libi386. I think this is currently the least bad place for it (except there is not enough room to do int 0x15:0xe820 in boot2). > - Mark the bootinfo fields bi_basemem and bi_extmem as > deprecated. Doesn't go with leaving it in boot2, etc. > - Determine basemem in locore.s using 15h:e820h, with a > fallback to int 12h. I think this is the worst place to do it. > - Remove the basemem calculation from machdep.c. machdep.c could probably do the real mode switch without much more difficulty than boot2, etc. I would prefer to fix int 0x12 (if BIOSes are so broken as to trap even when it is set up correctly, then handle the trap and make int 0x12 return 0; also return 0 if it fails. So basemem is 0 in broken cases -- waste a whole 640K as a reward for being broken. Note that the subsequent int 0x15 call(s) in machdep.c will still work, just as if the BIOS ate the 640K -- we map it all r/w for the BIOS). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing /boot/modules from BSD.root.dist
On Fri, 15 Nov 2002, Ruslan Ermilov wrote: > Anyone objects to this patch? Yes - this is the only place to put modules which are not built as part of the kernel, for example /usr/ports/comms/ltmdm. Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /dev/acd*t* no longer available in -current?
On Fri, Nov 15, 2002 at 04:29:50AM -0800, Kris Kennaway <[EMAIL PROTECTED]> wrote: > > > Don't you think it makes more sense for the kernel to start off with > > > more restrictive permissions, and have the administrator determine > > > whether more restrictive permissions are appropriate? > > > > Actually no I dont. > > The security aware admin will know (or should that be "should know" :) ) > > what to do to make a system secure. > > That's a particularly uncompelling argument. Yes. For what it's worth, I think that system should be airtight out of the box and the consequences for average desktop user (as I am) clearly documented in handbook. Users who will not read the fine documentation fully deserve the pain. Moreover, they probably will not make a way as fine FreeBSD user in a long run. Be sure you read the following line: IMHO -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /dev/acd*t* no longer available in -current?
On Fri, Nov 15, 2002 at 09:48:56AM +0100, Soeren Schmidt wrote: > It seems Sheldon Hearn wrote: > > On (2002/11/14 19:27), Soeren Schmidt wrote: > > > > > > - insecure permissions. Among other holes, these allowed the world to > > > > erase cd-rw's. > > > > > > Use rc.devfs for that as it was intended. > > > > Don't you think it makes more sense for the kernel to start off with > > more restrictive permissions, and have the administrator determine > > whether more restrictive permissions are appropriate? > > Actually no I dont. > The security aware admin will know (or should that be "should know" :) ) > what to do to make a system secure. That's a particularly uncompelling argument. Kris msg46713/pgp0.pgp Description: PGP signature
Re: Kernel not booting....Immediate crash
On Sat, 9 Nov 2002, David Schultz wrote: > Thus spake Mitsuru IWASAKI <[EMAIL PROTECTED]>: > > Hmmm, I didn't notice that there is a BIOS which requires > > memory area below 640K even when calling INT 15H/E820. > > > > We cannot trust that today's BOISes have INT 12H, so it's > > difficult to determine base memory size w/o INT 15H/E820. > > You keep saying this, which really surprises me, because the int > 12h interface has been standard for over two decades. I have not > heard any great clammoring that DOS and NetBSD fail to boot on > modern machines, and yet they both use int 12h. Are you *sure* > int 12h is really broken, or do you think perhaps the breakage > you're seeing is a side-effect of another bug? Does int 12h work > in real mode? Exactly what hardware has this problem? Perhaps the problem with int 0x12 is the same as the one with int 0x15. Old implementations of int 0x12 just read the word at 0x40:0x13 in real or vm86 mode. This only requires physical page 0 to be mapped readable to work in vm86 calls. New implementations might want more. They could reasonably expect all of the first MB of physical memory to be mapped r/w into vm86 space. It's not clear that any BIOS call works in vm86 mode. BIOS calls could unreasonably expect to access all of memory as if in real mode (e.g., they could stash their variables in extended memory and use the himem hack or a switch to protected mode to access them). > Also, you mentioneded earlier that Linux doesn't use int 12h > anymore. But notice that they call 15:E820 in real mode, rather > than turning on virtual memory and then temporarily mapping an > arbitrary chunk of the first 640K of RAM. Why don't you just put > the memory size detection code in locore.s? I'd be happy to help > out with this, although my time is constrained after Monday. locore.s runs entirely in protected mode. It could switch between real and protected mode like the boot code does, but that would defeat the point of the (not very well designed) division of labour between the boot code and locore -- the complications for real mode are supposed to be limited to the boot code. Of course, they have been replaced by larger complications and bugs for vm86 mode :-(. More in another reply. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
alpha tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Fri Nov 15 03:03:39 PST 2002 -- >>> Kernel build for GENERIC completed on Fri Nov 15 03:33:49 PST 2002 -- >>> Kernel build for LINT started on Fri Nov 15 03:33:49 PST 2002 -- ===> vinum "Makefile", line 4441: warning: duplicate script for target "geom_bsd.o" ignored cc1: warnings being treated as errors /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_in': /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1931: warning: unsigned int format, different type arg (arg 2) /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_out': /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, different type arg (arg 2) /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, different type arg (arg 4) /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, different type arg (arg 5) *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /dev/acd*t* no longer available in -current?
On Fri, 15 Nov 2002, Sheldon Hearn wrote: > On (2002/11/15 09:48), Soeren Schmidt wrote: > > > > Don't you think it makes more sense for the kernel to start off with > > > more restrictive permissions, and have the administrator determine > > > whether more restrictive permissions are appropriate? > > > > Actually no I dont. > > The security aware admin will know (or should that be "should know" :) ) > > what to do to make a system secure. > > The avarage user that uses FreeBSD dont, and will get confused if the CDROM > > device doesn't appear to work (ie writeprotected). > > Well I think this goes against the grain of much of the work that's > happened recently. It is just a bug. SCSI cd devices never had this bug, and acd devices don't have it in the non-devfs case. Average users don't depend on this bug since average users run RELENG_4 which doesn't have devfs. Some other devices have even more insecure permissions. Sound devices have mode 0666. This bugs is "documented" in the snd_security_hole variable name in MAKEDEV. For devfs, you can grep the kernel sources for 0666 to find similar security holes. There are an alarming number of 0666's. Most are for ptys where they are OK. The most obviously wrong ones are for rp. rp devices have mode 0666 in the devfs case. rp gets this wrong in the opposite direction in MAKEDEV -- it is missing a "umask 7" for the cua case, so its cua devices are not group readable. rp also gets the user and group wrong for the cua devices the devfs case, so world r/w permissions are necessary to grant even the usual access to uucp:dialer. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DISABLE_PSE & DISABLE_PG_G still needed?
Vallo Kallaste wrote: > > Hi > > The kernel compiled from yesterday sources and with the > abovementioned options disabled will not finish make -j2 buildworld > on P4. Dies with bus error: > > /usr/src/lib/libc/gen/termios.c: In function `tcgetpgrp': > /usr/src/lib/libc/gen/termios.c:104: internal error: Bus error > Please submit a full bug report, > with preprocessed source if appropriate. > See http://www.gnu.org/software/gcc/bugs.html> for instructions. > > Are those options still needed? They are commented out in NOTES and > shouldn't be necessary, right? What happens if you add those options? Does it still crash? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: addition to cdefs
On Wed, 13 Nov 2002, Mike Barcroft wrote:
> Bruce Evans <[EMAIL PROTECTED]> writes:
> > Both have large namespace pollution (p and n are in the application
> > namespace). Both give huge code wih a copy of the function in every
> > object file whose source file(s) include this header if inline functions
> > are not actually inline (which happens if the compiler is gcc -O0 or
> > non-gcc).
>
> I fixed the namespace problems in the version I posted for review on
> -standards. Do you see any problems with changing FD_ZERO() to:
>
> #define FD_ZERO(p)do {\
> fd_set *_p = (p); \
> __size_t _n = _howmany(FD_SETSIZE, _NFDBITS); \
> while (_n > 0) \
> _p->__fds_bits[--_n] = 0; \
> } while (0);
>
> ...to overcome the issues with the inline version?
I think avoiding the inline function is especially worthwile here,
since FD_ZERO is is always defined in in the default
(__BSD_VISIBLE) case and that won't change soon.
The above version has a bug: the semicolon at the end defeats the point
of the `do ... while (0)'.
I would format it a little differently (tab instead of space after
#define; space instead of tab before `do', and maybe not initialize
variables in declarations, and maybe leave a blank line after the
declarations -- I like to use normal formatting for macros unless
breaking the normal formatting can be used to get 1-line macros.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
DISABLE_PSE & DISABLE_PG_G still needed?
Hi The kernel compiled from yesterday sources and with the abovementioned options disabled will not finish make -j2 buildworld on P4. Dies with bus error: /usr/src/lib/libc/gen/termios.c: In function `tcgetpgrp': /usr/src/lib/libc/gen/termios.c:104: internal error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See http://www.gnu.org/software/gcc/bugs.html> for instructions. Are those options still needed? They are commented out in NOTES and shouldn't be necessary, right? -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: SCSI & 'iir' problems on -CURRENT
On Fri, 15 Nov 2002, Patrick Fish wrote: > When you upgrade to 5.0, you need to do the following things from > console: > > cd /usr/src/sys/boot/ && make && make install > > > This is because the kernel location was changed, so you need to make > boot manually. > > I also suggest you compile pam.d manually also. > I tried to do binary upgrade (4.7->5.0) because plain 5.0 installation is impossible - same problem. > pf > vd To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /dev/acd*t* no longer available in -current?
On Thu, 14 Nov 2002, Soeren Schmidt wrote: > It seems Bruce Evans wrote: > > Single-digit track numbers are correct and are still generated by MAKEDEV. > > Single digit track numbers are wrong and should be fixed in MAKEDEV. I disagree. > > Contrary to the log message, %02d is harder for scripts. It gives many > > more cases to handle: > > - %d format under RELENG_4 > > Should be fixed. Apart from being wrong, this would break compatibility with released versions of RELENG_4 (except 4.0-4.2 since they didn't support tracks on acd). > > - %d format under -current in the non-devfs case > > DEVFS should be considered mandatory for the track devices on current. No thanks. I only use devfs to debug it. > > - %d format under -current even in the devfs case for track numbers >= 100 > > BZZT!! there can be a max of 99 tracks on a CD. Thnaks for your polite correction. I was misled by MAKEDEV supporting track numbers up to 169. Google agrees that the maximum is 99, but cd drivers in linux-2.4.1 have an interesting number of different definitions of the maximum: aztcd.h:#define MAX_TRACKS 104 cdu31a.h:#define MAX_TRACKS 100 /* The maximum tracks a disk may have. */ gscd.h:#define MAX_TRACKS 104 mcd.h:#define MAX_TRACKS104 optcd.c:#define MAX_TRACKS 111 sbpcd.h:#define MAX_TRACKS 99 sjcd.h:#define SJCD_MAX_TRACKS 100 > > The following patch backs out rev.1.119 of atapi-cd.c and fixes the > > following older devfs bugs in acd: > > - insecure permissions. Among other holes, these allowed the world to > > erase cd-rw's. > > Use rc.devfs for that as it was intended. rc.devfs is not intended for fixing kernel bugs. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SCSI & 'iir' problems on -CURRENT
Hello, Few minutes ago I tried to upgrade 4.7 -> 5.0 (2002.11.15) and after reboot I got problem: Waiting 15 seconds for SCSI device to settle Mounting root from ufs:/dev/da0s1a sethostbyname failed ffs_mountroot: can't find rootvp Root mount failed: 6 mountroot> ? List of GEOM disk devices: geom.ctl 4.7 works with Intel RAID Controller SRCU32, but with 5.0 I have this problem ... vd To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /dev/acd*t* no longer available in -current?
On (2002/11/15 09:48), Soeren Schmidt wrote: > > Don't you think it makes more sense for the kernel to start off with > > more restrictive permissions, and have the administrator determine > > whether more restrictive permissions are appropriate? > > Actually no I dont. > The security aware admin will know (or should that be "should know" :) ) > what to do to make a system secure. > The avarage user that uses FreeBSD dont, and will get confused if the CDROM > device doesn't appear to work (ie writeprotected). Well I think this goes against the grain of much of the work that's happened recently. Look at how sysinstall now defaults to installing an inetd.conf with no services enabled. Look at how sshd doesn't allow root login or empty passwords by default. Look at how IPFW defaults to deny all. Look at how the floppy drive is inaccessible to anyone but root by default. And so on and so forth. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing /boot/modules from BSD.root.dist
On Fri, 15 Nov 2002, Ruslan Ermilov wrote: RE>Hi! RE> RE>Anyone objects to this patch? Yes. Where do a install my modules then, that don't build with the kernel? harti RE> RE>%%% RE>Index: BSD.root.dist RE>=== RE>RCS file: /home/ncvs/src/etc/mtree/BSD.root.dist,v RE>retrieving revision 1.58 RE>diff -u -5 -r1.58 BSD.root.dist RE>--- BSD.root.dist10 Jun 2002 04:47:26 - 1.58 RE>+++ BSD.root.dist15 Nov 2002 08:38:24 - RE>@@ -10,12 +10,10 @@ RE> boot RE> defaults RE> .. RE> kernel RE> .. RE>-modules RE>-.. RE> .. RE> dev RE> fd mode=0555 RE> .. RE> .. RE>%%% RE> RE> RE>Cheers, RE> -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /dev/acd*t* no longer available in -current?
It seems Sheldon Hearn wrote: > On (2002/11/14 19:27), Soeren Schmidt wrote: > > > > - insecure permissions. Among other holes, these allowed the world to > > > erase cd-rw's. > > > > Use rc.devfs for that as it was intended. > > Don't you think it makes more sense for the kernel to start off with > more restrictive permissions, and have the administrator determine > whether more restrictive permissions are appropriate? Actually no I dont. The security aware admin will know (or should that be "should know" :) ) what to do to make a system secure. The avarage user that uses FreeBSD dont, and will get confused if the CDROM device doesn't appear to work (ie writeprotected). -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /dev/acd*t* no longer available in -current?
On (2002/11/14 19:27), Soeren Schmidt wrote: > > - insecure permissions. Among other holes, these allowed the world to > > erase cd-rw's. > > Use rc.devfs for that as it was intended. Don't you think it makes more sense for the kernel to start off with more restrictive permissions, and have the administrator determine whether more restrictive permissions are appropriate? I think this approach is much more in line with "the Unix way". Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Removing /boot/modules from BSD.root.dist
Hi! Anyone objects to this patch? %%% Index: BSD.root.dist === RCS file: /home/ncvs/src/etc/mtree/BSD.root.dist,v retrieving revision 1.58 diff -u -5 -r1.58 BSD.root.dist --- BSD.root.dist 10 Jun 2002 04:47:26 - 1.58 +++ BSD.root.dist 15 Nov 2002 08:38:24 - @@ -10,12 +10,10 @@ boot defaults .. kernel .. -modules -.. .. dev fd mode=0555 .. .. %%% Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg46697/pgp0.pgp Description: PGP signature
sparc64 tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Fri Nov 15 08:03:44 GMT 2002 -- ===> ipfilter cc1: warnings being treated as errors /tinderbox/sparc64/src/sys/dev/gem/if_gem.c: In function `gem_start': /tinderbox/sparc64/src/sys/dev/gem/if_gem.c:1232: warning: passing arg 1 of `bpf_mtap' from incompatible pointer type /tinderbox/sparc64/src/sys/dev/gem/if_gem.c: In function `gem_rint': /tinderbox/sparc64/src/sys/dev/gem/if_gem.c:1457: warning: unused variable `eh' *** Error code 1 Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/sparc64/src. *** Error code 1 Stop in /tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
