Re: Slow seq. write on Seagate ST36530N
Sounds familiar to me. I had trouble with a Seagate Wide scsi harddisk in a HP Kajak. First thought it's the NCR. Repllaces it with a AHA 2940UW. Nothing helps. Installed FreeBSD 2.2.7. With 2.2.7 the disk maxed at about 12 MB/sec write and write. When I enabled tagged command queuing in 2.2.7, the write performance went down to 2 MB/sec. Using 3.0/3.1 disabling tagged command queuing didn't help. When only reducing the number of tags from 64 (which the drive supported/CAM reported) to 8/16 (min/max) I got a SCSI race condition, error messages of SCSI bus. Well, now I'm using 2.2.8-STABLE :-) Had loved to use 3.1, but no way ... This is now the 2nd problem ... Perhaps our scsi gurus have to look at it ?! I can't send my drive to Kenneth or Justin, sorry. Andreas /// On Thu, Feb 18, 1999 at 11:24:21PM +0100, Paul van der Zwan wrote: > > I am having some performance problems on my -current ( update last weekend) > I hooked up a new Seagate ST36530N yesterday ( connected to an Adaptec 2940U) > and sequential write is very slow. > Compared to an IBM DORS-32160 connected to the same controller ( even the > same > cable) it is half as fast. > Iozone auto shows the following : > > Seagate > IOZONE: Performance Test of Sequential File I/O -- V2.01 (10/21/94) > By Bill Norcott > > Operating System: FreeBSD 2.x -- using fsync() > > IOZONE: auto-test mode > > MB reclen bytes/sec written bytes/sec read > 1 512 5835553 22369621 > 1 10243627506 33554432 > 1 20483441480 44739242 > 1 40964329604 44739242 > 1 81923121342 67108864 > 2 512 3627506 22369621 > 2 10244260880 44739242 > 2 20483273603 38347922 > 2 40964067203 67108864 > 2 81924067203 67108864 > 4 512 4161790 21474836 > 4 10242354696 35791394 > 4 20482418337 38347922 > 4 40962418337 59652323 > 4 81921988410 53687091 > 8 512 2863311 20259279 > 8 10241565221 37025580 > 8 20481470879 31580641 > 8 40961514445 48806446 > 8 81921337162 56512727 > 16 512 2041334 14412641 > 16 10241536111 27531841 > 16 20481476948 43826196 > 16 40961410961 48806446 > 16 81921432610 52377649 > > IBM > MB reclen bytes/sec written bytes/sec read > 1 512 3728270 22369621 > 1 10244067203 26843545 > 1 20483947580 67108864 > 1 40963728270 44739242 > 1 81923834792 67108864 > 2 512 4549753 13421772 > 2 10244194304 44739242 > 2 20483890368 53687091 > 2 40964400581 67108864 > 2 81923677198 67108864 > 4 512 4129776 21474836 > 4 10243532045 44739242 > 4 20482451465 53687091 > 4 40963016128 59652323 > 4 81922870967 53687091 > 8 512 2396745 21053761 > 8 10242894182 37025580 > 8 20482587329 42949672 > 8 40962526451 51130563 > 8 81922520520 56512727 > 16 512 3067833 20069940 > 16 10242701237 34087042 > 16 20483591109 43826196 > 16 40962306641 42949672 > 16 81923121342 52377649 > > Bonnie shows the following: > Seagate > ---Sequential Outp
Add me to the list
I am a Student studying Information Systems and I want to added to your current mailing list. Please add my e-mail address to any list regarding freebsd. Thank you, Pat Cahill To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: uptime weirdnessl
On Thu, 18 Feb 1999, Matthew D. Fuller wrote: > On Thu, Feb 18, 1999 at 07:05:39PM -0500, a little birdie told me > that Brian Feldman remarked > > > On Thu, Feb 18, 1999, Erik Funkenbusch put this into my mailbox: > > > > > > > > Any ideas? > > > > Yes. Look at /var/run/wtmp. Look CAREFULLY at /dev/null. > > Look even more carefully at /var/run/utmp, since wtmp is in /var/log and > doesn't affect w/uptime anyway. O:-) > Eek, it must be that bug in remember.c:similarly_named_files(). Time to upgrade to Brain 1.1-STABLE! Btw, I was of course referring to wtmp being garbage and /dev/null being a "regular" file. > > > --- > > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > | Matthew Fuller http://www.over-yonder.net/~fullermd | > * fulle...@futuresouth.com fulle...@over-yonder.net * > | UNIX Systems Administrator Specializing in FreeBSD | > * FutureSouth Communications ISPHelp ISP Consulting * > | "The only reason I'm burning my candle at both ends, | > *is because I haven't figured out how to light the* > | middle yet" | > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: uptime weirdnessl
On Thu, Feb 18, 1999 at 07:05:39PM -0500, a little birdie told me that Brian Feldman remarked > > On Thu, Feb 18, 1999, Erik Funkenbusch put this into my mailbox: > > > > > > Any ideas? > > Yes. Look at /var/run/wtmp. Look CAREFULLY at /dev/null. Look even more carefully at /var/run/utmp, since wtmp is in /var/log and doesn't affect w/uptime anyway. O:-) --- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | Matthew Fuller http://www.over-yonder.net/~fullermd | * fulle...@futuresouth.com fulle...@over-yonder.net * | UNIX Systems Administrator Specializing in FreeBSD | * FutureSouth Communications ISPHelp ISP Consulting * | "The only reason I'm burning my candle at both ends, | *is because I haven't figured out how to light the* | middle yet" | *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: Problems in VM structure ?
I've adjusted MAXUSERS to 128 on my heavily loaded PIIs and the crashes have not re-occurred for 24 hours now. (Had to adjust NMBCLUSTERS up, though) The panics were happening every 5-8 hours like clockwork prior to this. I believe that these crashes are caused by heavy network traffic, not heavy load values, so a make world may not trigger this. Actually, I couldn't force it to happen when I hit the box hard during testing with web traffic, so it must be a combination thing. Another clue is the fact that I can't seem to get a Pentium (P5) to crash at all, ever, even when running exactly the same kernel config. The Pentium IIs fell over like crazy. -Troy Cobb Circle Net, Inc. http://www.circle.net To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Buildworld fails on today 3.1-STABLE!
Mike Smith writes: > > > I usually keep -O to just '-O' - I had been upping it recently, but then > > > it > > > started breaking even some of my simple programs, so leasson learn't, it's > > > staying at just '-O' from now on in... (safety first? :-) > > > > -O2 works fine too. -O3 does not. We'll probably see the newer version > > of compiler before this is fixed. > > No, -O2 does not work fine; we've seen reports of it breaking things > before. Maybe that's an explantation for the strange things I have seen with gnome a while ago ? I frequently got floating point exceptions in libgtk, (especially when running the pager applet), but I wasn't able to find anything. Recompiling everthing with pgcc did solve this for me. -- # /AS/# To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Cant install filesystem of 3.0 release.
Hi I cant install the freebsd unix filesystem, i downloaded boot.flp and made the image to a floopy, when i shutdown and restart the computer, the boot command prompt appear, after a while it automatic shutdown, the kernel configuration dont appear, i tryied de -cv , d and s command but was useless, so i download the kern.flp and mfsroot.gz, when starting the computer with the kern image all worked out for a while, when it asked me the floopy with the mfsroot.gz a put it in the floppy drive, but i got the msg "dont find: /mfsroot" ( i didnt created a image). The thing that bother me, is that i had installed the 2.2.7 release a pair of week ago, but i made a mistake with windows and that screw up everthing, i had to reformat the entire hard drive, unix go too, (windows is a good OS for playing). I installed a older version of window95, could be windows the problem?... i try the boot.flp of the 2.2.7 release but dont work either. What might be the problem? any help will be apreciate. doa...@hotmail.com Regards, Dimettrio.
AMD K6-2 for smp
Hello, I am planning to setup my SMP system and want to know if some can share his/her experience with me. I would like to use AMD K6-2 (for lower price). is there anyone using AMD K6-2 for your SMP system. If so, please share your expeience with me. Thanks. Clarence To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: paranoid patches
> > Basically, it is a patch into libkvm and w, that will allow a user (with > > the exception to the super user, naturally) to only view processes or > > information belonging to him/herself. > The only problem with this is setuid binaries. The processes may have > been started by me (top, etc..), but this wouldn't allow me to monitor > the process once it's started. And, anything that can read /dev/[k]mem is free to bypass libkvm and just grovel around in the kernel memory space, anyway. --lyndon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: uptime weirdnessl
On Thu, 18 Feb 1999, Chris Costello wrote: > On Thu, Feb 18, 1999, Erik Funkenbusch put this into my mailbox: > > I'm seeing a problem with uptime in recent -currents which doesn't make any > > sense to me. > >I've had that with 3.0-STABLE, as well. I'm not sure why, but it kept > saying: > > uptime: /dev//chris: No such file or directory > ... uptime output ... > >Obviously the same problem existed in w(1). A reboot solved the problem. > I suppose I should look into this and produce a patch. A patchh is unnecessary. I figured that all out long ago. A patchh is unnecessary. > > > > odin# uptime > > uptime: /dev//umount: /proc: not currently mounted > > umount:: No such file or directory > > uptime: /dev// /var: not currently mounted > > umount: /usr: n: No such file or directory > > 3:24PM up 1 day, 18:17, 3 users, load averages: 1.00, 1.00, 1.00 > > > > umount is available and it's in the path, and all the above directories > > exists (and /proc seems to be functioning) > > > > Any ideas? Yes. Look at /var/run/wtmp. Look CAREFULLY at /dev/null. > > > > > > > > To Unsubscribe: send mail to majord...@freebsd.org > > with "unsubscribe freebsd-current" in the body of the message > > > > -- > When I was a boy I was told that anybody could become President. Now > I'm beginning to believe it. > -- Clarence Darrow > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Slow seq. write on Seagate ST36530N
I am having some performance problems on my -current ( update last weekend) I hooked up a new Seagate ST36530N yesterday ( connected to an Adaptec 2940U) and sequential write is very slow. Compared to an IBM DORS-32160 connected to the same controller ( even the same cable) it is half as fast. Iozone auto shows the following : Seagate IOZONE: Performance Test of Sequential File I/O -- V2.01 (10/21/94) By Bill Norcott Operating System: FreeBSD 2.x -- using fsync() IOZONE: auto-test mode MB reclen bytes/sec written bytes/sec read 1 512 5835553 22369621 1 10243627506 33554432 1 20483441480 44739242 1 40964329604 44739242 1 81923121342 67108864 2 512 3627506 22369621 2 10244260880 44739242 2 20483273603 38347922 2 40964067203 67108864 2 81924067203 67108864 4 512 4161790 21474836 4 10242354696 35791394 4 20482418337 38347922 4 40962418337 59652323 4 81921988410 53687091 8 512 2863311 20259279 8 10241565221 37025580 8 20481470879 31580641 8 40961514445 48806446 8 81921337162 56512727 16 512 2041334 14412641 16 10241536111 27531841 16 20481476948 43826196 16 40961410961 48806446 16 81921432610 52377649 IBM MB reclen bytes/sec written bytes/sec read 1 512 3728270 22369621 1 10244067203 26843545 1 20483947580 67108864 1 40963728270 44739242 1 81923834792 67108864 2 512 4549753 13421772 2 10244194304 44739242 2 20483890368 53687091 2 40964400581 67108864 2 81923677198 67108864 4 512 4129776 21474836 4 10243532045 44739242 4 20482451465 53687091 4 40963016128 59652323 4 81922870967 53687091 8 512 2396745 21053761 8 10242894182 37025580 8 20482587329 42949672 8 40962526451 51130563 8 81922520520 56512727 16 512 3067833 20069940 16 10242701237 34087042 16 20483591109 43826196 16 40962306641 42949672 16 81923121342 52377649 Bonnie shows the following: Seagate ---Sequential Output ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 100 3251 44.0 1307 4.0 2285 11.5 5006 69.0 8644 23.0 115.1 4.2 IBM 100 45.0 2533 8.8 1878 10.1 4244 58.2 5140 19.7 76.4 3.3 If I interpret it correctly the Seagate is faster in everything but sequential writes. dmesg shows the following : da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 10.0MB/s transfers (10.0MHz, offset 15), Tagged Queueing Enabled da1: 6208MB (12715920 512 byte sectors: 255H 63S/T 791C) da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 10.0MB/s transfers (10.0MHz, offset 15), Tagged Queueing Enabled da0: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) Anybody an idea ?? Paul -- Paul van der Zwan paulz @ trantor.xs4all.nl "I think I'll move to the
Re: uptime weirdness
On Thu, Feb 18, 1999, Erik Funkenbusch put this into my mailbox: > I'm seeing a problem with uptime in recent -currents which doesn't make any > sense to me. I've had that with 3.0-STABLE, as well. I'm not sure why, but it kept saying: uptime: /dev//chris: No such file or directory ... uptime output ... Obviously the same problem existed in w(1). A reboot solved the problem. I suppose I should look into this and produce a patch. > > odin# uptime > uptime: /dev//umount: /proc: not currently mounted > umount:: No such file or directory > uptime: /dev// /var: not currently mounted > umount: /usr: n: No such file or directory > 3:24PM up 1 day, 18:17, 3 users, load averages: 1.00, 1.00, 1.00 > > umount is available and it's in the path, and all the above directories > exists (and /proc seems to be functioning) > > Any ideas? > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > -- When I was a boy I was told that anybody could become President. Now I'm beginning to believe it. -- Clarence Darrow To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Compaq built-in ncr & tl controllers with 4.0
On Thu, 18 Feb 1999, Michael Reifenberger wrote:
> On Thu, 18 Feb 1999, Doug Rabson wrote:
> ...
> > It may be that we aren't detecting the bridge properly in the 3.1 pci
> > code.
> dmesg under 2.2.7 shows:
> ...
> eisa0:
> Probing for devices on the EISA bus
> DPT: EISA SCSI HBA Driver, version 1.4.3
> Probing for devices on PCI bus 0:
> chip0 rev 3 on pci0:0:0
> vga0...
> ncr0...
> ...
> chip1 rev 7 on
> pci0:15:0
> chip2 rev 3 on pci0:17:0
> Probing for devices on PCI bus 1:
> ...
> ncr1...
> sd0...
> st0...
> ...
>
> Hmm. a quick: `cvs diff -u -r1.40.2.1 -r1.40.2.7 pcisupport.c` showed that the
> occurances of config_Ross went in in 1.40.2.7 to pcisupport.c by se.
> Seems we have some functtionality missing in the -current.
> May I ask you to merge the missing routines over?
>
> ...
> > I may end up changing this so we probe in a depth first order due to some
> > other changes I am making to the pci code.
> Would be nice. Thanks.
I'm working blind here but it seems to me that this patch might fix it.
It might probe one too many busses but that can be fixed by removing the
+1 in fixbushigh_Ross().
Index: pcisupport.c
===
RCS file: /home/ncvs/src/sys/pci/pcisupport.c,v
retrieving revision 1.92
diff -u -r1.92 pcisupport.c
--- pcisupport.c1999/02/13 17:51:46 1.92
+++ pcisupport.c1999/02/18 22:34:59
@@ -204,7 +204,17 @@
tag->secondarybus = tag->subordinatebus = subordinatebus;
}
+static void
+fixbushigh_Ross(pcici_t tag)
+{
+ int secondarybus;
+ /* just guessing the secondary bus register number ... */
+ secondarybus = pci_cfgread(tag, 0x45, 1);
+ if (secondarybus != 0)
+ tag->secondarybus = tag->subordinatebus = secondarybus + 1;
+}
+
static void
fixwsc_natoma(pcici_t tag)
{
@@ -388,6 +398,11 @@
return ("NEC 002C PCI to PC-98 C-bus bridge");
case 0x003b1033:
return ("NEC 003B PCI to PC-98 C-bus bridge");
+
+ /* Ross (?) -- vendor 0x1166 */
+ case 0x00051166:
+ fixbushigh_Ross(tag);
+ return ("Ross (?) host to PCI bridge");
};
if ((descr = generic_pci_bridge(tag)) != NULL)
--
Doug Rabson Mail: d...@nlsystems.com
Nonlinear Systems Ltd. Phone: +44 181 442 9037
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: Compaq built-in ncr & tl controllers with 4.0
On Thu, 18 Feb 1999, Doug Rabson wrote: ... > It may be that we aren't detecting the bridge properly in the 3.1 pci > code. dmesg under 2.2.7 shows: ... eisa0: Probing for devices on the EISA bus DPT: EISA SCSI HBA Driver, version 1.4.3 Probing for devices on PCI bus 0: chip0 rev 3 on pci0:0:0 vga0... ncr0... ... chip1 rev 7 on pci0:15:0 chip2 rev 3 on pci0:17:0 Probing for devices on PCI bus 1: ... ncr1... sd0... st0... ... Hmm. a quick: `cvs diff -u -r1.40.2.1 -r1.40.2.7 pcisupport.c` showed that the occurances of config_Ross went in in 1.40.2.7 to pcisupport.c by se. Seems we have some functtionality missing in the -current. May I ask you to merge the missing routines over? ... > I may end up changing this so we probe in a depth first order due to some > other changes I am making to the pci code. Would be nice. Thanks. Bye! Michael Reifenberger Plaut Software GmbH, R/3 Basis To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: axp kernel breakage
On Thu, 18 Feb 1999 21:38:37 GMT, Doug Rabson wrote: > Interesting stats. Can you run size(1) on them too. I wonder how much > of that is actual code. Feast your eyes. :-) textdata bss dec hex filename 1049161 84468 120572 1254201 132339 /kernel 1153284 85752 123692 1362728 14cb28 /kernel.old Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: axp kernel breakage
On Thu, 18 Feb 1999, Sheldon Hearn wrote: > > > On Thu, 18 Feb 1999 11:54:01 PST, Julian Elischer wrote: > > > huh? can you expand on this... > > Um, sure. > > When my kernel build broke, I tried removing the option NFS_NOSERVER. > This allowed me to build a kernel. After the problem in nfs_syscalls.c > was repaired today (maybe last night), I put the option NFS_NOSERVER > back into my kernel config and rebuilt the kernel. > > I now have two files that make me think that including NFS_NOSERVER > dropped my kernel file size by 100KB: > > -r-xr-xr-x 1 root wheel 1385750 Feb 18 15:40 /kernel > -r-xr-xr-x 1 root wheel 1494920 Feb 17 11:57 /kernel.old > > The box in question is used _only_ as an NFS client and the kind of > environmental change that would demand NFS server capabilities would > merit a reboot. Interesting stats. Can you run size(1) on them too. I wonder how much of that is actual code. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
uptime weirdness
I'm seeing a problem with uptime in recent -currents which doesn't make any sense to me. odin# uptime uptime: /dev//umount: /proc: not currently mounted umount:: No such file or directory uptime: /dev// /var: not currently mounted umount: /usr: n: No such file or directory 3:24PM up 1 day, 18:17, 3 users, load averages: 1.00, 1.00, 1.00 umount is available and it's in the path, and all the above directories exists (and /proc seems to be functioning) Any ideas? To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: softupdate panic, anyone seen this? (fwd)
[Expanded audience] This is a generic problem with the present VFS system and also with some specific parts of FreeBSD. There is "bleed-over" of all sorts of parameters from filesystems and devices that they are mounted on and devices that are sourced from them. (e.g. blocksizes etc.) luckily at the moment it doesn't usually break things. I've come across quite a few examples of it though through the system at various times. Has anyone any plans for cleaning up this sort of thing? I've been tempted several times. julian On Thu, 18 Feb 1999, Kirk McKusick wrote: > Date: Thu, 18 Feb 1999 01:12:50 -0800 > From: Don Lewis > To: Jake , hack...@freebsd.org > Subject: Re: softupdate panic, anyone seen this? > > On Feb 17, 7:30pm, Jake wrote: > } Subject: Re: softupdate panic, anyone seen this? > } > > * mfs process aborts with signal 11. > } > > * Hang after "syncing disks ... done" message. > } > > } > occasionaly I see the "panic: softdep_sync_metadata: > } > Unknown type bmsafemap" > > After reading the source for softdep_sync_metadata(), I > might believe this could happen if the system tried to sync > the block device for a softdep filesystem before had synced > all the files. > > } I was seeing all of this and other wierdness when I had mfs's > } mounted on /tmp and /var/tmp. > > I don't know why MFS would have an effect on this. The > only two things I can think of are either swapping to a > file on a softdep filesystem, or somehow the softupdates > stuff thinks it should be active on the MFS filesystems. > What does /sbin/mount say about the mount flags on these > filesystems? > > Bmsafemap structures hang only from buffers associated with > filesystem block devices. In looking at the code I can imagine > that these could show up if you were running soft updates on > the filesystem that contains the block devices (e.g., the root > filesystem). On that filesystem, the block device will be > encountered during the walk of the files and potentially before > the rest of the files associated with its filesystem have been > sync'ed to disk. Can you verify that you are running with soft > updates on your root filesystem. If so, does turning them off > on that filesystem make the panic go away? > > Kirk McKusick > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: axp kernel breakage
On Thu, 18 Feb 1999 11:54:01 PST, Julian Elischer wrote: > huh? can you expand on this... Um, sure. When my kernel build broke, I tried removing the option NFS_NOSERVER. This allowed me to build a kernel. After the problem in nfs_syscalls.c was repaired today (maybe last night), I put the option NFS_NOSERVER back into my kernel config and rebuilt the kernel. I now have two files that make me think that including NFS_NOSERVER dropped my kernel file size by 100KB: -r-xr-xr-x 1 root wheel 1385750 Feb 18 15:40 /kernel -r-xr-xr-x 1 root wheel 1494920 Feb 17 11:57 /kernel.old The box in question is used _only_ as an NFS client and the kind of environmental change that would demand NFS server capabilities would merit a reboot. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: axp kernel breakage
huh? can you expand on this... On Thu, 18 Feb 1999, Sheldon Hearn wrote: > > > On Thu, 18 Feb 1999 09:21:17 GMT, Doug Rabson wrote: > > > It should be fixed now. > > Thanks! Kernel's back down 100KB in file size. :-) > > Ciao, > Sheldon. > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: paranoid patches
> Basically, it is a patch into libkvm and w, that will allow a user (with > the exception to the super user, naturally) to only view processes or > information belonging to him/herself. > options I_AM_A_PARANOID_GOOD The only problem with this is setuid binaries. The processes may have been started by me (top, etc..), but this wouldn't allow me to monitor the process once it's started. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
paranoid patches
Greetings, I've begun a series of patches against the 4.0-current tree that I hope you will find helpful. As this is my first attempt at contributing to freebsd, I hope you will excuse any potentional ``newbie'' behaviour in the field. I'm not sure whether or not this has already been done, but while being relevant to you it is irrelevant to me; this was just practice anyway :-). Basically, it is a patch into libkvm and w, that will allow a user (with the exception to the super user, naturally) to only view processes or information belonging to him/herself. I'm in the process right now I've trying to figure out how to make this an option, so if users wanted this feature they could add options I_AM_A_PARANOID_GOOD or something to that effect to the kernel config. Of course, I'd have to move these patches away from userland programs and into the kernel for this to work, which is what I intend to do anyway. Comments? Regards, -- Dan Moschuk (tfreak...@globalserve.net) Senior Systems/Network Administrator Globalserve Communications Inc., a Primus Canada Company "Even a stopped clock is right twice a day" To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Error handling for src/usr.sbin/pccard/pccardc/*
> > > @@ -138,9 +138,9 @@
> > > usage(msg)
> > > char *msg;
> > > {
> > > - warnx("enabler: %s", msg);
> > > + fprintf(stderr, "enabler: %s\n", msg);
> > > fprintf(stderr,
> > > -"usage: pccardc enabler slot driver [-m addr size] [-a iobase] [-i
> > > irq]\n");
> > > +"Usage: enabler slot driver [-m addr size] [-a iobase] [-i irq]\n");
> >
> > The usage really is 'pccardc enabled', not 'enabler', so this should
> > stay, or at least converted to use argv[0] to be consistent with
> > the other changes.
>
> As Philippe Charnier said, I'll keep last line as original. But it
> seems
> replacing warnx with fprintf(stderr, ) is reasonable, right?
>
> I cannot understand about usage of "enabled". Is this simply English
> representation issue?
It was a 'typo'.
> > > - fprintf(stderr, "usage: pccardc ...\n");
> > > - fprintf(stderr, "subcommands:\n");
> > > + fprintf(stderr, "Usage:\n");
> > > + fprintf(stderr, "\t%s ...\n", argv[0]);
> > > + fprintf(stderr, "Subcommands:\n");
> > > for (i = 0; subcommands[i].name; i++)
> > > - fprintf(stderr, "\t%s\n\t\t%s\n",
> > > + fprintf(stderr, "\t%s\t: %s\n",
> > > subcommands[i].name, subcommands[i].help);
> >
> > However, I'm not sure why we are changing the output. It seems
> > gratiutious.
>
> I cannot find "gratiutious" in my dictionary... But changing output is
> not necessary, I'll keep it as original.
You just defined gratiutious. 'Is not necessary. Provides no
additional functionality. Is different just to be different.'
> > Again, we use warn one place, and then err. Any chance of keeping it
> > consistent in all places.
>
> I think we should use "warn" when program can continue to work and use
> "err" when cannot continue to work and exit, is it right?
>
> Of course, err() should not use to display usage, as Philippe said. :-)
Philippe is the expert in the usafe of err/warn.
Nate
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: Error handling for src/usr.sbin/pccard/pccardc/*
Nate Williams wrote:
> > @@ -138,9 +138,9 @@
> > usage(msg)
> > char *msg;
> > {
> > - warnx("enabler: %s", msg);
> > + fprintf(stderr, "enabler: %s\n", msg);
> > fprintf(stderr,
> > -"usage: pccardc enabler slot driver [-m addr size] [-a iobase] [-i
> > irq]\n");
> > +"Usage: enabler slot driver [-m addr size] [-a iobase] [-i irq]\n");
>
> The usage really is 'pccardc enabled', not 'enabler', so this should
> stay, or at least converted to use argv[0] to be consistent with
> the other changes.
As Philippe Charnier said, I'll keep last line as original. But it
seems
replacing warnx with fprintf(stderr, ) is reasonable, right?
I cannot understand about usage of "enabled". Is this simply English
representation issue?
> > - fprintf(stderr, "usage: pccardc ...\n");
> > - fprintf(stderr, "subcommands:\n");
> > + fprintf(stderr, "Usage:\n");
> > + fprintf(stderr, "\t%s ...\n", argv[0]);
> > + fprintf(stderr, "Subcommands:\n");
> > for (i = 0; subcommands[i].name; i++)
> > - fprintf(stderr, "\t%s\n\t\t%s\n",
> > + fprintf(stderr, "\t%s\t: %s\n",
> > subcommands[i].name, subcommands[i].help);
>
> However, I'm not sure why we are changing the output. It seems
> gratiutious.
I cannot find "gratiutious" in my dictionary... But changing output is
not necessary, I'll keep it as original.
> Again, we use warn one place, and then err. Any chance of keeping it
> consistent in all places.
I think we should use "warn" when program can continue to work and use
"err" when cannot continue to work and exit, is it right?
Of course, err() should not use to display usage, as Philippe said. :-)
--
Jun Kuriyama // kuriy...@sky.rim.or.jp
// kuriy...@freebsd.org
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Problem with newfs_msdos
Hi folks, It seems that newfs_msdos doesn't work on 4.0-current - when I try to format msdos partition "newfs_msdos /dev/wd0s1" (one created with sysinstall) my machine after few seconds of disk activity just hangs - no messages on console, no messages in logs, keyboard blocked (however I can switch between consoles, but can't type anything) and most interesting, that machine responding to pings (but anyway telnet, ftp etc. doesn't work). Anyone observed similar misbehavior? Sincerely, Maxim ? To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: axp kernel breakage
On Thu, 18 Feb 1999 09:21:17 GMT, Doug Rabson wrote: > It should be fixed now. Thanks! Kernel's back down 100KB in file size. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: How to power off an ATX power supply machine on shutdown ?
Yes I know now... and it does work the only problem now is that I've only seen it once because I never turn the machine off !! :) On Tue, 16 Feb 1999, Warner Losh wrote: > In message Matthew Thyer > writes: > : I have "apm" in the kernel and it probes as apm v 1.2 but when > : the "shutdown -p now" command is run, the power is not turned > : off and I have to hold down the power button for 4 seconds to > : turn it off. > : > : Hows it done ? > > You need to set apm_enabled="YES" in your rc.conf file. > > Warner > > /=\ |Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au| \=/ "If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time." E. P. Tryon from "Nature" Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-current make release failure (sysctl)
On Thu, 18 Feb 1999, Sheldon Hearn wrote: > > > On Wed, 17 Feb 1999 19:12:59 EST, "John W. DeBoskey" wrote: > > > Just fyi, current as of 2pm EST. > > > > ../../nfs/nfs_syscalls.c:92: warning: `nfsrv_zapsock' declared `static' but > > never defined > > *** Error code 1 > > I get this when I set ``option NFS_NOSERVER''. If I disable the option, > my kernel builds. > > Ciao, > Sheldon. This should be fixed now. Sorry for the disruption. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Compaq built-in ncr & tl controllers with 4.0
On Thu, 18 Feb 1999, Michael Reifenberger wrote: > Hi, > On Wed, 17 Feb 1999, Benjamin Lewis wrote: > ... > > We then tried to boot with the 3.1 and the 4.0 boot floppies. Neither was > > able to find the SCSI controller or the ethernet device. Of course, we find > > it odd that 2.2.8 found the devices ok, but newer releases do not. As far > > as I can tell, the hardware is supported by CAM, etc. (I have a Tekram 390F > > 53c875-based card in another 4.0 machine that works great). The installs > > failed with the complaint that no disks could be found to install on. > > I have the same symptoms with an Compaq Proliant 1600. > The cause seems to be that these machines have more than one PCI-Busses which > lay behind on PCI-PCI-Bridges and only one gets probed/found under 3.*, 4.*. > > Furthermore under 2.2.7 the Busses seems to get probed but in an different > order > than the BIOS does because the ncr for the internal disks (which gets probed > first by BIOS) is probed last by the Kernel and im my case the BIOS-drive C: > gets da2. Verry annoying if Disks get added into the cabinet... :-( > > Do the symptoms trigger some Ideas by someone? It may be that we aren't detecting the bridge properly in the 3.1 pci code. On the subject of probe ordering, I know about this. We probe the pci bus tree in breadth first order (i.e. we finish probing all the devices in the top bus before probing bridges attached to it). I guess most other systems (including your BIOS) use a depth first order which means that the contents of the bus behind the bridge is probed before it goes onto the next device at the top level. I may end up changing this so we probe in a depth first order due to some other changes I am making to the pci code. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Compaq built-in ncr & tl controllers with 4.0
On Wed, 17 Feb 1999, Benjamin Lewis wrote: > Hello- > > I've been trying to get 3.1 or 4.0 to run on a Compaq Professional Workstation > 6000 with dual PII-300s, using the built-in symbios 53c875 SCSI controller, > and > the built-in "ThunderLan" ethernet adapter. The machine works perfectly with > 2.2.8, but we'd like to get it running 3.1 (or 4.0 if necessary) to take > advantage of the second CPU. > > We have been able to complete a make upgrade with freshly cvsupped 3.1 source, > to the point where the new kernel boots. While booting, the GENERIC kernel > does not find the ncr or tl devices, and of course fails to mount root. I'd > include dmesg from those boots, but it doesn't get far enough to write it > anywhere. The new bootblocks seem to be working fine, and are able to boot > the kernel, but it fails with a "cannot mount root" message and then panics. > > We then tried to boot with the 3.1 and the 4.0 boot floppies. Neither was > able to find the SCSI controller or the ethernet device. Of course, we find > it odd that 2.2.8 found the devices ok, but newer releases do not. As far > as I can tell, the hardware is supported by CAM, etc. (I have a Tekram 390F > 53c875-based card in another 4.0 machine that works great). The installs > failed with the complaint that no disks could be found to install on. > > A search through the mailing list archives yielded little information that > still seemed relevant (apparently, the tl0 driver wasn't around in 2.2.6 or > earlier but that obviously changed before 2.2.8). > > I've included the 2.2.8 dmesg output below. I'm hoping that someone out there > will see something in them that I cannot and will provide us with the magic > incantation needed to get this thing running 3.1 or 4.0. Our suspicions are > on the PCI bridge, since both the unfound devices are on pci bus 1, while > the detected devices reside on bus 0, but we don't know what to do about that. > > By the way, the unidentified storage device that doesn't get a driver assigned > on pci1:10 is a Jaz Jet card, apparently with an Advansys chipset, that 2.2.8 > doesn't grok, but 3.1+ should find ok. It doesn't get detected by 3.1 or 4.0 > kernels either. > > Thank you in advance, > > -Ben As Michael Reifenberger suggested, it might be something to do with the fact that all of these devices are behind a pci-pci bridge. In the 2.2.8 boot, you can see the bridge as chip1 in log. Can you tell me if the 3.1 kernel detects this bridge properly and what the probe message is for it. Try a verbose boot (boot -v) to get the pci code to print more about what it is doing. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: axp kernel breakage
On Thu, 18 Feb 1999, Bruce Evans wrote: > >cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > >-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual > >-fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include > >-DKERNEL -include opt_global.h -mno-fp-regs -Wa,-mev56 > >../../nfs/nfs_syscalls.c > >../../nfs/nfs_syscalls.c:924: `sysctl__vfs_nfs_children' undeclared here > >(not in a function) > >../../nfs/nfs_syscalls.c:924: initializer element for > >`sysctl___vfs_nfs_defect.oid_parent' is not constant > >../../nfs/nfs_syscalls.c:92: warning: `nfsrv_zapsock' declared `static' but > >never defined > >*** Error code 1 > > > >Not *quite* sure where its coming from. > > The new SYSCTL_DECL() is in an ifdef tangle for NFS_NOSERVER, so it only > works if NFS_NOSERVER is not defined. It should be fixed now. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
