Re: subtle problem du jour....
Is there a quick and dirty way for the label editor to detect if a BIOS is using LBA? This actually sounds like a setup in which the error condition should be alerted on placing / on a cylinder higher than 1024 rather than long after you can do anything about it. The loader error might be a good extra, but the real place the user should be notified of the error condition is upon creation. If the editor can't detect LBA, maybe a generic warning about the wisdom of root partitions above cyl 1024 on non-LBA drives might popup when root partition exists above cyl 1024 (and prepare for lusers who don't know what LBA is flying off the proverbial handle). On Wed, 5 Jul 2000, Garance A Drosihn wrote: At 3:18 PM -0700 7/5/00, Mike Smith wrote: someone else wrote: The only time this showed up as problem was that when I reinstalled the loader (and related forth files), loader silently was not able to read /boot or /modules- the key word here is "silently". There ought to be a warning in loader(8) maybe about this? There would be a couple of ways to deal with the problem you're seeing (in addition to the very worthwhile documentation) - a) bitch if the loader.rc file can't be found/read. b) bitch in the BIOS disk driver if an illegal read is attempted. Both of these might have given you enough clue to help find the problem more quickly. Any comments, folks? Something along these lines might have saved me a few hours a week or two ago. I managed to create my partitions so '/' was the LAST freebsd in the slice I was installing into, instead of the first partition. This gave me some weird error messages when trying to start up. In my case the problem was that '/' started out past the 8-gig mark (even though the rest of the partitions were all before the 8-gig mark). I don't know how much work it would be to generate a specific enough error message, but in my case I didn't realize I had put the partition where I had put it. I was getting some kind of error message, but it wasn't specific enough to help jar me into looking at the right issue. Eventually one of my friends asked for some disklabel info, and then we were able to see where I had mixed things up. --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Pardon me, but you have obviously mistaken me for someone who gives a damn. email [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1) does
On Wed, 5 Jul 2000, Bill Fumerola wrote: On Tue, Jul 04, 2000 at 09:56:43PM +0200, Blaz Zupan wrote: this number is completely useless to me. I have to agree with Sheldon, where is the use to this number? Think about doing something like $ df -c/disk0 /disk1 /disk2 ... /diskX To just monitor a cluster of disks. I'm all for adding options to get features you can't otherwise get (even *IF* the use of "total" is debatable), but c'mon, this is an awk one-liner. I would agree with Sheldon as well. Let this one go. -Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Call for help: KAME (inter)operational testing
If anyone is able to help in verifying the new FreeBSD-current KAME ipv6/ipsec code, especially if you have available other platform ipv6/ipsec implementations to test against, please let me know or drop by the #kame channel on efnet on IRC (server irc.lsl.com, for example) so we can work together. We need to test the new KAME code as much as possible prior to merging into 4.0-STABLE, so anything you can do to help would be appreciated. I particularly want to make sure that racoon (IKE daemon) works as expected (/usr/ports/security/racoon) since that is the primary reason for wanting to push this stuff into -stable. Thanks! Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: subtle problem du jour....
Is there a quick and dirty way for the label editor to detect if a BIOS is using LBA? No. This actually sounds like a setup in which the error condition should be alerted on placing / on a cylinder higher than 1024 rather than long after you can do anything about it. There's actually more productive work underway to remove the entire 1024 cylinder issue from the picture. The set of systems where this will remain a problem is bounded and rapidly diminishing. The loader error might be a good extra, but the real place the user should be notified of the error condition is upon creation. If the editor can't detect LBA, maybe a generic warning about the wisdom of root partitions above cyl 1024 on non-LBA drives might popup when root partition exists above cyl 1024 (and prepare for lusers who don't know what LBA is flying off the proverbial handle). This already happens. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current with new KAME doesn't build with KERBEROS5 defined
On Wed, 5 Jul 2000, Louis A. Mamakos wrote: I get errors like this while 'make depend' in the Heimdel code. So far, in libroken and libasn1. Fixed. I tried looking at fixing this, but I fear the build system is too tricky for me to want to venture in to fix. Actually, the fix was one line ;-) netinet6/in6.h is no longer supposed to be included, so we just had to disable it in the pregenerated heimdal config.h file. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1) does
As a side issue, can anyone explain these peculiar results from df(1)'s huamn-readable (-h) output: Filesystem Size Used Avail Capacity Mounted on mfs:26 87M11K80M 0%/tmp /dev/ad0s1f 1.2G 934M 241M80%/usr /dev/ad0s1e 193M92M86M52%/var /dev/ccd0c 1.8G 786M 900M47%/a /dev/ad1s1e 1.3G 728M 474M61%/b procfs 4.0K 4.0K 0B 100%/proc rodent.ops:/home/ncvs 3.4G 3.1G36M99%/usr/home/ncvs In particular, I can't believe that 87M - 11K == 80M (I'd expect 86M or 87M). Nor is it credible that 1.8G - 786 == 900M (I'd expect 1057M or 1G). Am I being obtuse, and if so could someone explain my folly? :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1) does
+[ Sheldon Hearn ]- | | As a side issue, can anyone explain these peculiar results from df(1)'s | huamn-readable (-h) output: | | Filesystem Size Used Avail Capacity Mounted on | mfs:26 87M11K80M 0%/tmp | /dev/ad0s1f 1.2G 934M 241M80%/usr | /dev/ad0s1e 193M92M86M52%/var | /dev/ccd0c 1.8G 786M 900M47%/a | /dev/ad1s1e 1.3G 728M 474M61%/b | procfs 4.0K 4.0K 0B 100%/proc | rodent.ops:/home/ncvs 3.4G 3.1G36M99%/usr/home/ncvs | | In particular, I can't believe that 87M - 11K == 80M (I'd expect 86M or | 87M). Nor is it credible that 1.8G - 786 == 900M (I'd expect 1057M or | 1G). | | Am I being obtuse, and if so could someone explain my folly? :-) Those are block available to non-superuser I think, not "just available" There's some amount reserved (10% ?). -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Milton The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1) does
On Thu, 06 Jul 2000 20:48:46 +1000, Andrew Kenneth Milton wrote: Those are block available to non-superuser I think, not "just available" There's some amount reserved (10% ?). Duh. Classic mistake in disguise. :-) Sorry to trouble. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1)does
At 12:41 PM +0200 2000/7/6, Sheldon Hearn wrote: Filesystem Size Used Avail Capacity Mounted on mfs:26 87M11K80M 0%/tmp /dev/ad0s1f 1.2G 934M 241M80%/usr /dev/ad0s1e 193M92M86M52%/var /dev/ccd0c 1.8G 786M 900M47%/a /dev/ad1s1e 1.3G 728M 474M61%/b procfs 4.0K 4.0K 0B 100%/proc rodent.ops:/home/ncvs 3.4G 3.1G36M99%/usr/home/ncvs In particular, I can't believe that 87M - 11K == 80M (I'd expect 86M or 87M). Nor is it credible that 1.8G - 786 == 900M (I'd expect 1057M or 1G). You're ignoring the fact that "Size" is the total physical size of the device, while "Used", "Avail", and "Capacity" take into account the 10% (or whatever) overhead that is typically left unallocated for performance reasons. Thus, when "Capacity" shows that ~110% is used, and "Used" == "Size", then you are really and truly completely full on that device. -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, [EMAIL PROTECTED]|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Large disks (was Re: bin/19635: add -c for grand total to df(1))
On Thu, Jul 06, 2000 at 12:58:27PM +0200, Brad Knowles wrote: [whole discussion about df -h output snipped] You're ignoring the fact that "Size" is the total physical size of the device, while "Used", "Avail", and "Capacity" take into account the 10% (or whatever) overhead that is typically left unallocated for performance reasons. Maybe this isn't the right list to ask, but stepping into this: I bought a 30G drive recently, and I was wondering if the 10% 'rule' for performance is still really needed. I mean, I lose 3 _gigs_ of storage space, and otherwise the performance detoriates? That doesn't make sense to me. I am running now with reserved set to 2% (on my /home, not on smaller / /usr of course) and haven't noticed anything of performance loss; of course I haven't managed to fill that ~27G in the short time I have this setup ;) Which also leads me to the question: is it desirable, given those large disks, to have a finer grain of control over reserved space, for example setting reserved space to 2.5% or whatever? Or can this be done already? In the hopes that someone can enlighten me... --Stijn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: /etc/rc.shutdown calls local scripts now
Moin,
sorry for the late notice, I forgot to mail this yesterday.
/etc/rc.shutdown in -current has been changed to call the scripts in
${local_startup} with the `stop' option. This allows packages like
databases to call their own shutdown methods and clean up after
themselves. All the ports have been changed accordingly. If you still
have old startup scripts lying around in /usr/{local,X11R6}/etc/rc.d
you should upgrade these ASAP.
Basically, the new scripts look like this:
,
| case "$1" in
| start)
| # startup code here
| ;;
| stop)
| # shutdown code here
| ;;
| *)
| echo "Usage: `basename $0` {start|stop}" 2
| exit 64
| ;;
| esac
| exit 0
`
-stable users: I intend to merge and activate this change shortly
before the code freeze for the 4.1 release, which is July 20th, if I'm
not mistaken.
tg
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
config/hints changes: panic booting pcvt kernel
After the latest config/hints changes, just commenting the syscons driver "sc" line and uncommenting the pcvt "vt" line in the GENERIC kernel config file, a booting kernel panics after the the message "atkbdc0: Keyboard controller (i8042) .." with a fatal trap 12, page fault while in kernel mode. This is reliably reproducible on my 2 test machines running current cvsuped a day ago. I'm now trying and searching for two days and i'm running out of ideas. It might be that i'm doing something very stupid here, but i tried hard to make shure i'm doing not. Help hellmuth -- Hellmuth MichaelisTel +49 40 55 97 47-70 HCS Hanseatischer Computerservice GmbHFax +49 40 55 97 47-77 Oldesloer Strasse 97-99 Mail hm [at] hcs.de D-22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] buildworld broken in libusb
Yes, that will work. Sorry for breaking the build. The problem was some
stale files in my directories.
Nick
On Wed, 5 Jul 2000, Ollivier Robert wrote:
According to Ollivier Robert:
buildworld is broken in libusb. Here is a tentative patch (I'm re-building
the world right now). The alternative is to #define UPACKED in usbhid.h.
Forget that fix, it doesn't work.
This one will although I don't like it.
cvs diff: Diffing .
Index: usbhid.h
===
RCS file: /home/ncvs/src/sys/dev/usb/usbhid.h,v
retrieving revision 1.9
diff -u -2 -r1.9 usbhid.h
--- usbhid.h 2000/07/05 08:11:43 1.9
+++ usbhid.h 2000/07/05 11:14:13
@@ -55,4 +55,6 @@
#define UR_SET_PROTOCOL 0x0b
+#define UPACKED __attribute__ ((packed))
+
typedef struct usb_hid_descriptor {
uByte bLength;
--
Ollivier ROBERT -=- Eurocontrol EEC/ITM -=- [EMAIL PROTECTED]
The Postman hits! The Postman hits! You have new mail.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
--
[EMAIL PROTECTED]
[EMAIL PROTECTED] USB project
http://www.etla.net/~n_hibma/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
buildworld breakage in pim6sd
CVSup-ed one hour ago. mkdep -f .depend -a-DINET6 -DPIM -DIOCTL_OK_ON_RAW_SOCKET -DHAVE_GETIFADDRS -DHAVE_STDARG_H -I/usr/obj/src/src/i386/usr/include /src/src/usr.sbin/pim6sd/mld6.c /src/src/usr.sbin/pim6sd/mld6_proto.c /src/src/usr.sbin/pim6sd/inet6.c /src/src/usr.sbin/pim6sd/kern.c /src/src/usr.sbin/pim6sd/main.c /src/src/usr.sbin/pim6sd/config.c /src/src/usr.sbin/pim6sd/debug.c /src/src/usr.sbin/pim6sd/routesock.c /src/src/usr.sbin/pim6sd/vers.c /src/src/usr.sbin/pim6sd/callout.c /src/src/usr.sbin/pim6sd/route.c /src/src/usr.sbin/pim6sd/vif.c /src/src/usr.sbin/pim6sd/timer.c /src/src/usr.sbin/pim6sd/mrt.c /src/src/usr.sbin/pim6sd/pim6.c /src/src/usr.sbin/pim6sd/pim6_proto.c /src/src/usr.sbin/pim6sd/rp.c /src/src/usr.sbin/pim6sd/crc.c /src/src/usr.sbin/pim6sd/trace.c cfparse.c cftoken.c /src/src/usr.sbin/pim6sd/cftoken.l:47: y.tab.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /src/src/usr.sbin/pim6sd. *** Error code 1 -- Ollivier ROBERT -=- Eurocontrol EEC/ITM -=- [EMAIL PROTECTED] The Postman hits! The Postman hits! You have new mail. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] buildworld broken in libusb
According to Nick Hibma: Yes, that will work. Sorry for breaking the build. The problem was some stale files in my directories. No problem, now it is broken elsewhere anyway :-) -- Ollivier ROBERT -=- Eurocontrol EEC/ITM -=- [EMAIL PROTECTED] The Postman hits! The Postman hits! You have new mail. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KAME integration and plans
Could you mention the locations (as in a set of paths) that are hands-off? I'll generate a list and put it somewhere (in the tree?) Good idea. To be honest, I was more thinking of the heads up message. But it was suggested to add it to the readme in netinet6/ Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1) does
On Thu, 06 Jul 2000 10:26:00 -0400, Brian Hechinger wrote: beancounters don't understand that computers can have more than one disk let alone multiple slices. so it gives a nice total number to slap into a pie chart so that you can requisition more hard drives for your machines. This argument from Bill Fumerola is what swayed me enough to bring me back to being neutral. ;-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Large disks (was Re: bin/19635: add -c for grand total to df(1))
On Thu, 6 Jul 2000 13:18:40 +0200, Stijn Hoop [EMAIL PROTECTED] said: Maybe this isn't the right list to ask, but stepping into this: I bought a 30G drive recently, and I was wondering if the 10% 'rule' for performance is still really needed. I mean, I lose 3 _gigs_ of storage space, and otherwise the performance detoriates? That doesn't make sense to me. Yes. The efficiency of the hashing mechanism used to lay out new blocks on the disk depends only on what fraction of the disk is used, not how much space that represents. (On the other hand, it is unlikely that you are significantly stressing the allocator in any meaningful way.) If you're concerned about wasted disk space, there's a lot to be gained by fiddling with the block sizes, bytes per inode, and other layout parameters. Your 30-GB disk probably has a zillion cylinder groups, which is far too many to actually be helpful in disk layout. When creating a large filesystem, it pays to increase the `-c' parameter as high as newfs will permit. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1) does
On Thu, 6 Jul 2000, Sheldon Hearn wrote:
On Thu, 06 Jul 2000 10:26:00 -0400, Brian Hechinger wrote:
beancounters don't understand that computers can have more than one disk let
alone multiple slices. so it gives a nice total number to slap into a pie
chart so that you can requisition more hard drives for your machines.
This argument from Bill Fumerola is what swayed me enough to bring me
back to being neutral. ;-)
First of all I'll state, I (just some FreeBSD user) am neutral on this
as well -- which means, I wouldn't complain if it gets commited. :)
There's just one thing nagging me:
I still can't get past the fact that this can all be done very simply
and much better with available tools. I see this option similar to,
for example, "why not have an option to print only the 'Used' column."
If this were to be commited, there would be no net gain. (No net
loss, either.)
Naturally, "no reason not to put it in" is most certainly *not* a
reason to put it in. I would like to hear some to sway me one way or
the other.
Spoiler:
df /disk1 /disk2 | \
awk '/^\// {t+=$2;u+=$3;} END { print "Total:", t,u,t-u,u*100/t; }'
...and "slaping 'df -c' into a pie chart" usually intails running it
through some parser like this, anyway... or?
-Paul.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
pam login.conf
Looking through new PAMed login and PAM unix auth module i didn't find setting of login class params, such as resource limits, environment variables, etc. Do somebody working on it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1) does
On Thu, Jul 06, 2000 at 06:09:54PM +0200, Paul Herman wrote: Naturally, "no reason not to put it in" is most certainly *not* a reason to put it in. I would like to hear some to sway me one way or the other. How about precedent: du -c. "Hey, we could have used an awk script with du(1) too!!" -- Will Andrews [EMAIL PROTECTED] [EMAIL PROTECTED] GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+ G+ e- h! r--+++ y? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: subtle problem du jour....
At 12:50 AM -0600 7/6/00, John Galt wrote: Is there a quick and dirty way for the label editor to detect if a BIOS is using LBA? This actually sounds like a setup in which the error condition should be alerted on placing / on a cylinder higher than 1024 rather than long after you can do anything about it. The loader error might be a good extra, but the real place the user should be notified of the error condition is upon creation. In theory I agree with you. In my specific case, I was trying to do something "clever" (ahem), and as such it's pretty much my own fault that the partition ended up past the 8-gig mark. The label editor would have had to have been mighty smart to realize what I was up to. So, based on the sample of what I myself was doing, I don't really think it's possible to detect this problem at creation time. A clearer message at boot time would have been appreciated, though. --- Garance Alistair Drosehn = [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Institute To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld breakage in pim6sd
On Thu, 6 Jul 2000 15:49:27 +0200
Ollivier Robert [EMAIL PROTECTED] said:
roberto /src/src/usr.sbin/pim6sd/cftoken.l:47: y.tab.h: No such file or directory
roberto mkdep: compile failed
roberto *** Error code 1
Thank you for reporting.
I just fixed.
Index: Makefile
===
RCS file: /home/ncvs/src/usr.sbin/pim6sd/Makefile,v
retrieving revision 1.4
diff -u -r1.4 Makefile
--- Makefile2000/07/06 01:48:00 1.4
+++ Makefile2000/07/06 18:13:29
@@ -84,6 +84,7 @@
y.tab.h: cfparse.y
CLEANFILES+= lex.yy.c y.tab.h y.tab.c
CFLAGS+=-Wall
+CFLAGS+=-I. -I${.CURDIR}
CFLAGS+=-DINET6 -DPIM -DIOCTL_OK_ON_RAW_SOCKET -DHAVE_GETIFADDRS
CFLAGS+=-DHAVE_STDARG_H
DPADD= ${LIBY} ${LIBL}
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
SB Live (or RAM parity?) crash on today's -CURRENT
'panic: RAM parity error, likely hardware failure.'
This one had me confused at first, because it blamed a RAM parity
error. As this is a brand new machine (Gateway GP-800), so I first thought
I got a bad batch. Then I realized this only happens with apps that try to
do sound stuff. It's also doubtful that it's a RAM parity error due to the
severe compiling workout I've given it in the last 24 hours (134 ports, a
few kernels and several attempts make world).
Unfortunatly, since this machine was installed with
yesterdays build to begin with, I cannot confirm whether or sound works on
older builds (if needed for testing, I can rollback to an earlier kern
revision..). I can get it to crash just by playing mpg123 or restarting
esd.
machine:
FreeBSD aesthetic.detachment.org 5.0-CURRENT FreeBSD 5.0-CURRENT
#0: Thu Jul 6 12:55:50 EDT 2000
[EMAIL PROTECTED]:/usr/src/sys/compile/AESTHETIX i386
gdb -k backtrace:
=
IdlePTD 3555328
initial pcb at 2dd180
panicstr: RAM parity error, likely hardware failure.
panic messages:
---
panic: RAM parity error, likely hardware failure.
syncing disks... 14 11
done
Uptime: 10m21s
dumping to dev #ad/0x20001, offset 786432
dump ata0: resetting devices .. done
128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111
110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90
89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65
64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40
39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15
14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:303
303 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:303
#1 0xc0151320 in poweroff_wait (junk=0xc0291e80, howto=-903562160)
at ../../kern/kern_shutdown.c:553
#2 0xc0260341 in isa_nmi (cd=0) at ../../i386/isa/intr_machdep.c:254
#3 0xc025a652 in trap (frame={tf_fs = -1058078704, tf_es = 16,
tf_ds = -903610352, tf_edi = -1058025472, tf_esi = 49151,
tf_ebp = -903562084, tf_isp = -903562108, tf_ebx = 4, tf_edx = 4260,
tf_ecx = 49151, tf_eax = 49151, tf_trapno = 19, tf_err = 0,
tf_eip = -1072503013, tf_cs = 8, tf_eflags = 582, tf_esp = 16,
tf_ss = -903562048}) at ../../i386/i386/trap.c:583
#4 0xc012e71b in emu_wr (sc=0xc0efd000, regno=4, data=49151, size=4)
at machine/cpufunc.h:331
#5 0xc012e807 in emu_wrptr (sc=0xc0efd000, chn=0, reg=16, data=49151)
at ../../dev/sound/pci/emu10k1.c:258
#6 0xc012ef82 in emu_vwrite (sc=0xc0efd000, v=0xc0efd088)
at ../../dev/sound/pci/emu10k1.c:585
#7 0xc012f21b in emupchan_trigger (data=0xc0efda88, go=1)
at ../../dev/sound/pci/emu10k1.c:719
#8 0xc0135a58 in chn_trigger (c=0xc0ef9800, go=1)
at ../../dev/sound/pcm/channel.c:1251
#9 0xc0134a06 in chn_wrintr (c=0xc0ef9800)
at ../../dev/sound/pcm/channel.c:385
#10 0xc013503f in chn_intr (c=0xc0ef9800) at
../../dev/sound/pcm/channel.c:785
#11 0xc01350b7 in chn_start (c=0xc0ef9800) at
../../dev/sound/pcm/channel.c:811
#12 0xc0134b33 in chn_write (c=0xc0ef9800, buf=0xca24bedc)
at ../../dev/sound/pcm/channel.c:476
#13 0xc0135e70 in dsp_write (d=0xc0ef7c00, chan=0, buf=0xca24bedc,
flag=131089)
at ../../dev/sound/pcm/dsp.c:194
#14 0xc0137e21 in sndwrite (i_dev=0xc0efa800, buf=0xca24bedc, flag=131089)
at ../../dev/sound/pcm/sound.c:359
#15 0xc018bffd in spec_write (ap=0xca24be70)
at ../../miscfs/specfs/spec_vnops.c:291
#16 0xc0221c38 in ufsspec_write (ap=0xca24be70)
at ../../ufs/ufs/ufs_vnops.c:1857
#17 0xc02220ed in ufs_vnoperatespec (ap=0xca24be70)
at ../../ufs/ufs/ufs_vnops.c:2305
#18 0xc01874e4 in vn_write (fp=0xc105ae00, uio=0xca24bedc,
cred=0xc102f200,
flags=0, p=0xca212100) at vnode_if.h:363
#19 0xc0161ca6 in dofilewrite (p=0xca212100, fp=0xc105ae00, fd=4,
buf=0x8056000, nbyte=4096, offset=-1, flags=0) at ../../sys/file.h:157
#20 0xc0161b9b in write (p=0xca212100, uap=0xca24bf80)
at ../../kern/sys_generic.c:308
#21 0xc025af01 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 134569984, tf_esi = 55, tf_ebp = -1077937444,
tf_isp = -903561260, tf_ebx = 671725864, tf_edx = 671686271,
tf_ecx = 7807, tf_eax = 4, tf_trapno = 22, tf_err = 2,
tf_eip = 672214240, tf_cs = 31, tf_eflags = 663, tf_esp =
-1077937488,
tf_ss = 47}) at ../../i386/i386/trap.c:1126
#22 0xc0250205 in Xint0x80_syscall ()
#23 0x804a0d9 in ?? ()
#24 0x804901d in ?? ()
dmesg:
==
CPU: Pentium III/Pentium III Xeon/Celeron (796.54-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x683 Stepping = 3
Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,XMM
real memory = 134217728 (131072K bytes)
avail memory = 127098880 (124120K bytes)
Preloaded elf kernel "kernel" at 0xc0352000.
Pentium Pro MTRR support enabled
md0: Malloc disk
npx0: math processor on
Re: HEADS UP: /etc/rc.shutdown calls local scripts now
Thomas Gellekum [EMAIL PROTECTED] writes:
/etc/rc.shutdown in -current has been changed to call the scripts in
${local_startup} with the `stop' option. This allows packages like
databases to call their own shutdown methods and clean up after
themselves
This will make it a bit harder to quickly add a boot-time start-up
script. If not done right, the start-up script will be called twice,
and will try to start the program each time, if it doesn't recognize the
'stop' argument. Not upward compatible and possibly harmful to some
software.
Better would be to put compatible scripts in a new directory.
rc.d : invoked without arguments only when system boots
rc.e : invoked with 'start' or 'stop'
argument, when system boots or shuts down
Alternatively a new suffix could be used.
name.sh : invoked without arguments only when system boots
name.nsh : invoked with 'start' or 'stop' argument,
when system boots or shuts down
Alternatively (less upward compatible) legacy scripts could be
given a different suffix. Then just a rename would make a script
compatible, without having to rewrite it to recognize 'start'
and 'stop' arguments.
name.osh : invoked without arguments only when system boots
name.sh : invoked with 'start' or 'stop' argument,
when system boots or shuts down
Other upward-compatible solutions are probably possible.
Oh, also, the order in which scripts are called ought ideally
be to be reversed at shutdown time.
--
Rahul
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/netgraph ng_ether.c
Julian Elischer writes: julian 2000/07/06 08:36:00 PDT Modified files: sys/netgraph ng_ether.c Log: Don't forget to set our MAC address into packets we wre sending out via netgraph. Eventually we may need to have a separate hook for packets that already have a source AMC address but for now just drop it in. Should fix PPPoE. Revision ChangesPath 1.2 +7 -1 src/sys/netgraph/ng_ether.c Yes, that fixed it. Thanks, Julian ! --- Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pam login.conf
Looking through new PAMed login and PAM unix auth module i didn't find setting of login class params, such as resource limits, environment variables, etc. Do somebody working on it? I'll get there (eventually). Patches welcome :-). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: /etc/rc.shutdown calls local scripts now
Rahul Dhesi wrote: Can we have little green "[ OK ]"s as well? :) I hope you are joking... LOL... We don't want Linux emulation to go in that direction. It's not the green that's important, it's the 'OK'. The way Redhat Linux boots, you can see at a glance which start-up commands failed and which ones succeeded. The way FreeBSD boots, it's all one big blur. I don't like the Linux/HP-UX/whatever way simply because it's non-unix in the sense that normally output is generated only in case of failure or in exceptional conditions. It's "telling" me things I don't want to "hear". The same applies to having "N/A" or "FAIL" emitted for services that aren't enabled/configured (in which case printing "FAIL" is plain wrong). Also, in the Linux scheme, there is a standard mechanism to keep track of which boot-time service has already been started, and any accidental re-invocation of the script (without an intervening 'stop') will be detected and rejected. Which means that if the daemon is down and the script doesn't know about it, you have to remove pid files and whatnot to use the script again to get the daemon running, right? I personally find the 'chkconfig' command to be very convenient to enable, disable, and list boot-time services, without having to manually rename xxx.sh to xxx.sh.DISABLED and back. You mean the irritating pop-up that asks you questions everytime the bloody machine boots? :-) -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: /etc/rc.shutdown calls local scripts now
We have gone to some pains in the past to make the rc.d scripts silent. Either work or fail silently. if [ -x ... ]; do ... done Now, with the addition of the start/stop, there is a message output if the argument is not 'start' or 'stop'. The default should be 'start'. These scripts are frequently used to restart or redo things. And, continue to exit silently in all cases. tomdean To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SB Live (or RAM parity?) crash on today's -CURRENT
I filed a PR on this a little while ago. i386/19410.It happens on 4.0-STABLE (as
of
Tue Jun 20 19:40:01 PDT 2000), too. I have a revision 5 SBLive card. An interesting
commonality (possible connection) is that I have a Gateway system; This is a GP6-450.
Tim
On Thu, Jul 06, 2000 at 02:26:01PM -0400, Thomas Stromberg wrote:
'panic: RAM parity error, likely hardware failure.'
This one had me confused at first, because it blamed a RAM parity
error. As this is a brand new machine (Gateway GP-800), so I first thought
I got a bad batch. Then I realized this only happens with apps that try to
do sound stuff. It's also doubtful that it's a RAM parity error due to the
severe compiling workout I've given it in the last 24 hours (134 ports, a
few kernels and several attempts make world).
Unfortunatly, since this machine was installed with
yesterdays build to begin with, I cannot confirm whether or sound works on
older builds (if needed for testing, I can rollback to an earlier kern
revision..). I can get it to crash just by playing mpg123 or restarting
esd.
machine:
FreeBSD aesthetic.detachment.org 5.0-CURRENT FreeBSD 5.0-CURRENT
#0: Thu Jul 6 12:55:50 EDT 2000
[EMAIL PROTECTED]:/usr/src/sys/compile/AESTHETIX i386
gdb -k backtrace:
=
IdlePTD 3555328
initial pcb at 2dd180
panicstr: RAM parity error, likely hardware failure.
panic messages:
---
panic: RAM parity error, likely hardware failure.
syncing disks... 14 11
done
Uptime: 10m21s
dumping to dev #ad/0x20001, offset 786432
dump ata0: resetting devices .. done
128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111
110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90
89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65
64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40
39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15
14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:303
303 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:303
#1 0xc0151320 in poweroff_wait (junk=0xc0291e80, howto=-903562160)
at ../../kern/kern_shutdown.c:553
#2 0xc0260341 in isa_nmi (cd=0) at ../../i386/isa/intr_machdep.c:254
#3 0xc025a652 in trap (frame={tf_fs = -1058078704, tf_es = 16,
tf_ds = -903610352, tf_edi = -1058025472, tf_esi = 49151,
tf_ebp = -903562084, tf_isp = -903562108, tf_ebx = 4, tf_edx = 4260,
tf_ecx = 49151, tf_eax = 49151, tf_trapno = 19, tf_err = 0,
tf_eip = -1072503013, tf_cs = 8, tf_eflags = 582, tf_esp = 16,
tf_ss = -903562048}) at ../../i386/i386/trap.c:583
#4 0xc012e71b in emu_wr (sc=0xc0efd000, regno=4, data=49151, size=4)
at machine/cpufunc.h:331
#5 0xc012e807 in emu_wrptr (sc=0xc0efd000, chn=0, reg=16, data=49151)
at ../../dev/sound/pci/emu10k1.c:258
#6 0xc012ef82 in emu_vwrite (sc=0xc0efd000, v=0xc0efd088)
at ../../dev/sound/pci/emu10k1.c:585
#7 0xc012f21b in emupchan_trigger (data=0xc0efda88, go=1)
at ../../dev/sound/pci/emu10k1.c:719
#8 0xc0135a58 in chn_trigger (c=0xc0ef9800, go=1)
at ../../dev/sound/pcm/channel.c:1251
#9 0xc0134a06 in chn_wrintr (c=0xc0ef9800)
at ../../dev/sound/pcm/channel.c:385
#10 0xc013503f in chn_intr (c=0xc0ef9800) at
../../dev/sound/pcm/channel.c:785
#11 0xc01350b7 in chn_start (c=0xc0ef9800) at
../../dev/sound/pcm/channel.c:811
#12 0xc0134b33 in chn_write (c=0xc0ef9800, buf=0xca24bedc)
at ../../dev/sound/pcm/channel.c:476
#13 0xc0135e70 in dsp_write (d=0xc0ef7c00, chan=0, buf=0xca24bedc,
flag=131089)
at ../../dev/sound/pcm/dsp.c:194
#14 0xc0137e21 in sndwrite (i_dev=0xc0efa800, buf=0xca24bedc, flag=131089)
at ../../dev/sound/pcm/sound.c:359
#15 0xc018bffd in spec_write (ap=0xca24be70)
at ../../miscfs/specfs/spec_vnops.c:291
#16 0xc0221c38 in ufsspec_write (ap=0xca24be70)
at ../../ufs/ufs/ufs_vnops.c:1857
#17 0xc02220ed in ufs_vnoperatespec (ap=0xca24be70)
at ../../ufs/ufs/ufs_vnops.c:2305
#18 0xc01874e4 in vn_write (fp=0xc105ae00, uio=0xca24bedc,
cred=0xc102f200,
flags=0, p=0xca212100) at vnode_if.h:363
#19 0xc0161ca6 in dofilewrite (p=0xca212100, fp=0xc105ae00, fd=4,
buf=0x8056000, nbyte=4096, offset=-1, flags=0) at ../../sys/file.h:157
#20 0xc0161b9b in write (p=0xca212100, uap=0xca24bf80)
at ../../kern/sys_generic.c:308
#21 0xc025af01 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 134569984, tf_esi = 55, tf_ebp = -1077937444,
tf_isp = -903561260, tf_ebx = 671725864, tf_edx = 671686271,
tf_ecx = 7807, tf_eax = 4, tf_trapno = 22, tf_err = 2,
tf_eip = 672214240, tf_cs = 31, tf_eflags = 663, tf_esp =
-1077937488,
tf_ss = 47}) at ../../i386/i386/trap.c:1126
#22 0xc0250205 in Xint0x80_syscall ()
#23 0x804a0d9 in ?? ()
#24 0x804901d in ?? ()
Re: HEADS UP: /etc/rc.shutdown calls local scripts now
On Thu, Jul 06, 2000, Rahul Dhesi wrote: Linh Pham [EMAIL PROTECTED] writes: Can we have little green "[ OK ]"s as well? :) j/k I hope you are joking... LOL... We don't want Linux emulation to go in that direction. It's not the green that's important, it's the 'OK'. The way Redhat Linux boots, you can see at a glance which start-up commands failed and which ones succeeded. The way FreeBSD boots, it's all one big blur. Also, in the Linux scheme, there is a standard mechanism to keep track of which boot-time service has already been started, and any accidental re-invocation of the script (without an intervening 'stop') will be detected and rejected. I personally find the 'chkconfig' command to be very convenient to enable, disable, and list boot-time services, without having to manually rename xxx.sh to xxx.sh.DISABLED and back. Well, chkconfig isn't a linux thing: replicate 1% uname -a IRIX replicate 6.5 05190003 IP22 replicate 2% which chkconfig /sbin/chkconfig replicate 3% And its actually very useful IMHO. Thats what rc.conf is for though, right? enable_pkg_apache="YES" enable_pkg_qmail="YES" enable_pkg_mysql="YES" and so on .. ? Adrian -- Adrian ChaddBuild a man a fire, and he's warm for the [EMAIL PROTECTED]rest of the evening. Set a man on fire and he's warm for the rest of his life. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pam login.conf
On Thu, 6 Jul 2000, Mark Murray wrote: I'll get there (eventually). Oh, great. Somebody do get there. ;-) Patches welcome :-). I don't know if i can help much. PAM is new and completly unknown to me. Old login was much more simlier. Maybe i'll try to integrate something from 2.2. Can you help me - which pam functions should i use or read man/sources to set such user attributes as resource limits are? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: /etc/rc.shutdown calls local scripts now
On Thu, Jul 06, 2000, Adrian Chadd wrote: And its actually very useful IMHO. Thats what rc.conf is for though, right? enable_pkg_apache="YES" enable_pkg_qmail="YES" enable_pkg_mysql="YES" and so on .. ? Before people start going "huh?" .. that was an idea, not an outline as to what happens today. :-P Adrian -- Adrian ChaddBuild a man a fire, and he's warm for the [EMAIL PROTECTED]rest of the evening. Set a man on fire and he's warm for the rest of his life. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bin/19635: add -c for grand total to df(1), like du(1) does
On Thu, Jul 06, 2000 at 06:09:54PM +0200, Paul Herman wrote:
Naturally, "no reason not to put it in" is most certainly *not* a
reason to put it in. I would like to hear some to sway me one way or
the other.
Spoiler:
df /disk1 /disk2 | \
awk '/^\// {t+=$2;u+=$3;} END { print "Total:", t,u,t-u,u*100/t; }'
...and "slaping 'df -c' into a pie chart" usually intails running it
through some parser like this, anyway... or?
[hawk-billf] /home/billf du -s /usr/src/sys/i386 /usr/ports/math | \
awk '{t+=$1; print $0} END { print t, "\ttotal" }'
6282/usr/src/sys/i386
15288 /usr/ports/math
21570 total
[hawk-billf] /home/billf du -cs /usr/src/sys/i386 /usr/ports/math
6282/usr/src/sys/i386
15288 /usr/ports/math
21570 total
Precedence.
--
Bill Fumerola - Network Architect / Computer Horizons Corp - CHIMES
e-mail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
HEADS UP: cvs commit: src/lib/libftpio Makefile (fwd)
If anyone has done a make world within the past few days you should remove your libftpio.6 since the version bump was made in error. It's now back to libftpio.5. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] -- Forwarded message -- Date: Thu, 6 Jul 2000 13:19:02 -0700 (PDT) From: Hajimu UMEMOTO [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: cvs commit: src/lib/libftpio Makefile ume 2000/07/06 13:19:02 PDT Modified files: lib/libftpio Makefile Log: Reduce shlib major that is bumped by my mistake. We don't need bumping it in this time. Revision ChangesPath 1.11 +2 -2 src/lib/libftpio/Makefile To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: /etc/rc.shutdown calls local scripts now
Quickie question:
By implementing the 'start' and 'stop' in the local scripts, how much
should one _expect_ their systems bootup and slow down times to take?
I'm hearing whines of being to linux like, to sysv'ish and some likely
valid complaints on startup/shutdown time.
I, for one, like the functionality, and thought it kinda already worked
that way (or maybe I _made_ it work that way on my machines, cn't
remember). I would like solid facts, rather than a religious/exagerated
discussion.
To my (limited) understanding of this subject, it's not going to make hour
long boot-ups. It may increase shutdown time to do things, but, sometimes
you need to properly shut things down. If that were not the case, one
could flip the power switch instead of typing shutdown..
--
Close your eyes. Now forget what you see. What do you feel? --
My heart. -- Come here. -- Your heart. -- See? We're exactly the same.
Jon Smith -- Senior Math Major @ Purdue
On Thu, 6 Jul 2000, Dan Nelson wrote:
In the last episode (Jul 06), Thomas Gellekum said:
sorry for the late notice, I forgot to mail this yesterday.
/etc/rc.shutdown in -current has been changed to call the scripts in
${local_startup} with the `stop' option. This allows packages like
databases to call their own shutdown methods and clean up after
themselves. All the ports have been changed accordingly. If you still
have old startup scripts lying around in /usr/{local,X11R6}/etc/rc.d
you should upgrade these ASAP.
Can we have little green "[ OK ]"s as well? :)
j/k
--
Dan Nelson
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: /etc/rc.shutdown calls local scripts now
On Thu, Jul 06, 2000 at 12:53:09PM -0400, Brandon D. Valentine wrote: On Thu, 6 Jul 2000, Chris D. Faulhaber wrote: Many Linux distributions do this too. It seems about as useful as a car's idiot light(s)... IMO, I would prefer to see useful information during boot than that eye-candy. I'd prefer to buy a box of blinkenlights to put in a spare 5.25" bay and let the dmesg on boot reflect only what I need to know as an admin when the box comes up. We had that once. It's called a PDP/11 -- Wilko Bulte http://www.freebsd.org "Do, or do not. There is no try" [EMAIL PROTECTED] http://www.nlfug.nl Yoda - The Empire Strikes Back To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: /etc/rc.shutdown calls local scripts now
In the last episode (Jul 06), Thomas Gellekum said:
sorry for the late notice, I forgot to mail this yesterday.
/etc/rc.shutdown in -current has been changed to call the scripts in
${local_startup} with the `stop' option. This allows packages like
databases to call their own shutdown methods and clean up after
themselves. All the ports have been changed accordingly. If you still
have old startup scripts lying around in /usr/{local,X11R6}/etc/rc.d
you should upgrade these ASAP.
Can we have little green "[ OK ]"s as well? :)
j/k
--
Dan Nelson
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: /etc/rc.shutdown calls local scripts now
In the last episode (Jul 06), Thomas Gellekum said:
sorry for the late notice, I forgot to mail this yesterday.
/etc/rc.shutdown in -current has been changed to call the scripts in
${local_startup} with the `stop' option. This allows packages like
databases to call their own shutdown methods and clean up after
themselves. All the ports have been changed accordingly. If you still
have old startup scripts lying around in /usr/{local,X11R6}/etc/rc.d
you should upgrade these ASAP.
Can we have little green "[ OK ]"s as well? :)
j/k
I hope you are joking... LOL... We don't want Linux emulation to go in
that direction.
--
Dan Nelson
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: /etc/rc.shutdown calls local scripts now
On Thu, 6 Jul 2000, Linh Pham wrote: : : Can we have little green "[ OK ]"s as well? :) : : j/k : :I hope you are joking... LOL... We don't want Linux emulation to go in :that direction. HP/UX does something like this. I find it rather useful, but that may be because I have boxes that take almost an hour to boot David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: /etc/rc.shutdown calls local scripts now
On Thu, 6 Jul 2000, David Scheidt wrote: On Thu, 6 Jul 2000, Linh Pham wrote: : : Can we have little green "[ OK ]"s as well? :) : : j/k : :I hope you are joking... LOL... We don't want Linux emulation to go in :that direction. HP/UX does something like this. I find it rather useful, but that may be because I have boxes that take almost an hour to boot An hour to boot? Boy... the only time I ever saw a machine take an hour to boot (which does not include the POST/memory check/BIOS screen) was a 486SX/33 with 24MB of RAM running Windows NT 3.51 SP3. Of course it was running off of a 5 1/4" 400MB SCSI hard drive too! David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: /etc/rc.shutdown calls local scripts now
On Thu, 6 Jul 2000, David Scheidt wrote: On Thu, 6 Jul 2000, Linh Pham wrote: : : Can we have little green "[ OK ]"s as well? :) : : j/k : :I hope you are joking... LOL... We don't want Linux emulation to go in :that direction. HP/UX does something like this. I find it rather useful, but that may be because I have boxes that take almost an hour to boot Many Linux distributions do this too. It seems about as useful as a car's idiot light(s)... IMO, I would prefer to see useful information during boot than that eye-candy. - Chris D. Faulhaber - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: 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: HEADS UP: /etc/rc.shutdown calls local scripts now
HP/UX does something like this. I find it rather useful, but that may be because I have boxes that take almost an hour to boot An hour to boot? Boy... the only time I ever saw a machine take an hour to boot (which does not include the POST/memory check/BIOS screen) was a 486SX/33 with 24MB of RAM running Windows NT 3.51 SP3. Of course it was running off of a 5 1/4" 400MB SCSI hard drive too! Try a Solaris 2.6 machine fsck'ing an array of 14 9.1 giggers Longest I've ever seen a BSD box boot was about 10-15 minutes though, including fsck'ing 4 drives To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: /etc/rc.shutdown calls local scripts now
On Thu, 6 Jul 2000, Chris D. Faulhaber wrote: Many Linux distributions do this too. It seems about as useful as a car's idiot light(s)... IMO, I would prefer to see useful information during boot than that eye-candy. I'd prefer to buy a box of blinkenlights to put in a spare 5.25" bay and let the dmesg on boot reflect only what I need to know as an admin when the box comes up. Brandon D. Valentine -- bandix at looksharp.net | bandix at structbio.vanderbilt.edu "Truth suffers from too much analysis." -- Ancient Fremen Saying To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
_DIAGASSERT in libusb libutil
# grep -r DIAGASSERT . (from /usr/src) ./lib/libutil/fparseln.c: _DIAGASSERT(sp != NULL); ./lib/libutil/fparseln.c: _DIAGASSERT(p != NULL); ./lib/libutil/fparseln.c: _DIAGASSERT(fp != NULL); ./lib/libusb/data.c:_DIAGASSERT(p != NULL); ./lib/libusb/data.c:_DIAGASSERT(h != NULL); ./lib/libusb/data.c:_DIAGASSERT(p != NULL); ./lib/libusb/data.c:_DIAGASSERT(h != NULL); ./lib/libusb/descr.c: _DIAGASSERT(fd != -1); ./lib/libusb/parse.c: _DIAGASSERT(c != NULL); ./lib/libusb/parse.c: _DIAGASSERT(d != NULL); ./lib/libusb/parse.c: _DIAGASSERT(s != NULL); ./lib/libusb/parse.c: _DIAGASSERT(s != NULL); ./lib/libusb/parse.c: _DIAGASSERT(h != NULL); ./lib/libusb/parse.c: _DIAGASSERT(r != NULL); ./lib/libusb/parse.c: _DIAGASSERT(desc != NULL); ./lib/libusb/parse.c: _DIAGASSERT(h != NULL); ./make.out.070600.1528:/usr/obj/usr/src/i386/usr/lib/libusb.so: undefined reference to `_DIAGASSERT' Where does _DIAGASSERT come from? I updated right before I built which was 3:30 edt -Charlie -- Charles Anderson[EMAIL PROTECTED] No quote, no nothin' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
module compile problems, partial fix attached
I've got a source tree with -current from today, and I'm trying to build a
kernel using that source on a machine running -current from about June
10th.
I'm using a config built from the tree in question, so I know that's up to
date.
Anyway, I'm running into problems building the sound modules modules,
since it seems that the sound modules are one directory level deeper than
any other modules, and the sys directory search process in bsd.kmod.mk
wasn't updated to take that into account.
The result is that the build for the sound modules on my system is looking
in /usr/src (which is symlinked to /a/src) on my machine, which doesn't
contain an up-to-date -current.
This is from the sys/compile/MACHINE/modules//sound/drivers/ad1816
directory:
total 19
drwx-- 2 ken wheel 512 Jul 6 15:20 ./
drwx-- 17 ken wheel 512 Jul 6 14:59 ../
-rw--- 1 ken wheel 1490 Jul 6 15:00 .depend
lrwx-- 1 ken wheel10 Jul 6 15:00 @@ - /a/src/sys
-rw--- 1 ken wheel 7297 Jul 6 15:00 bus_if.h
-rw--- 1 ken wheel 2069 Jul 6 15:00 device_if.h
-rw--- 1 ken wheel 1570 Jul 6 15:00 isa_if.h
lrwx-- 1 ken wheel23 Jul 6 15:00 machine@ - /a/src/sys/i386/include
-rw--- 1 ken wheel 1140 Jul 6 15:00 pci_if.h
/a/src isn't the tree that the modules are being compiled from, but rather
another, older -current tree.
This causes the sound modules to blow up:
=
=== sound/driver
=== sound/driver/ad1816
cc -O -pipe -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi
-DKLD_MODULE -nostdinc -I- -I. -I@ -I@/../include -mpreferred-stack-boundary=2 -c
/a/ken/perforce/cam/sys/modules/sound/driver/ad1816/../../../../dev/sound/isa/ad1816.c
/a/ken/perforce/cam/sys/modules/sound/driver/ad1816/../../../../dev/sound/isa/ad1816.c:623:
`PCM_MINVER' undeclared here (not in a function)
/a/ken/perforce/cam/sys/modules/sound/driver/ad1816/../../../../dev/sound/isa/ad1816.c:623:
initializer element is not constant
/a/ken/perforce/cam/sys/modules/sound/driver/ad1816/../../../../dev/sound/isa/ad1816.c:623:
(near initialization for `_snd_ad1816_depend_on_snd_pcm.md_ver_minimum')
/a/ken/perforce/cam/sys/modules/sound/driver/ad1816/../../../../dev/sound/isa/ad1816.c:623:
`PCM_PREFVER' undeclared here (not in a function)
/a/ken/perforce/cam/sys/modules/sound/driver/ad1816/../../../../dev/sound/isa/ad1816.c:623:
initializer element is not constant
/a/ken/perforce/cam/sys/modules/sound/driver/ad1816/../../../../dev/sound/isa/ad1816.c:623:
(near initialization for `_snd_ad1816_depend_on_snd_pcm.md_ver_preferred')
/a/ken/perforce/cam/sys/modules/sound/driver/ad1816/../../../../dev/sound/isa/ad1816.c:623:
`PCM_MAXVER' undeclared here (not in a function)
/a/ken/perforce/cam/sys/modules/sound/driver/ad1816/../../../../dev/sound/isa/ad1816.c:623:
initializer element is not constant
/a/ken/perforce/cam/sys/modules/sound/driver/ad1816/../../../../dev/sound/isa/ad1816.c:623:
(near initialization for `_snd_ad1816_depend_on_snd_pcm.md_ver_maximum')
*** Error code 1
Stop in /a/ken/perforce/cam/sys/modules/sound/driver/ad1816.
*** Error code 1
Stop in /a/ken/perforce/cam/sys/modules/sound/driver.
*** Error code 1
Stop in /a/ken/perforce/cam/sys/modules/sound.
*** Error code 1
Stop in /a/ken/perforce/cam/sys/modules.
*** Error code 1
Stop in /a/ken/perforce/cam/sys/compile/sphere.
=
I suspect that the problem is the depth of the sound driver module tree and
the method that bsd.kmod.mk uses to determine where the sys directory is.
sys/modules/sound/driver/ad1816/Makefile includes bsd.kmod.mk, which does
the following to find the "sys" directory:
# Search for kernel source tree in standard places.
.for _dir in ${.CURDIR}/../.. ${.CURDIR}/../../.. /sys /usr/src/sys
.if !defined(SYSDIR) exists(${_dir}/kern/) exists(${_dir}/conf/)
SYSDIR= ${_dir}
.endif
.endfor
.if !defined(SYSDIR) || !exists(${SYSDIR}/kern/) || !exists(${SYSDIR}/conf/)
.error "can't find kernel source tree"
.endif
.include "${SYSDIR}/conf/kmod.mk"
Note that it checks two directories up, and three directories up from the
current directory for a sys directory, but the ad1816 module is actually
four directories down from the top level sys directory.
So the 'kern' and 'conf' directories are not found, and the search then
looks in /sys and /usr/src/sys, which is the wrong thing to do on this
system.
The fix for this is to include the directory four levels higher than the
current directory in the search path in bsd.kmod.mk, above.
The problem with this fix is that it only works after you've done an
installworld or manually installed bsd.kmod.mk, because the module build
uses the system's bsd.kmod.mk from /usr/share/mk instead of attempting to
pull in bsd.kmod.mk
Re: bin/19635: add -c for grand total to df(1), like du(1) does
On Thu, 6 Jul 2000, Bill Fumerola wrote: On Thu, Jul 06, 2000 at 06:09:54PM +0200, Paul Herman wrote: Naturally, "no reason not to put it in" is most certainly *not* a reason to put it in. I would like to hear some to sway me one way or the other. [...] [hawk-billf] /home/billf du -cs /usr/src/sys/i386 /usr/ports/math 6282/usr/src/sys/i386 15288 /usr/ports/math 21570 total Precedence. OK, I'm with ya, I could go with Precedence, but you have to admit, it's pretty weak. Just because "it's been done before"...? Hmmm. Well, I was hoping for something concrete about the program like "because this option gives us something never seen by sysadmins before without massive contortions", or "this option does correctly what XXX program never could..." etc. Unfortunately, I can't think of any myself. For what one person's opinion is worth, I still haven't heard a strong reason for this. Sorry guys, you can still color me undecided on this one. :( On a side note, look what I found: bash-2.03# cd bash-2.03# ln -s /dev/ad0s6e "Heh? What's this?" bash-2.03# mount "Heh? What's this?" /mnt bash-2.03# ln -s /dev/ad0s6f total bash-2.03# mount total /mnt2 bash-2.03# mkdir whut_thuh_hey; cd whut_thuh_hey bash-2.03# ln -s /dev/ad0s6g total bash-2.03# mount total /mnt3 bash-2.03# df Filesystem1K-blocks UsedAvail Capacity Mounted on /dev/ad0s2a 44650330922 379861 8%/ /dev/ad0s9e 1453615 758910 57841657%/usr /dev/ad0s9f 968983 357403 53406240%/usr/local /dev/ad0s9g 242239 9945 212915 4%/var /dev/ad0s9h 2013515 1242447 60998767%/u01 procfs440 100%/proc Heh? What's this?242239 9945 212915 4%/mnt total 1581144 505684 99514034%/mnt2 total 1391380 414168 90652831%/mnt3 bash-2.03# Hee, hee. Yes, this is probably no big deal (and not put forth as any strong argument for not commiting this) but who knows what some cronjob scripts might expect. Hmmm, let me give constructive criticism a shot and see how far it goes: Perhaps if it were expected that the "df -c" output were completly different? Then "total" would be less likely to be counted as some other filesystem by mistake? Perhaps something along the lines: bash-2.0.3# df -c /usr /usr/local Totals for: /usr /usr/local 1K-Blocks: 2422598 Used: 1116313 Avail: 1306285 Capacity: 46% Dunno how that would go over with the purists, though... after all 'df' is in one of the holiest of directories... /bin. g -Paul. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: /etc/rc.shutdown calls local scripts now
On Thu, 6 Jul 2000, Rahul Dhesi wrote: Linh Pham [EMAIL PROTECTED] writes: Can we have little green "[ OK ]"s as well? :) j/k I hope you are joking... LOL... We don't want Linux emulation to go in that direction. It's not the green that's important, it's the 'OK'. The way Redhat Linux boots, you can see at a glance which start-up commands failed and which ones succeeded. The way FreeBSD boots, it's all one big blur. But guess what, the error messages are eaten. I've had times where errors were not redirected into the log so you have phantom errors. Plus I've had erroneous 'OK' conditions on things that were actually broken (eg missing ethernet interfaces). The current way spews the error all over, but it's plainly obvious what's broken and why. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: /etc/rc.shutdown calls local scripts now
Jonathan Smith writes: I, for one, like the functionality, and thought it kinda already worked that way (or maybe I _made_ it work that way on my machines, cn't remember). I would like solid facts, rather than a religious/exagerated discussion. I agree. I first ran into this on solaris. I *like* being able to shut down subsystems in a consistent manner. This makes every bit as much sense as having "make deinstall" work in the ports tree. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SB Live (or RAM parity?) crash on today's -CURRENT
On Thu, 6 Jul 2000, Thomas Stromberg wrote: 'panic: RAM parity error, likely hardware failure.' This one had me confused at first, because it blamed a RAM parity error. As this is a brand new machine (Gateway GP-800), so I first thought I got a bad batch. Then I realized this only happens with apps that try to do sound stuff. This is a known problem with all PCI sound cards. It happens most often with ECC ram, but it also happens without. What kind of NIC do you have, and specifically, is it a PCI card or ISA? We're trying to track that bit down too. Doug -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SB Live (or RAM parity?) crash on today's -CURRENT
Its in the dmesg from my post, but: CPU: Pentium III/Pentium III Xeon/Celeron (796.54-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,XMM real memory = 134217728 (131072K bytes) avail memory = 127098880 (124120K bytes) .. pcib0: Intel 82443BX (440 BX) host to PCI bridge on motherboard pci0: PCI bus on pcib0 pci0: Intel 82443BX (440 BX) host to PCI bridge at 0.0 pcib1: Intel 82443BX (440 BX) PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: NVidia Riva Ultra Vanta TNT2 graphics accelerator at 0.0 irq 11 .. pci0: Intel 82371AB/EB (PIIX4) USB controller at 7.2 irq 9 pci0: Intel 82371AB Power management controller at 7.3 pcm0: Creative EMU10K1 port 0x10a0-0x10bf irq 11 at device 14.0 on pci0 xl0: 3Com 3c905C-TX Fast Etherlink XL port 0x1000-0x107f mem 0xf400-0xf47f irq 10 at device 15.0 on pci0 Good luck.. happy to test patches. thomas r. stromberg [EMAIL PROTECTED] senior systems administratorhttp://www.afterthought.org/ research triangle commerce, inc. 1.919.657.1317 bless(\$Perl++);# the power to hack. http://www.perl.com/ #include freebsd.h /* the power to serve. http://www.freebsd.org/ */ On Thu, 6 Jul 2000, Doug Barton wrote: On Thu, 6 Jul 2000, Thomas Stromberg wrote: 'panic: RAM parity error, likely hardware failure.' This one had me confused at first, because it blamed a RAM parity error. As this is a brand new machine (Gateway GP-800), so I first thought I got a bad batch. Then I realized this only happens with apps that try to do sound stuff. This is a known problem with all PCI sound cards. It happens most often with ECC ram, but it also happens without. What kind of NIC do you have, and specifically, is it a PCI card or ISA? We're trying to track that bit down too. Doug -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: /etc/rc.shutdown calls local scripts now
On Thu, 6 Jul 2000, Cy Schubert - ITSD Open Systems Group wrote: An Alpha my team manages with 1 TB of images on UFS takes 4 hours to fsck. Sounds like a good enough reason to me to port the newer NetBSD LFS code to FreeBSD. Brandon D. Valentine -- bandix at looksharp.net | bandix at structbio.vanderbilt.edu "Truth suffers from too much analysis." -- Ancient Fremen Saying To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: /etc/rc.shutdown calls local scripts now
In message [EMAIL PROTECTED], Walter Campbe ll writes: HP/UX does something like this. I find it rather useful, but that may be because I have boxes that take almost an hour to boot An hour to boot? Boy... the only time I ever saw a machine take an hour to boot (which does not include the POST/memory check/BIOS screen) was a 486SX/33 with 24MB of RAM running Windows NT 3.51 SP3. Of course it was running off of a 5 1/4" 400MB SCSI hard drive too! Try a Solaris 2.6 machine fsck'ing an array of 14 9.1 giggers An Alpha my team manages with 1 TB of images on UFS takes 4 hours to fsck. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: [EMAIL PROTECTED] Open Systems Group, ITSD, ISTA Province of BC To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: /etc/rc.shutdown calls local scripts now
--- Cy Schubert - ITSD Open Systems Group [EMAIL PROTECTED] wrote: An Alpha my team manages with 1 TB of images on UFS takes 4 hours to fsck. Now that's a bit of thrashing, eh? Jordan, or anyone else who might know.. How long does it take "our" beast (ftp.freebsd.org) to bring up 400+ GB of RAID? -Richard __ Do You Yahoo!? Send instant messages get email alerts with Yahoo! Messenger. http://im.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Problems building kernel with IPSEC_DEBUG
While compiling a kernel with recent code (cvsup 22:30 -0400 July 6), I had some undefined symbols. I traced the symbols to netkey/key_debug.c and found that it did not test IPSEC_DEBUG correctly. I have attached a patch below. Jim Bloom [EMAIL PROTECTED] Index: netkey/key_debug.c === RCS file: /users/ncvs/src/sys/netkey/key_debug.c,v retrieving revision 1.11 diff -u -r1.11 key_debug.c --- netkey/key_debug.c 2000/07/04 16:35:14 1.11 +++ netkey/key_debug.c 2000/07/07 03:26:30 @@ -33,6 +33,7 @@ #ifdef _KERNEL #include "opt_inet.h" #include "opt_inet6.h" +#include "opt_ipsec.h" #endif #include sys/types.h To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems building kernel with IPSEC_DEBUG
On Thu, 6 Jul 2000, Jim Bloom wrote: While compiling a kernel with recent code (cvsup 22:30 -0400 July 6), I had some undefined symbols. I traced the symbols to netkey/key_debug.c and found that it did not test IPSEC_DEBUG correctly. I have attached a patch below. Whee! Thanks. I'll commit this later on tonight. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: could someone with committer access commit this?
Ollivier Robert wrote:
According to Kenneth Wayne Culver:
This is the patch to make my soundcard, a Creative Ensoniq AudioPCI (an
es1371 chip, device id 0x58801274 rev 0x02). Can someone commit it please?
Done.
There is a problem with that patch.
I'm not sure if there are older 1371 rev 2 boards out there, but they would
be incorrectly inited.
Test this patch first, but it should be more definitive.
Index: es137x.c
===
RCS file: /usr/FreeBSD-CVS/src/sys/dev/sound/pci/es137x.c,v
retrieving revision 1.21
diff -u -r1.21 es137x.c
--- es137x.c2000/07/03 20:52:26 1.21
+++ es137x.c2000/07/07 05:05:48
@@ -107,7 +107,7 @@
static voides1371_src_write(struct es_info *, u_short, unsigned short);
static u_int es1371_adc_rate(struct es_info *, u_int, int);
static u_int es1371_dac_rate(struct es_info *, u_int, int);
-static int es1371_init(struct es_info *es, int);
+static int es1371_init(struct es_info *es, device_t);
static int es1370_init(struct es_info *);
static int es1370_wrcodec(struct es_info *, u_char, u_char);
@@ -484,9 +484,11 @@
/* ES1371 specific */
int
-es1371_init(struct es_info *es, int rev)
+es1371_init(struct es_info *es, device_t dev)
{
int idx;
+ int devid = pci_get_devid(dev);
+ int rev = pci_get_revid(dev);
if (debug 0) printf("es_init\n");
@@ -494,7 +496,7 @@
es-ctrl = 0;
es-sctrl = 0;
/* initialize the chips */
- if (rev == 7 || rev = 9 || rev == 2) {
+ if (rev == 7 || rev = 9 || (devid == ES1371_PCI_ID3 rev == 2)) {
#define ES1371_BINTSUMM_OFF 0x07
bus_space_write_4(es-st, es-sh, ES1371_BINTSUMM_OFF, 0x20);
if (debug 0) printf("es_init rev == 7 || rev = 9\n");
@@ -793,7 +795,7 @@
if (pci_get_devid(dev) == ES1371_PCI_ID ||
pci_get_devid(dev) == ES1371_PCI_ID2 ||
pci_get_devid(dev) == ES1371_PCI_ID3) {
- if(-1 == es1371_init(es, pci_get_revid(dev))) {
+ if(-1 == es1371_init(es, dev)) {
device_printf(dev, "unable to initialize the card\n");
goto bad;
}
Re: Large disks (was Re: bin/19635: add -c for grand total to df(1))
On Thu, 6 Jul 2000, Garrett Wollman wrote: When creating a large filesystem, it pays to increase the `-c' parameter as high as newfs will permit. I always do this manually. It should probably be the default for sufficiently large filesystems. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: /etc/rc.shutdown calls local scripts now
On Thu, Jul 06, 2000 at 06:53:49PM -0700, Cy Schubert - ITSD Open Systems Group wrote: In message [EMAIL PROTECTED], Walter Campbe ll writes: HP/UX does something like this. I find it rather useful, but that may be because I have boxes that take almost an hour to boot An hour to boot? Boy... the only time I ever saw a machine take an hour to boot (which does not include the POST/memory check/BIOS screen) was a 486SX/33 with 24MB of RAM running Windows NT 3.51 SP3. Of course it was running off of a 5 1/4" 400MB SCSI hard drive too! Try a Solaris 2.6 machine fsck'ing an array of 14 9.1 giggers An Alpha my team manages with 1 TB of images on UFS takes 4 hours to fsck. At work I've watched some of our BSD/OS 4.0.1 servers go down hard while qmail had its queue totaly backed up. And when the ufs (running softupdates) 500MB /var got to fsck'ing it could take over 8 hours. (and yes, we know something was not right there, the problem has since been solved for the most part) Not fun. -- --Travis To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
