From owner-freebsd-current  Sun Mar 19  3:43: 3 2000
Delivered-To: freebsd-current@freebsd.org
Received: from freebsd.dk (freebsd.dk [212.242.42.178])
	by hub.freebsd.org (Postfix) with ESMTP
	id 33E8837B53A; Sun, 19 Mar 2000 03:42:56 -0800 (PST)
	(envelope-from sos@freebsd.dk)
Received: (from sos@localhost)
	by freebsd.dk (8.9.3/8.9.1) id MAA71047;
	Sun, 19 Mar 2000 12:42:35 +0100 (CET)
	(envelope-from sos)
From: Soren Schmidt <sos@freebsd.dk>
Message-Id: <200003191142.MAA71047@freebsd.dk>
Subject: Re: problem with CD changer 4.0-STABLE
In-Reply-To: <Pine.BSF.4.10.10003182249010.97310-100000@pawn.primelocation.net> from "Chris D. Faulhaber" at "Mar 18, 2000 10:52:52 pm"
To: jedgar@fxp.org (Chris D. Faulhaber)
Date: Sun, 19 Mar 2000 12:42:35 +0100 (CET)
Cc: abc@bsdi.com (Alan Clegg), current@FreeBSD.ORG, sos@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

It seems Chris D. Faulhaber wrote:
> On Sat, 18 Mar 2000, Alan Clegg wrote:
> 
> > Panasonic CD-ROM Changer that is found in by the kernel as:
> > 
> > acd0-4: CDROM with 5 CD changer <RD-DRC004-M> at ata0-master using PIO4
> > 
> > Mounting /cdrom1 works just fine:
> > 
> > /dev/acd0c on /cdrom1 (cd9660, local, read-only, reads: sync 5 async 0)
> > 
> > But, attempting to mount the second CD-ROM provides only:
> > 
> > ecto 110} mount /cdrom2
> > cd9660: Device not configured
> > 
> 
> Interesting, I'm seeing the same thing here with my changers:
> 
> acd0-3: CDROM with 4 CD changer <NEC CD-ROM DRIVE:251> at ata1-master
> using PIO3
> acd4-7: CDROM with 4 CD changer <NEC CD-ROM DRIVE:252> at ata1-slave using
> PIO3
> 
> It appears as though the changer no longer changes discs when attempting
> to access the non-current disc.  I know it worked a few weeks under
> 4.0-CURRENT but is not using:
> FreeBSD sol.fxp.org 4.0-STABLE FreeBSD 4.0-STABLE #4: Tue Mar 14 09:09:53
> EST 2000  root@sol.fxp:/usr/src/sys/compile/SOL  i386
> 
> Soren (cc:'d), any recent changes that may have caused this?

Yes, I know where the problem is, but solving that uncovers a 
new "interesting" bug...
I'm working on it...

-Søren


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sun Mar 19  5:14:49 2000
Delivered-To: freebsd-current@freebsd.org
Received: from overcee.netplex.com.au (peter1.yahoo.com [208.48.107.4])
	by hub.freebsd.org (Postfix) with ESMTP id 48EB937B667
	for <current@freebsd.org>; Sun, 19 Mar 2000 05:14:45 -0800 (PST)
	(envelope-from peter@netplex.com.au)
Received: by overcee.netplex.com.au (Postfix, from userid 433)
	id E6EF21CD9; Sun, 19 Mar 2000 21:14:47 +0800 (WST)
To: current@freebsd.org
Subject: HEADS UP; new options for -current!
Message-Id: <20000319131447.E6EF21CD9@overcee.netplex.com.au>
Date: Sun, 19 Mar 2000 21:14:47 +0800 (WST)
From: peter@netplex.com.au (Peter Wemm)
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

If you are using old drivers that haven't been newbusified yet, you will
need to add 'options COMPAT_OLDPCI' and/or 'options COMPAT_OLDISA' to your
kernel configs and regenerate.  Otherwise you will get compile failures.

This is for -current only.  4.x is not affected.

Incidently, I was encouraged to break the shims rather than put an option
around them, but that was too drastic for now.  This won't be happening
in 4.x so be sure to consider which codebase you want to be running.
Remember, -current is going to get rather bumpy soon once merges start
happening..

-Peter


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sun Mar 19  5:35:28 2000
Delivered-To: freebsd-current@freebsd.org
Received: from crap.31337.net (p.funk.org [194.109.61.126])
	by hub.freebsd.org (Postfix) with ESMTP id 2ED2F37B65B
	for <freebsd-current@FreeBSD.ORG>; Sun, 19 Mar 2000 05:35:04 -0800 (PST)
	(envelope-from alexlh@crap.31337.net)
Received: (from alexlh@localhost)
	by crap.31337.net (8.9.3/8.9.1) id OAA71659;
	Sun, 19 Mar 2000 14:27:01 +0100 (CET)
	(envelope-from alexlh)
Date: Sun, 19 Mar 2000 14:26:52 +0100
From: Alex Le Heux <alexlh@funk.org>
To: Munehiro Matsuda <haro@tk.kubota.co.jp>
Cc: will@iki.fi, darrylo@sr.hp.com, julian@elischer.org,
	freebsd-current@FreeBSD.ORG
Subject: Re: [sound] PCI ESS support
Message-ID: <20000319142651.C67290@funk.org>
References: <200003161702.JAA23772@mina.sr.hp.com.newsgate.clinet.fi> <86itymyuz0.fsf@not.demophon.com> <20000317161702A.haro@tk.kubota.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4i
In-Reply-To: <20000317161702A.haro@tk.kubota.co.jp>; from Munehiro Matsuda on Fri, Mar 17, 2000 at 04:17:02PM +0900
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

I believe I've got one of these in my Toshiba 4090XCDDT as well.
(device id 1978?)

It's running 4.0 at the moment. If I should test anything, let me know.

Alex

On Fri, Mar 17, 2000 at 04:17:02PM +0900, Munehiro Matsuda wrote:
> From: Ville-Pertti Keinonen <will@iki.fi>
> Date: 17 Mar 2000 08:24:51 +0200
> ::Another (perhaps simpler) alternative might be to try to get it to
> ::work in SB emulation mode.
> ::
> ::I've managed to get it to probe as a SoundBlaster (just by adding
> ::pci_write_config(dev, 0x41, 0x10, 1) to the probe code in my mixer
> ::driver):
> ::
> ::sbc0: <Soundblaster Pro> at port 0x220-0x22f irq 5 drq 1 on isa0
> ::
> ::However, it doesn't work (the interfaces seem to work, but the mixer
> ::settings don't affect anything and playback doesn't get anywhere) and
> ::I still haven't had time to look at it properly (and don't expect to
> ::any time soon).
> 
> Well, it's not that simple. 
> When I tried to write driver for it last year, I found that:
> 1) You also need to setup ASSP (Application Specific Signal Processor)
>    in the chip and GPIO properly.
> 
>    Source code for BTM2E.EXE should be a help here.
>    (I didn't have that source, when I was tryng to write the driver.)
> 
> 2) For DMA to work, you need to support DDMA in FreeBSD.
>    
>    I have small patch for 3-stable, but will not work with -current
>    due to newbus changes.
> 
> 3) When Maestro2E acts as Soundblaster Pro emulation, DSP_CMD_GETVER
>    returns 0x302 (or may be it was 0x303?), that are not supported in
>    newpcm and luigi's pcm drivers.
> 
>    May be the current support for ver=0x301 work? I have no clue here. 
> 
> 
> If I get the time, I could try to write from scratch, again.
> 
>   Haro
> =------------------------------------------------------------------------------
>            _ _    Munehiro (haro) Matsuda
>  -|- /_\  |_|_|   Office of Business Planning & Development, Kubota Corp.
>  /|\ |_|  |_|_|   1-3 Nihonbashi-Muromachi 3-Chome
>                   Chuo-ku Tokyo 103, Japan
>                   Tel: +81-3-3245-3318  Fax: +81-3-32454-3315
>                   Email: haro@tk.kubota.co.jp
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message

-- 
GCS/O 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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sun Mar 19  5:40:12 2000
Delivered-To: freebsd-current@freebsd.org
Received: from news.IAEhv.nl (news.IAE.nl [194.151.64.4])
	by hub.freebsd.org (Postfix) with ESMTP id 6BCAA37B5DE
	for <current@freebsd.org>; Sun, 19 Mar 2000 05:40:08 -0800 (PST)
	(envelope-from marc@bowtie.nl)
Received: (from uucp@localhost)
	by news.IAEhv.nl (8.9.1/8.9.1) with IAEhv.nl id OAA24097
	for current@freebsd.org; Sun, 19 Mar 2000 14:40:05 +0100 (MET)
Received: from localhost (localhost [127.0.0.1])
	by bowtie.nl (8.8.8/8.8.8) with ESMTP id OAA02984
	for <current@freebsd.org>; Sun, 19 Mar 2000 14:38:22 +0100 (CET)
	(envelope-from marc@bowtie.nl)
Message-Id: <200003191338.OAA02984@bowtie.nl>
To: current@freebsd.org
Subject: install problem with 4.0 (spec_getpages)
Reply-To: marc@bowtie.nl
Date: Sun, 19 Mar 2000 14:38:22 +0100
From: Marc van Kempen <marc@bowtie.nl>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


Hi,

While trying to boot from the 4.0 installation disks,
I get the following error after the devices have been probed:

(I couldn't get a screen dump, so I had to write this down)

md0: raw partition size != slice size
md0: start 0, end 607, size 608
md0c: start 0, end 5759, size 5760
md0: truncating raw partition
md0: rejecting partition in BSD label, it isn't entirely withing the slice
md0: start 0, end 607, size 608
md0a: start 0, end 5759, size 5760
spec_getpages: (#md/2) I/O read failure: (error = 22) bp 0xc31dea20 
  vp 0xc7739f60, size 4096, resid: 4096, a_count: 4096, valid 0x0,
  nread: 0, reqpage: 0, pindex: 392, pcount: 1
vmfault: pager read error, pid 1
init died (signal 6, exit 0)
panic: going nowhere without my init

 
And then it reboots, I have been looking in the mailing archives for
this problem, but the latest occurence was januari last year, and it 
didn't look like the same problem.

So has anyone any idea about how to proceed?

Here is my dmesg from 3.3:

Copyright (c) 1992-1999 FreeBSD Inc.
Copyright (c) 1982, 1986, 1989, 1991, 1993
        The Regents of the University of California. All rights reserved.
FreeBSD 3.3-RELEASE #4: Mon Jan 10 23:27:28 CET 2000
    root@localhost:/usr/src/sys/compile/SCHOPENHAUER
Timecounter "i8254"  frequency 1193182 Hz
CPU: Celeron (412.50-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x665  Stepping = 5
  Features=0x183f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PA
T,PSE36,MMX,FXSR>
real memory  = 134217728 (131072K bytes)
avail memory = 127463424 (124476K bytes)
Preloaded elf kernel "kernel" at 0xc02d4000.
Pentium Pro MTRR support enabled
Probing for devices on PCI bus 0:
chip0: <Intel 82443BX host to PCI bridge> rev 0x03 on pci0.0.0
chip1: <Intel 82443BX host to AGP bridge> rev 0x03 on pci0.1.0
chip2: <Intel 82371AB PCI to ISA bridge> rev 0x02 on pci0.2.0
ide_pci0: <Intel PIIX4 Bus-master IDE controller> rev 0x01 on pci0.2.1
chip3: <Intel 82371AB Power management controller> rev 0x02 on pci0.2.3
ncr0: <ncr 53c875 fast20 wide scsi> rev 0x03 int a irq 11 on pci0.14.0
es1: <AudioPCI ES1370> rev 0x01 int a irq 11 on pci0.15.0
pcm1: using I/O space register mapping at 0xe800
Probing for devices on PCI bus 1:
vga0: <Matrox model 0525 graphics accelerator> rev 0x04 int a irq 255 on pci1.0.
0
Probing for PnP devices:
CSN 1 Vendor ID: TCM5095 [0x95506d50] Serial 0x4b58aba7 Comp ID: @@@0000 [0x0000
0000]
Probing for devices on the ISA bus:
sc0 on isa
sc0: VGA color <16 virtual consoles, flags=0x0>
ed0 not found at 0x280
atkbdc0 at 0x60-0x6f on motherboard
atkbd0 irq 1 on isa
psm0 irq 12 on isa
psm0: model Generic PS/2 mouse, device ID 0
sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa
sio0: type 16550A
pcm0 not found
fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1.44MB 3.5in
wdc0 at 0x1f0-0x1f7 irq 14 on isa
wdc0: unit 0 (wd0): <SAMSUNG WNR-31601A (1600MB)>
wd0: 1536MB (3145968 sectors), 3121 cyls, 16 heads, 63 S/T, 512 B/S
wdc1 at 0x170-0x177 irq 15 on isa
wdc1: unit 0 (atapi): <HITACHI DVD-ROM GD-2500/A011>, removable, accel, dma, ior
dis
acd0: drive speed 1722 - 4134KB/sec, 512KB cache
acd0: supported read types: CD-R, CD-RW, CD-DA, packet track
acd0: Audio: play, 256 volume levels
acd0: Mechanism: ejectable tray
acd0: Medium: no/blank disc inside, unlocked
ppc0 at 0x378 irq 7 on isa
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
ppi0: <generic parallel i/o> on ppbus 0
plip0: <PLIP network interface> on ppbus 0
1 3C5x9 board(s) on ISA found at 0x300
ep0 at 0x300-0x30f irq 10 on isa
ep0: utp[*UTP*] address 00:10:4b:58:ab:a7
isic0: Error, signature 1 0xff != 0x51 for Teles S0/16.3!isic0 not found at 0xe8
0
vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa
npx0 on motherboard
npx0: INT 16 interface
IP packet filtering initialized, divert enabled, rule-based forwarding disabled,
 unlimited logging
i4b: ISDN call control device attached
i4bisppp: 4 ISDN SyncPPP device(s) attached
i4bctl: ISDN system control port attached
i4bipr: 4 IP over raw HDLC ISDN device(s) attached (VJ header compression)
i4btel: 2 ISDN telephony interface device(s) attached
i4brbch: 4 raw B channel access device(s) attached
i4btrc: 4 ISDN trace device(s) attached
Waiting 3 seconds for SCSI devices to settle
sa0 at ncr0 bus 0 target 5 lun 0
sa0: <WANGTEK 5525ES SCSI REV7 3R1> Removable Sequential Access SCSI-CCS device 
sa0: 3.300MB/s transfers
da0 at ncr0 bus 0 target 0 lun 0
da0: <Quantum XP34300W L912> Fixed Direct Access SCSI-2 device 
da0: 20.000MB/s transfers (10.000MHz, offset 15, 16bit), Tagged Queueing Enabled
da0: 4101MB (8399520 512 byte sectors: 255H 63S/T 522C)
changing root device to da0s1a


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sun Mar 19  6: 4:46 2000
Delivered-To: freebsd-current@freebsd.org
Received: from viking.sophos.com (viking.sophos.com [193.82.145.128])
	by hub.freebsd.org (Postfix) with ESMTP id 18B0037B734
	for <current@FreeBSD.ORG>; Sun, 19 Mar 2000 06:04:44 -0800 (PST)
	(envelope-from gjvc@sophos.com)
Received: from trafalgar.sophos.com (trafalgar.sophos.com [193.82.145.143])
	by viking.sophos.com (MAILER-DAEMON) with ESMTP
	id 7FC9E45C1F; Sun, 19 Mar 2000 14:04:42 +0000 (GMT)
Received: by trafalgar.sophos.com (Postfix, from userid 1010)
	id 034A41F86; Sun, 19 Mar 2000 14:04:35 +0000 (GMT)
Date: Sun, 19 Mar 2000 14:04:35 +0000
From: George Cox <gjvc@sophos.com>
To: "Nicolai Petri (ML)" <nppmf@swamp.dk>
Cc: Idea Receiver <receiver@RedDust.BlueSky.net.au>,
	Donn Miller <dmmiller@cvzoom.net>, current@FreeBSD.ORG
Subject: Re: port/XFree86-4 make install fail.
Message-ID: <20000319140435.A76960@trafalgar.sophos.com>
References: <Pine.BSF.4.10.10003161508350.39942-100000@RedDust.BlueSky.net.au> <Pine.BSF.4.21.0003182333400.32902-100000@distortion.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.2i
In-Reply-To: <Pine.BSF.4.21.0003182333400.32902-100000@distortion.dk>; from nppmf@swamp.dk on Sat, Mar 18, 2000 at 11:35:16PM +0100
X-Operating-System: FreeBSD 5.0-CURRENT (i386)
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On 18/03 23:35, Nicolai Petri (ML) wrote:

> > > > xf86vmode.c: In function `ProcXF86VidModeGetMonitor':
> > > > xf86vmode.c:1320: Unable to generate reloads for:
> > > > (insn 298 296 300 (parallel[
> > > >             (set (reg:SI 0 %eax)
> > > >                 (fix:SI (fix:SF (subreg:SF (reg:SI 0 %eax) 0))))
> > > >             (clobber (mem:HI (plus:SI (reg:SI 6 %ebp)
> > > >                         (const_int -34 [0xffffffde])) 0))
> > > >             (clobber (mem:HI (plus:SI (reg:SI 6 %ebp)
> > > >                         (const_int -36 [0xffffffdc])) 0))
> > > >             (clobber (mem:SI (plus:SI (reg:SI 6 %ebp)
> > > >                         (const_int -40 [0xffffffd8])) 0))
> > > 
> > > This sounds like a problem with older 4.0-currents.  Did you make
> > > world and your kernel recently?
> > 
> > That is what i though before! so I just cvsup up to this morning,
> > and try to make install again. same problem.
> > 
> Same problem here. Just did a cvsup and a make world... I'm lost to a
> solution to this problem. Help please :-)

This is due to a bug in gcc.  Edit the Makefile in the directory of
xf86vmode.c, and compile without any optimization.  (No -O switch at all).

best;


gjvc

-- 
George Cox <gjvc@sophos.com>
+44 1235 544 127


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sun Mar 19  6:34:14 2000
Delivered-To: freebsd-current@freebsd.org
Received: from www.talk2theworld.com (ppp5229.nocharge.com [64.40.45.229])
	by hub.freebsd.org (Postfix) with SMTP
	id A602537B513; Sun, 19 Mar 2000 06:34:04 -0800 (PST)
	(envelope-from ped@isy.liu.se)
From: <ped@isy.liu.se>
Subject: Paycheck To Paycheck, Feeling Stuck?
Date: Sun, 19 Mar 2000 02:54:39
Message-Id: <777.249386.199191@www.talk2theworld.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

FREE NetLinks Guaranteed To SAVE You MONEY!

Please be advised, links presented in this email have been sent 
E-nonymously without the knowledge or consent of the domain 
owners. The Internet is World Public Domain, which can, and 
should be shared freely.  
   
 Information Advocates Association
"Knowledge is Power"

Here are a few sites we found very useful.
-----------------------------------------------------------------
----------------------------- 

Music Anyone?: http://www.listen.com
This site is guaranteed to be for everyone. It does'nt matter 
what your listening please may be they have it here. All songs 
available for dowmload and immediate use. N-Joy!

Beware of Internet Scams: http://www.rcmp-grc.gc.ca 
If you are concerned with email ads or websites offering 
opportunities or programs that may seem suspicious, report it to 
this site. They have the latest and most common scams circulated 
on the net. 

Free Internet: http://www.thesimpsons.com 
Don't want to continue paying $19.95 or more just to Surf the 
Net? This site offers the future of the Internet, Today. Never 
pay to Surf again. In this case, Free Does Mean Free!

Cheap Phone Rates: http://www.voicelinkinc.com 
We found a .04cents long distance rate, no switching, no fees and 
low international rates using 10-10 access numbers. If you can 
handle the 10 minute minimum, you're in business.

Invention Fraud: http://www.inventorfraud.com
If you are trying to submit your invention for patent be very 
cautious. The site list a number of companies that are out to get 
your money and ones that provide viable patent services. 

FREE 800 Number & Voice Mail: http://www.ureach.com
Here you can get a FREE voicemail account and 800 number. Just 
sign up for the service.

FREE Website Development: http://www.bigstep.com
This site offers an opportunity for you to develop and design 
your very own website for FREE! They offer different ready to use 
formats that will assist you in the development of your site.

Know Your Schedule: http://www.anyday.com 
This site offers an online personal calendar including a private 
address book and events schedule that can be accessed from 
anywhere. You also have the option of sharing your schedule with 
colleagues via the Net. 

Need To Send A Large File: http://www.whalemail.com
The is a great service for sending large files up to 50 megs, 
your regular ISP just can't handle that kind of load. Go ahead, 
transfer you entire C Drive to the ones you love most. It's even 
FREE! Nice guys huh?

Internet Service Providers: http://www.thelist.com
Don't like the service you've been getting from your present 
Internet Service Provider? Take a look at the more than 8,000 
ISP's you have to choose from. You're Not Stuck!

Nothing But FREE Stuff: http://www.thefreesite.com
Now who doesn't like Free Stuff that is really Free? This site is 
a ton-of-fun and there is something for everyone. It offers a 
multitude of freebies and we are sure you may find something that 
interest you.

Free Fax Service: http://www.fax4free.com 
Here you can get a free fax phone number and receive your faxes 
on your computer. You can print your faxes out on your printer. 
Print quality is much higher than normal fax machines. 

Looking For A Job or Career? http://www.jobfinders.com
This site is very user friendly. If you are in need of searching 
for that one job you can't seem to locate anywhere else, this 
site is up to the challenge.

International Directory Assistance Online: http://www.infobel.com
If you have ever gotten International Directory Assistance from 
AT&T then you are aware that you can easily pay up to $9.00 
dollars for that information. Here is an online solution and it's 
free.

Get Directions Anywhere: http://www.mapquest.com 
It does not matter where you're trying to go, this site will 
provide with complete details and instructions on how to get 
there. See for yourself. Traveling has never been easier!

Looking For Someone?  http://www.discreetdatasystems.com
Yes, this site will assist you in finding that someone special or 
not so special, whatever the case maybe. You will need to have 
some basic information regarding your search, but the site does 
deliver.



 

 






   
 
 
 
 
 
 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sun Mar 19  6:45: 5 2000
Delivered-To: freebsd-current@freebsd.org
Received: from camus.cybercable.fr (camus.cybercable.fr [212.198.0.200])
	by hub.freebsd.org (Postfix) with SMTP id 9763D37B775
	for <current@freebsd.org>; Sun, 19 Mar 2000 06:44:59 -0800 (PST)
	(envelope-from herbelot@cybercable.fr)
Received: (qmail 25818933 invoked from network); 19 Mar 2000 14:44:58 -0000
Received: from d016.paris-30.cybercable.fr (HELO cybercable.fr) ([212.198.30.16]) (envelope-sender <herbelot@cybercable.fr>)
          by camus.cybercable.fr (qmail-ldap-1.03) with SMTP
          for <marc@bowtie.nl>; 19 Mar 2000 14:44:58 -0000
Message-ID: <38D4E6F2.FCDB2141@cybercable.fr>
Date: Sun, 19 Mar 2000 15:40:50 +0100
From: "Thierry.herbelot" <herbelot@cybercable.fr>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: marc@bowtie.nl
Cc: current@freebsd.org
Subject: Re: install problem with 4.0 (spec_getpages)
References: <200003191338.OAA02984@bowtie.nl>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Marc van Kempen wrote:
> 
> Hi,
> 
> While trying to boot from the 4.0 installation disks,
> I get the following error after the devices have been probed:
> 

[SNIP]

>     root@localhost:/usr/src/sys/compile/SCHOPENHAUER
> Timecounter "i8254"  frequency 1193182 Hz
> CPU: Celeron (412.50-MHz 686-class CPU)

412 MHz is a non-conventional speed for a Celly : if you are
overclocking (I'm doing it, too), does the bug repeats itself when at
the normal speed ?

	TfH

[SNIÞ]
-- 
Thierry Herbelot                        ASCII RIBBON CAMPAIGN   /"\
mailto:herbelot@cybercable.fr          AGAINST HTML MAIL & NEWS \ /
http://perso.cybercable.fr/herbelot           PAS DE HTML DANS   X 
Hiroshima 45, Tchernobyl 86, Windows 95...      LES COURRIELS   / \


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sun Mar 19  6:55:12 2000
Delivered-To: freebsd-current@freebsd.org
Received: from news.IAEhv.nl (news.IAE.nl [194.151.64.4])
	by hub.freebsd.org (Postfix) with ESMTP id 4B28337B765
	for <current@freebsd.org>; Sun, 19 Mar 2000 06:55:07 -0800 (PST)
	(envelope-from marc@bowtie.nl)
Received: (from uucp@localhost)
	by news.IAEhv.nl (8.9.1/8.9.1) with IAEhv.nl id PAA00592;
	Sun, 19 Mar 2000 15:55:05 +0100 (MET)
Received: from localhost (localhost [127.0.0.1])
	by bowtie.nl (8.8.8/8.8.8) with ESMTP id PAA03310;
	Sun, 19 Mar 2000 15:53:46 +0100 (CET)
	(envelope-from marc@bowtie.nl)
Message-Id: <200003191453.PAA03310@bowtie.nl>
X-Mailer: exmh version 2.0.2 2/24/98
To: "Thierry.herbelot" <herbelot@cybercable.fr>
Cc: current@freebsd.org
Subject: Re: install problem with 4.0 (spec_getpages) 
In-reply-to: herbelot's message of Sun, 19 Mar 2000 15:40:50 +0100.
	     <38D4E6F2.FCDB2141@cybercable.fr> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Date: Sun, 19 Mar 2000 15:53:46 +0100
From: Marc van Kempen <marc@bowtie.nl>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


> Marc van Kempen wrote:
> > =

> > Hi,
> > =

> > While trying to boot from the 4.0 installation disks,
> > I get the following error after the devices have been probed:
> > =

> =

> [SNIP]
> =

> >     root@localhost:/usr/src/sys/compile/SCHOPENHAUER
> > Timecounter "i8254"  frequency 1193182 Hz
> > CPU: Celeron (412.50-MHz 686-class CPU)
> =

> 412 MHz is a non-conventional speed for a Celly : if you are
> overclocking (I'm doing it, too), does the bug repeats itself when at
> the normal speed ?
> =

I will try that, it didn't occur to me to do that, since I've been runnin=
g
that for a year or so now, without any problems.

Regards,
Marc.


-- =

----------------------------------------------------
Marc van Kempen                 BowTie Technology     =

Email: marc@bowtie.nl            WWW & Databases
tel. +31 40 2 43 20 65         =

fax. +31 40 2 44 21 86         http://www.bowtie.nl
----------------------------------------------------





To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sun Mar 19  7:14:40 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mail3.atl.bellsouth.net (mail3.atl.bellsouth.net [205.152.0.38])
	by hub.freebsd.org (Postfix) with ESMTP id 6125A37B65A
	for <freebsd-current@freebsd.org>; Sun, 19 Mar 2000 07:14:38 -0800 (PST)
	(envelope-from sid@lambert.yi.org)
Received: from kathy (host-216-78-101-37.asm.bellsouth.net [216.78.101.37])
	by mail3.atl.bellsouth.net (3.3.5alt/0.75.2) with SMTP id KAA08903
	for <freebsd-current@freebsd.org>; Sun, 19 Mar 2000 10:07:29 -0500 (EST)
Message-ID: <007c01bf91b5$d661b960$0b00a8c0@lambert.org>
From: "Sid Lambert" <sid@lambert.yi.org>
To: <freebsd-current@freebsd.org>
Subject: 
Date: Sun, 19 Mar 2000 10:14:34 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0079_01BF918B.EC978D60"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

This is a multi-part message in MIME format.

------=_NextPart_000_0079_01BF918B.EC978D60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

This error occured during "make installworld" on a 5.0 Current =
systems....cvsuped from late afternoon Saturday March 18.

ln -s curses.h /usr/include/ncurses.h
1 error
*** Error code 2
1 error

------=_NextPart_000_0079_01BF918B.EC978D60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>This error occured during "make =
installworld" on a=20
5.0 Current systems....cvsuped from late afternoon Saturday March=20
18.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>ln -s curses.h =
/usr/include/ncurses.h</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>1 error</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>*** Error code 2</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>1 error</FONT></DIV></BODY></HTML>

------=_NextPart_000_0079_01BF918B.EC978D60--



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sun Mar 19  7:26:55 2000
Delivered-To: freebsd-current@freebsd.org
Received: from bluebottle.calcaphon.com (calcaphon.demon.co.uk [193.237.19.5])
	by hub.freebsd.org (Postfix) with ESMTP id 6D2D737B513
	for <current@FreeBSD.ORG>; Sun, 19 Mar 2000 07:26:42 -0800 (PST)
	(envelope-from n_hibma@calcaphon.com)
Received: from henny.calcaphon.com (henny.calcaphon.com [10.0.0.36])
	by bluebottle.calcaphon.com (8.9.3/8.9.1) with ESMTP id PAA86376;
	Sun, 19 Mar 2000 15:29:50 GMT
	(envelope-from n_hibma@calcaphon.com)
Date: Sun, 19 Mar 2000 15:24:36 +0000 (GMT)
From: Nick Hibma <n_hibma@calcaphon.com>
X-Sender: n_hibma@localhost
Reply-To: Nick Hibma <n_hibma@calcaphon.com>
To: FreeBSD CURRENT Mailing List <current@FreeBSD.ORG>,
	USB BSD list <usb-bsd@egroups.com>
Subject: umass driver
Message-ID: <Pine.BSF.4.20.0003191511010.1430-100000@localhost>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


If anyone is using the umass driver, please send me the output of (*)

	dmesg | grep '^\(.hci\|usb\|umass\|da\|(da\)' \
		mail -s 'Drive info' n_hibma@freebsd.org

And if you like, send me comments on whether that works for you and
whether you have seen any problems.

Thanks in advance.

Nick


(*)
Which will give me the information on the USB host controller, any usbXX
error messages and the umass drive in use, the SCSI device messages,
including the 'lost device' messages'
--
n_hibma@webweaving.org
n_hibma@freebsd.org                                          USB project
http://www.etla.net/~n_hibma/



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sun Mar 19  7:54:27 2000
Delivered-To: freebsd-current@freebsd.org
Received: from RedDust.BlueSky.net.au (reddust.bluesky.net.au [203.31.37.15])
	by hub.freebsd.org (Postfix) with ESMTP id 95E0A37B513
	for <current@FreeBSD.ORG>; Sun, 19 Mar 2000 07:54:21 -0800 (PST)
	(envelope-from receiver@RedDust.BlueSky.net.au)
Received: from localhost (receiver@localhost)
	by RedDust.BlueSky.net.au (8.9.3/8.9.3) with ESMTP id BAA47796;
	Mon, 20 Mar 2000 01:55:11 +1000 (EST)
	(envelope-from receiver@RedDust.BlueSky.net.au)
Date: Mon, 20 Mar 2000 01:55:11 +1000 (EST)
From: Idea Receiver <receiver@RedDust.BlueSky.net.au>
To: "Thierry.herbelot" <herbelot@cybercable.fr>
Cc: marc@bowtie.nl, current@FreeBSD.ORG
Subject: Re: install problem with 4.0 (spec_getpages)
In-Reply-To: <38D4E6F2.FCDB2141@cybercable.fr>
Message-ID: <Pine.BSF.4.10.10003200154040.47791-100000@RedDust.BlueSky.net.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG



On Sun, 19 Mar 2000, Thierry.herbelot wrote:

> Marc van Kempen wrote:
> > 
> > Hi,
> > 
> > While trying to boot from the 4.0 installation disks,
> > I get the following error after the devices have been probed:
> > 
> 
> [SNIP]
> 
> >     root@localhost:/usr/src/sys/compile/SCHOPENHAUER
> > Timecounter "i8254"  frequency 1193182 Hz
> > CPU: Celeron (412.50-MHz 686-class CPU)
> 
> 412 MHz is a non-conventional speed for a Celly : if you are
> overclocking (I'm doing it, too), does the bug repeats itself when at
> the normal speed ?

yes it does.
anyway.. problem fixed this afternoon (australia time :P)!



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sun Mar 19 10:34:31 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mail-out.visi.com (kauket.visi.com [209.98.98.22])
	by hub.freebsd.org (Postfix) with ESMTP id 37C9137B73F
	for <freebsd-current@freebsd.org>; Sun, 19 Mar 2000 10:34:29 -0800 (PST)
	(envelope-from veldy@visi.com)
Received: from isis.visi.com (isis.visi.com [209.98.98.8])
	by mail-out.visi.com (Postfix) with ESMTP id E81333945
	for <freebsd-current@freebsd.org>; Sun, 19 Mar 2000 12:34:22 -0600 (CST)
Received: from localhost (veldy@localhost)
	by isis.visi.com (8.8.8/8.8.8) with ESMTP id MAA03466
	for <freebsd-current@freebsd.org>; Sun, 19 Mar 2000 12:34:22 -0600 (CST)
X-Authentication-Warning: isis.visi.com: veldy owned process doing -bs
Date: Sun, 19 Mar 2000 12:34:22 -0600 (CST)
From: Thomas Veldhouse <veldy@visi.com>
To: freebsd-current@freebsd.org
Subject: emu10k1 (SB Live!) support under FreeBSD?
Message-ID: <Pine.GSO.4.10.10003191230190.3416-100000@isis.visi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Are there any plans to support the emu10k1 chip (SoundBlaster Live! and
SB512) under FreeBSD?

I would love to help out, but I don't know where to start, and I have no
kernel programming experience.  There are reference drivers available for
linux via http://opensource.creative.com or http://www.alsa-project.org
(my preference).

Tom Veldhouse
veldy@visi.com



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sun Mar 19 11:31: 5 2000
Delivered-To: freebsd-current@freebsd.org
Received: from pinhead.parag.codegen.com (207-44-235-154.CodeGen.COM [207.44.235.154])
	by hub.freebsd.org (Postfix) with ESMTP id 1C0ED37B6C6
	for <freebsd-current@freebsd.org>; Sun, 19 Mar 2000 11:30:46 -0800 (PST)
	(envelope-from parag@pinhead.parag.codegen.com)
Received: from pinhead.parag.codegen.com (parag@localhost.parag.codegen.com [127.0.0.1])
	by pinhead.parag.codegen.com (8.9.3/8.9.3) with ESMTP id LAA70535
	for <freebsd-current@freebsd.org>; Sun, 19 Mar 2000 11:30:44 -0800 (PST)
	(envelope-from parag@pinhead.parag.codegen.com)
X-Mailer: exmh version 2.1.1 09/19/1999
To: freebsd-current@freebsd.org
Subject: 4.0 kernel size quite a bit larger than 3.4?
X-Image-URL: http://www.codegen.com/images/CG-logo-only.gif
X-URL: http://www.codegen.com
X-Face: =O'Kj74icvU|oS*<7gS/8'\Pbpm}okVj*@UC!IgkmZQAO!W[|iBiMs*|)n*`X
        ]pW%m>Oz_mK^Gdazsr.Z0/JsFS1uF8gBVIoChGwOy{EK=<6g?aHE`[\S]C]T0Wm
Mime-Version: 1.0
Content-Type: multipart/mixed ;
	boundary="==_Exmh_-15024258400"
Date: Sun, 19 Mar 2000 11:30:44 -0800
Message-ID: <70531.953494244@pinhead.parag.codegen.com>
From: Parag Patel <parag@cgt.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

This is a multipart MIME message.

--==_Exmh_-15024258400
Content-Type: text/plain; charset=us-ascii


Has anyone else noticed their 4.0 kernel is quite a bit larger than 3.4?
I've been building 4.0 kernels before I try to upgrade pinhead from
3-CURRENT to 4.  I started with GENERIC in both cases and simply turned
off all the features/drivers I don't need and added the ones I do.
(/kernel is 3.4):

    $ ll /kernel kernel; size /kernel kernel 
    -rwxr-xr-x  1 root   wheel  1877424 Feb  7 14:15 /kernel
    -rwxr-xr-x  1 parag  bin    2331259 Mar 19 11:28 kernel
       text    data     bss     dec     hex filename
    1451231  109080  158188 1718499  1a38e3 /kernel
    1721108  234908  120376 2076392  1faee8 kernel

~280Kb of .text seems a bit excessive.  I completely stripped both
images and compared them but the size difference is still the same.

(Both config files are attached below.)

It's hard to diff the config files as so much stuff has changed and
rearranged between the 3.4 and 4.0.  A manual exam/compare of both
didn't point out anything obvious to me but perhaps I've simply missed
something big.  I prefer to build everything into the kernel rather than
use KLDs just to be sure I haven't forgotten to update the latter.

(I searched the mail archives but didn't find anything obvious.)

Thanks!


	-- Parag Patel


--==_Exmh_-15024258400
Content-Type: text/plain ; name="PINHEAD-4.0"; charset=us-ascii
Content-Description: PINHEAD-4.0
Content-Disposition: attachment; filename="PINHEAD-4.0"

#
# PINHEAD config file developed from:
# GENERIC -- Generic kernel configuration file for FreeBSD/i386
#
# For more information on this file, please read the handbook section on
# Kernel Configuration Files:
#
#    http://www.freebsd.org/handbook/kernelconfig-config.html
#
# The handbook is also available locally in /usr/share/doc/handbook
# if you've installed the doc distribution, otherwise always see the
# FreeBSD World Wide Web server (http://www.FreeBSD.ORG/) for the
# latest information.
#
# An exhaustive list of options and more detailed explanations of the
# device lines is also present in the ./LINT configuration file. If you are
# in doubt as to the purpose or necessity of a line, check first in LINT.
#
# $FreeBSD: src/sys/i386/conf/GENERIC,v 1.246 2000/03/09 16:32:55 jlemon Exp $

machine		i386
#cpu		I386_CPU
#cpu		I486_CPU
cpu		I586_CPU
cpu		I686_CPU
ident		PINHEAD
maxusers	32

#makeoptions	DEBUG=-g		#Build kernel with gdb(1) debug symbols

#options 	MATH_EMULATE		#Support for x87 emulation
options 	INET			#InterNETworking
#options 	INET6			#IPv6 communications protocols
options 	FFS			#Berkeley Fast Filesystem
options 	FFS_ROOT		#FFS usable as root device [keep this!]
options 	MFS			#Memory Filesystem
#options 	MD_ROOT			#MD is a potential root device
options 	NFS			#Network Filesystem
#options 	NFS_ROOT		#NFS usable as root device, NFS required
#options 	MSDOSFS			#MSDOS Filesystem
options 	CD9660			#ISO 9660 Filesystem
#options 	CD9660_ROOT		#CD-ROM usable as root, CD9660 required
options 	PROCFS			#Process filesystem
options 	COMPAT_43		#Compatible with BSD 4.3 [KEEP THIS!]
options 	SCSI_DELAY=3000		#Delay (in ms) before probing SCSI
options 	UCONSOLE		#Allow users to grab the console
#options 	USERCONFIG		#boot -c editor
#options 	VISUAL_USERCONFIG	#visual boot -c editor
options 	KTRACE			#ktrace(1) support
options 	SYSVSHM			#SYSV-style shared memory
options 	SYSVMSG			#SYSV-style message queues
options 	SYSVSEM			#SYSV-style semaphores
options 	P1003_1B		#Posix P1003_1B real-time extentions
options 	_KPOSIX_PRIORITY_SCHEDULING
#options		ICMP_BANDLIM		#Rate limit bad replies

options		DDB
options		INVARIANTS
options		INVARIANT_SUPPORT
options		MD5
options		COMPAT_LINUX
#options		VESA
options		IDE_DELAY=3000
options 	NETATALK		#Appletalk communications protocols
options		SOFTUPDATES		#Copyrighted FFS changes

# To make an SMP kernel, the next two are needed
options 	SMP			# Symmetric MultiProcessor Kernel
options 	APIC_IO			# Symmetric (APIC) I/O
# Optionally these may need tweaked, (defaults shown):
#options 	NCPU=2			# number of CPUs
#options 	NBUS=4			# number of busses
#options 	NAPIC=1			# number of IO APICs
#options 	NINTR=24		# number of INTs

device		isa
#device		eisa
device		pci

# Floppy drives
device		fdc0	at isa? port IO_FD1 irq 6 drq 2
device		fd0	at fdc0 drive 0
#device		fd1	at fdc0 drive 1

# ATA and ATAPI devices
#device		ata0	at isa? port IO_WD1 irq 14
#device		ata1	at isa? port IO_WD2 irq 15
device		ata
device		atadisk			# ATA disk drives
device		atapicd			# ATAPI CDROM drives
#device		atapifd			# ATAPI floppy drives
#device		atapist			# ATAPI tape drives
options 	ATA_STATIC_ID		#Static device numbering
#options 	ATA_ENABLE_ATAPI_DMA	#Enable DMA on ATAPI devices

# misc stuff
device		joy0	at isa? port "IO_GAME"
device		pcm

# SCSI Controllers
#device		ahb		# EISA AHA1742 family
device		ahc		# AHA2940 and onboard AIC7xxx devices
options		AHC_ALLOW_MEMIO
#device		amd		# AMD 53C974 (Teckram DC-390(T))
#device		dpt		# DPT Smartcache - See LINT for options!
#device		isp		# Qlogic family
device		ncr		# NCR/Symbios Logic
#device		sym		# NCR/Symbios Logic (newer chipsets)

device		adv0	at isa?
device		adw
device		bt0	at isa?
device		aha0	at isa?
device		aic0	at isa?

# SCSI peripherals
device		scbus		# SCSI bus (required)
device		da		# Direct Access (disks)
device		sa		# Sequential Access (tape etc)
device		cd		# CD
device		pass		# Passthrough device (direct SCSI access)

# RAID controllers
#device		ida		# Compaq Smart RAID
#device		amr		# AMI MegaRAID
#device		mlx		# Mylex DAC960 family

# atkbdc0 controls both the keyboard and the PS/2 mouse
device		atkbdc0	at isa? port IO_KBD
device		atkbd0	at atkbdc? irq 1
device		psm0	at atkbdc? irq 12

device		vga0	at isa?

# splash screen/screen saver
#pseudo-device	splash

# syscons is the default console driver, resembling an SCO console
device		sc0	at isa?

# Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver
#device		vt0	at isa?
#options 	XSERVER			# support for X server on a vt console
#options 	FAT_CURSOR		# start with block cursor
# If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines
#options 	PCVT_SCANSET=2		# IBM keyboards are non-std

# Floating point support - do not disable.
device		npx0	at nexus? port IO_NPX irq 13

# Power management support (see LINT for more options)
#device		apm0    at nexus? disable flags 0x20 # Advanced Power Management

# PCCARD (PCMCIA) support
#device		card
#device		pcic0	at isa? irq 10 port 0x3e0 iomem 0xd0000
#device		pcic1	at isa? irq 11 port 0x3e2 iomem 0xd4000 disable

# Serial (COM) ports
device		sio0	at isa? port IO_COM1 flags 0x10 irq 4
device		sio1	at isa? port IO_COM2 irq 3
device		sio2	at isa? port IO_COM3 irq 5
device		sio3	at isa? port IO_COM4 irq 9

# Parallel port
device		ppc0	at isa? irq 7
device		ppbus		# Parallel port bus (required)
device		lpt		# Printer
#device		plip		# TCP/IP over parallel
device		ppi		# Parallel port interface device
#device		vpo		# Requires scbus and da


# PCI Ethernet NICs.
#device		de		# DEC/Intel DC21x4x (``Tulip'')
device		fxp		# Intel EtherExpress PRO/100B (82557, 82558)
#device		tx		# SMC 9432TX (83c170 ``EPIC'')
#device		vx		# 3Com 3c590, 3c595 (``Vortex'')
#device		wx		# Intel Gigabit Ethernet Card (``Wiseman'')

# PCI Ethernet NICs that use the common MII bus controller code.
#device		miibus		# MII bus support
#device		dc		# DEC/Intel 21143 and various workalikes
#device		rl		# RealTek 8129/8139
#device		sf		# Adaptec AIC-6915 (``Starfire'')
#device		sis		# Silicon Integrated Systems SiS 900/SiS 7016
#device		ste		# Sundance ST201 (D-Link DFE-550TX)
#device		tl		# Texas Instruments ThunderLAN
#device		vr		# VIA Rhine, Rhine II
#device		wb		# Winbond W89C840F
#device		xl		# 3Com 3c90x (``Boomerang'', ``Cyclone'')

# ISA Ethernet NICs.
#device		ed0	at isa? port 0x280 irq 10 iomem 0xd8000
#device		ex
#device		ep
# WaveLAN/IEEE 802.11 wireless NICs. Note: the WaveLAN/IEEE really
# exists only as a PCMCIA device, so there is no ISA attatement needed
# and resources will always be dynamically assigned by the pccard code.
#device		wi
# Aironet 4500/4800 802.11 wireless NICs. Note: the declaration below will
# work for PCMCIA and PCI cards, as well as ISA cards set to ISA PnP
# mode (the factory default). If you set the switches on your ISA
# card for a manually chosen I/O address and IRQ, you must specify
# those paremeters here.
#device		an
# The probe order of these is presently determined by i386/isa/isa_compat.c.
#device		ie0	at isa? port 0x300 irq 10 iomem 0xd0000
#device		fe0	at isa? port 0x300
#device		le0	at isa? port 0x300 irq 5 iomem 0xd0000
#device		lnc0	at isa? port 0x280 irq 10 drq 0
#device		cs0	at isa? port 0x300
#device		sn0	at isa? port 0x300 irq 10
# requires PCCARD (PCMCIA) support to be activated
#device		xe0	at isa?

# Pseudo devices - the number indicates how many units to allocated.
pseudo-device	loop		# Network loopback
pseudo-device	ether		# Ethernet support
#pseudo-device	sl	1	# Kernel SLIP
pseudo-device	ppp	1	# Kernel PPP
pseudo-device	tun		# Packet tunnel.
pseudo-device	pty		# Pseudo-ttys (telnet etc)
#pseudo-device	md		# Memory "disks"
#pseudo-device	gif	4	# IPv6 and IPv4 tunneling
#pseudo-device	faith	1	# IPv6-to-IPv4 relaying (translation)

pseudo-device	vn		#Vnode driver (turns a file into a device)
#pseudo-device	vinum	#Volume Manager

# The `bpf' pseudo-device enables the Berkeley Packet Filter.
# Be aware of the administrative consequences of enabling this!
pseudo-device	bpf		#Berkeley packet filter

# USB support
#device		uhci		# UHCI PCI->USB interface
#device		ohci		# OHCI PCI->USB interface
#device		usb		# USB Bus (required)
#device		ugen		# Generic
#device		uhid		# "Human Interface Devices"
#device		ukbd		# Keyboard
#device		ulpt		# Printer
#device		umass		# Disks/Mass storage - Requires scbus and da
#device		ums		# Mouse
# USB Ethernet, requires mii
#device		aue		# ADMtek USB ethernet
#device		cue		# CATC USB ethernet
#device		kue		# Kawasaki LSI USB ethernet

--==_Exmh_-15024258400
Content-Type: text/plain ; name="PINHEAD-3.4"; charset=us-ascii
Content-Description: PINHEAD-3.4
Content-Disposition: attachment; filename="PINHEAD-3.4"

#
# GENERIC -- Generic machine with WD/AHx/NCR/BTx family disks
#
# For more information read the handbook part System Administration -> 
# Configuring the FreeBSD Kernel -> The Configuration File. 
# The handbook is available in /usr/share/doc/handbook or online as
# latest version from the FreeBSD World Wide Web server 
# <URL:http://www.FreeBSD.ORG/>
#
# An exhaustive list of options and more detailed explanations of the 
# device lines is present in the ./LINT configuration file. If you are 
# in doubt as to the purpose or necessity of a line, check first in LINT.
#
#	$Id: GENERIC,v 1.112 1998/07/20 20:00:29 msmith Exp $

machine		"i386"
#cpu		"I386_CPU"
#cpu		"I486_CPU"
cpu		"I586_CPU"	# for npx0
cpu		"I686_CPU"
ident		PINHEAD
maxusers	32

#options	MATH_EMULATE		#Support for x87 emulation
options		INET			#InterNETworking
options		NETATALK		#Appletalk communications protocols
#options	NETATALKDEBUG
options		FFS			#Berkeley Fast Filesystem
options		NFS			#Network Filesystem
options		MFS			#Memory File System
#options		MSDOSFS			#MSDOS Filesystem
options		"CD9660"		#ISO 9660 Filesystem
#options		"CD9660_ROOT"		#CD-ROM usable as root device
options		FFS_ROOT		#FFS usable as root device [keep this!]
#options		NFS_ROOT		#NFS usable as root device
options		PROCFS			#Process filesystem
options		"COMPAT_43"		#Compatible with BSD 4.3 [KEEP THIS!]
#options	SCSI_DELAY=15000	#Be pessimistic about Joe SCSI device
options		SCSI_DELAY=3000
options		UCONSOLE		#Allow users to grab the console
options		FAILSAFE		#Be conservative
#options		USERCONFIG		#boot -c editor
#options		VISUAL_USERCONFIG	#visual boot -c editor
options		USER_LDT		#allow user-level control of i386 ldt - wine
options		"MD5"
options		"VM86"
#options		VESA
options		COMPAT_LINUX

options		IDE_DELAY=3000
options		SMP			# Symmetric MultiProcessor Kernel
options		APIC_IO			# Symmetric (APIC) I/O
options		SOFTUPDATES		#Copyrighted FFS changes

# These provide support for System V shared memory/semaphores/message-queues
#
options		SYSVSHM
options		SYSVSEM
options		SYSVMSG

# POSIX P1003.1B
#
# Real time extensions added int the 1993 Posix
# P1003_1B: Infrastructure
# _KPOSIX_PRIORITY_SCHEDULING: Build in _POSIX_PRIORITY_SCHEDULING
# _KPOSIX_VERSION:             Version kernel is built for
#
options		"P1003_1B"
options		"_KPOSIX_PRIORITY_SCHEDULING"
options		"_KPOSIX_VERSION=199309L"

# KTRACE enables the system-call tracing facility ktrace(2).
# This adds 4 KB bloat to your kernel, and slightly increases
# the costs of each syscall.
options		KTRACE		#kernel tracing

# Turn on kernel debugging
#
options		DDB

# Be paranoid to help shake out bugs early
#
options		INVARIANTS
options		INVARIANT_SUPPORT

config		kernel	root on da0

controller	isa0
#controller	eisa0
controller	pci0

controller	fdc0	at isa? port "IO_FD1" bio irq 6 drq 2
disk		fd0	at fdc0 drive 0
#disk		fd1	at fdc0 drive 1
# Unless you know very well what you're doing, leave ft0 at drive 2, or
# remove the line entirely if you don't need it.  Trying to configure
# it on another unit might cause surprises, see PR kern/7176.
#tape		ft0	at fdc0 drive 2

#options		"CMD640"	# work around CMD640 chip deficiency
controller	wdc0	at isa? port "IO_WD1" bio irq 14 flags 0xB0FFB0FF
disk		wd0	at wdc0 drive 0
disk		wd1	at wdc0 drive 1

controller	wdc1	at isa? port "IO_WD2" bio irq 15 flags 0xB0FFB0FF
disk		wd2	at wdc1 drive 0
disk		wd3	at wdc1 drive 1

options		ATAPI		#Enable ATAPI support for IDE bus
options		ATAPI_STATIC	#Don't do it as an LKM
device		acd0		# ATAPI CD-ROM, CD-R/RW
#device		wfd0		# ATAPI Floppy (e.g. LS-120)

#
# ATA and ATAPI devices
# This is work in progress, use at your own risk.
# It currently reuses the majors of wd.c and freinds.
# It cannot co-exist with the old system in one kernel.
# You only need one "controller ata0" for it to find all
# PCI devices on modern machines.
#options	"ATA_DEBUG"
#options	"ATAPI_DEBUG"
#options	"ACD_DEBUG"
#controller	ata0
#device		atadisk0	# ATA disk drives
#device		atapicd0	# ATAPI CDROM drives
#device		atapifd0	# ATAPI floppy drives
#device		atapist0	# ATAPI tape drives
#
# If you need ISA only devices, this is the lines to add:
#controller	ata1	at isa? port "IO_WD1" bio irq 14
#controller	ata2	at isa? port "IO_WD2" bio irq 15
# 
# All the controller lines can coexist, the driver will
# find out which ones are there.

# Enable PnP support in the kernel.  This allows you to automaticly
# attach to PnP cards for drivers that support it and allows you to
# configure cards from USERCONFIG.  See pnp(4) for more info.
controller	pnp0

# Luigi's snd code (use INSTEAD of snd0 and all VOXWARE drivers!).
# You may also wish to enable the pnp controller with this, for pnp
# sound cards.
#
#device pcm0 at isa? port ? tty irq 10 drq 1 flags 0x0
#device pcm0 at isa? port ? tty irq ? drq ? flags 0x0
device pcm0

#controller      snd0
#device sb0      at isa? port 0x220 irq 10 drq 1
#device sbxvi0   at isa? drq 5
#device sbmidi0  at isa? port 0x330
#device opl0     at isa? port 0x388
#device awe0     at isa? port 0x620


# Joystick(s)
#
device		joy0	at isa? port "IO_GAME"
device		joy1	at isa? disable port "IO_GAME"


# A single entry for any of these controllers (ncr, ahb, ahc, amd) is
# sufficient for any number of installed devices.
controller	ncr0
#controller	amd0
#controller	ahb0
controller	ahc0
#controller	isp0

# The aic7xxx driver will attempt to use memory mapped I/O for all PCI
# controllers that have it configured only if this option is set. Unfortunately,
# this doesn't work on some motherboards, which prevents it from being the
# default.
options AHC_ALLOW_MEMIO

# This controller offers a number of configuration options, too many to
# document here  - see the LINT file in this directory and look up the
# dpt0 entry there for much fuller documentation on this.  The options
# line following dpt0 here is also currently a *required* option for it.
#controller      dpt0
#options DPT_MEASURE_PERFORMANCE

#controller	bt0	at isa? port "IO_BT0" bio irq ?
#controller	uha0	at isa? port "IO_UHA0" bio irq ? drq 5
#controller	aha0	at isa? port "IO_AHA0" bio irq ? drq 5
#controller	aic0	at isa? port 0x340 bio irq 11
#controller	nca0	at isa? port 0x1f88 bio irq 10
#controller	nca1	at isa? port 0x350 bio irq 5
#controller	sea0	at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000

controller	scbus0	#base SCSI code
#device		ch0	#SCSI media changers
device		da0	#SCSI direct access devices (aka disks)
#device		sa0	#SCSI tapes
device		cd0	#SCSI CD-ROMs
#device		od0	#SCSI optical disk
device		pass0	#CAM passthrough driver

#device worm0 at scbus?	# SCSI worm
#device pt0 at scbus?	# SCSI processor type
#device sctarg0 at scbus? # SCSI target

#device		wt0	at isa? port 0x300 bio irq 5 drq 1
#device		mcd0	at isa? port 0x300 bio irq 10

#controller	matcd0	at isa? port 0x230 bio

#device		scd0	at isa? port 0x230 bio


# syscons is the default console driver, resembling an SCO console
controller 	atkbdc0	at isa? port IO_KBD tty
device		atkbd0	at isa? tty irq 1
device		psm0	at isa? tty irq 12 flags 0x04
device		vga0	at isa? port ? conflicts

# Splash screen at start up!  Screen savers require this too.
#pseudo-device   splash
 
device		sc0	at isa? tty


# Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver
#device		vt0	at isa? port "IO_KBD" tty irq 1
#options		XSERVER			# support for X server
#options		FAT_CURSOR		# start with block cursor
# If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines
#options		PCVT_SCANSET=2		# IBM keyboards are non-std

device		npx0	at isa? port "IO_NPX" irq 13

#
# Laptop support (see LINT for more options)
#
#device		apm0    at isa?	disable	flags 0x31 # Advanced Power Management

# PCCARD (PCMCIA) support
#controller	card0
#device		pcic0	at card?
#device		pcic1	at card?

device		sio0	at isa? port "IO_COM1" flags 0x10 tty irq 4
device		sio1	at isa? port "IO_COM2" tty irq 3
device		sio2	at isa? port "IO_COM3" tty irq 5
device		sio3	at isa? port "IO_COM4" tty irq 9

# Parallel port
device		ppc0	at isa? port ? tty irq 7
controller	ppbus0
device		lpt0	at ppbus?
#device		plip0	at ppbus?
device		ppi0	at ppbus?
#controller	vpo0	at ppbus?

# Order is important here due to intrusive probes, do *not* alphabetize
# this list of network interfaces until the probes have been fixed.
# Right now it appears that the ie0 must be probed before ep0. See
# revision 1.20 of this file.
#device de0
device fxp0
#device tl0
#device tx0
#device vx0

#device ed0 at isa? port 0x280 net irq 10 iomem 0xd8000
#device ie0 at isa? port 0x300 net irq 10 iomem 0xd0000
#device ep0 at isa? port 0x300 net irq 10
#device ex0 at isa? port? net irq?
#device fe0 at isa? port 0x300 net irq ?
#device le0 at isa? port 0x300 net irq 5 iomem 0xd0000
#device lnc0 at isa? port 0x280 net irq 10 drq 0
#device ze0 at isa? port 0x300 net irq 10 iomem 0xd8000
#device zp0 at isa? port 0x300 net irq 10 iomem 0xd8000
#device cs0 at isa? port 0x300 net irq ?

pseudo-device	loop
pseudo-device	ether
#pseudo-device	sl	1
#pseudo-device	ppp	1
pseudo-device	tun	1
pseudo-device	pty	64
pseudo-device	bpfilter	16	#Berkeley packet filter
pseudo-device	vn		#Vnode driver (turns a file into a device)
#pseudo-device	ccd	4	#Concatenated disk driver
#pseudo-device	vinum	#Volume Manager

--==_Exmh_-15024258400--




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sun Mar 19 11:39: 3 2000
Delivered-To: freebsd-current@freebsd.org
Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20])
	by hub.freebsd.org (Postfix) with ESMTP id ED46637BCE5
	for <current@FreeBSD.ORG>; Sun, 19 Mar 2000 11:38:53 -0800 (PST)
	(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
	by fw.wintelcom.net (8.10.0/8.10.0) id e2JK1fA28737;
	Sun, 19 Mar 2000 12:01:41 -0800 (PST)
Date: Sun, 19 Mar 2000 12:01:40 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Marc van Kempen <marc@bowtie.nl>
Cc: "Thierry.herbelot" <herbelot@cybercable.fr>, current@FreeBSD.ORG
Subject: Re: install problem with 4.0 (spec_getpages)
Message-ID: <20000319120140.Q14789@fw.wintelcom.net>
References: <38D4E6F2.FCDB2141@cybercable.fr> <200003191453.PAA03310@bowtie.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200003191453.PAA03310@bowtie.nl>; from marc@bowtie.nl on Sun, Mar 19, 2000 at 03:53:46PM +0100
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

* Marc van Kempen <marc@bowtie.nl> [000319 07:18] wrote:
> 
> > Marc van Kempen wrote:
> > > 
> > > Hi,
> > > 
> > > While trying to boot from the 4.0 installation disks,
> > > I get the following error after the devices have been probed:
> > > 
> > 
> > [SNIP]
> > 
> > >     root@localhost:/usr/src/sys/compile/SCHOPENHAUER
> > > Timecounter "i8254"  frequency 1193182 Hz
> > > CPU: Celeron (412.50-MHz 686-class CPU)
> > 
> > 412 MHz is a non-conventional speed for a Celly : if you are
> > overclocking (I'm doing it, too), does the bug repeats itself when at
> > the normal speed ?
> > 
> I will try that, it didn't occur to me to do that, since I've been running
> that for a year or so now, without any problems.

You also ought to make sure the floppies can get through a complete
format before dd'ing the images over them.

-Alfred


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sun Mar 19 11:40: 0 2000
Delivered-To: freebsd-current@freebsd.org
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131])
	by hub.freebsd.org (Postfix) with ESMTP id 4F7BA37B6C6
	for <current@FreeBSD.ORG>; Sun, 19 Mar 2000 11:39:45 -0800 (PST)
	(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1])
	by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id UAA14764;
	Sun, 19 Mar 2000 20:38:56 +0100 (CET)
	(envelope-from phk@critter.freebsd.dk)
To: peter@netplex.com.au (Peter Wemm)
Cc: current@FreeBSD.ORG
Subject: Re: HEADS UP; new options for -current! 
In-reply-to: Your message of "Sun, 19 Mar 2000 21:14:47 +0800."
             <20000319131447.E6EF21CD9@overcee.netplex.com.au> 
Date: Sun, 19 Mar 2000 20:38:56 +0100
Message-ID: <14762.953494736@critter.freebsd.dk>
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <20000319131447.E6EF21CD9@overcee.netplex.com.au>, Peter Wemm writes
:
>If you are using old drivers that haven't been newbusified yet, you will
>need to add 'options COMPAT_OLDPCI' and/or 'options COMPAT_OLDISA' to your
>kernel configs and regenerate.  Otherwise you will get compile failures.

I think this is premature.

I tried to newbusify if_mn.c, but after having added about 50 lines
of code to replace the current about 10, I gave up.

We need a highlevel wrapper for newbus before we should force people
to upgrade the old-style drivers.

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sun Mar 19 12:55:15 2000
Delivered-To: freebsd-current@freebsd.org
Received: from spirit.jaded.net (liv3-3.hamilton.idirect.com [209.161.208.3])
	by hub.freebsd.org (Postfix) with ESMTP id E0AA237B6C8
	for <freebsd-current@FreeBSD.ORG>; Sun, 19 Mar 2000 12:55:12 -0800 (PST)
	(envelope-from dan@spirit.jaded.net)
Received: (from dan@localhost)
	by spirit.jaded.net (8.9.3/8.9.3) id PAA24786;
	Sun, 19 Mar 2000 15:55:21 -0500 (EST)
Date: Sun, 19 Mar 2000 15:55:20 -0500
From: Dan Moschuk <dan@FreeBSD.ORG>
To: Thomas Veldhouse <veldy@visi.com>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: emu10k1 (SB Live!) support under FreeBSD?
Message-ID: <20000319155520.B82854@spirit.jaded.net>
References: <Pine.GSO.4.10.10003191230190.3416-100000@isis.visi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <Pine.GSO.4.10.10003191230190.3416-100000@isis.visi.com>; from veldy@visi.com on Sun, Mar 19, 2000 at 12:34:22PM -0600
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


| Are there any plans to support the emu10k1 chip (SoundBlaster Live! and
| SB512) under FreeBSD?
| 
| I would love to help out, but I don't know where to start, and I have no
| kernel programming experience.  There are reference drivers available for
| linux via http://opensource.creative.com or http://www.alsa-project.org
| (my preference).

One is on the way...

-- 
Dan Moschuk (TFreak!dan@freebsd.org)
"Waste not fresh tears on old griefs."


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sun Mar 19 12:58:56 2000
Delivered-To: freebsd-current@freebsd.org
Received: from pinhead.parag.codegen.com (207-44-235-154.CodeGen.COM [207.44.235.154])
	by hub.freebsd.org (Postfix) with ESMTP id BB4B637B7AA
	for <freebsd-current@FreeBSD.ORG>; Sun, 19 Mar 2000 12:58:39 -0800 (PST)
	(envelope-from parag@pinhead.parag.codegen.com)
Received: from pinhead.parag.codegen.com (parag@localhost.parag.codegen.com [127.0.0.1])
	by pinhead.parag.codegen.com (8.9.3/8.9.3) with ESMTP id MAA73376;
	Sun, 19 Mar 2000 12:58:39 -0800 (PST)
	(envelope-from parag@pinhead.parag.codegen.com)
To: freebsd-current@FreeBSD.ORG,
	Julian Elischer <julian@elischer.org>
Subject: Re: 4.0 kernel size quite a bit larger than 3.4? 
In-Reply-To: Message from Parag Patel <parag@cgt.com> 
   of "Sun, 19 Mar 2000 11:30:44 PST." <70531.953494244@pinhead.parag.codegen.com> 
X-Image-URL: http://www.codegen.com/images/CG-logo-only.gif
X-URL: http://www.codegen.com
X-Face: =O'Kj74icvU|oS*<7gS/8'\Pbpm}okVj*@UC!IgkmZQAO!W[|iBiMs*|)n*`X
        ]pW%m>Oz_mK^Gdazsr.Z0/JsFS1uF8gBVIoChGwOy{EK=<6g?aHE`[\S]C]T0Wm
Date: Sun, 19 Mar 2000 12:58:39 -0800
Message-ID: <73372.953499519@pinhead.parag.codegen.com>
From: Parag Patel <parag@cgt.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


To follow-up to my own note, I found some ISA devices that I failed to
turn off under 4.0.  Now the sizes are closer, but still around 180Kb
.text larger, ~270Kb overall:

    $ ll /kernel kernel
    -rwxr-xr-x  1 root   wheel  1877424 Feb  7 14:15 /kernel # (3.4)
    -rwxr-xr-x  1 parag  bin    2230379 Mar 19 12:47 kernel

    $ size /kernel kernel 
       text    data     bss     dec     hex filename
    1451231  109080  158188 1718499  1a38e3 /kernel # (3.4)
    1634903  231484  120264 1986651  1e505b kernel

So I created a merged list of object file sizes (appended below).  It
looks like a case of being nibbled to death by cats.  (Julian Elischer
suggested it may be due to the newbus code which affects just about
everything.)  No obvious place that has eaten a bunch of space - it's
pretty well scattered throughout.


	-- Parag Patel


   text	   data	    bss	    dec	    hex	filename
   1298	      4	      0	   1302	    516	93cx6.o
   1298	      4	      0	   1302	    516	93cx6.o (3.4)
   3652	     20	   2736	   6408	   1908	aarp.o
   3064	     20	   2736	   5820	   16bc	aarp.o (3.4)
   2509	    388	      0	   2897	    b51	ac97.o
   3522	    520	      4	   4046	    fce	ad1816.o
  13495	   1164	      0	  14659	   3943	ad1848.o (3.4)
   9915	   1356	      8	  11279	   2c0f	ahc_pci.o
   8260	   1056	      4	   9320	   2468	ahc_pci.o (3.4)
  40642	   4372	     10	  45024	   afe0	aic7xxx.o
  41005	   4192	     10	  45207	   b097	aic7xxx.o (3.4)
   4491	      0	      8	   4499	   1193	aicasm.o
   4491	      0	      8	   4499	   1193	aicasm.o (3.4)
  19354	      0	     60	  19414	   4bd6	aicasm_gram.o
  19354	      0	     60	  19414	   4bd6	aicasm_gram.o (3.4)
  11393	     24	     20	  11437	   2cad	aicasm_scan.o
  11393	     24	     20	  11437	   2cad	aicasm_scan.o (3.4)
   2234	      0	      4	   2238	    8be	aicasm_symbol.o
   2234	      0	      4	   2238	    8be	aicasm_symbol.o (3.4)
    483	      8	    258	    749	    2ed	arc4random.o
   3092	      0	      0	   3092	    c14	at_control.o
   3112	      0	      0	   3112	    c28	at_control.o (3.4)
     16	    116	      0	    132	     84	at_proto.o
     16	    100	      0	    116	     74	at_proto.o (3.4)
  11856	    620	    272	  12748	   31cc	ata-all.o
   5111	    200	    112	   5423	   152f	ata-disk.o
   9276	      0	      0	   9276	   243c	ata-dma.o
   6434	     84	     16	   6534	   1986	atapi-all.o
  14699	    148	      0	  14847	   39ff	atapi-cd.o
  11238	    108	     64	  11410	   2c92	atapi-cd.o (3.4)
   6991	      0	   1736	   8727	   2217	atapi.o (3.4)
   5781	   6020	   5892	  17693	   451d	atkbd.o
   5726	   6016	   5888	  17630	   44de	atkbd.o (3.4)
    374	    108	      0	    482	    1e2	atkbd_isa.o
    139	     16	      4	    159	     9f	atkbd_isa.o (3.4)
   4308	      8	     96	   4412	   113c	atkbdc.o
   4284	      8	     96	   4388	   1124	atkbdc.o (3.4)
   1033	    280	      0	   1313	    521	atkbdc_isa.o
    105	     16	      0	    121	     79	atkbdc_isa.o (3.4)
    220	      0	      0	    220	     dc	atomic.o
    220	      0	      0	    220	     dc	atomic.o (3.4)
    925	     96	      0	   1021	    3fd	autoconf.o
   1687	    156	      0	   1843	    733	autoconf.o (3.4)
    291	      0	      0	    291	    123	bcd.o
    291	      0	      0	    291	    123	bcd.o (3.4)
   2461	     44	      0	   2505	    9c9	bios.o
   1350	     52	      0	   1402	    57a	bios.o (3.4)
    219	      8	      0	    227	     e3	bioscall.o
     47	      0	      0	     47	     2f	bioscall.o (3.4)
   4083	    248	     20	   4351	   10ff	bpf.o
   3978	    136	   1244	   5358	   14ee	bpf.o (3.4)
   2393	      0	      0	   2393	    959	bpf_filter.o
   2393	      0	      0	   2393	    959	bpf_filter.o (3.4)
   1196	    256	      0	   1452	    5ac	bus_if.o
    660	     72	      0	    732	    2dc	bus_if.o (3.4)
   3024	      4	     80	   3108	    c24	busdma_machdep.o
   2906	      4	     80	   2990	    bae	busdma_machdep.o (3.4)
    318	      0	      0	    318	    13e	cam.o
    318	      0	      0	    318	    13e	cam.o (3.4)
    375	      0	      0	    375	    177	cam_extend.o
    375	      0	      0	    375	    177	cam_extend.o (3.4)
   6288	      0	      0	   6288	   1890	cam_periph.o
   6075	      0	      0	   6075	   17bb	cam_periph.o (3.4)
   1438	      0	      0	   1438	    59e	cam_queue.o
   1438	      0	      0	   1438	    59e	cam_queue.o (3.4)
    234	      0	      0	    234	     ea	cam_sim.o
    234	      0	      0	    234	     ea	cam_sim.o (3.4)
  23494	    968	     72	  24534	   5fd6	cam_xpt.o
  22815	    992	     76	  23883	   5d4b	cam_xpt.o (3.4)
    154	      0	      0	    154	     9a	cd9660_bmap.o
    154	      0	      0	    154	     9a	cd9660_bmap.o (3.4)
   2319	      0	      0	   2319	    90f	cd9660_lookup.o
   2319	      0	      0	   2319	    90f	cd9660_lookup.o (3.4)
   1779	      0	     12	   1791	    6ff	cd9660_node.o
   1763	      0	     12	   1775	    6ef	cd9660_node.o (3.4)
   3108	    384	      0	   3492	    da4	cd9660_rrip.o
   3096	    384	      0	   3480	    d98	cd9660_rrip.o (3.4)
    572	      0	      0	    572	    23c	cd9660_util.o
    572	      0	      0	    572	    23c	cd9660_util.o (3.4)
   4621	    292	      0	   4913	   1331	cd9660_vfsops.o
   4780	    304	      0	   5084	   13dc	cd9660_vfsops.o (3.4)
   4100	    496	      0	   4596	   11f4	cd9660_vnops.o
   4108	    520	      0	   4628	   1214	cd9660_vnops.o (3.4)
   5644	      0	      0	   5644	   160c	channel.o
   5707	    372	     40	   6119	   17e7	clock.o
   5199	    332	     40	   5571	   15c3	clock.o (3.4)
      0	      0	      0	      0	      0	clones.o (3.4)
      0	      0	      0	      0	      0	config.o
      0	      0	      0	      0	      0	config.o (3.4)
   1434	    208	     40	   1682	    692	cons.o (3.4)
   2684	  55516	      4	  58204	   e35c	csa.o
   3093	    380	      4	   3477	    d95	csapcm.o
    127	     16	      0	    143	     8f	db_access.o
    127	     16	      0	    143	     8f	db_access.o (3.4)
      0	      0	      0	      0	      0	db_aout.o (3.4)
    980	     16	   2800	   3796	    ed4	db_break.o
    980	     16	   2800	   3796	    ed4	db_break.o (3.4)
   1891	    528	      0	   2419	    973	db_command.o
   1755	    524	      0	   2279	    8e7	db_command.o (3.4)
  12996	      0	      0	  12996	   32c4	db_disasm.o
  12996	      0	      0	  12996	   32c4	db_disasm.o (3.4)
   1753	    121	      0	   1874	    752	db_examine.o
   1747	    121	      0	   1868	    74c	db_examine.o (3.4)
    889	      0	      0	    889	    379	db_expr.o
    889	      0	      0	    889	    379	db_expr.o (3.4)
   2086	      0	   2084	   4170	   104a	db_input.o
   2091	      0	   2084	   4175	   104f	db_input.o (3.4)
   1056	      4	     56	   1116	    45c	db_interface.o
   1005	      8	     40	   1053	    41d	db_interface.o (3.4)
    184	      0	      0	    184	     b8	db_kld.o
    184	      0	      0	    184	     b8	db_kld.o (3.4)
   1370	     12	    128	   1510	    5e6	db_lex.o
   1370	     12	    128	   1510	    5e6	db_lex.o (3.4)
    450	     16	      0	    466	    1d2	db_output.o
    450	     16	      0	    466	    1d2	db_output.o (3.4)
    210	      0	      0	    210	     d2	db_print.o
    209	      0	      0	    209	     d1	db_print.o (3.4)
    546	      0	      0	    546	    222	db_ps.o
    546	      0	      0	    546	    222	db_ps.o (3.4)
    973	      0	     16	    989	    3dd	db_run.o
    973	      0	     16	    989	    3dd	db_run.o (3.4)
   1239	     60	    260	   1559	    617	db_sym.o
   1190	     60	    260	   1510	    5e6	db_sym.o (3.4)
    202	     40	      0	    242	     f2	db_sysctl.o
    202	     32	      0	    234	     ea	db_sysctl.o (3.4)
   1415	    184	      0	   1599	    63f	db_trace.o
   1412	    172	      0	   1584	    630	db_trace.o (3.4)
    268	      0	      0	    268	    10c	db_trap.o
    268	      0	      0	    268	    10c	db_trap.o (3.4)
    443	     52	      0	    495	    1ef	db_variables.o
    443	     52	      0	    495	    1ef	db_variables.o (3.4)
    847	     20	   1600	   2467	    9a3	db_watch.o
    847	     20	   1600	   2467	    9a3	db_watch.o (3.4)
    249	      0	      0	    249	     f9	db_write_cmd.o
    247	      0	      0	    247	     f7	db_write_cmd.o (3.4)
   1457	     28	     60	   1545	    609	ddp_input.o
   1433	     20	     60	   1513	    5e9	ddp_input.o (3.4)
   1102	      4	      0	   1106	    452	ddp_output.o
    862	      4	      0	    866	    362	ddp_output.o (3.4)
   2057	     92	      0	   2149	    865	ddp_usrreq.o
   2073	     92	      0	   2165	    875	ddp_usrreq.o (3.4)
    572	    280	      0	    852	    354	dead_vnops.o
    576	    288	      0	    864	    360	dead_vnops.o (3.4)
    289	     32	      0	    321	    141	default_pager.o
    359	     28	      0	    387	    183	default_pager.o (3.4)
    459	    112	      0	    571	    23b	device_if.o
    349	     48	      0	    397	    18d	device_if.o (3.4)
   1303	     32	     88	   1423	    58f	device_pager.o
   1189	     28	     88	   1305	    519	device_pager.o (3.4)
   2728	     64	      1	   2793	    ae9	diskslice_machdep.o (3.4)
    114	      0	      0	    114	     72	divdi3.o
    114	      0	      0	    114	     72	divdi3.o (3.4)
   3698	    512	      0	   4210	   1072	dmabuf.o (3.4)
   4607	      0	      0	   4607	   11ff	dsp.o
    368	      0	      0	    368	    170	elf_machdep.o
    368	      0	      0	    368	    170	elf_machdep.o (3.4)
   7661	    960	      0	   8621	   21ad	es1370.o (3.4)
   7507	    204	      0	   7711	   1e1f	es1371.o (3.4)
   6052	    820	      4	   6876	   1adc	es137x.o
    353	    100	      4	    457	    1c9	es1888.o
  21063	   2064	      0	  23127	   5a57	exception.o
  21447	   1360	      0	  22807	   5917	exception.o (3.4)
    134	    256	      0	    390	    186	fake.o
   2690	    152	     12	   2854	    b26	fb.o
   1471	     68	      8	   1547	    60b	fb.o (3.4)
  11206	   1132	      8	  12346	   303a	fd.o
   9074	    740	    192	  10006	   2716	fd.o (3.4)
   1928	   1536	      0	   3464	    d88	feeder.o
  12452	    128	      0	  12580	   3124	ffs_alloc.o
  12595	    108	      0	  12703	   319f	ffs_alloc.o (3.4)
   3488	      0	      0	   3488	    da0	ffs_balloc.o
   3198	      0	      0	   3198	    c7e	ffs_balloc.o (3.4)
   4219	      0	      0	   4219	   107b	ffs_inode.o
   4247	      0	      0	   4247	   1097	ffs_inode.o (3.4)
  26580	   1592	    140	  28312	   6e98	ffs_softdep.o
  24365	   1460	    132	  25957	   6565	ffs_softdep.o (3.4)
      0	      0	      0	      0	      0	ffs_softdep_stub.o
      0	      0	      0	      0	      0	ffs_softdep_stub.o (3.4)
   1474	      0	      0	   1474	    5c2	ffs_subr.o
   1466	      0	      0	   1466	    5ba	ffs_subr.o (3.4)
      0	    620	      0	    620	    26c	ffs_tables.o
      0	    620	      0	    620	    26c	ffs_tables.o (3.4)
   7859	    208	      4	   8071	   1f87	ffs_vfsops.o
   7802	    216	      4	   8022	   1f56	ffs_vfsops.o (3.4)
   5031	    264	      0	   5295	   14af	ffs_vnops.o
   5774	    288	      0	   6062	   17ae	ffs_vnops.o (3.4)
   1805	    288	      0	   2093	    82d	fifo_vnops.o
   1801	    304	      0	   2105	    839	fifo_vnops.o (3.4)
      0	    432	      0	    432	    1b0	genassym.o
   4862	      0	      0	   4862	   12fe	genassym.o (3.4)
      0	      0	      0	      0	      0	globals.o
      0	      0	      0	      0	      0	globals.o (3.4)
   2318	    220	      4	   2542	    9ee	gusc.o
   2416	      0	    800	   3216	    c90	i386-gdbstub.o
   2364	      0	    800	   3164	    c5c	i386-gdbstub.o (3.4)
   3860	     92	     16	   3968	    f80	i686_mem.o
   3860	     96	     16	   3972	    f84	i686_mem.o (3.4)
  10418	     84	      8	  10510	   290e	ide_pci.o (3.4)
   7131	    224	    132	   7487	   1d3f	identcpu.o
   6986	    208	    132	   7326	   1c9e	identcpu.o (3.4)
   5812	    284	      4	   6100	   17d4	if.o
   4992	    284	      4	   5280	   14a0	if.o (3.4)
   4261	    396	     16	   4673	   1241	if_ether.o
   4055	    356	     16	   4427	   114b	if_ether.o (3.4)
   2573	     48	      0	   2621	    a3d	if_ethersubr.o
   2141	     44	      0	   2185	    889	if_ethersubr.o (3.4)
   9422	    160	      4	   9586	   2572	if_fxp.o
   7558	     60	      4	   7622	   1dc6	if_fxp.o (3.4)
   1813	     32	      0	   1845	    735	if_loop.o
   1259	     40	      0	   1299	    513	if_loop.o (3.4)
    899	      0	      0	    899	    383	if_media.o
    839	      0	      0	    839	    347	if_media.o (3.4)
    576	    120	      0	    696	    2b8	if_mib.o
    584	    104	      0	    688	    2b0	if_mib.o (3.4)
   8148	     64	      0	   8212	   2014	if_ppp.o
   5025	    216	      0	   5241	   1479	if_tun.o
   4016	    152	    236	   4404	   1134	if_tun.o (3.4)
   1852	    124	     76	   2052	    804	igmp.o
   1732	    120	     76	   1928	    788	igmp.o (3.4)
   1212	    100	      0	   1312	    520	imgact_aout.o
   1148	    100	      0	   1248	    4e0	imgact_aout.o (3.4)
   5144	    252	      0	   5396	   1514	imgact_elf.o
   5008	    184	      0	   5192	   1448	imgact_elf.o (3.4)
    968	     40	      0	   1008	    3f0	imgact_linux.o
    976	     40	      0	   1016	    3f8	imgact_linux.o (3.4)
    372	     40	      0	    412	    19c	imgact_shell.o
    376	     40	      0	    416	    1a0	imgact_shell.o (3.4)
   3823	    128	      4	   3955	    f73	in.o
   2846	    124	      4	   2974	    b9e	in.o (3.4)
   1051	      0	      0	   1051	    41b	in_cksum.o
   1049	      0	      0	   1049	    419	in_cksum.o (3.4)
   3740	    304	      0	   4044	    fcc	in_pcb.o
   3550	    252	      0	   3802	    eda	in_pcb.o (3.4)
     84	    812	     80	    976	    3d0	in_proto.o
    112	    768	     80	    960	    3c0	in_proto.o (3.4)
   1328	    140	      0	   1468	    5bc	in_rmx.o
   1324	    116	      0	   1440	    5a0	in_rmx.o (3.4)
     36	      0	      0	     36	     24	index.o
     28	      0	      0	     28	     1c	index.o (3.4)
     57	      0	     16	     73	     49	inet_ntoa.o
     57	      0	     16	     73	     49	inet_ntoa.o (3.4)
   2374	   1392	    636	   4402	   1132	init_main.o
   2554	   1416	    584	   4554	   11ca	init_main.o (3.4)
      0	   2896	      0	   2896	    b50	init_sysent.o
      0	   2704	      0	   2704	    a90	init_sysent.o (3.4)
    838	      4	      0	    842	    34a	initcpu.o
    838	      4	      0	    842	    34a	initcpu.o (3.4)
   2804	    192	    192	   3188	    c74	intr_machdep.o
   1525	    192	     96	   1813	    715	intr_machdep.o (3.4)
    363	      0	      0	    363	    16b	intrq.o
     91	    636	      0	    727	    2d7	ioconf.o
      0	   2032	      0	   2032	    7f0	ioconf.o (3.4)
    187	      0	      0	    187	     bb	ip_ecn.o
   1163	    128	    260	   1551	    60f	ip_flow.o
   1164	    124	    260	   1548	    60c	ip_flow.o (3.4)
   2809	    356	    192	   3357	    d1d	ip_icmp.o
   2861	    308	    192	   3361	    d21	ip_icmp.o (3.4)
   5752	    445	   1612	   7809	   1e81	ip_input.o
   5700	    341	   1612	   7653	   1de5	ip_input.o (3.4)
    233	     36	      0	    269	    10d	ip_mroute.o
    225	     36	      0	    261	    105	ip_mroute.o (3.4)
   6455	     84	      0	   6539	   198b	ip_output.o
   6219	     88	      0	   6307	   18a3	ip_output.o (3.4)
   1964	      0	      0	   1964	    7ac	ipl_funcs.o
   1930	      0	      0	   1930	    78a	ipl_funcs.o (3.4)
    343	      0	      0	    343	    157	isa.o
   4507	     36	     64	   4607	   11ff	isa.o (3.4)
   4375	    544	     12	   4931	   1343	isa_common.o
   1711	     28	      0	   1739	    6cb	isa_compat.o
   1758	     36	     64	   1858	    742	isa_dma.o
    216	     48	      0	    264	    108	isa_if.o
    832	    108	      4	    944	    3b0	isahint.o
   1354	    236	      0	   1590	    636	joy.o
   1062	    120	     56	   1238	    4d6	joy.o (3.4)
   5660	     40	      8	   5708	   164c	kbd.o
   4304	     36	      8	   4348	   10fc	kbd.o (3.4)
   1360	    136	      8	   1504	    5e0	kern_acct.o
   1320	    112	      8	   1440	    5a0	kern_acct.o (3.4)
   1392	     84	      0	   1476	    5c4	kern_acl.o
   3860	    400	     20	   4280	   10b8	kern_clock.o
   3524	    304	     20	   3848	    f08	kern_clock.o (3.4)
   1732	    124	   5172	   7028	   1b74	kern_conf.o
    677	      8	      0	    685	    2ad	kern_conf.o (3.4)
   5826	    512	      4	   6342	   18c6	kern_descrip.o
   5682	    496	      4	   6182	   1826	kern_descrip.o (3.4)
    400	     40	      0	    440	    1b8	kern_environment.o
    404	     36	      0	    440	    1b8	kern_environment.o (3.4)
   3752	    260	      4	   4016	    fb0	kern_exec.o
   3400	     72	      4	   3476	    d94	kern_exec.o (3.4)
   2882	    176	      0	   3058	    bf2	kern_exit.o
   2643	     88	      4	   2735	    aaf	kern_exit.o (3.4)
   2421	    192	      0	   2613	    a35	kern_fork.o
   2187	     48	      4	   2239	    8bf	kern_fork.o (3.4)
    604	      0	     64	    668	    29c	kern_intr.o
   1877	      0	    160	   2037	    7f5	kern_intr.o (3.4)
    518	    168	      0	    686	    2ae	kern_jail.o
    487	      0	      0	    487	    1e7	kern_kthread.o
   2431	     84	      0	   2515	    9d3	kern_ktrace.o
   2371	     88	      0	   2459	    99b	kern_ktrace.o (3.4)
   5122	   1192	     48	   6362	   18da	kern_linker.o
   5066	   1200	     48	   6314	   18aa	kern_linker.o (3.4)
   2186	      0	      0	   2186	    88a	kern_lock.o
   2098	      0	      0	   2098	    832	kern_lock.o (3.4)
   2761	     94	      0	   2855	    b27	kern_lockf.o
   2750	     98	      0	   2848	    b20	kern_lockf.o (3.4)
   2829	    592	    736	   4157	   103d	kern_malloc.o
   2711	    444	    660	   3815	    ee7	kern_malloc.o (3.4)
   1046	   3276	      0	   4322	   10e2	kern_mib.o
    930	   2708	      0	   3638	    e36	kern_mib.o (3.4)
   1540	     24	      8	   1572	    624	kern_module.o
   1256	     28	      8	   1292	    50c	kern_module.o (3.4)
   2428	    120	     36	   2584	    a18	kern_ntptime.o
   2376	    112	     28	   2516	    9d4	kern_ntptime.o (3.4)
    692	      0	      0	    692	    2b4	kern_physio.o
    853	      0	      0	    853	    355	kern_physio.o (3.4)
   3650	    660	      8	   4318	   10de	kern_proc.o
   2999	    604	      8	   3611	    e1b	kern_proc.o (3.4)
   3087	     84	      0	   3171	    c63	kern_prot.o
   2174	     88	      0	   2262	    8d6	kern_prot.o (3.4)
   3988	      0	      0	   3988	    f94	kern_resource.o
   3099	      0	      0	   3099	    c1b	kern_resource.o (3.4)
   3167	    304	    524	   3995	    f9b	kern_shutdown.o
   2332	    104	    508	   2944	    b80	kern_shutdown.o (3.4)
   8372	   1280	      0	   9652	   25b4	kern_sig.o
   6064	   1260	      0	   7324	   1c9c	kern_sig.o (3.4)
   1321	    108	      0	   1429	    595	kern_subr.o
   1562	    108	      0	   1670	    686	kern_subr.o (3.4)
   1018	     20	      0	   1038	    40e	kern_switch.o
   4186	    148	   1024	   5358	   14ee	kern_synch.o
   3485	    152	   1024	   4661	   1235	kern_synch.o (3.4)
    403	      0	      0	    403	    193	kern_syscalls.o
    353	      0	      0	    353	    161	kern_syscalls.o (3.4)
   4568	    304	    184	   5056	   13c0	kern_sysctl.o
   4732	    284	    184	   5200	   1450	kern_sysctl.o (3.4)
    431	      0	      0	    431	    1af	kern_threads.o
    425	      0	      0	    425	    1a9	kern_threads.o (3.4)
   2688	      8	     20	   2716	    a9c	kern_time.o
   2724	      8	     20	   2752	    ac0	kern_time.o (3.4)
    760	      0	      4	    764	    2fc	kern_timeout.o
    764	      0	      4	    768	    300	kern_timeout.o (3.4)
    740	      0	      0	    740	    2e4	kern_xxx.o
    768	      0	      0	    768	    300	kern_xxx.o (3.4)
    603	      0	      0	    603	    25b	ksched.o
    591	      0	      0	    591	    24f	ksched.o (3.4)
   2555	     56	      0	   2611	    a33	link_aout.o
   2539	     60	      0	   2599	    a27	link_aout.o (3.4)
   4724	     56	      0	   4780	   12ac	link_elf.o
   4708	     60	      0	   4768	   12a0	link_elf.o (3.4)
   1826	      0	      0	   1826	    722	linux_dummy.o
   2261	      0	      0	   2261	    8d5	linux_dummy.o (3.4)
   4954	      0	      0	   4954	   135a	linux_file.o
   4982	      0	      0	   4982	   1376	linux_file.o (3.4)
      0	     16	      0	     16	     10	linux_genassym.o
   7638	    272	      0	   7910	   1ee6	linux_ioctl.o
   6673	    168	      0	   6841	   1ab9	linux_ioctl.o (3.4)
   2160	      0	      0	   2160	    870	linux_ipc.o
   2160	      0	      0	   2160	    870	linux_ipc.o (3.4)
     24	      4	      0	     28	     1c	linux_locore.o
     28	      4	      0	     32	     20	linux_locore.o (3.4)
    661	    300	      0	    961	    3c1	linux_mib.o
   5837	     40	      0	   5877	   16f5	linux_misc.o
   5117	     40	      0	   5157	   1425	linux_misc.o (3.4)
   2390	      0	      0	   2390	    956	linux_signal.o
   1838	      0	      0	   1838	    72e	linux_signal.o (3.4)
   3120	      0	      0	   3120	    c30	linux_socket.o
   3064	      0	      0	   3064	    bf8	linux_socket.o (3.4)
   1501	      0	      0	   1501	    5dd	linux_stats.o
   1316	      0	      0	   1316	    524	linux_stats.o (3.4)
      0	   1584	      0	   1584	    630	linux_sysent.o
      0	   1528	      0	   1528	    5f8	linux_sysent.o (3.4)
   1952	    876	      0	   2828	    b0c	linux_sysvec.o
   1784	    808	      0	   2592	    a20	linux_sysvec.o (3.4)
    855	      0	      0	    855	    357	linux_util.o
    794	      0	      0	    794	    31a	linux_util.o (3.4)
   1847	   8372	      0	  10219	   27eb	locore.o
   1902	   8368	      0	  10270	   281e	locore.o (3.4)
   3515	    192	      4	   3711	    e7f	lpt.o
   3022	    144	     32	   3198	    c7e	lpt.o (3.4)
  11192	    800	   6268	  18260	   4754	machdep.o
   7604	    692	   4220	  12516	   30e4	machdep.o (3.4)
   2122	     64	      0	   2186	    88a	md5c.o
   2122	     64	      0	   2186	    88a	md5c.o (3.4)
   2642	    160	    200	   3002	    bba	mem.o
   2348	    188	    204	   2740	    ab4	mem.o (3.4)
   1260	    268	      4	   1532	    5fc	mfs_vfsops.o
   1083	    220	     12	   1315	    523	mfs_vfsops.o (3.4)
   1484	    184	      0	   1668	    684	mfs_vnops.o
   1110	    192	      0	   1302	    516	mfs_vnops.o (3.4)
    899	     50	      0	    949	    3b5	mixer.o
    124	      0	      0	    124	     7c	moddi3.o
    124	      0	      0	    124	     7c	moddi3.o (3.4)
    387	    284	      8	    679	    2a7	mp_clock.o
  10682	    696	    568	  11946	   2eaa	mp_machdep.o
  10757	    640	    564	  11961	   2eb9	mp_machdep.o (3.4)
   1792	      4	      0	   1796	    704	mpapic.o
   1797	      4	      0	   1801	    709	mpapic.o (3.4)
    159	    418	      0	    577	    241	mpboot.o
    121	    418	      0	    539	    21b	mpboot.o (3.4)
    446	      8	      0	    454	    1c6	mplock.o
    481	      8	      0	    489	    1e9	mplock.o (3.4)
   9238	   1560	      4	  10802	   2a32	mss.o
  18930	   9352	     84	  28366	   6ece	ncr.o
  18915	   9276	     84	  28275	   6e73	ncr.o (3.4)
   3566	  50968	      4	  54538	   d50a	neomagic.o
     43	      0	     26	     69	     45	net_osdep.o
   1573	    220	    148	   1941	    795	nexus.o
  10408	      0	      0	  10408	   28a8	nfs_bio.o
   9473	      0	      0	   9473	   2501	nfs_bio.o (3.4)
   1459	      0	     16	   1475	    5c3	nfs_node.o
   1435	      0	     16	   1451	    5ab	nfs_node.o (3.4)
  10726	    208	      0	  10934	   2ab6	nfs_nqlease.o
  10330	    212	      0	  10542	   292e	nfs_nqlease.o (3.4)
  86391	    208	   1292	  87891	  15753	nfs_serv.o
  80771	    120	      4	  80895	  13bff	nfs_serv.o (3.4)
  14183	    328	      8	  14519	   38b7	nfs_socket.o
  13371	    248	      0	  13619	   3533	nfs_socket.o (3.4)
   1369	    212	     20	   1601	    641	nfs_srvcache.o
   1369	    212	     20	   1601	    641	nfs_srvcache.o (3.4)
  13262	    924	     16	  14202	   377a	nfs_subs.o
  12113	    920	     24	  13057	   3301	nfs_subs.o (3.4)
   7089	    272	   3156	  10517	   2915	nfs_syscalls.o
   7215	    244	   3156	  10615	   2977	nfs_syscalls.o (3.4)
   7815	   2816	      0	  10631	   2987	nfs_vfsops.o
   7499	   2848	      0	  10347	   286b	nfs_vfsops.o (3.4)
  74606	    716	      4	  75326	  1263e	nfs_vnops.o
  69446	    760	     12	  70218	  1124a	nfs_vnops.o (3.4)
   1694	    316	     12	   2022	    7e6	npx.o
   1258	     48	      3	   1309	    51d	npx.o (3.4)
    710	    104	      4	    818	    332	p1003_1b.o
    710	    112	      4	    826	    33a	p1003_1b.o (3.4)
      0	    132	      0	    132	     84	param.o
      0	    140	      0	    140	     8c	param.o (3.4)
   6465	    396	     16	   6877	   1add	pci.o
   4311	    124	      0	   4435	   1153	pci.o (3.4)
   1136	      0	      0	   1136	    470	pci_compat.o
   1863	     12	      8	   1883	    75b	pci_compat.o (3.4)
    146	     32	      0	    178	     b2	pci_if.o
   3965	    196	     16	   4177	   1051	pcibus.o
   1576	      0	      4	   1580	    62c	pcibus.o (3.4)
  23923	    600	     16	  24539	   5fdb	pcisupport.o
  15245	     92	     16	  15353	   3bf9	pcisupport.o (3.4)
  14142	     68	    288	  14498	   38a2	pmap.o
  12052	     68	    316	  12436	   3094	pmap.o (3.4)
   2995	    140	     16	   3151	    c4f	pnp.o
   4511	   1800	     20	   6331	   18bb	pnp.o (3.4)
   3473	      0	      0	   3473	    d91	pnpparse.o
    502	   1000	    100	   1602	    642	posix4_mib.o
    502	    800	    100	   1402	    57a	posix4_mib.o (3.4)
   3075	      0	      0	   3075	    c03	ppb_1284.o
   2905	      0	      0	   2905	    b59	ppb_1284.o (3.4)
    629	      0	      0	    629	    275	ppb_base.o
    670	      0	      0	    670	    29e	ppb_base.o (3.4)
   1370	      0	      0	   1370	    55a	ppb_msq.o
   1309	      0	      0	   1309	    51d	ppb_msq.o (3.4)
   2655	    296	      4	   2955	    b8b	ppbconf.o
   2498	     68	      0	   2566	    a06	ppbconf.o (3.4)
    471	    112	      0	    583	    247	ppbus_if.o
   5556	    396	      0	   5952	   1740	ppc.o
   9374	    634	      4	  10012	   271c	ppc.o (3.4)
    999	    172	      4	   1175	    497	ppi.o
    970	    124	     32	   1126	    466	ppi.o (3.4)
   5981	    580	      0	   6561	   19a1	ppp_tty.o
    951	    312	      0	   1263	    4ef	procfs_ctl.o
    951	    312	      0	   1263	    4ef	procfs_ctl.o (3.4)
    227	      0	      0	    227	     e3	procfs_dbregs.o
    243	      0	      0	    243	     f3	procfs_fpregs.o
    291	      0	      0	    291	    123	procfs_fpregs.o (3.4)
    219	      0	      0	    219	     db	procfs_machdep.o
    155	      0	      0	    155	     9b	procfs_machdep.o (3.4)
    903	      0	      0	    903	    387	procfs_map.o
    805	      0	      0	    805	    325	procfs_map.o (3.4)
    863	      0	      0	    863	    35f	procfs_mem.o
   1033	      0	      0	   1033	    409	procfs_mem.o (3.4)
     58	      0	      0	     58	     3a	procfs_note.o
     58	      0	      0	     58	     3a	procfs_note.o (3.4)
    227	      0	      0	    227	     e3	procfs_regs.o
    275	      0	      0	    275	    113	procfs_regs.o (3.4)
    387	     40	      0	    427	    1ab	procfs_rlimit.o
   1218	      0	      0	   1218	    4c2	procfs_status.o
   1051	      0	      0	   1051	    41b	procfs_status.o (3.4)
   1354	      0	      8	   1362	    552	procfs_subr.o
   1306	      0	      8	   1314	    522	procfs_subr.o (3.4)
    237	      0	      0	    237	     ed	procfs_type.o
    237	      0	      0	    237	     ed	procfs_type.o (3.4)
    524	    124	      0	    648	    288	procfs_vfsops.o
    575	    128	      0	    703	    2bf	procfs_vfsops.o (3.4)
   3743	    488	      4	   4235	   108b	procfs_vnops.o
   3599	    488	      0	   4087	    ff7	procfs_vnops.o (3.4)
  10259	    480	      0	  10739	   29f3	psm.o
  10014	    428	      4	  10446	   28ce	psm.o (3.4)
   1252	      4	      0	   1256	    4e8	qdivrem.o
   1252	      4	      0	   1256	    4e8	qdivrem.o (3.4)
   1988	      0	      0	   1988	    7c4	qsort.o
   1988	      0	      0	   1988	    7c4	qsort.o (3.4)
   4751	     16	     24	   4791	   12b7	radix.o
   4751	     16	     24	   4791	   12b7	radix.o (3.4)
    103	      4	      0	    107	     6b	random.o
    103	      4	      0	    107	     6b	random.o (3.4)
   2317	      0	    852	   3169	    c61	random_machdep.o
   2317	      0	    852	   3169	    c61	random_machdep.o (3.4)
    199	      8	      0	    207	     cf	raw_cb.o
    199	      8	      0	    207	     cf	raw_cb.o (3.4)
   2926	    224	      0	   3150	    c4e	raw_ip.o
   2674	    200	     48	   2922	    b6a	raw_ip.o (3.4)
    826	     80	      0	    906	    38a	raw_usrreq.o
    838	     80	      0	    918	    396	raw_usrreq.o (3.4)
     39	      0	      0	     39	     27	rindex.o
     39	      0	      0	     39	     27	rindex.o (3.4)
   3767	     20	     16	   3803	    edb	route.o
   3676	      0	     16	   3692	    e6c	route.o (3.4)
   4821	    372	      0	   5193	   1449	rtsock.o
   4785	    356	      0	   5141	   1415	rtsock.o (3.4)
   5556	   1656	      4	   7216	   1c30	sb.o
   7247	   1052	      0	   8299	   206b	sb_dsp.o (3.4)
   3185	    376	      4	   3565	    ded	sbc.o
     52	      0	      0	     52	     34	scanc.o
     52	      0	      0	     52	     34	scanc.o (3.4)
   1243	      4	      0	   1247	    4df	schistory.o
   4757	     16	      8	   4781	   12ad	scmouse.o
  18207	   5280	      0	  23487	   5bbf	scsi_all.o
  18199	   5272	      0	  23471	   5baf	scsi_all.o (3.4)
  12776	    348	     72	  13196	   338c	scsi_cd.o
  13092	    340	     16	  13448	   3488	scsi_cd.o (3.4)
   6889	    200	     64	   7153	   1bf1	scsi_da.o
   7432	    224	      8	   7664	   1df0	scsi_da.o (3.4)
   2816	     80	      4	   2900	    b54	scsi_pass.o
   2871	    100	      4	   2975	    b9f	scsi_pass.o (3.4)
  16501	    532	      4	  17037	   428d	scsi_sa.o
      0	      0	      0	      0	      0	scterm-dumb.o
   6256	    116	     72	   6444	   192c	scterm-sc.o
    401	      4	      0	    405	    195	scterm.o
      0	      0	      0	      0	      0	scvesactl.o (3.4)
   1777	    356	      8	   2141	    85d	scvgarndr.o
   3393	      4	      0	   3397	    d45	scvidctl.o
   3097	      0	      0	   3097	    c19	scvidctl.o (3.4)
   1403	      0	      0	   1403	    57b	scvtb.o
      0	     52	      0	     52	     34	setdef0.o
      0	    272	      0	    272	    110	setdef0.o (3.4)
      0	     52	      0	     52	     34	setdef1.o
      0	    272	      0	    272	    110	setdef1.o (3.4)
    347	      0	      0	    347	    15b	simplelock.o
    327	      0	      0	    327	    147	simplelock.o (3.4)
  12025	    892	     36	  12953	   3299	sio.o
  10683	    444	   3000	  14127	   372f	sio.o (3.4)
     35	      0	      0	     35	     23	skpc.o
     35	      0	      0	     35	     23	skpc.o (3.4)
   2539	      0	      0	   2539	    9eb	slcompress.o
   2756	     68	   4100	   6924	   1b0c	sound.o
   7600	    168	   4000	  11768	   2df8	sound.o (3.4)
   3557	    304	      0	   3861	    f15	spec_vnops.o
   4344	    328	      0	   4672	   1240	spec_vnops.o (3.4)
     45	      0	      0	     45	     2d	strcat.o
     45	      0	      0	     45	     2d	strcat.o (3.4)
     44	      0	      0	     44	     2c	strcmp.o
     44	      0	      0	     44	     2c	strcmp.o (3.4)
     37	      0	      0	     37	     25	strcpy.o
     37	      0	      0	     37	     25	strcpy.o (3.4)
     26	      0	      0	     26	     1a	strlen.o
     26	      0	      0	     26	     1a	strlen.o (3.4)
     58	      0	      0	     58	     3a	strncmp.o
     58	      0	      0	     58	     3a	strncmp.o (3.4)
     60	      0	      0	     60	     3c	strncpy.o
     60	      0	      0	     60	     3c	strncpy.o (3.4)
    370	      0	      0	    370	    172	strtol.o
    370	      0	      0	    370	    172	strtol.o (3.4)
    602	      0	      0	    602	    25a	strtoq.o
    602	      0	      0	    602	    25a	strtoq.o (3.4)
    350	      0	      0	    350	    15e	strtoul.o
    350	      0	      0	    350	    15e	strtoul.o (3.4)
    542	      0	      0	    542	    21e	strtouq.o
    542	      0	      0	    542	    21e	strtouq.o (3.4)
    405	     28	      0	    433	    1b1	subr_autoconf.o
    401	     32	      0	    433	    1b1	subr_autoconf.o (3.4)
   2105	     84	      0	   2189	    88d	subr_blist.o
  10143	    248	      0	  10391	   2897	subr_bus.o
   5867	    160	      0	   6027	   178b	subr_bus.o (3.4)
   1110	    204	     20	   1334	    536	subr_devstat.o
   1006	    168	     12	   1186	    4a2	subr_devstat.o (3.4)
   1393	    204	      0	   1597	    63d	subr_disk.o
   3364	     64	     33	   3461	    d85	subr_diskmbr.o
   5730	      0	     33	   5763	   1683	subr_diskslice.o
   6009	      0	     33	   6042	   179a	subr_diskslice.o (3.4)
    486	      0	      0	    486	    1e6	subr_dkbad.o (3.4)
    519	     88	      8	    615	    267	subr_eventhandler.o
    799	     76	     16	    891	    37b	subr_log.o
    818	    100	     20	    938	    3aa	subr_log.o (3.4)
    540	      0	      0	    540	    21c	subr_module.o
    540	      0	      0	    540	    21c	subr_module.o (3.4)
   4961	     16	      4	   4981	   1375	subr_prf.o
   4009	     12	      4	   4025	    fb9	subr_prf.o (3.4)
    392	      0	      0	    392	    188	subr_prof.o
    392	      0	      0	    392	    188	subr_prof.o (3.4)
   1113	      4	      4	   1121	    461	subr_rlist.o (3.4)
   2492	     84	      8	   2584	    a18	subr_rman.o
   2379	     88	      8	   2475	    9ab	subr_rman.o (3.4)
   2836	     34	      0	   2870	    b36	subr_scanf.o
   2896	     34	      0	   2930	    b72	subr_scanf.o (3.4)
    131	      0	      0	    131	     83	subr_xxx.o
    193	      0	      0	    193	     c1	subr_xxx.o (3.4)
   2465	     28	      0	   2493	    9bd	support.o
   2383	     24	      0	   2407	    967	support.o (3.4)
   6911	     84	    104	   7099	   1bbb	swap_pager.o
   8367	     44	   2624	  11035	   2b1b	swap_pager.o (3.4)
      5	      8	      0	     13	      d	swapkernel.o (3.4)
    802	      8	      0	    810	    32a	swtch.o
   1463	     20	      0	   1483	    5cb	swtch.o (3.4)
   5144	    304	      4	   5452	   154c	sys_generic.o
   4876	    276	      4	   5156	   1424	sys_generic.o (3.4)
    741	      0	      0	    741	    2e5	sys_machdep.o
   1683	      0	      0	   1683	    693	sys_machdep.o (3.4)
   5491	     24	     12	   5527	   1597	sys_pipe.o
   5088	     20	     12	   5120	   1400	sys_pipe.o (3.4)
   1993	      0	      0	   1993	    7c9	sys_process.o
   1763	      0	      0	   1763	    6e3	sys_process.o (3.4)
    558	     24	      0	    582	    246	sys_socket.o
    547	     20	      0	    567	    237	sys_socket.o (3.4)
  17749	    296	  14332	  32377	   7e79	syscons.o
  29322	    352	   8932	  38606	   96ce	syscons.o (3.4)
    758	    116	   1380	   2254	    8ce	syscons_isa.o
     64	     16	      0	     80	     50	syscons_isa.o (3.4)
   1602	    108	     32	   1742	    6ce	sysmouse.o
    139	      0	      0	    139	     8b	sysv_ipc.o
    127	      0	      0	    127	     7f	sysv_ipc.o (3.4)
   3923	     36	     12	   3971	    f83	sysv_msg.o
   3959	     40	     12	   4011	    fab	sysv_msg.o (3.4)
   4385	     44	      4	   4433	   1151	sysv_sem.o
   4393	     48	      4	   4445	   115d	sysv_sem.o (3.4)
   2707	    124	     12	   2843	    b1b	sysv_shm.o
   2587	    132	     12	   2731	    aab	sysv_shm.o (3.4)
   4238	    380	      4	   4622	   120e	t4dwave.o
   8980	    260	      0	   9240	   2418	tcp_input.o
   7841	    108	      0	   7949	   1f0d	tcp_input.o (3.4)
   3162	    144	      0	   3306	    cea	tcp_output.o
   2953	     11	      0	   2964	    b94	tcp_output.o (3.4)
   3701	    340	      0	   4041	    fc9	tcp_subr.o
   3257	    240	      0	   3497	    da9	tcp_subr.o (3.4)
   1293	    304	      0	   1597	    63d	tcp_timer.o
    965	    208	      0	   1173	    495	tcp_timer.o (3.4)
   2868	    168	      0	   3036	    bdc	tcp_usrreq.o
   2793	    152	      0	   2945	    b81	tcp_usrreq.o (3.4)
   6227	    116	      0	   6343	   18c7	trap.o
   5513	    116	      0	   5629	   15fd	trap.o (3.4)
  12471	    144	      4	  12619	   314b	tty.o
  12107	    108	      0	  12215	   2fb7	tty.o (3.4)
   2218	    268	      0	   2486	    9b6	tty_compat.o
   2218	    260	      0	   2478	    9ae	tty_compat.o (3.4)
    254	    364	      0	    618	    26a	tty_conf.o
    258	    328	      0	    586	    24a	tty_conf.o (3.4)
   1584	    204	     44	   1832	    728	tty_cons.o
   3600	    216	      0	   3816	    ee8	tty_pty.o
   3558	    180	  17156	  20894	   519e	tty_pty.o (3.4)
   3016	     32	      8	   3056	    bf0	tty_subr.o
   3028	     36	      8	   3072	    c00	tty_subr.o (3.4)
    799	     76	      0	    875	    36b	tty_tty.o
    814	    100	      4	    918	    396	tty_tty.o (3.4)
     28	      0	      0	     28	     1c	udivdi3.o
     28	      0	      0	     28	     1c	udivdi3.o (3.4)
   3675	    436	      0	   4111	   100f	udp_usrreq.o
   3399	    336	     48	   3783	    ec7	udp_usrreq.o (3.4)
   1295	      0	      0	   1295	    50f	ufs_bmap.o
   1435	      0	      0	   1435	    59b	ufs_bmap.o (3.4)
   1645	      0	      0	   1645	    66d	ufs_disksubr.o
   1576	      0	      0	   1576	    628	ufs_disksubr.o (3.4)
    488	     84	     12	    584	    248	ufs_ihash.o
    479	     88	     12	    579	    243	ufs_ihash.o (3.4)
    483	      4	      0	    487	    1e7	ufs_inode.o
    483	      4	      0	    487	    1e7	ufs_inode.o (3.4)
   5796	     44	      0	   5840	   16d0	ufs_lookup.o
   5696	      4	      0	   5700	   1644	ufs_lookup.o (3.4)
   4724	    100	     20	   4844	   12ec	ufs_quota.o
   4700	    104	     20	   4824	   12d8	ufs_quota.o (3.4)
    300	     84	      4	    388	    184	ufs_vfsops.o
    291	     88	      4	    383	    17f	ufs_vfsops.o (3.4)
  11067	    720	     12	  11799	   2e17	ufs_vnops.o
  11315	    752	     12	  12079	   2f2f	ufs_vnops.o (3.4)
    799	     20	      0	    819	    333	uipc_domain.o
    959	     72	      4	   1035	    40b	uipc_domain.o (3.4)
   8397	    388	      0	   8785	   2251	uipc_mbuf.o
   6205	    184	      0	   6389	   18f5	uipc_mbuf.o (3.4)
     44	    340	      0	    384	    180	uipc_proto.o
     48	    308	      0	    356	    164	uipc_proto.o (3.4)
   9111	    212	      0	   9323	   246b	uipc_socket.o
   7123	    212	      0	   7335	   1ca7	uipc_socket.o (3.4)
   4767	    228	     24	   5019	   139b	uipc_socket2.o
   4163	    204	     24	   4391	   1127	uipc_socket2.o (3.4)
   8986	     20	     16	   9022	   233e	uipc_syscalls.o
   8493	     24	     16	   8533	   2155	uipc_syscalls.o (3.4)
   6025	    392	     40	   6457	   1939	uipc_usrreq.o
   5305	    336	     36	   5677	   162d	uipc_usrreq.o (3.4)
     39	      0	      0	     39	     27	umoddi3.o
     39	      0	      0	     39	     27	umoddi3.o (3.4)
      0	    180	      0	    180	     b4	vers.o
      0	    147	      0	    147	     93	vers.o (3.4)
      0	      0	      0	      0	      0	vesa.o (3.4)
   7462	    560	     52	   8074	   1f8a	vfs_aio.o
   8788	    476	     52	   9316	   2464	vfs_aio.o (3.4)
  17960	    860	    100	  18920	   49e8	vfs_bio.o
  14361	    564	   2104	  17029	   4285	vfs_bio.o (3.4)
   2921	   1172	     96	   4189	   105d	vfs_cache.o
   2322	    688	     68	   3078	    c06	vfs_cache.o (3.4)
   5391	    128	      0	   5519	   158f	vfs_cluster.o
   4805	     88	      0	   4893	   131d	vfs_cluster.o (3.4)
   2130	    128	      0	   2258	    8d2	vfs_conf.o
    511	    120	      0	    631	    277	vfs_conf.o (3.4)
   1152	    240	      0	   1392	    570	vfs_default.o
    979	    216	      0	   1195	    4ab	vfs_default.o (3.4)
   2392	    104	     24	   2520	    9d8	vfs_init.o
   2576	    176	     28	   2780	    adc	vfs_init.o (3.4)
   3242	      0	      0	   3242	    caa	vfs_lookup.o
   3170	      0	      0	   3170	    c62	vfs_lookup.o (3.4)
  14578	   1036	     80	  15694	   3d4e	vfs_subr.o
  13286	    592	     60	  13938	   3672	vfs_subr.o (3.4)
  20224	     88	      4	  20316	   4f5c	vfs_syscalls.o
  17573	    260	     28	  17861	   45c5	vfs_syscalls.o (3.4)
   3511	     24	      0	   3535	    dcf	vfs_vnops.o
   3219	     20	      0	   3239	    ca7	vfs_vnops.o (3.4)
  10390	   7468	    756	  18614	   48b6	vga.o
    357	    116	      4	    477	    1dd	vga_isa.o
   7542	   3228	    528	  11298	   2c22	vga_isa.o (3.4)
   3392	      0	      0	   3392	    d40	vm86.o
   3872	      0	      0	   3872	    f20	vm86.o (3.4)
   4888	      0	      0	   4888	   1318	vm_fault.o
   4187	      0	      0	   4187	   105b	vm_fault.o (3.4)
   1881	    128	      0	   2009	    7d9	vm_glue.o
   1622	    120	      0	   1742	    6ce	vm_glue.o (3.4)
    223	     20	      0	    243	     f3	vm_init.o
    127	     24	      0	    151	     97	vm_init.o (3.4)
   2442	     28	      0	   2470	    9a6	vm_kern.o
   2125	     40	      0	   2165	    875	vm_kern.o (3.4)
   2708	     40	     20	   2768	    ad0	vm_machdep.o
   2608	     32	     16	   2656	    a60	vm_machdep.o (3.4)
  13961	     24	  13880	  27865	   6cd9	vm_map.o
  14959	     24	  11836	  26819	   68c3	vm_map.o (3.4)
   1575	   2232	      0	   3807	    edf	vm_meter.o
   1465	   1776	      0	   3241	    ca9	vm_meter.o (3.4)
   3976	     60	      4	   4040	    fc8	vm_mmap.o
   3562	      0	      0	   3562	    dea	vm_mmap.o (3.4)
   8256	     12	  24864	  33132	   816c	vm_object.o
   8103	     12	  32088	  40203	   9d0b	vm_object.o (3.4)
   8545	     24	     20	   8589	   218d	vm_page.o
   8987	   4734	     28	  13749	   35b5	vm_page.o (3.4)
   5935	    532	     16	   6483	   1953	vm_pageout.o
   5807	    460	     16	   6283	   188b	vm_pageout.o (3.4)
   2183	    148	      8	   2339	    923	vm_pager.o
   1293	    144	      8	   1445	    5a5	vm_pager.o (3.4)
   1195	     80	     84	   1359	    54f	vm_swap.o
   1186	    116	     64	   1366	    556	vm_swap.o (3.4)
    222	      0	      0	    222	     de	vm_unix.o
    230	      0	      0	    230	     e6	vm_unix.o (3.4)
   2120	    244	     16	   2380	    94c	vm_zone.o
   2008	    216	     16	   2240	    8c0	vm_zone.o (3.4)
   4166	     88	      8	   4262	   10a6	vn.o
   4274	    104	     36	   4414	   113e	vn.o (3.4)
    547	   2128	      0	   2675	    a73	vnode_if.o
    494	   1948	      0	   2442	    98a	vnode_if.o (3.4)
   5600	     36	      0	   5636	   1604	vnode_pager.o
   5357	     28	      0	   5385	   1509	vnode_pager.o (3.4)
  11633	    128	    180	  11941	   2ea5	wd.o (3.4)
      0	      0	      0	      0	      0	wdc_p.o (3.4)


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sun Mar 19 13:35:19 2000
Delivered-To: freebsd-current@freebsd.org
Received: from news.IAEhv.nl (news.IAE.nl [194.151.64.4])
	by hub.freebsd.org (Postfix) with ESMTP id E355B37B790
	for <current@FreeBSD.ORG>; Sun, 19 Mar 2000 13:35:15 -0800 (PST)
	(envelope-from marc@bowtie.nl)
Received: (from uucp@localhost)
	by news.IAEhv.nl (8.9.1/8.9.1) with IAEhv.nl id WAA13118;
	Sun, 19 Mar 2000 22:35:07 +0100 (MET)
Received: (from marc@localhost)
	by bowtie.nl (8.8.8/8.8.8) id WAA04741;
	Sun, 19 Mar 2000 22:33:10 +0100 (CET)
	(envelope-from marc)
Message-ID: <20000319223310.42913@nietzsche.intra.bowtie.nl>
Date: Sun, 19 Mar 2000 22:33:10 +0100
From: Marc van Kempen <marc@bowtie.nl>
To: Idea Receiver <receiver@RedDust.BlueSky.net.au>
Cc: "Thierry.herbelot" <herbelot@cybercable.fr>, marc@bowtie.nl,
	current@FreeBSD.ORG
Subject: Re: install problem with 4.0 (spec_getpages)
References: <38D4E6F2.FCDB2141@cybercable.fr> <Pine.BSF.4.10.10003200154040.47791-100000@RedDust.BlueSky.net.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.69e
In-Reply-To: <Pine.BSF.4.10.10003200154040.47791-100000@RedDust.BlueSky.net.au>; from Idea Receiver on Mon, Mar 20, 2000 at 01:55:11AM +1000
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Mon, Mar 20, 2000 at 01:55:11AM +1000, Idea Receiver wrote:
> 
> 
> On Sun, 19 Mar 2000, Thierry.herbelot wrote:
> 
> > Marc van Kempen wrote:
> > > 
> > > Hi,
> > > 
> > > While trying to boot from the 4.0 installation disks,
> > > I get the following error after the devices have been probed:
> > > 
> > 
> > [SNIP]
> > 
> > >     root@localhost:/usr/src/sys/compile/SCHOPENHAUER
> > > Timecounter "i8254"  frequency 1193182 Hz
> > > CPU: Celeron (412.50-MHz 686-class CPU)
> > 
> > 412 MHz is a non-conventional speed for a Celly : if you are
> > overclocking (I'm doing it, too), does the bug repeats itself when at
> > the normal speed ?
> 
> yes it does.
> anyway.. problem fixed this afternoon (australia time :P)!
> 
???? What are you saying? That you have the same problem and that 
you managed to fix it?


-- 
----------------------------------------------------
Marc van Kempen                 BowTie Technology     
Email: marc@bowtie.nl            WWW & Databases
tel. +31 40 2 43 20 65         
fax. +31 40 2 44 21 86         http://www.bowtie.nl
----------------------------------------------------



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sun Mar 19 15: 2:48 2000
Delivered-To: freebsd-current@freebsd.org
Received: from norn.ca.eu.org (cr965240-b.abtsfd1.bc.wave.home.com [24.113.19.137])
	by hub.freebsd.org (Postfix) with ESMTP id B473F37B6B4
	for <current@FreeBSD.org>; Sun, 19 Mar 2000 15:02:43 -0800 (PST)
	(envelope-from cpiazza@norn.ca.eu.org)
Received: by norn.ca.eu.org (Postfix, from userid 1000)
	id 5087C199E; Sun, 19 Mar 2000 15:00:09 -0800 (PST)
Date: Sun, 19 Mar 2000 15:00:09 -0800
From: Chris Piazza <cpiazza@jaxon.net>
To: current@FreeBSD.org
Subject: 75 second delay using telnet/ssh (ipv6 related)
Message-ID: <20000319150009.A404@norn.ca.eu.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
X-Operating-System: FreeBSD 5.0-CURRENT i386
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Hi.

This is kind of weird, so I want to see if anyone else has noticed
this or has a solution to it.

If I use telnet or ssh (there might be more programs,
but I have only noticed these two so far), and supply a hostname to it,
my machine is constantly requesting AAAA records, and finally after
75 seconds it requests and receives an A record from the nameserver.

Using ssh -4 or telnet -4 makes it work right away (of course), but
I don't want to have to type that all the time. [program] ipv4address
also works.

Logs are attached..

norn[~]# tcpdump -n net 128.189.4.1
tcpdump: listening on ed0
14:50:33.016513 24.113.19.137.1112 > 128.189.4.1.53:  25863+ AAAA? freefall.free
bsd.org. (38)
14:50:33.574535 128.189.4.1.53 > 24.113.19.137.1112:  25863* 0/1/0 (112) (DF)
14:50:33.575014 24.113.19.137.1113 > 128.189.4.1.53:  25864+ AAAA? freefall.free
bsd.org.norn.ca.eu.org. (53)
14:50:38.576829 24.113.19.137.1114 > 128.189.4.1.53:  25864+ AAAA? freefall.free
bsd.org.norn.ca.eu.org. (53)
14:50:48.586848 24.113.19.137.1115 > 128.189.4.1.53:  25864+ AAAA? freefall.free
bsd.org.norn.ca.eu.org. (53)
14:51:08.596965 24.113.19.137.1116 > 128.189.4.1.53:  25864+ AAAA? freefall.free
bsd.org.norn.ca.eu.org. (53)  
14:51:48.617121 24.113.19.137.1117 > 128.189.4.1.53:  25865+ A? freefall.freebsd
.org. (38)
14:51:48.739460 128.189.4.1.53 > 24.113.19.137.1117:  25865* 1/7/7 A 204.216.27.
21 (339) (DF)   

% ssh -v freefall.freebsd.org
SSH Version OpenSSH-1.2.2, protocol version 1.5.
Compiled with SSL.
debug: Reading configuration data /home/cpiazza/.ssh/config
debug: Applying options for *
debug: Reading configuration data /etc/ssh/ssh_config
debug: Applying options for *
debug: ssh_connect: getuid 0 geteuid 0 anon 0
***PAUSE HAPPENS HERE***
debug: Connecting to freefall.freebsd.org [204.216.27.21] port 22.
debug: Allocated local port 1021.
debug: Connection established.
...etc

This happened about a month ago but it fixed itself after a few hours
so I thought it was a name server problem until it happened again today...
It happens with any nameserver I try.

Any ideas??

-Chris
-- 
cpiazza@jaxon.net   cpiazza@FreeBSD.org
        Abbotsford, BC, Canada


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sun Mar 19 16:32:11 2000
Delivered-To: freebsd-current@freebsd.org
Received: from RedDust.BlueSky.net.au (reddust.bluesky.net.au [203.31.37.15])
	by hub.freebsd.org (Postfix) with ESMTP id B1C1B37B6DC
	for <current@FreeBSD.org>; Sun, 19 Mar 2000 16:32:06 -0800 (PST)
	(envelope-from receiver@RedDust.BlueSky.net.au)
Received: from localhost (receiver@localhost)
	by RedDust.BlueSky.net.au (8.9.3/8.9.3) with ESMTP id KAA48421
	for <current@FreeBSD.org>; Mon, 20 Mar 2000 10:33:02 +1000 (EST)
	(envelope-from receiver@RedDust.BlueSky.net.au)
Date: Mon, 20 Mar 2000 10:33:02 +1000 (EST)
From: Idea Receiver <receiver@RedDust.BlueSky.net.au>
To: current@FreeBSD.org
Subject: Re: install problem with 4.0 (spec_getpages)
In-Reply-To: <20000319223310.42913@nietzsche.intra.bowtie.nl>
Message-ID: <Pine.BSF.4.10.10003201032240.48406-100000@RedDust.BlueSky.net.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG



On Sun, 19 Mar 2000, Marc van Kempen wrote:

> On Mon, Mar 20, 2000 at 01:55:11AM +1000, Idea Receiver wrote:
> > 
> > 
> > On Sun, 19 Mar 2000, Thierry.herbelot wrote:
> > 
> > > Marc van Kempen wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > While trying to boot from the 4.0 installation disks,
> > > > I get the following error after the devices have been probed:
> > > > 
> > > 
> > > [SNIP]
> > > 
> > > >     root@localhost:/usr/src/sys/compile/SCHOPENHAUER
> > > > Timecounter "i8254"  frequency 1193182 Hz
> > > > CPU: Celeron (412.50-MHz 686-class CPU)
> > > 
> > > 412 MHz is a non-conventional speed for a Celly : if you are
> > > overclocking (I'm doing it, too), does the bug repeats itself when at
> > > the normal speed ?
> > 
> > yes it does.
> > anyway.. problem fixed this afternoon (australia time :P)!

oops.. sorry.. I try to reply a different mail in a different group with
a totally different topic and nothing to do with FreeBSD at all...
I dont know what my finger do.. I was think other thing and accidently
replied this mail... :^P



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sun Mar 19 16:46:12 2000
Delivered-To: freebsd-current@freebsd.org
Received: from lamb.sas.com (lamb.sas.com [192.35.83.8])
	by hub.freebsd.org (Postfix) with ESMTP id C8BCD37B6DC
	for <freebsd-current@FreeBSD.ORG>; Sun, 19 Mar 2000 16:46:01 -0800 (PST)
	(envelope-from brdean@unx.sas.com)
Received: from mozart (mozart.unx.sas.com [149.173.6.8])
	by lamb.sas.com (8.9.3/8.9.1) with SMTP id TAA21011;
	Sun, 19 Mar 2000 19:45:19 -0500 (EST)
Received: from dean.pc.sas.com by mozart (5.65c/SAS/Domains/5-6-90)
	id AA11191; Sun, 19 Mar 2000 19:44:48 -0500
Received: (from brdean@localhost)
	by dean.pc.sas.com (8.9.3/8.9.1) id TAA55169;
	Sun, 19 Mar 2000 19:44:43 -0500 (EST)
	(envelope-from brdean)
From: Brian Dean <brdean@unx.sas.com>
Message-Id: <200003200044.TAA55169@dean.pc.sas.com>
Subject: Re: Streamlining FreeBSD Installations
In-Reply-To: <38D3019C.9D717EDA@newsguy.com> from "Daniel C. Sobral" at "Mar
 18, 2000 01:10:04 pm"
To: "Daniel C. Sobral" <dcs@newsguy.com>
Date: Sun, 19 Mar 2000 19:44:43 -0500 (EST)
Cc: Forrest Aldrich <forrie@forrie.com>, freebsd-current@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL61 (25)]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Daniel C. Sobral wrote:
> Brian Dean wrote:
> > 
> > Forrest Aldrich wrote:
> > > Someone mentioned that sysinstall could be scripted... is this the way to
> > > go, then?
> > 
> > I use scripted sysinstalls here.  It's really easy, however, you still
> > have to interact with a few dialogs, namely:
> > 
> >         1) of course, you have to specify your config file from
> >            the "Load Config" main menu option
> 
> Huh? AFAIK, sysinstall accept script commands from the command line, so
> this could be skipped.

I was referring to the use of sysinstall for the initial installation
of the OS.  I don't see how you can do what you say unless you create
a custom boot floppy (or CD) for _each_ machine you want to install.
And since we are talking on the order of 100 machines here, I don't
think that is practical.  Perhaps you could get by with one boot image
if your machines were configured via DHCP (mine are not, and in my
case, it is not practical to do so, at least not right now).

And just so I'm not misinterpretted, I'm not complaining about having
to specify the config file.  It's not that big of a deal.  In fact, I
think Jordan has made it just about as simple as it can reasonably
get.  I was just pointing out that it's not _entirely_ hands off, and
merely listed that interaction with sysinstall for the sake of
completeness.  For the remaining four, we can probably code
appropriately via the scripting mechanism to avoid the prompts:

	1) dhcp yes/no
	2) crypto yes/no/which ones
	3) ports yes/no
	4) are you sure you want to really do this? yes/no

-Brian


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sun Mar 19 17:41:35 2000
Delivered-To: freebsd-current@freebsd.org
Received: from cr759667-a.nvcr1.bc.wave.home.com (cr759667-a.nvcr1.bc.wave.home.com [24.113.130.83])
	by hub.freebsd.org (Postfix) with ESMTP id 2218437B86A
	for <freebsd-current@freebsd.org>; Sun, 19 Mar 2000 17:41:33 -0800 (PST)
	(envelope-from freebsdcurrent@cr759667-a.nvcr1.bc.wave.home.com)
Received: from localhost (freebsdcurrent@localhost)
	by cr759667-a.nvcr1.bc.wave.home.com (8.9.3/8.9.3) with ESMTP id RAA24390
	for <freebsd-current@freebsd.org>; Sun, 19 Mar 2000 17:44:11 -0800 (PST)
	(envelope-from freebsdcurrent@cr759667-a.nvcr1.bc.wave.home.com)
Date: Sun, 19 Mar 2000 17:44:10 -0800 (PST)
From: freebsd current <freebsdcurrent@cr759667-a.nvcr1.bc.wave.home.com>
To: freebsd-current@freebsd.org
Message-ID: <Pine.BSF.4.21.0003191743490.24219-100000@cr759667-a.nvcr1.bc.wave.home.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

subscribe freebsd-current



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sun Mar 19 17:54:58 2000
Delivered-To: freebsd-current@freebsd.org
Received: from RedDust.BlueSky.net.au (reddust.bluesky.net.au [203.31.37.15])
	by hub.freebsd.org (Postfix) with ESMTP
	id 5838A37B835; Sun, 19 Mar 2000 17:54:50 -0800 (PST)
	(envelope-from receiver@RedDust.BlueSky.net.au)
Received: from localhost (receiver@localhost)
	by RedDust.BlueSky.net.au (8.9.3/8.9.3) with ESMTP id LAA48531;
	Mon, 20 Mar 2000 11:55:48 +1000 (EST)
	(envelope-from receiver@RedDust.BlueSky.net.au)
Date: Mon, 20 Mar 2000 11:55:48 +1000 (EST)
From: Idea Receiver <receiver@RedDust.BlueSky.net.au>
To: jmz@freebsd.org
Cc: current@freebsd.org
Subject: about XFree86-4
Message-ID: <Pine.BSF.4.10.10003201150340.48524-100000@RedDust.BlueSky.net.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


I take a look at the XFree86-4 patches.
I found in those patches, "zh_TW.big5" and "zh_CN.big5" maybe wrong.

the "zh_TW.big5" should be "zh_TW.BIG5"
and the "zh_CN.big5" should be "zhTW.BIG5"

hopefuly I am right about this..



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sun Mar 19 18: 1:16 2000
Delivered-To: freebsd-current@freebsd.org
Received: from lamb.sas.com (lamb.sas.com [192.35.83.8])
	by hub.freebsd.org (Postfix) with ESMTP id 7C55637B879
	for <freebsd-current@freebsd.org>; Sun, 19 Mar 2000 18:01:10 -0800 (PST)
	(envelope-from jwd@unx.sas.com)
Received: from mozart (mozart.unx.sas.com [149.173.6.8])
	by lamb.sas.com (8.9.3/8.9.1) with SMTP id VAA22371
	for <freebsd-current@freebsd.org>; Sun, 19 Mar 2000 21:01:06 -0500 (EST)
Received: from bb01f39.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90)
	id AA13272; Sun, 19 Mar 2000 21:00:35 -0500
Received: (from jwd@localhost)
	by bb01f39.unx.sas.com (8.9.3/8.9.1) id VAA11571;
	Sun, 19 Mar 2000 21:00:35 -0500 (EST)
	(envelope-from jwd)
From: "John W. DeBoskey" <jwd@unx.sas.com>
Message-Id: <200003200200.VAA11571@bb01f39.unx.sas.com>
Subject: AMI MegaRAID lockup? not accepting commands.
To: freebsd-current@freebsd.org
Date: Sun, 19 Mar 2000 21:00:35 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL61 (25)]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Hi,

   We have a system with a new AMI card in it controlling a pair
of shelves from Dell (fbsd dated: 4.0-20000313-SNAP).

   The relevant dmesg output is below: (complete dmesg at end)

amr0: <AMI MegaRAID> mem 0xf6c00000-0xf6ffffff irq 14 at device 10.1 on pci2
amr0: firmware 1.01 bios 1p00  128MB memory
amrd0: <MegaRAID logical drive> on amr0
amrd0: 172780MB (353853440 sectors) RAID 5 (optimal)

   The adapter does not lockup while testing with bonnie and such.
However, we have a 50Gig CVS repository sitting on the raid
volume. When we do a 'cvs co' of -HEAD, it causes it to lockup.
The following messages are repeating continuously:

Mar 19 16:02:59 cvs /kernel: amr0: controller wedged (not taking commands)
Mar 19 16:03:00 cvs /kernel: amr0: I/O error - dead
Mar 19 16:03:00 cvs /kernel: amr0: cmd 2  ident 178  drive 0
Mar 19 16:03:00 cvs /kernel: amr0: blkcount 12  lba 59506736
Mar 19 16:03:00 cvs /kernel: amr0: virtaddr 0xd3089000  length 6144
Mar 19 16:03:00 cvs /kernel: amr0: physaddr 0000c880  nsg 2
Mar 19 16:03:00 cvs /kernel: amr0:   1abea000/4096
Mar 19 16:03:00 cvs /kernel: amr0:   25d2b000/2048
Mar 19 16:03:00 cvs /kernel: amr0: controller wedged (not taking commands)
Mar 19 16:03:00 cvs /kernel: amr0: I/O error - dead
Mar 19 16:03:00 cvs /kernel: amr0: cmd 2  ident 178  drive 0
Mar 19 16:03:00 cvs /kernel: amr0: blkcount 16  lba 59506768
Mar 19 16:03:00 cvs /kernel: amr0: virtaddr 0xd330f000  length 8192
Mar 19 16:03:00 cvs /kernel: amr0: physaddr 0000c880  nsg 2
Mar 19 16:03:00 cvs /kernel: amr0:   2396e000/4096
Mar 19 16:03:00 cvs /kernel: amr0:   28fef000/4096
Mar 19 16:03:00 cvs /kernel: amr0: controller wedged (not taking commands)
Mar 19 16:03:00 cvs /kernel: amr0: I/O error - dead
Mar 19 16:03:00 cvs /kernel: amr0: cmd 2  ident 178  drive 0
Mar 19 16:03:00 cvs /kernel: amr0: blkcount 16  lba 59506784
Mar 19 16:03:00 cvs /kernel: amr0: virtaddr 0xcebf3000  length 8192
Mar 19 16:03:01 cvs /kernel: amr0: physaddr 0000c880  nsg 2
Mar 19 16:03:01 cvs /kernel: amr0:   25470000/4096
Mar 19 16:03:01 cvs /kernel: amr0:   28ab1000/4096


   We have locked the card up twice in a row. In looking through
the cvs logs, I find the following concerning amr.c 1.7:
http://www.FreeBSD.org/cgi/cvsweb.cgi/src/sys/dev/amr/amr.c

---------------------
Increase the time we spend waiting for the controller to become ready to
accept a new command; in high load cases it may be too busy for the old
value.

This loop needs something to tie it to real time, rather than just the CPU's
ability to fetch from the L1 data cache, but this hack works for now.
---------------------

   Also, looking through freebsd-current archives, this topic seems to
have been discussed in mid February, and then disappeared.


   If anyone has any ideas, or if there is anything we can try to help
debug this problem, please let me know.


Thanks,
John

ps: Complete dmesg output below.


Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
	The Regents of the University of California. All rights reserved.
FreeBSD 4.0-20000313-SNAP #0: Sun Mar 19 15:07:38 EST 2000
    root@cvs.unx.sas.com:/usr/src/sys/compile/CVSKERN
Timecounter "i8254"  frequency 1193182 Hz
CPU: Pentium III/Pentium III Xeon (548.63-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x673  Stepping = 3
  Features=0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,XMM>
real memory  = 805306368 (786432K bytes)
avail memory = 777945088 (759712K bytes)
Preloaded elf kernel "kernel" at 0xc02fe000.
Pentium Pro MTRR support enabled
md0: Malloc disk
npx0: <math processor> on motherboard
npx0: INT 16 interface
pcib0: <Intel 82443BX (440 BX) host to PCI bridge> on motherboard
pci0: <PCI bus> on pcib0
pcib1: <Intel 82443BX (440 BX) PCI-PCI (AGP) bridge> at device 1.0 on pci0
pci1: <PCI bus> on pcib1
pci1: <ATI Mach64-GB graphics accelerator> at 0.0 irq 9
isab0: <Intel 82371AB PCI to ISA bridge> at device 7.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel PIIX4 ATA33 controller> port 0xffa0-0xffaf at device 7.1 on pci0
ata1: at 0x170 irq 15 on atapci0
pci0: <Intel 82371AB/EB (PIIX4) USB controller> at 7.2 irq 14
chip1: <Intel 82371AB Power management controller> port 0x850-0x85f at device 7.3 on pci0
fxp0: <Intel EtherExpress Pro 10/100B Ethernet> port 0xcc80-0xccbf mem 0xff100000-0xff1fffff,0xff201000-0xff201fff irq 11 at device 13.0 on pci0
fxp0: Ethernet address 00:90:27:89:eb:9b
fxp1: <Intel EtherExpress Pro 10/100B Ethernet> port 0xcc40-0xcc7f mem 0xff000000-0xff0fffff,0xff200000-0xff200fff irq 10 at device 14.0 on pci0
fxp1: Ethernet address 00:90:27:89:ef:10
pcib2: <DEC 21152 PCI-PCI bridge> at device 15.0 on pci0
pci2: <PCI bus> on pcib2
ahc0: <Adaptec 2940 Ultra SCSI adapter> port 0xdc00-0xdcff mem 0xfafff000-0xfaffffff irq 9 at device 9.0 on pci2
ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs
pcib3: <PCI to PCI bridge (vendor=8086 device=0964)> at device 10.0 on pci2
pci3: <PCI bus> on pcib3
amr0: <AMI MegaRAID> mem 0xf6c00000-0xf6ffffff irq 14 at device 10.1 on pci2
amr0: firmware 1.01 bios 1p00  128MB memory
amrd0: <MegaRAID logical drive> on amr0
amrd0: 172780MB (353853440 sectors) RAID 5 (optimal)
xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xc880-0xc8ff mem 0xff202000-0xff20207f irq 14 at device 17.0 on pci0
xl0: Ethernet address: 00:b0:d0:19:18:81
miibus0: <MII bus> on xl0
xlphy0: <3Com internal media interface> on miibus0
xlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
atkbdc0: <keyboard controller (i8042)> at port 0x60-0x6f on isa0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: model Generic PS/2 mouse, device ID 0
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
sc0: <System console> on isa0
sc0: VGA <16 virtual consoles, flags=0x200>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/8 bytes threshold
lpt0: <Printer> on ppbus0
lpt0: Interrupt-driven port
unknown0: <WSS/SB> at port 0x534-0x537,0x388-0x38b,0x220-0x22f irq 5 drq 1,0 on isa0
unknown1: <Game> at port 0x3a0-0x3a7 on isa0
unknown2: <Ctrl> at port 0xf00-0xf07 on isa0
unknown3: <MPU> at port 0x330-0x331 on isa0
acd0: CDROM <SAMSUNG CD-ROM SC-140F> at ata1-master using PIO4
Waiting 2 seconds for SCSI devices to settle
Mounting root from ufs:/dev/da0s1a
da0 at ahc0 bus 0 target 0 lun 0
da0: <QUANTUM ATLAS IV 9 WLS 0808> Fixed Direct Access SCSI-3 device 
da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled
da0: 8683MB (17783249 512 byte sectors: 255H 63S/T 1106C)
da1 at ahc0 bus 0 target 1 lun 0
da1: <QUANTUM ATLAS IV 9 WLS 0808> Fixed Direct Access SCSI-3 device 
da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled
da1: 8683MB (17783249 512 byte sectors: 255H 63S/T 1106C)



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sun Mar 19 18: 4:44 2000
Delivered-To: freebsd-current@freebsd.org
Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6])
	by hub.freebsd.org (Postfix) with ESMTP id 159EB37B839
	for <freebsd-current@freebsd.org>; Sun, 19 Mar 2000 18:04:42 -0800 (PST)
	(envelope-from billf@jade.chc-chimes.com)
Received: by jade.chc-chimes.com (Postfix, from userid 1001)
	id B28C61C4D; Sun, 19 Mar 2000 21:04:41 -0500 (EST)
Date: Sun, 19 Mar 2000 21:04:41 -0500
From: Bill Fumerola <billf@chc-chimes.com>
To: "John W. DeBoskey" <jwd@unx.sas.com>
Cc: freebsd-current@freebsd.org
Subject: Re: AMI MegaRAID lockup? not accepting commands.
Message-ID: <20000319210441.T25438@jade.chc-chimes.com>
References: <200003200200.VAA11571@bb01f39.unx.sas.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200003200200.VAA11571@bb01f39.unx.sas.com>; from jwd@unx.sas.com on Sun, Mar 19, 2000 at 09:00:35PM -0500
X-Operating-System: FreeBSD 3.2-RELEASE i386
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Sun, Mar 19, 2000 at 09:00:35PM -0500, John W. DeBoskey wrote:

> amr0: <AMI MegaRAID> mem 0xf6c00000-0xf6ffffff irq 14 at device 10.1 on pci2
> amr0: firmware 1.01 bios 1p00  128MB memory
> amrd0: <MegaRAID logical drive> on amr0
> amrd0: 172780MB (353853440 sectors) RAID 5 (optimal)
> 
>    The adapter does not lockup while testing with bonnie and such.
> However, we have a 50Gig CVS repository sitting on the raid
> volume. When we do a 'cvs co' of -HEAD, it causes it to lockup.
> The following messages are repeating continuously:
> 
> Mar 19 16:02:59 cvs /kernel: amr0: controller wedged (not taking commands)
> Mar 19 16:03:00 cvs /kernel: amr0: I/O error - dead
> Mar 19 16:03:00 cvs /kernel: amr0: cmd 2  ident 178  drive 0
> Mar 19 16:03:00 cvs /kernel: amr0: blkcount 12  lba 59506736
> Mar 19 16:03:00 cvs /kernel: amr0: virtaddr 0xd3089000  length 6144
> Mar 19 16:03:00 cvs /kernel: amr0: physaddr 0000c880  nsg 2
> Mar 19 16:03:00 cvs /kernel: amr0:   1abea000/4096
> Mar 19 16:03:00 cvs /kernel: amr0:   25d2b000/2048

Ditto, less the kernel messages. Every process wedged into biord and I
couldn't reboot the machine or do much of anything (no DDB, grrrr). Rebooting
this resulted in all the of the disks being marked 'failed' by the controller
and I had to remark them 'online' and boot. A very long night(well, whatever
3am is..) of fscking followed.

It was not fun.

amr0: <AMI MegaRAID> mem 0xf6c00000-0xf6ffffff irq 10 at device 10.1 on pci2
amr0: firmware 3.13 bios 1.43  16MB memory
amrd0: <MegaRAID logical drive> on amr0
amrd0: 173390MB (355102720 sectors) RAID 5 (optimal)

-- 
Bill Fumerola - Network Architect
Computer Horizons Corp - CVM
e-mail: billf@chc-chimes.com / billf@FreeBSD.org
Office: 800-252-2421 x128 / Cell: 248-761-7272





To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sun Mar 19 19:22:36 2000
Delivered-To: freebsd-current@freebsd.org
Received: from RedDust.BlueSky.net.au (reddust.bluesky.net.au [203.31.37.15])
	by hub.freebsd.org (Postfix) with ESMTP
	id A131537B9A1; Sun, 19 Mar 2000 19:22:28 -0800 (PST)
	(envelope-from receiver@RedDust.BlueSky.net.au)
Received: from localhost (receiver@localhost)
	by RedDust.BlueSky.net.au (8.9.3/8.9.3) with ESMTP id NAA48638;
	Mon, 20 Mar 2000 13:23:27 +1000 (EST)
	(envelope-from receiver@RedDust.BlueSky.net.au)
Date: Mon, 20 Mar 2000 13:23:27 +1000 (EST)
From: Idea Receiver <receiver@RedDust.BlueSky.net.au>
To: jmz@FreeBSD.ORG
Cc: current@FreeBSD.ORG
Subject: Re: about XFree86-4
In-Reply-To: <Pine.BSF.4.10.10003201150340.48524-100000@RedDust.BlueSky.net.au>
Message-ID: <Pine.BSF.4.10.10003201323020.48636-100000@RedDust.BlueSky.net.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG



On Mon, 20 Mar 2000, Idea Receiver wrote:

> 
> I take a look at the XFree86-4 patches.
> I found in those patches, "zh_TW.big5" and "zh_CN.big5" maybe wrong.
> 
> the "zh_TW.big5" should be "zh_TW.BIG5"
> and the "zh_CN.big5" should be "zhTW.BIG5"
				^^^^^^^^^^^^^^^
oops. should be "zh_TW.BIG5" :P



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sun Mar 19 21:17:35 2000
Delivered-To: freebsd-current@freebsd.org
Received: from otto.oss.uswest.net (otto.oss.uswest.net [204.147.85.81])
	by hub.freebsd.org (Postfix) with SMTP id 5C48337B6C5
	for <freebsd-current@FreeBSD.ORG>; Sun, 19 Mar 2000 21:17:31 -0800 (PST)
	(envelope-from pmckenna@uswest.net)
Received: (qmail 98045 invoked from network); 20 Mar 2000 05:22:30 -0000
Received: from operations-dialup41.oss.uswest.net (HELO uswest.net) (209.180.23.41)
  by otto.oss.uswest.net with SMTP; 20 Mar 2000 05:22:30 -0000
Message-ID: <38D5B4C1.A170936A@uswest.net>
Date: Sun, 19 Mar 2000 23:18:57 -0600
From: Pete <pmckenna@uswest.net>
X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 3.3-STABLE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Brian Dean <brdean@unx.sas.com>
Cc: "Daniel C. Sobral" <dcs@newsguy.com>,
	Forrest Aldrich <forrie@forrie.com>, freebsd-current@FreeBSD.ORG
Subject: Re: Streamlining FreeBSD Installations
References: <200003200044.TAA55169@dean.pc.sas.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

It does not have to be that hands on.

Brian Dean wrote:
> 
> Daniel C. Sobral wrote:
> > Brian Dean wrote:
> > >
> > > Forrest Aldrich wrote:
> > > > Someone mentioned that sysinstall could be scripted... is this the way to
> > > > go, then?
> > >
> > > I use scripted sysinstalls here.  It's really easy, however, you still
> > > have to interact with a few dialogs, namely:
> > >
> > >         1) of course, you have to specify your config file from
> > >            the "Load Config" main menu option
> >
> > Huh? AFAIK, sysinstall accept script commands from the command line, so
> > this could be skipped.
> 
> I was referring to the use of sysinstall for the initial installation
> of the OS.  I don't see how you can do what you say unless you create
> a custom boot floppy (or CD) for _each_ machine you want to install.
> And since we are talking on the order of 100 machines here, I don't
> think that is practical.  Perhaps you could get by with one boot image
> if your machines were configured via DHCP (mine are not, and in my
> case, it is not practical to do so, at least not right now).
> 
> And just so I'm not misinterpretted, I'm not complaining about having
> to specify the config file.  It's not that big of a deal.  In fact, I
> think Jordan has made it just about as simple as it can reasonably
> get.  I was just pointing out that it's not _entirely_ hands off, and
> merely listed that interaction with sysinstall for the sake of
> completeness.  For the remaining four, we can probably code
> appropriately via the scripting mechanism to avoid the prompts:
>

 
>         1) dhcp yes/no
If the sysinstall script has all the host info you don't need to answer
this.

>         2) crypto yes/no/which ones
What I did is make a package of ssh it no longer asks.

>         3) ports yes/no
Can be specified in the sysinstall script.

>         4) are you sure you want to really do this? yes/no
I still answer this one.
> 
> -Brian

I hacked PicoBSD to do this so it works from one floppy. You can either
name 
the file install.cfg in which case it is run automatically or give it a 
../stand/my_script.cfg to grab the build file you wish from stand which
is 
where I put my scripts on the build floppy. I have about a dozen
different
scripts on the floppy and still seem to have lots of room. I haven't 
automated adding users. I did this under 3.2 and am trying to find the
time 
to move it to 3.4 although it should be able to build 3.4 servers with
no 
problem.

Pete


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sun Mar 19 21:30:30 2000
Delivered-To: freebsd-current@freebsd.org
Received: from smtp.bankinter.es (dns.bankinter.es [195.235.30.34])
	by hub.freebsd.org (Postfix) with ESMTP id A08E937B846
	for <current@freebsd.org>; Sun, 19 Mar 2000 21:30:26 -0800 (PST)
	(envelope-from feria@mac21.com)
Received: from default (h027139.nexo.es [195.235.27.139])
	by smtp.bankinter.es (8.8.8+Sun/8.8.8) with SMTP id GAA10418
	for <current@freebsd.org>; Mon, 20 Mar 2000 06:26:58 +0100 (MET)
From: feria@mac21.com
To: <current@freebsd.org>
Subject: MAC21 Art Fair 2000
Date: Mon, 20 Mar 2000 06:26:05 +0100
Message-Id: <36605.268113888889600.11145@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 8bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

M A C  2 1 - 2000

International Contemporary Art Fair
Feria Internacional de Arte Contemporáneo
===============================================

Contenido:
1 ................. ENGLISH TEXT
2 ................. TEXTO EN ESPAÑOL  


****************  ENGLISH TEXT ****************


You can visit actualized:

www.mac21.com

with complete information of 3 Edition of
MAC21 - International Contemporary Art Fair,
that will take place in the Fairs and Congresses
Center of Marbella (Spain), from 19 to 23 July, 2000.

Galleries, conditions, application, prices,...

Moreover, information of the 2 Edition of
Art-e-mail, International Exhibition of 
E-mails of Artists.
 
MAC21

feria@mac21.com
art-e-mail@mac21.com

===============================================
We adhere to responsible e-mail ethics
if you wish to be "removed" from future 
mailings, please click on this link mailto:
publicidad@mac21.com?subject=REMOVE:current@freebsd.org
and hit send. 
===============================================

**************** TEXTO ESPAÑOL **************** 


Ya puedes visitar actualizada:

www.mac21.com

con toda la información de la 3 edicion de
MAC21-Feria Internacional de Arte Contemporaneo,
que se celebrara en el Palacio de Ferias y
Congresos de Marbella (España), del 19 al 23 de 
julio del 2000.

Galerías, condiciones, inscripcion, precios,...

Además, información de la 2 Edición de 
Art-e-mail, Exposición Internacional de
E-mails de Artistas.
 
MAC21

feria@mac21.com  
art-e-mail@mac21.com

===============================================
Acogiendonos a la etica de la comunicacion por e-mail,
si desea ser "borrado" de futuros envios,
por favor pulse el siguiente link mailto:
publicidad@mac21.com?subject=BORRAR:current@freebsd.org
y envie. 
===============================================





To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sun Mar 19 21:39:14 2000
Delivered-To: freebsd-current@freebsd.org
Received: from news.ethome.net.tw (sgi1.ethome.net.tw [202.178.244.131])
	by hub.freebsd.org (Postfix) with ESMTP id 0002137B618
	for <current@FreeBSD.ORG>; Sun, 19 Mar 2000 21:39:07 -0800 (PST)
	(envelope-from jtjang@gcn.net.tw)
Received: from phantom.at.home (211.c211.ethome.net.tw [202.178.211.211])
	by news.ethome.net.tw (8.8.8/8.8.8) with ESMTP id NAA51261806
	for <current@FreeBSD.ORG>; Mon, 20 Mar 2000 13:39:00 +0800 (TAIST)
Received: (from keith@localhost)
	by phantom.at.home (8.9.3/8.9.3) id NAA37762
	for current@FreeBSD.ORG; Mon, 20 Mar 2000 13:38:27 +0800 (CST)
	(envelope-from keith)
Date: Mon, 20 Mar 2000 13:38:27 +0800
From: Keith Jang <jtjang@gcn.net.tw>
To: current@FreeBSD.ORG
Subject: Re: about XFree86-4
Message-ID: <20000320133826.A39586@phantom.ethome.net.tw>
Reply-To: jtjang@gcn.net.tw
References: <Pine.BSF.4.10.10003201150340.48524-100000@RedDust.BlueSky.net.au> <Pine.BSF.4.10.10003201323020.48636-100000@RedDust.BlueSky.net.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre1i
In-Reply-To: <Pine.BSF.4.10.10003201323020.48636-100000@RedDust.BlueSky.net.au>
X-Operating-System: FreeBSD phantom 5.0-CURRENT FreeBSD 5.0-CURRENT
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On 03/20/00, Idea Receiver wrote:
> > the "zh_TW.big5" should be "zh_TW.BIG5"
> > and the "zh_CN.big5" should be "zhTW.BIG5"
> 				^^^^^^^^^^^^^^^
> oops. should be "zh_TW.BIG5" :P

Actually, that should be zh_TW.Big5 and zh_CN.Big5. :)

Thanks to vanilla for fixing this.
-- 
jtjang@gcn.net.tw


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sun Mar 19 22:38:31 2000
Delivered-To: freebsd-current@freebsd.org
Received: from wint.itfs.nsk.su (wint.itfs.nsk.su [212.20.32.43])
	by hub.freebsd.org (Postfix) with ESMTP id 8D31E37BE7F
	for <current@freebsd.org>; Sun, 19 Mar 2000 22:38:21 -0800 (PST)
	(envelope-from nnd@wint.itfs.nsk.su)
Received: (from nnd@localhost)
	by wint.itfs.nsk.su (8.9.3/8.9.3) id MAA93316;
	Mon, 20 Mar 2000 12:38:17 +0600 (NOVT)
	(envelope-from nnd)
Date: Mon, 20 Mar 2000 12:38:17 +0600 (NOVT)
Message-Id: <200003200638.MAA93316@wint.itfs.nsk.su>
From: nnd@mail.nsk.ru
To: current@freebsd.org
Subject: Broken buildworld in CURRENT
User-Agent: tin/1.4.2-20000123 ("Polish") (UNIX) (FreeBSD/5.0-CURRENT (i386))
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

	Freshly 'cvsup'-ed 5.0-CURRENT.

===> gnu/usr.bin/binutils/doc
makeinfo --no-validate -I /arch/FreeBSD-current/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/gas/doc -I /arch/FreeBSD-current/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/ld -I /arch/FreeBSD-current/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/bfd/doc -I /arch/FreeBSD-current/src/gnu/usr.bin/binutils/doc/../../../../contrib/gdb/gdb/doc -I /arch/FreeBSD-current/src/gnu/usr.bin/binutils/doc/../../../../contrib/libreadline/doc --no-split -I /arch/FreeBSD-current/src/gnu/usr.bin/binutils/doc -I /arch/FreeBSD-current/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils /arch/FreeBSD-current/src/gnu/usr.bin/binutils/doc/../../../../contrib/gdb/gdb/doc/gdb.texinfo  -o gdb.info
/arch/FreeBSD-current/src/gnu/usr.bin/binutils/doc/../../../../contrib/gdb/gdb/doc/gdb.texinfo:4647: warning: unlikely character , in @var.
/arch/FreeBSD-current/src/gnu/usr.bin/binutils/doc/../../../../contrib/gdb/gdb/doc/gdb.texinfo:5284: warning: @sc argument all uppercase, thus no effect.
/arch/FreeBSD-current/src/gnu/usr.bin/binutils/doc/../../../../contrib/gdb/gdb/doc/gdb.texinfo:6531: warning: @sc argument all uppercase, thus no effect.
/arch/FreeBSD-current/src/gnu/usr.bin/binutils/doc/../../../../contrib/libreadline/doc/rluser.texinfo:1331: warning: @sc argument all uppercase, thus no effect.
./inc-hist.texi:31: Index `bt' already exists.
makeinfo: Removing output file `gdb.info' due to errors; use --force to preserve.
*** Error code 2

Stop in /arch/FreeBSD-current/src/gnu/usr.bin/binutils/doc.
*** Error code 1

Stop in /arch/FreeBSD-current/src/gnu/usr.bin/binutils.
*** Error code 1

Stop in /arch/FreeBSD-current/src/gnu/usr.bin.
*** Error code 1

Stop in /arch/FreeBSD-current/src/gnu.
*** Error code 1

Stop in /arch/FreeBSD-current/src.
*** Error code 1

Stop in /arch/FreeBSD-current/src.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20  0:35:26 2000
Delivered-To: freebsd-current@freebsd.org
Received: from news.IAEhv.nl (news.IAE.nl [194.151.64.4])
	by hub.freebsd.org (Postfix) with ESMTP id 6DF3A37B871
	for <current@FreeBSD.ORG>; Mon, 20 Mar 2000 00:35:12 -0800 (PST)
	(envelope-from marc@bowtie.nl)
Received: (from uucp@localhost)
	by news.IAEhv.nl (8.9.1/8.9.1) with IAEhv.nl id JAA10722;
	Mon, 20 Mar 2000 09:35:04 +0100 (MET)
Received: from localhost (localhost [127.0.0.1])
	by bowtie.nl (8.8.8/8.8.8) with ESMTP id JAA07659;
	Mon, 20 Mar 2000 09:34:32 +0100 (CET)
	(envelope-from marc@bowtie.nl)
Message-Id: <200003200834.JAA07659@bowtie.nl>
X-Mailer: exmh version 2.1.1 10/15/1999
To: Alfred Perlstein <bright@wintelcom.net>
Cc: current@FreeBSD.ORG
Subject: Re: install problem with 4.0 (spec_getpages) 
In-reply-to: bright's message of Sun, 19 Mar 2000 12:01:40 -0800.
	     <20000319120140.Q14789@fw.wintelcom.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 20 Mar 2000 09:34:32 +0100
From: Marc van Kempen <marc@bowtie.nl>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


> 
> You also ought to make sure the floppies can get through a complete
> format before dd'ing the images over them.
> 
This was it! I went through 8 floppies before I found a decent pair,
these 3.5" things s*ck.

Thanks,
Marc.


-- 
----------------------------------------------------
Marc van Kempen                 BowTie Technology     
Email: marc@bowtie.nl            WWW & Databases
tel. +31 40 2 43 20 65         
fax. +31 40 2 44 21 86         http://www.bowtie.nl
----------------------------------------------------




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20  1: 0:26 2000
Delivered-To: freebsd-current@freebsd.org
Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20])
	by hub.freebsd.org (Postfix) with ESMTP id 3EF8537B803
	for <current@FreeBSD.ORG>; Mon, 20 Mar 2000 01:00:21 -0800 (PST)
	(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
	by fw.wintelcom.net (8.10.0/8.10.0) id e2K9NGk17635;
	Mon, 20 Mar 2000 01:23:16 -0800 (PST)
Date: Mon, 20 Mar 2000 01:23:15 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Marc van Kempen <marc@bowtie.nl>
Cc: current@FreeBSD.ORG
Subject: Re: install problem with 4.0 (spec_getpages)
Message-ID: <20000320012315.V14789@fw.wintelcom.net>
References: <20000319120140.Q14789@fw.wintelcom.net> <200003200834.JAA07659@bowtie.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200003200834.JAA07659@bowtie.nl>; from marc@bowtie.nl on Mon, Mar 20, 2000 at 09:34:32AM +0100
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

* Marc van Kempen <marc@bowtie.nl> [000320 00:58] wrote:
> 
> > 
> > You also ought to make sure the floppies can get through a complete
> > format before dd'ing the images over them.
> > 
> This was it! I went through 8 floppies before I found a decent pair,
> these 3.5" things s*ck.

Another fun one is dd'ing the 2.88MB images to a 1.44 diskette and
being too tired to figure out what the #@$@#$@@# is going wrong while
shivering your butt off in the colo facility.

blech! :)

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20  1:20:23 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP
	id 7395B37B92D; Mon, 20 Mar 2000 01:20:19 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id BAA65798;
	Mon, 20 Mar 2000 01:20:19 -0800 (PST)
	(envelope-from dillon)
Date: Mon, 20 Mar 2000 01:20:19 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003200920.BAA65798@apollo.backplane.com>
To: Poul-Henning Kamp <phk@FreeBSD.ORG>
Cc: current@FreeBSD.ORG
Subject: Re: patches for test / review
References:  <5701.953319823@critter.freebsd.dk>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


:I have two patches up for test at http://phk.freebsd.dk/misc
:
:I'm looking for reviews and tests, in particular vinum testing
:would be nice since Grog is quasi-offline at the moment.
:
:Poul-Henning
:
:20000317 BWRITE-STRATEGY.patch
:
:        This patch is machine generated except for the ccd.c and buf.h
:        parts.
:
:        Rename existing BUF_STRATEGY to DEV_STRATEGY
:        substitute BUF_WRITE(foo) for VOP_BWRITE(foo->b_vp, foo);
:        substitute BUF_STRATEGY(foo) for VOP_STRATEGY(foo->b_vp, foo);
:
:        Please test & review.
:
:
:20000317 b_iocmd.patch
:
:        This patch removes B_READ, B_WRITE and B_FREEBUF and replaces
:        them with a new field in struct buf: b_iocmd.
:
:        B_WRITE was bogusly defined as zero giving rise to obvious
:        coding mistakes and a lot of code implicitly knew this.
:
:        This patch also eliminates the redundant flag B_CALL, it can
:        just as efficiently be done by comparing b_iodone to NULL.
:
:        Should you get a panic or drop into the debugger, complaining about
:        "b_iocmd", don't continue, it is likely to write where it should
:        have read.
:
:        Please test & review.

    Kirk and I have already mapped out a plan to drastically update
    the buffer cache API which will encapsulate much of the state within
    the buffer cache module.  I don't think it makes much sense to make
    these relatively complex but ultimately not-significantly-improving 
    changes to the buffer cache code at this time.  Specifically, I
    don't think renaming the BUF_WRITE/VOP_BWRITE or BUF_STRATEGY/DEV_STRATEGY
    stuff is worth doing at all, and while I agree that the idea of separting
    out the IO command (b_iocmd patch) is a good one, it will be much more
    effective to do it *AFTER* Kirk and I have separated out the functional 
    interfaces because it will be mostly encapsulated in a single source
    module.  At the current time the extensive nature of the changes have
    too high a potential for introducing new bugs in a system that has 
    undergone significant debugging and testing and is pretty much known to
    work properly.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>

:
:--
:Poul-Henning Kamp             FreeBSD coreteam member
:phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
:FreeBSD -- It will take a long time before progress goes too far!
:
:
:To Unsubscribe: send mail to majordomo@FreeBSD.org
:with "unsubscribe freebsd-current" in the body of the message
:



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20  2:23:33 2000
Delivered-To: freebsd-current@freebsd.org
Received: from dt051n0b.san.rr.com (dt051n0b.san.rr.com [204.210.32.11])
	by hub.freebsd.org (Postfix) with ESMTP id 7C05D37B584
	for <current@freebsd.org>; Mon, 20 Mar 2000 02:23:30 -0800 (PST)
	(envelope-from Doug@gorean.org)
Received: from gorean.org (doug@master [10.0.0.2])
	by dt051n0b.san.rr.com (8.9.3/8.9.3) with ESMTP id CAA51280
	for <current@freebsd.org>; Mon, 20 Mar 2000 02:23:29 -0800 (PST)
	(envelope-from Doug@gorean.org)
Message-ID: <38D5FC21.39620710@gorean.org>
Date: Mon, 20 Mar 2000 02:23:29 -0800
From: Doug Barton <Doug@gorean.org>
Organization: Triborough Bridge & Tunnel Authority
X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 5.0-CURRENT-0316 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: current@freebsd.org
Subject: makeinfo for gdb.info is broken
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

	My latest world breakage involves makeinfo on gdb.info. I tried to dig
through the makefile maze to try and get just that bit not to build and
I can't sort it out. Error message below.

Doug
-- 
"While the future's there for anyone to change, still you know it seems, 
 it would be easier sometimes to change the past"

     - Jackson Browne, "Fountain of Sorrow"

makeinfo --no-validate -I
/usr/amd/realmounts/slave/usr/current/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/gas/doc
-I
/usr/amd/realmounts/slave/usr/current/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/ld
-I
/usr/amd/realmounts/slave/usr/current/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/bfd/doc
-I
/usr/amd/realmounts/slave/usr/current/src/gnu/usr.bin/binutils/doc/../../../../contrib/gdb/gdb/doc
-I
/usr/amd/realmounts/slave/usr/current/src/gnu/usr.bin/binutils/doc/../../../../contrib/libreadline/doc
--no-split -I
/usr/amd/realmounts/slave/usr/current/src/gnu/usr.bin/binutils/doc -I
/usr/amd/realmounts/slave/usr/current/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils
/usr/amd/realmounts/slave/usr/current/src/gnu/usr.bin/binutils/doc/../../../../contrib/gdb/gdb/doc/gdb.texinfo 
-o gdb.info
/usr/amd/realmounts/slave/usr/current/src/gnu/usr.bin/binutils/doc/../../../../contrib/gdb/gdb/doc/gdb.texinfo:4647:
warning: unlikely character , in @var.
/usr/amd/realmounts/slave/usr/current/src/gnu/usr.bin/binutils/doc/../../../../contrib/gdb/gdb/doc/gdb.texinfo:5284:
warning: @sc argument all uppercase, thus no effect.
/usr/amd/realmounts/slave/usr/current/src/gnu/usr.bin/binutils/doc/../../../../contrib/gdb/gdb/doc/gdb.texinfo:6531:
warning: @sc argument all uppercase, thus no effect.
/usr/amd/realmounts/slave/usr/current/src/gnu/usr.bin/binutils/doc/../../../../contrib/libreadline/doc/rluser.texinfo:1331:
warning: @sc argument all uppercase, thus no effect.
./inc-hist.texi:31: Index `bt' already exists.
makeinfo: Removing output file `gdb.info' due to errors; use --force to
preserve.
*** Error code 2

Stop in
/usr/amd/realmounts/slave/usr/current/src/gnu/usr.bin/binutils/doc.
*** Error code 1

Stop in /usr/amd/realmounts/slave/usr/current/src/gnu/usr.bin/binutils.
*** Error code 1

Stop in /usr/amd/realmounts/slave/usr/current/src/gnu/usr.bin.
*** Error code 1

Stop in /usr/amd/realmounts/slave/usr/current/src/gnu.
*** Error code 1

Stop in /usr/amd/realmounts/slave/usr/current/src.
*** Error code 1

Stop in /usr/amd/realmounts/slave/usr/current/src.
*** Error code 1

Stop in /usr/amd/realmounts/slave/usr/current/src.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20  2:48:26 2000
Delivered-To: freebsd-current@freebsd.org
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131])
	by hub.freebsd.org (Postfix) with ESMTP id C9F3737B5A2
	for <current@FreeBSD.ORG>; Mon, 20 Mar 2000 02:48:22 -0800 (PST)
	(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1])
	by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id LAA18041;
	Mon, 20 Mar 2000 11:48:09 +0100 (CET)
	(envelope-from phk@critter.freebsd.dk)
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: current@FreeBSD.ORG
Subject: Re: patches for test / review 
In-reply-to: Your message of "Mon, 20 Mar 2000 01:20:19 PST."
             <200003200920.BAA65798@apollo.backplane.com> 
Date: Mon, 20 Mar 2000 11:48:09 +0100
Message-ID: <18039.953549289@critter.freebsd.dk>
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


>    Kirk and I have already mapped out a plan to drastically update
>    the buffer cache API which will encapsulate much of the state within
>    the buffer cache module.

Sounds good.  Combined with my stackable BIO plans that sounds like
a really great win for FreeBSD.

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20  2:48:49 2000
Delivered-To: freebsd-current@freebsd.org
Received: from polaris.we.lc.ehu.es (polaris.we.lc.ehu.es [158.227.6.43])
	by hub.freebsd.org (Postfix) with ESMTP
	id 1CD2037B610; Mon, 20 Mar 2000 02:48:10 -0800 (PST)
	(envelope-from jose@we.lc.ehu.es)
Received: from we.lc.ehu.es (v-ger [158.227.6.179])
	by polaris.we.lc.ehu.es (8.9.1/8.9.1) with ESMTP id LAA24986;
	Mon, 20 Mar 2000 11:48:01 +0100 (MET)
Message-ID: <38D601E2.268BEB2B@we.lc.ehu.es>
Date: Mon, 20 Mar 2000 11:48:02 +0100
From: "Jose M. Alcaide" <jose@we.lc.ehu.es>
Organization: Universidad del =?iso-8859-1?Q?Pa=EDs?= Vasco - Dpto. de Electricidad y 
	=?iso-8859-1?Q?Electr=F3nica?=
X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: es-ES, es, en-US, en
MIME-Version: 1.0
To: obrien@FreeBSD.ORG
Cc: Satoshi - Ports Wraith - Asami <asami@FreeBSD.ORG>,
	freebsd-current@FreeBSD.ORG
Subject: Re: suggestion: a g77 -> f77 link
References: <38CD1091.94E73AC9@we.lc.ehu.es> <20000314143826.D9311@dragon.nuxi.com> <vqcog8h9f3q.fsf@silvia.hip.berkeley.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Hi David,

Now, a week after the discussion, what do you think about my proposal
of the "g77" link under /usr/bin? IMHO, the following facts are all good
reasons for creating the link:

  - the output of "f77 -V", "f77 --version", "man f77", and "info g77";
  - our Fortran compiler _is_ GNU Fortran, i.e., g77;
  - there are configure scripts which [legitimately] look for g77 when
    instructed to use the GNU Fortran compiler;
  - we already have a "gcc" link.

I understand (and agree) your arguments against Gfoo, but I think that
the benefits of the g77 link are worth the "sacrifice" (gsacrifice?) :-)

Regards,
-- JMA

 ***** Jose M. Alcaide // jose@we.lc.ehu.es // jmas@FreeBSD.org *****
 "Beware of Programmers who carry screwdrivers" --  Leonard Brandwein


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20  4:37:22 2000
Delivered-To: freebsd-current@freebsd.org
Received: from lucifer.bart.nl (lucifer.bart.nl [194.158.168.74])
	by hub.freebsd.org (Postfix) with ESMTP id B0B1B37B910
	for <current@FreeBSD.ORG>; Mon, 20 Mar 2000 04:37:11 -0800 (PST)
	(envelope-from asmodai@lucifer.bart.nl)
Received: (from asmodai@localhost)
	by lucifer.bart.nl (8.9.3/8.9.3) id NAA53444;
	Mon, 20 Mar 2000 13:36:59 +0100 (CET)
	(envelope-from asmodai)
Date: Mon, 20 Mar 2000 13:36:59 +0100
From: Jeroen Ruigrok van der Werven <asmodai@bart.nl>
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc: Peter Wemm <peter@netplex.com.au>, current@FreeBSD.ORG
Subject: Re: HEADS UP; new options for -current!
Message-ID: <20000320133659.I95266@lucifer.bart.nl>
References: <20000319131447.E6EF21CD9@overcee.netplex.com.au> <14762.953494736@critter.freebsd.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <14762.953494736@critter.freebsd.dk>; from phk@critter.freebsd.dk on Sun, Mar 19, 2000 at 08:38:56PM +0100
Organisation: bART Internet Services B.V.
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

-On [20000319 21:00], Poul-Henning Kamp (phk@critter.freebsd.dk) wrote:
>In message <20000319131447.E6EF21CD9@overcee.netplex.com.au>, Peter Wemm writes
>:
>>If you are using old drivers that haven't been newbusified yet, you will
>>need to add 'options COMPAT_OLDPCI' and/or 'options COMPAT_OLDISA' to your
>>kernel configs and regenerate.  Otherwise you will get compile failures.
>
>I think this is premature.
>
>I tried to newbusify if_mn.c, but after having added about 50 lines
>of code to replace the current about 10, I gave up.
>
>We need a highlevel wrapper for newbus before we should force people
>to upgrade the old-style drivers.

I already addressed that in new-bus and there is some discussion and
finding out the best way to do a higher level wrapping for a lot of
newbus' stuff.

So rest assured, work is underway. =)

-- 
Jeroen Ruigrok van der Werven          Network- and systemadministrator
<asmodai@bart.nl>                      VIA NET.WORKS The Netherlands
BSD: Technical excellence at its best  http://www.bart.nl
The mediocre teacher tells, the good teacher explains, the superior
teacher demonstrates, the great teacher inspires...


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20  6:28:11 2000
Delivered-To: freebsd-current@freebsd.org
Received: from boco.fee.vutbr.cz (boco.fee.vutbr.cz [147.229.9.11])
	by hub.freebsd.org (Postfix) with ESMTP id A58EF37B7FD
	for <freebsd-current@freebsd.org>; Mon, 20 Mar 2000 06:28:05 -0800 (PST)
	(envelope-from cejkar@dcse.fee.vutbr.cz)
Received: from kazi.dcse.fee.vutbr.cz (kazi.dcse.fee.vutbr.cz [147.229.8.12])
	by boco.fee.vutbr.cz (8.9.3/8.9.3) with ESMTP id PAA63550
	for <freebsd-current@freebsd.org>; Mon, 20 Mar 2000 15:28:03 +0100 (CET)
Received: (from cejkar@localhost)
	by kazi.dcse.fee.vutbr.cz (8.9.3/8.9.3) id PAA76445
	for freebsd-current@freebsd.org; Mon, 20 Mar 2000 15:28:02 +0100 (CET)
Date: Mon, 20 Mar 2000 15:28:02 +0100
From: Cejka Rudolf <cejkar@dcse.fee.vutbr.cz>
To: freebsd-current@freebsd.org
Subject: SUS/2 non-compliance in waitpid() function?
Message-ID: <20000320152801.A76099@dcse.fee.vutbr.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


I have found that in Single Unix Specification 2 in waitpid() function
there are allowed options not only WNOHANG and WUNTRACED as is in FreeBSD,
but furthermore option WCONTINUED (Unixware and Solaris both know about
this option and FreeBSD and possible Linux don't).

The next problem is in macro WIFCONTINUED(), which is specified
by SUS 2 too, but again in FreeBSD it is missing.

Are there any chances to satisfy SUS 2 in FreeBSD in waitpid() function?

-- 
Rudolf Cejka   (cejkar@dcse.fee.vutbr.cz;  http://www.fee.vutbr.cz/~cejkar)
Brno University of Technology, Faculty of El. Engineering and Comp. Science
Bozetechova 2, 612 66  Brno, Czech Republic


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20  7: 4:21 2000
Delivered-To: freebsd-current@freebsd.org
Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38])
	by hub.freebsd.org (Postfix) with ESMTP id 89DA037B811
	for <freebsd-current@FreeBSD.ORG>; Mon, 20 Mar 2000 07:04:18 -0800 (PST)
	(envelope-from obrien@NUXI.ucdavis.edu)
Received: from dragon.nuxi.com (root@d60-024.leach.ucdavis.edu [169.237.60.24])
	by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id HAA54872;
	Mon, 20 Mar 2000 07:04:18 -0800 (PST)
	(envelope-from obrien@dragon.nuxi.com)
Received: (from obrien@localhost)
	by dragon.nuxi.com (8.9.3/8.9.1) id HAA91563;
	Mon, 20 Mar 2000 07:04:11 -0800 (PST)
	(envelope-from obrien)
Date: Mon, 20 Mar 2000 07:04:11 -0800
From: "David O'Brien" <obrien@FreeBSD.ORG>
To: "Jose M. Alcaide" <jose@we.lc.ehu.es>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: suggestion: a g77 -> f77 link
Message-ID: <20000320070411.A91543@dragon.nuxi.com>
Reply-To: obrien@FreeBSD.ORG
References: <38CD1091.94E73AC9@we.lc.ehu.es> <20000314143826.D9311@dragon.nuxi.com> <vqcog8h9f3q.fsf@silvia.hip.berkeley.edu> <38D601E2.268BEB2B@we.lc.ehu.es>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <38D601E2.268BEB2B@we.lc.ehu.es>; from jose@we.lc.ehu.es on Mon, Mar 20, 2000 at 11:48:02AM +0100
X-Operating-System: FreeBSD 4.0-CURRENT
Organization: The NUXI BSD group
X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3  90 76 5D 69 58 D9 98 7A
X-Pgp-Keyid: 34F9F9D5
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Mon, Mar 20, 2000 at 11:48:02AM +0100, Jose M. Alcaide wrote:
> Now, a week after the discussion, what do you think about my proposal
> of the "g77" link under /usr/bin?

What part about "NO" was unclear?

-- 
-- David    (obrien@NUXI.com)


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20  7:55:48 2000
Delivered-To: freebsd-current@freebsd.org
Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9])
	by hub.freebsd.org (Postfix) with ESMTP id AFB4337B851
	for <freebsd-current@freebsd.org>; Mon, 20 Mar 2000 07:55:30 -0800 (PST)
	(envelope-from julian@elischer.org)
Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1])
	by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id HAA71202;
	Mon, 20 Mar 2000 07:55:25 -0800 (PST)
Date: Mon, 20 Mar 2000 07:55:24 -0800 (PST)
From: Julian Elischer <julian@elischer.org>
To: Cejka Rudolf <cejkar@dcse.fee.vutbr.cz>
Cc: freebsd-current@freebsd.org
Subject: Re: SUS/2 non-compliance in waitpid() function?
In-Reply-To: <20000320152801.A76099@dcse.fee.vutbr.cz>
Message-ID: <Pine.BSF.4.10.10003200752010.71150-100000@InterJet.elischer.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Adherance to standards is always a goal for FreeBSD.
If you wish to try implement this change, then your patches would make a 
good starting point for people to look and discuss.
(I say this because technically those parts of the kernel are not that
complex, but what is harder is finding people with time and
who are interested in the change).

Julian

On Mon, 20 Mar 2000, Cejka Rudolf wrote:

> 
> I have found that in Single Unix Specification 2 in waitpid() function
> there are allowed options not only WNOHANG and WUNTRACED as is in FreeBSD,
> but furthermore option WCONTINUED (Unixware and Solaris both know about
> this option and FreeBSD and possible Linux don't).
> 
> The next problem is in macro WIFCONTINUED(), which is specified
> by SUS 2 too, but again in FreeBSD it is missing.
> 
> Are there any chances to satisfy SUS 2 in FreeBSD in waitpid() function?
> 
> -- 
> Rudolf Cejka   (cejkar@dcse.fee.vutbr.cz;  http://www.fee.vutbr.cz/~cejkar)
> Brno University of Technology, Faculty of El. Engineering and Comp. Science
> Bozetechova 2, 612 66  Brno, Czech Republic
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message
> 



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20  8:16:11 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mail.freeride.com (mail.freeride.com [64.14.46.158])
	by hub.freebsd.org (Postfix) with ESMTP id E7EBE37B828
	for <freebsd-current@freebsd.org>; Mon, 20 Mar 2000 08:16:05 -0800 (PST)
	(envelope-from tim@freeride.com)
Received: from tryder ([216.33.50.62])
	by mail.freeride.com (8.9.1/8.9.1) with SMTP id LAA23111
	for <freebsd-current@freebsd.org>; Mon, 20 Mar 2000 11:15:51 -0500 (EST)
Message-ID: <007001bf9287$13b78de0$380aa8c0@tryder.freeride.com>
From: "Tim Ryder" <tim@freeride.com>
To: <freebsd-current@freebsd.org>
Subject: PCMCIA Maker Modem
Date: Mon, 20 Mar 2000 11:12:00 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

My pcmcia modem seems to show up as sio4 which does not exist on my system. 

It is a:
pcmcia maker modem 56k v.90 datafax modem


does any have the settings for this modem

i use a sony vaio PCG_V505VE

tim ryder
please cc me on this because i am not on the list

tim@freeride.com



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20  8:36:38 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mail.freeride.com (mail.freeride.com [64.14.46.158])
	by hub.freebsd.org (Postfix) with ESMTP id DF77737B66E
	for <freebsd-current@freebsd.org>; Mon, 20 Mar 2000 08:36:31 -0800 (PST)
	(envelope-from tim@freeride.com)
Received: from tryder ([216.33.50.62])
	by mail.freeride.com (8.9.1/8.9.1) with SMTP id LAA23849;
	Mon, 20 Mar 2000 11:36:12 -0500 (EST)
Message-ID: <007f01bf9289$ed842ae0$380aa8c0@tryder.freeride.com>
From: "Tim Ryder" <tim@freeride.com>
To: "Tim Ryder" <tim@mail.freeride.com>,
	<freebsd-current@freebsd.org>
Subject: Re: PCMCIA Maker Modem
Date: Mon, 20 Mar 2000 11:32:17 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Also how do i compile sio4 into my kernel

tim ryder

-----Original Message-----
From: Tim Ryder <tim@freeride.com>
To: freebsd-current@freebsd.org <freebsd-current@freebsd.org>
Date: Monday, March 20, 2000 11:12 AM
Subject: PCMCIA Maker Modem


>My pcmcia modem seems to show up as sio4 which does not exist on my system.
>
>It is a:
>pcmcia maker modem 56k v.90 datafax modem
>
>
>does any have the settings for this modem
>
>i use a sony vaio PCG_V505VE
>
>tim ryder
>please cc me on this because i am not on the list
>
>tim@freeride.com
>



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20  8:44:41 2000
Delivered-To: freebsd-current@freebsd.org
Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9])
	by hub.freebsd.org (Postfix) with ESMTP id D66C337B924
	for <freebsd-current@freebsd.org>; Mon, 20 Mar 2000 08:44:35 -0800 (PST)
	(envelope-from julian@elischer.org)
Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1])
	by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id IAA71349;
	Mon, 20 Mar 2000 08:44:24 -0800 (PST)
Date: Mon, 20 Mar 2000 08:44:23 -0800 (PST)
From: Julian Elischer <julian@elischer.org>
To: Tim Ryder <tim@freeride.com>
Cc: Tim Ryder <tim@mail.freeride.com>, freebsd-current@freebsd.org
Subject: Re: PCMCIA Maker Modem
In-Reply-To: <007f01bf9289$ed842ae0$380aa8c0@tryder.freeride.com>
Message-ID: <Pine.BSF.4.10.10003200842000.71150-100000@InterJet.elischer.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

you don't
it IS sio4
you need to make /dev/ entried for sio4
and they should work. sio4 has been created in the kernel dynamically by
the pcmcia code.
you can also look at the pccard.conf file in /etc
and rename it to make sio2 if you want.
however in that case you'd have to make sure that sio2 is NOT in your
kernel.

julian


On Mon, 20 Mar 2000, Tim Ryder wrote:

> Also how do i compile sio4 into my kernel
> 
> tim ryder
> 
> -----Original Message-----
> From: Tim Ryder <tim@freeride.com>
> To: freebsd-current@freebsd.org <freebsd-current@freebsd.org>
> Date: Monday, March 20, 2000 11:12 AM
> Subject: PCMCIA Maker Modem
> 
> 
> >My pcmcia modem seems to show up as sio4 which does not exist on my system.
> >
> >It is a:
> >pcmcia maker modem 56k v.90 datafax modem
> >
> >
> >does any have the settings for this modem
> >
> >i use a sony vaio PCG_V505VE
> >
> >tim ryder
> >please cc me on this because i am not on the list
> >
> >tim@freeride.com
> >
> 
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message
> 



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20  9:26:19 2000
Delivered-To: freebsd-current@freebsd.org
Received: from www.telemere.net (www.telemere.net [63.224.9.3])
	by hub.freebsd.org (Postfix) with ESMTP id 1176C37B8A5
	for <current@FreeBSD.org>; Mon, 20 Mar 2000 09:26:09 -0800 (PST)
	(envelope-from visigoth@telemere.net)
Received: by www.telemere.net (Postfix, from userid 1001)
	id 4C61570601; Mon, 20 Mar 2000 11:33:24 -0600 (CST)
Received: from localhost (localhost [127.0.0.1])
	by www.telemere.net (Postfix) with ESMTP
	id 4939B6C801; Mon, 20 Mar 2000 11:33:24 -0600 (CST)
Date: Mon, 20 Mar 2000 11:33:24 -0600 (CST)
From: Visigoth <visigoth@telemere.net>
To: Chris Piazza <cpiazza@jaxon.net>
Cc: current@FreeBSD.org
Subject: Re: 75 second delay using telnet/ssh (ipv6 related)
In-Reply-To: <20000319150009.A404@norn.ca.eu.org>
Message-ID: <Pine.BSF.4.21.0003201122310.25197-100000@www.telemere.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG



On Sun, 19 Mar 2000, Chris Piazza wrote:

> If I use telnet or ssh (there might be more programs,
> but I have only noticed these two so far), and supply a hostname to it,
> my machine is constantly requesting AAAA records, and finally after
> 75 seconds it requests and receives an A record from the nameserver.

    Could it be possible that you have "options inet6" in your
/etc/resolv.conf file?  This options causes calls for only AAAA records at
first and then if they fail, use A records. 

	According to Mr. Stevens (Unix Network Programing Vol 1
chapt 9.4) this option, or having the env. variable RES_OPTIONS=inet6 set
will cause the behavior you are describing... 

> Using ssh -4 or telnet -4 makes it work right away (of course), but
> I don't want to have to type that all the time. [program] ipv4address
> also works.

Hmmm...  I don't know but it seems that ssh -4 set's its own family to
AF_INET in all of it's calls to gethostbyname() rather than AF_INET6.
Thereby telling the resolver to only return A records....



Damieon Stark
Sr Unix System's Administrator
visigoth@telemere.net

__________________________________________________________

M$ Windows 2000 was built for the internet.
Unix *BUILT* the internet.
your call....
__________________________________________________________



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20  9:36:36 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id CB81037B8B9
	for <current@FreeBSD.ORG>; Mon, 20 Mar 2000 09:36:26 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id JAA70124;
	Mon, 20 Mar 2000 09:36:22 -0800 (PST)
	(envelope-from dillon)
Date: Mon, 20 Mar 2000 09:36:22 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003201736.JAA70124@apollo.backplane.com>
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc: current@FreeBSD.ORG
Subject: Re: patches for test / review 
References:  <18039.953549289@critter.freebsd.dk>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


:
:
:>    Kirk and I have already mapped out a plan to drastically update
:>    the buffer cache API which will encapsulate much of the state within
:>    the buffer cache module.
:
:Sounds good.  Combined with my stackable BIO plans that sounds like
:a really great win for FreeBSD.
:
:--
:Poul-Henning Kamp             FreeBSD coreteam member
:phk@FreeBSD.ORG               "Real hackers run -current on their laptop."

    I think so.  I can give -current a quick synopsis of the plan but I've
    probably forgotten some of the bits (note: the points below are not
    in any particular order):

    Probably the most important thing to keep in mind when reading over
    this list is to note that nearly all the changes being contemplated 
    can be implemented without breaking current interfaces, and the current
    interfaces can then be shifted over to the new interfaces one subsystem
    at a time (shift, test, shift, test, shift test) until none of the 
    original use remains.  At the point the support for the original API
    can be removed.

    * make VOP locking calls recursive.  That is, to obtain exclusive
      recursive locks by default rather then non-recursive locks.

    * cleanup all VOP_*() interfaces in regards to the special handling
      of the case where a locked vnode is passed, a locked vnode is
      returned, and the returned vnode happens to wind up being the same
      as the locked vnode (Allow a double-locked vnode on return and get
      rid of all the stupid code that juggles locks around to get around
      the non-recursive nature of current exclusive locks).

      VOP_LOOKUP is the most confused interface that needs cleaning up.

      With only a small amount of additional work, mainly KASERT's to
      catch potential problems, we should be able to turn on exclusive 
      recursion.  The VOP_*() interfaces will have to be fixed one at
      a time with VOP_LOOKUP topping the list.

    * Make exclusive buffer cache locks recursive.  Kirk has completed all
      the preliminary work on this and we should be able to just turn it
      on.  We just haven't gotten around to it (and the release got in the
      way).  This is necessary to support up and coming softupdates mechanisms
      (e.g. background fsck, snapshot dumps) as well as better-support device
      recursion.

    * Cleanup the buffer cache API (bread(), BUF_STRATEGY(), and so forth).
      Specifically, split out the call functionality such that the buffer
      cache can determine whether a buffer being obtained is going to be
      used for reading or writing.  At the moment we don't know if the system
      is going to dirty a buffer until after the fact and this has caused a
      lot of pain in regards to dealing with low-memory situations.

      getblk() -> getblk_sh() and getblk_ex()

	Obtain bp without issuing I/O, getting either a shared or exclusive
	lock on the bp.  With a shared lock you are allowed to issue READ
	I/O but you are not allowed to modify the contents of the buffer.
	With an exclusive lock you are allowed to issue both READ and WRITE
	I/O and you can modify the contents of the buffer.

      bread()  -> bread_sh() and bread_ex()

	Obtain and validate (issue read I/O as appropriate) a bp.  bread_sh()
	allows a buffer to be accessed but not modified or rewritten.
	bread_ex() allows a buffer to be modified and written.

    * Many uses of the buffer cache in the critical path do not actually 
      require the buffer data to be mapped into KVM.  For example, a number 
      of I/O devices need only the b_pages[] array and do not need a b_data
      mapping.  It would not take a huge amount of work to adjust the 
      uiomove*() interfaces appropriately.

      The general plan is to try remove whole portions of the current buffer
      cache funcitonality and shift them into the new vm_pager_*() API.  That
      is, to operate on VM Object's directly whenever possible.

      The idea for the buffer cache is to shift its functionality to one that
      is solely used to issue device I/O and to keep track of dirty areas for
      proper sequencing of I/O (e.g. softupdate's use of the buffer cache 
      to placemark I/O will not change).  The core buffer cache code would
      no longer map things to KVM with b_data, that functionality would be
      shifted to the VM Object vm_pager_*() API.  The buffer cache would
      continue to use the b_pages[] array mechanism to collect pages for I/O,
      for clustering, and so forth.


      It should be noted that the buffer cache's perceived slowness is almost
      entirely due to all the KVM manipulation it does for b_data, and that
      such manipulate is not necessary for the vast majority of the critical
      path:  Reading and writing file data (can run through the VM Object
      API), and issuing I/O (can avoid b_data KVM mappings entirely).  

      Meta data, such as mapping inodes and bitmap blocks, will almost
      certainly still require b_data mappings.  It would be much too much 
      work to change those at this time.  But meta-data is not in the critical
      path so this is not a big deal.

    * VOP_PUTPAGES() and VOP_GETPAGES().   During discussions with Tor on how 
      to implement O_DIRECT I/O (direct I/O that bypasses the buffer cache),
      We appear to have hit upon a solution that dovetails well into the
      other plans.

      The API change is to simply say that a VOP_PUTPAGES() and VOP_GETPAGES()
      calls are to become a lower level direct I/O interface that bypasses
      the buffer cache.  This would mean reimplmenting it in UFS (not 
      difficult) and a few other filesystems (because they currently fall 
      back to a degenerate case using the IO_VMIO flag and then running 
      through the normal I/O read-write VOP_*() calls, which obviously goes
      through the buffer cache).

      Only minor changes are required to the callers of VOP_PUTPAGES() /
      VOP_GETPAGES() - for the most part the callers *ALREADY* assume 
      a direct-I/O-ish interface.

      Additional advantages are glaringly obvious -- it instantly gives us
      an optimal path through the VFS layers for things like VN, CCD, and
      even vinum of Greg ever wants to support file-based vinum partitions.
      Not to mention an O_DIRECT file I/O flag (ala Solaris or IRIX but
      without the silly restrictions on mixed buffer-cache/non-buffer-cache
      I/O).

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20  9:46: 3 2000
Delivered-To: freebsd-current@freebsd.org
Received: from polaris.we.lc.ehu.es (polaris.we.lc.ehu.es [158.227.6.43])
	by hub.freebsd.org (Postfix) with ESMTP
	id 0D22C37B950; Mon, 20 Mar 2000 09:44:24 -0800 (PST)
	(envelope-from jose@we.lc.ehu.es)
Received: from we.lc.ehu.es (v-ger [158.227.6.179])
	by polaris.we.lc.ehu.es (8.9.1/8.9.1) with ESMTP id SAA28320;
	Mon, 20 Mar 2000 18:44:08 +0100 (MET)
Message-ID: <38D66364.9839CFF1@we.lc.ehu.es>
Date: Mon, 20 Mar 2000 18:44:04 +0100
From: "Jose M. Alcaide" <jose@we.lc.ehu.es>
Organization: Universidad del =?iso-8859-1?Q?Pa=EDs?= Vasco - Dpto. de Electricidad y 
	=?iso-8859-1?Q?Electr=F3nica?=
X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: es-ES, es, en-US, en
MIME-Version: 1.0
To: obrien@FreeBSD.ORG
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: suggestion: a g77 -> f77 link
References: <38CD1091.94E73AC9@we.lc.ehu.es> <20000314143826.D9311@dragon.nuxi.com> <vqcog8h9f3q.fsf@silvia.hip.berkeley.edu> <38D601E2.268BEB2B@we.lc.ehu.es> <20000320070411.A91543@dragon.nuxi.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

David O'Brien wrote:
> 
> On Mon, Mar 20, 2000 at 11:48:02AM +0100, Jose M. Alcaide wrote:
> > Now, a week after the discussion, what do you think about my proposal
> > of the "g77" link under /usr/bin?
> 
> What part about "NO" was unclear?
> 

Hey, OK, don't get upset! :-) You are the maintainer, so you have the
authority about this issue. Simply, I thought that, after explaining
my arguments and Satoshi giving his opinion, there was a chance that
you might changed your mind. If this not the case, well, forget it.
I'll do, too. End of discussion.

Regards,
-- JMA
-----------------------------------------------------------------------
José Mª Alcaide                         | mailto:jose@we.lc.ehu.es
Universidad del País Vasco              | mailto:jmas@FreeBSD.org
Dpto. de Electricidad y Electrónica     | http://www.we.lc.ehu.es/~jose
Facultad de Ciencias - Campus de Lejona | Tel.:  +34-946012479
48940 Lejona (Vizcaya) - SPAIN          | Fax:   +34-946013071
-----------------------------------------------------------------------
 "Beware of Programmers who carry screwdrivers"  --  Leonard Brandwein


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20  9:46:14 2000
Delivered-To: freebsd-current@freebsd.org
Received: from web2.sea.nwserv.com (web2.sea.nwserv.com [216.145.16.2])
	by hub.freebsd.org (Postfix) with ESMTP id 2C5E437B966
	for <current@freebsd.org>; Mon, 20 Mar 2000 09:46:03 -0800 (PST)
	(envelope-from spatula@spatula.net)
Received: from localhost (spatula@localhost [127.0.0.1])
	by web2.sea.nwserv.com (8.9.3/8.9.3) with ESMTP id JAA82231
	for <current@freebsd.org>; Mon, 20 Mar 2000 09:45:49 -0800 (PST)
	(envelope-from spatula@spatula.net)
Date: Mon, 20 Mar 2000 09:45:49 -0800 (PST)
From: Nick Johnson <freebsd@spatula.net>
X-Sender: spatula@web2.sea.nwserv.com
To: current@freebsd.org
Subject: syslogd_flags in /etc/defaults/rc.conf
Message-ID: <Pine.BSF.4.21.0003200935140.25240-100000@web2.sea.nwserv.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

I'm curious to see if anyone is like-minded with me that syslogd_flags in
/etc/defaults/rc.conf should be "-ss" instead of "".  I reasoned that it
should be, considering:

  1. Most people don't direct syslogs at other machines in my experience.
  2. Someone could conceivably DOS a machine by directing tons of crap at 
     port 121, which is also noted in the BUGS section of the syslogd
     manpage.
  3. Syslogd runs as root, and while it is a mature piece of code, I think
     it preferable to minimize the number of root applications listening
     on sockets.

   Nick

--
"Why do so many people concern themselves so much with the private
 affairs of complete strangers?"
 - Me
My PGP public key:    http://www.spatula.net/pubkey.txt
Nick Johnson, version 1.5	http://www.spatula.net/



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 10:16:19 2000
Delivered-To: freebsd-current@freebsd.org
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131])
	by hub.freebsd.org (Postfix) with ESMTP id 9E05737B893
	for <current@FreeBSD.ORG>; Mon, 20 Mar 2000 10:12:48 -0800 (PST)
	(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1])
	by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id TAA19792;
	Mon, 20 Mar 2000 19:12:22 +0100 (CET)
	(envelope-from phk@critter.freebsd.dk)
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: current@FreeBSD.ORG
Subject: Re: patches for test / review 
In-reply-to: Your message of "Mon, 20 Mar 2000 09:36:22 PST."
             <200003201736.JAA70124@apollo.backplane.com> 
Date: Mon, 20 Mar 2000 19:12:22 +0100
Message-ID: <19790.953575942@critter.freebsd.dk>
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <200003201736.JAA70124@apollo.backplane.com>, Matthew Dillon writes:

>    I think so.  I can give -current a quick synopsis of the plan but I've
>    probably forgotten some of the bits (note: the points below are not
>    in any particular order):

Thanks for the sketch.  It sounds really good.

Is it your intention that drivers which cannot work from the b_pages[]
array will call to map them into VM, or will a flag on the driver/dev_t/
whatever tell the generic code that it should be mapped before calling
the driver ?

What about unaligned raw transfers, say a raw CD read of 2352 bytes
from userland ?  I pressume we will need an offset into the first 
page for that ?

One thing I would like to see is for the buffers to know how to
write themselves.  There is nothing which mandates that a buffer
be backed by a disk-like device, and there are uses for buffers
which aren't.

Being able to say bp->bop_write(bp) rather than bwrite(bp) would
allow that flexibility.  Kirk already introduced a bio_ops[] but
made it global for now, that should be per buffer and have all the
bufferops in it, (except for the onces which instantiate the buffer).

If we had this, pseudo filesystems like DEVFS could use UFS for
much of their naming management.  This is currently impossible.

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 10:24:19 2000
Delivered-To: freebsd-current@freebsd.org
Received: from spirit.jaded.net (spirit.jaded.net [216.94.113.12])
	by hub.freebsd.org (Postfix) with ESMTP id E586537BB1C
	for <current@freebsd.org>; Mon, 20 Mar 2000 10:24:09 -0800 (PST)
	(envelope-from dan@spirit.jaded.net)
Received: (from dan@localhost)
	by spirit.jaded.net (8.9.3/8.9.3) id NAA02026
	for current@freebsd.org; Mon, 20 Mar 2000 13:24:33 -0500 (EST)
Date: Mon, 20 Mar 2000 13:24:33 -0500
From: Dan Moschuk <dan@freebsd.org>
To: current@freebsd.org
Subject: Re: emu10k1 (SB Live!) support under FreeBSD?
Message-ID: <20000320132433.B1790@spirit.jaded.net>
References: <Pine.GSO.4.10.10003191230190.3416-100000@isis.visi.com> <20000319155520.B82854@spirit.jaded.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <20000319155520.B82854@spirit.jaded.net>; from dan@FreeBSD.ORG on Sun, Mar 19, 2000 at 03:55:20PM -0500
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


| | I would love to help out, but I don't know where to start, and I have no
| | kernel programming experience.  There are reference drivers available for
| | linux via http://opensource.creative.com or http://www.alsa-project.org
| | (my preference).
| 
| One is on the way...

Cam's boredom out-weighed my initiative. 8)

http://www.freebsd.org/~cg/current.diff.gz contains a partial emu10k1
driver (minus recording) which is need of debugging.  Give it a try!

-- 
Dan Moschuk (TFreak!dan@freebsd.org)
"Waste not fresh tears on old griefs."


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 10:46:26 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id 8185A37B9C9
	for <current@FreeBSD.ORG>; Mon, 20 Mar 2000 10:46:20 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id KAA70820;
	Mon, 20 Mar 2000 10:46:15 -0800 (PST)
	(envelope-from dillon)
Date: Mon, 20 Mar 2000 10:46:15 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003201846.KAA70820@apollo.backplane.com>
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc: current@FreeBSD.ORG
Subject: Re: patches for test / review 
References:  <19790.953575942@critter.freebsd.dk>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

:Thanks for the sketch.  It sounds really good.
:
:Is it your intention that drivers which cannot work from the b_pages[]
:array will call to map them into VM, or will a flag on the driver/dev_t/
:whatever tell the generic code that it should be mapped before calling
:the driver ?
:
:What about unaligned raw transfers, say a raw CD read of 2352 bytes
:from userland ?  I pressume we will need an offset into the first 
:page for that ?

    Well, let me tell you what the fuzzy goal is first and then maybe we
    can work backwards.

    Eventually all physical I/O needs a physical address.  The quickest
    way to get to a physical address is to be given an array of vm_page_t's
    (which can be trivially translated to physical addresses).

    The buffer cache already has such an array, called b_pages[].

    Any I/O that runs through b_data or runs through a uio must eventually
    be cut up into blocks of contiguous physical addresses.

    What we want to do is to try to extend VMIO (aka the vm_page_t) all
    the way through the I/O system - both VFS and DEV I/O, in order to 
    remove all the nasty back and forth translations.

    In regards to raw devices I originally envisioned having two BUF_*()
    strategy calls - one that uses a page array, and one that uses b_data.
    But your idea below - using bio_ops[], is much better.

    In regards to odd block sizes and offsets the real question is whether
    an attempt should be made to translate UIO ops into buffer cache b_pages[]
    ops directly, maintaining offsets and odd sizes, or whether we should 
    back-off to a copy scheme where we allocate b_pages[] for oddly sized 
    uio's and then copy the data to the uio buffer.

    My personal preference is to not pollute the VMIO page-passing mechanism
    with all sorts of fields to handle weird offsets and sizes.  Instead we
    ought to take the copy hit for the non-optimal cases, and simply fix all
    the programs doing the accesses to pass optimally aligned buffers.  For
    example, for a raw-I/O on an audio CD track you would pass a page-aligned
    buffer with a request size of at least a page (e.g. 4K on IA32) in your
    read(), and the raw device would return '2352' as the result and the
    returned data would be page-aligned.

    This would allow the system call to use the b_pages[] strategy entry
    point even for devices with odd sizes and still get optimal (zero-copy)
    operation.  If the user passes a non-aligned (or mulitiple of a page-sized)
    buffer, the system takes the copy hit in order to keep the lower level
    I/O interface clean.

:One thing I would like to see is for the buffers to know how to
:write themselves.  There is nothing which mandates that a buffer
:be backed by a disk-like device, and there are uses for buffers
:which aren't.
:
:Being able to say bp->bop_write(bp) rather than bwrite(bp) would
:allow that flexibility.  Kirk already introduced a bio_ops[] but
:made it global for now, that should be per buffer and have all the
:bufferops in it, (except for the onces which instantiate the buffer).
:
:If we had this, pseudo filesystems like DEVFS could use UFS for
:much of their naming management.  This is currently impossible.
:
:--
:Poul-Henning Kamp             FreeBSD coreteam member
:phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
:FreeBSD -- It will take a long time before progress goes too far!

    I like the idea of dynamicizing bio_ops[] and using that to issue 
    struct buf based I/O.  It fits very nicely into the general idea of
    separating the VFS and DEV I/O interfaces (they are currently hopelessly
    intertwined).

    Actually, the more I think about it the more I'm willing to just say
    to hell with it and start doing all the changes all at once, in parallel,
    including the two patches you wanted reviewed earlier (though I would
    request that you not combine disparate patch funcitonalities into a 
    single patch set).  I agree with Julian on the point about IPSEC.

    Dynamicizing bio_ops[] ought to be trivial.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 10:52:48 2000
Delivered-To: freebsd-current@freebsd.org
Received: from yana.lemis.com (yana.lemis.com [192.109.197.140])
	by hub.freebsd.org (Postfix) with ESMTP id 27AA137B944
	for <freebsd-current@FreeBSD.ORG>; Mon, 20 Mar 2000 10:47:58 -0800 (PST)
	(envelope-from grog@mojave.worldwide.lemis.com)
Received: from mojave.worldwide.lemis.com ([216.88.157.130])
	by yana.lemis.com (8.8.8/8.8.8) with ESMTP id FAA12875
	for <freebsd-current@FreeBSD.ORG>; Tue, 21 Mar 2000 05:16:21 +1030 (CST)
	(envelope-from grog@mojave.worldwide.lemis.com)
Received: (from grog@localhost)
	by mojave.worldwide.lemis.com (8.9.3/8.9.3) id MAA00564;
	Sun, 19 Mar 2000 12:57:01 -0800 (PST)
	(envelope-from grog)
Date: Sun, 19 Mar 2000 12:57:01 -0800
From: Greg Lehey <grog@lemis.com>
To: Palle Girgensohn <girgen@partitur.se>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: 3 -> 4 when /usr is a vinum volume?
Message-ID: <20000319125700.D391@mojave.worldwide.lemis.com>
Reply-To: Greg Lehey <grog@lemis.com>
References: <38D2EB3E.C4548FCC@partitur.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <38D2EB3E.C4548FCC@partitur.se>; from girgen@partitur.se on Sat, Mar 18, 2000 at 03:34:38AM +0100
WWW-Home-Page: http://www.lemis.com/~grog
X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF  13 24 52 F8 6D A4 95 EF
Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8286
Fax: +61-8-8388-8725
Mobile: +61-41-739-7062
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

[Format recovered--see http://www.lemis.com/email/email-format.html]

On Saturday, 18 March 2000 at  3:34:38 +0100, Palle Girgensohn wrote:
> Hi!

Please don't send messages one line per paragraph.  It's a pain to
reformat.

> I'm having troubles updating a FreeBSD 3-stable system to current,
> since it has /usr as a vinum volume.  I've just updated about a dozen
> machines without any problems, but none of them uses vinum.
>
> Following the instructions in UPDATING, when rebooting to single
> user mode, vinum wouldn't work since the kernel module was out of
> date - no surprise.

Hmm.  After updating, you should have had new klds as well.  But
that's probably not your fault.  Could you enter a PR about it,
please?

> So, I copied a fresh vinum.ko in there and tried again. This time,
> vinum loaded fine, but complained that it couldn't get the list from
> disk (or similiar).

How similar?  That statement doesn't really help very much.  Vinum
produces error messages to help pinpoint problems.

> A 'vinum list' command would show nothing. So, I tried rebooting
> with the old 3-stable kernel. When makeing installworld running the
> 3-stable kernel, make first installed the make binary itself, and
> then could not do anything more, since the new libc was not in
> place, and the just installed make needed the new libc... odd? shall
> it really start by installing make? dunno how this happened?

It looks like you shot yourself in the foot.

> Anyway, what is a good strategy for upgrading a system where /usr is
> a vinum volume? Any tips, tricks or ideas (apart from moving /usr to
> a non-vinum volume and install onto that one).

I'd have to find out what went wrong first.  It looks as if it should
have worked modulo the problems installing the klds.

Greg
--
When replying to this message, please take care not to mutilate the
original text.
For more information, see http://www.lemis.com/email.html
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 10:52:59 2000
Delivered-To: freebsd-current@freebsd.org
Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20])
	by hub.freebsd.org (Postfix) with ESMTP id 64B2F37C32D
	for <current@FreeBSD.ORG>; Mon, 20 Mar 2000 10:52:47 -0800 (PST)
	(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
	by fw.wintelcom.net (8.10.0/8.10.0) id e2KJFjr00445;
	Mon, 20 Mar 2000 11:15:45 -0800 (PST)
Date: Mon, 20 Mar 2000 11:15:45 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, current@FreeBSD.ORG
Subject: Re: patches for test / review
Message-ID: <20000320111544.A14789@fw.wintelcom.net>
References: <18039.953549289@critter.freebsd.dk> <200003201736.JAA70124@apollo.backplane.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200003201736.JAA70124@apollo.backplane.com>; from dillon@apollo.backplane.com on Mon, Mar 20, 2000 at 09:36:22AM -0800
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

* Matthew Dillon <dillon@apollo.backplane.com> [000320 10:01] wrote:
> 
> :
> :
> :>    Kirk and I have already mapped out a plan to drastically update
> :>    the buffer cache API which will encapsulate much of the state within
> :>    the buffer cache module.
> :
> :Sounds good.  Combined with my stackable BIO plans that sounds like
> :a really great win for FreeBSD.
> :
> :--
> :Poul-Henning Kamp             FreeBSD coreteam member
> :phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
> 
>     I think so.  I can give -current a quick synopsis of the plan but I've
>     probably forgotten some of the bits (note: the points below are not
>     in any particular order):

....

>     * Cleanup the buffer cache API (bread(), BUF_STRATEGY(), and so forth).
>       Specifically, split out the call functionality such that the buffer
>       cache can determine whether a buffer being obtained is going to be
>       used for reading or writing.  At the moment we don't know if the system
>       is going to dirty a buffer until after the fact and this has caused a
>       lot of pain in regards to dealing with low-memory situations.
> 
>       getblk() -> getblk_sh() and getblk_ex()
> 
> 	Obtain bp without issuing I/O, getting either a shared or exclusive
> 	lock on the bp.  With a shared lock you are allowed to issue READ
> 	I/O but you are not allowed to modify the contents of the buffer.
> 	With an exclusive lock you are allowed to issue both READ and WRITE
> 	I/O and you can modify the contents of the buffer.
> 
>       bread()  -> bread_sh() and bread_ex()
> 
> 	Obtain and validate (issue read I/O as appropriate) a bp.  bread_sh()
> 	allows a buffer to be accessed but not modified or rewritten.
> 	bread_ex() allows a buffer to be modified and written.

This seems to allow for expressing intent to write to buffers,
which would be an excellent place to cow the pages 'in software'
rather than obsd's way of using cow'd pages to accomplish the same
thing.

I'm not sure if you remeber what I brought up at BAFUG, but I'd
like to see something along the lines of BX_BKGRDWRITE that Kirk
is using for the bitmaps blocks in softupdates to be enabled on a
system wide basis.  That way rewriting data that has been sent to
the driver isn't blocked and at the same time we don't need to page
protect during every strategy call.

I may have misunderstood your intent, but using page protections
on each IO would seem to introduce a lot of performance issues that
the rest of these points are all trying to get rid of.

>       The idea for the buffer cache is to shift its functionality to one that
>       is solely used to issue device I/O and to keep track of dirty areas for
>       proper sequencing of I/O (e.g. softupdate's use of the buffer cache 
>       to placemark I/O will not change).  The core buffer cache code would
>       no longer map things to KVM with b_data, that functionality would be
>       shifted to the VM Object vm_pager_*() API.  The buffer cache would
>       continue to use the b_pages[] array mechanism to collect pages for I/O,
>       for clustering, and so forth.

Keeping the currect cluster code is a bad idea, if the drivers were
taught how to traverse the linked list in the buf struct rather
than just notice "a big buffer" we could avoid a lot of page
twiddling and also allow for massive IO clustering ( > 64k ) because
we won't be limited by the size of the b_pages[] array for our
upper bound on the amount of buffers we can issue effectively a
scatter/gather on (since the drivers must VTOPHYS them anyway).

To realize my "nfs super commit" stuff all we'd need to do is make
the max cluster size something like 0-1 and instantly get an almost
unbounded IO burst.

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 10:56:26 2000
Delivered-To: freebsd-current@freebsd.org
Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87])
	by hub.freebsd.org (Postfix) with ESMTP id 3384C37C2A7
	for <current@FreeBSD.ORG>; Mon, 20 Mar 2000 10:56:20 -0800 (PST)
	(envelope-from dcs@newsguy.com)
Received: from newsguy.com (p39-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.104])
	by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id DAA12413;
	Tue, 21 Mar 2000 03:55:49 +0900 (JST)
Message-ID: <38D67177.BEE573D8@newsguy.com>
Date: Tue, 21 Mar 2000 03:44:07 +0900
From: "Daniel C. Sobral" <dcs@newsguy.com>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en,pt-BR,ja
MIME-Version: 1.0
To: Jeroen Ruigrok van der Werven <asmodai@bart.nl>
Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>,
	Peter Wemm <peter@netplex.com.au>, current@FreeBSD.ORG
Subject: Re: HEADS UP; new options for -current!
References: <20000319131447.E6EF21CD9@overcee.netplex.com.au> <14762.953494736@critter.freebsd.dk> <20000320133659.I95266@lucifer.bart.nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Jeroen Ruigrok van der Werven wrote:
> 
> I already addressed that in new-bus and there is some discussion and
> finding out the best way to do a higher level wrapping for a lot of
> newbus' stuff.

Is there? Where? I don't recall seeing that in any of the newbus mailing
lists I (used to) subscribe to.

--
Daniel C. Sobral			(8-DCS)
dcs@newsguy.com
dcs@freebsd.org

	One Unix to rule them all, One Resolver to find them,
        One IP to bring them all and in the zone bind them.



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 11: 1:45 2000
Delivered-To: freebsd-current@freebsd.org
Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7])
	by hub.freebsd.org (Postfix) with ESMTP id 6227837C346
	for <freebsd-current@FreeBSD.ORG>; Mon, 20 Mar 2000 11:01:36 -0800 (PST)
	(envelope-from archie@whistle.com)
Received: (from archie@localhost)
	by bubba.whistle.com (8.9.3/8.9.2) id LAA05709;
	Mon, 20 Mar 2000 11:00:57 -0800 (PST)
From: Archie Cobbs <archie@whistle.com>
Message-Id: <200003201900.LAA05709@bubba.whistle.com>
Subject: Re: kern/8324
In-Reply-To: <200003181152.DAA29093@salsa.gv.tsc.tdk.com> from Don Lewis at "Mar 18, 2000 03:52:54 am"
To: Don.Lewis@tsc.tdk.com (Don Lewis)
Date: Mon, 20 Mar 2000 11:00:57 -0800 (PST)
Cc: bright@wintelcom.net (Alfred Perlstein),
	freebsd-current@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Don Lewis writes:
> } * Archie Cobbs <archie@whistle.com> [000317 17:55] wrote:
> } > This bug has been around since at least 2.2.6 and is still present
> } > in RELENG_3, RELENG_4, and -current.
> } > 
> } >   http://www.freebsd.org/cgi/query-pr.cgi?pr=8324
> } > 
> } > Is anyone planning to tackle it? What would be required to fix it?
> } > (it's not clear (to me anyway) from Bruce's description how hard
> } > this is to fix..)
> 
> I never heard of using SIGIO for output, but section 6.4 of the daemon
> book says that SIGIO is sent "when a read or write becomes possible".
> On the other hand, section 10.8 (Terminal Operations) mentions SIGIO 
> for input but not for output.  I also looked at rev 1.1 of kern/tty.c
> and it only sends a SIGIO when input is ready, so this seems to be
> the historical behaviour, so I'm suprised that this program even
> worked with plain tty devices.
> 
> } I think Bruce sort of went off into a tangent with his diagnosis,
> } anyhow this is untested (of course :) ), but looks like the right
> } thing to do (from sys_pipe.c).
> } 
> } Perhaps the fcntls and ioctls aren't being propogated enough to set
> } the flags properly, but if they are then it should work sort of the
> } way SIGIO does, basically generating a signal for /some condition/
> } on a descriptor.
> 
> This patch (vs the 3.4-STABLE version of tty.c) causes SIGIO to be
> sent when a regular or pseudo tty becomes writeable.
> 
> 
> --- tty.c.orig	Sun Aug 29 09:26:09 1999
> +++ tty.c	Sat Mar 18 03:09:32 2000
> @@ -2133,6 +2133,8 @@
>  
>  	if (tp->t_wsel.si_pid != 0 && tp->t_outq.c_cc <= tp->t_olowat)
>  		selwakeup(&tp->t_wsel);
> +	if (ISSET(tp->t_state, TS_ASYNC) && tp->t_sigio != NULL)
> +		pgsigio(tp->t_sigio, SIGIO, (tp->t_session != NULL));
>  	if (ISSET(tp->t_state, TS_BUSY | TS_SO_OCOMPLETE) ==
>  	    TS_SO_OCOMPLETE && tp->t_outq.c_cc == 0) {
>  		CLR(tp->t_state, TS_SO_OCOMPLETE);
> 
> 
> BTW, I had to add:
> 	fcntl(1, F_SETOWN, getpid());
> to the test program since there is no longer a default target to send
> the signal to.  The old scheme had the defect of sending SIGIO to the
> process group that owned the terminal, which implied that the terminal
> had to be the controlling terminal for the process group.  This limited
> a process to only receiving SIGIO from one terminal device even if it
> had more than one open and it wanted to receive SIGIO from all of them.
> Also, SIGIO was sent to the entire process group, but it may be desireable
> to limit this to one process.  I wonder if it might make sense to go
> back to the old default for tty devices so that processes only receive
> SIGIO when they are in the foreground ...

Don-

After applying your patch to kern/tty.c and adding the F_SETOWN,
the problem indeed seems to go away..

Is this patch ready to be committed, or do we need more reviewers?

Thanks,
-Archie

___________________________________________________________________________
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 11: 4:18 2000
Delivered-To: freebsd-current@freebsd.org
Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7])
	by hub.freebsd.org (Postfix) with ESMTP id 87BE137C2B1
	for <freebsd-current@FreeBSD.ORG>; Mon, 20 Mar 2000 11:04:10 -0800 (PST)
	(envelope-from archie@whistle.com)
Received: (from archie@localhost)
	by bubba.whistle.com (8.9.3/8.9.2) id LAA05714;
	Mon, 20 Mar 2000 11:03:07 -0800 (PST)
From: Archie Cobbs <archie@whistle.com>
Message-Id: <200003201903.LAA05714@bubba.whistle.com>
Subject: Re: ICMP socket weirdness
In-Reply-To: <200003181954.OAA77677@khavrinen.lcs.mit.edu> from Garrett Wollman at "Mar 18, 2000 02:54:26 pm"
To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman)
Date: Mon, 20 Mar 2000 11:03:07 -0800 (PST)
Cc: freebsd-current@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Garrett Wollman writes:
> > When the program is run, if you ping the IP address from the
> > local machine, it sees packets.  However, if you ping it from
> > a remote machine, it doesn't see packets.
> 
> The ICMP never passes certain packets up to raw listeners.  These
> include ECHO REQUEST, TIMESTAMP REQUEST, and SUBNET MASK REQUEST
> packets -- but not the corresponding replies!  So, when you ping the
> local machine, you will see the ECHO REPLY packets on all raw
> listners, but not the initial ECHO REQUESTs.  When you ping from a
> remote machine, you never see the ECHO REQUEST packets because the
> kernel takes care of them, and you never see the ECHO REPLY packets
> because they are addressed to the other machine.

Is this a FreeBSD-specific thing, or to other UNIX's have this
same peculiar behavior?

> It would be possible to pass all ICMP packets to the raw listeners,
> but it would require rewriting parts of icmp_input() (which would not
> be a bad idea) either to avoid modifying the packet in-place or to
> keep a copy of the original before responding -- either of which would
> slow down `ping' processing.

The existence of m_dup() makes the latter option a lot easier..

-Archie

___________________________________________________________________________
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 11:17:20 2000
Delivered-To: freebsd-current@freebsd.org
Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193])
	by hub.freebsd.org (Postfix) with ESMTP id 21D1C37BB27
	for <current@FreeBSD.ORG>; Mon, 20 Mar 2000 11:16:42 -0800 (PST)
	(envelope-from wollman@khavrinen.lcs.mit.edu)
Received: (from wollman@localhost)
	by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id OAA88583;
	Mon, 20 Mar 2000 14:16:09 -0500 (EST)
	(envelope-from wollman)
Date: Mon, 20 Mar 2000 14:16:09 -0500 (EST)
From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Message-Id: <200003201916.OAA88583@khavrinen.lcs.mit.edu>
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: current@FreeBSD.ORG
Subject: Buffer cache renovation
In-Reply-To: <200003201736.JAA70124@apollo.backplane.com>
References: <18039.953549289@critter.freebsd.dk>
	<200003201736.JAA70124@apollo.backplane.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

<<On Mon, 20 Mar 2000 09:36:22 -0800 (PST), Matthew Dillon <dillon@apollo.backplane.com> said:

>     I think so.  I can give -current a quick synopsis of the plan but I've
>     probably forgotten some of the bits (note: the points below are not
>     in any particular order):

Cool!  Sounds like you've really done a lot of work to clean up one of
the darkest corners of the kernel.  I can't wait to see the results.

-GAWollman



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 11:20:51 2000
Delivered-To: freebsd-current@freebsd.org
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131])
	by hub.freebsd.org (Postfix) with ESMTP id 497F537C721
	for <current@FreeBSD.ORG>; Mon, 20 Mar 2000 11:17:28 -0800 (PST)
	(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1])
	by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id UAA20076;
	Mon, 20 Mar 2000 20:17:13 +0100 (CET)
	(envelope-from phk@critter.freebsd.dk)
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: current@FreeBSD.ORG
Subject: Re: patches for test / review 
In-reply-to: Your message of "Mon, 20 Mar 2000 10:46:15 PST."
             <200003201846.KAA70820@apollo.backplane.com> 
Date: Mon, 20 Mar 2000 20:17:13 +0100
Message-ID: <20074.953579833@critter.freebsd.dk>
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <200003201846.KAA70820@apollo.backplane.com>, Matthew Dillon writes:

>    Well, let me tell you what the fuzzy goal is first and then maybe we
>    can work backwards.
>
>    Eventually all physical I/O needs a physical address.  The quickest
>    way to get to a physical address is to be given an array of vm_page_t's
>    (which can be trivially translated to physical addresses).

Not all:
PIO access to ATA needs virtual access.
RAID5 needs virtual access to calculate parity.

>    What we want to do is to try to extend VMIO (aka the vm_page_t) all
>    the way through the I/O system - both VFS and DEV I/O, in order to 
>    remove all the nasty back and forth translations.

I agree, but some drivers need mapping we need to cater for those.
They could simply call a vm_something(struct buf *) call which would
map the pages and things would "just work".

For RAID5 we have the opposite problem also:  data is created which
has only a mapped existance and the b_pages[] array is not populated.

>    In regards to odd block sizes and offsets the real question is whether
>    an attempt should be made to translate UIO ops into buffer cache b_pages[]
>    ops directly, maintaining offsets and odd sizes, or whether we should 
>    back-off to a copy scheme where we allocate b_pages[] for oddly sized 
>    uio's and then copy the data to the uio buffer.

I don't know of any non DEV_BSIZE aligned apps that are sufficiently 
high-profile and high-performance to justify too much code to avoid
a copy operation, so I guess that is OK.

>    My personal preference is to not pollute the VMIO page-passing mechanism
>    with all sorts of fields to handle weird offsets and sizes.  Instead we
>    ought to take the copy hit for the non-optimal cases, and simply fix all
>    the programs doing the accesses to pass optimally aligned buffers.  For
>    example, for a raw-I/O on an audio CD track you would pass a page-aligned
>    buffer with a request size of at least a page (e.g. 4K on IA32) in your
>    read(), and the raw device would return '2352' as the result and the
>    returned data would be page-aligned.

No protest from here.  Encouraging people to think about their data
and the handling of them will always have my vote :-)


--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 11:22:52 2000
Delivered-To: freebsd-current@freebsd.org
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131])
	by hub.freebsd.org (Postfix) with ESMTP id 0EBCE37B966
	for <current@FreeBSD.ORG>; Mon, 20 Mar 2000 11:22:41 -0800 (PST)
	(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1])
	by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id UAA20104;
	Mon, 20 Mar 2000 20:21:52 +0100 (CET)
	(envelope-from phk@critter.freebsd.dk)
To: Alfred Perlstein <bright@wintelcom.net>
Cc: Matthew Dillon <dillon@apollo.backplane.com>, current@FreeBSD.ORG
Subject: Re: patches for test / review 
In-reply-to: Your message of "Mon, 20 Mar 2000 11:15:45 PST."
             <20000320111544.A14789@fw.wintelcom.net> 
Date: Mon, 20 Mar 2000 20:21:52 +0100
Message-ID: <20102.953580112@critter.freebsd.dk>
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <20000320111544.A14789@fw.wintelcom.net>, Alfred Perlstein writes:

>Keeping the currect cluster code is a bad idea, if the drivers were
>taught how to traverse the linked list in the buf struct rather
>than just notice "a big buffer" we could avoid a lot of page
>twiddling and also allow for massive IO clustering ( > 64k ) 

Before we redesign the clustering, I would like to know if we
actually have any recent benchmarks which prove that clustering
is overall beneficial ?

I would think that track-caches and intelligent drives would gain
much if not more of what clustering was designed to do gain.

I seem to remember Bruce saying that clustering could even hurt ?

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 11:36:22 2000
Delivered-To: freebsd-current@freebsd.org
Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20])
	by hub.freebsd.org (Postfix) with ESMTP id B111137B989
	for <current@FreeBSD.ORG>; Mon, 20 Mar 2000 11:36:17 -0800 (PST)
	(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
	by fw.wintelcom.net (8.10.0/8.10.0) id e2KJx2T01429;
	Mon, 20 Mar 2000 11:59:02 -0800 (PST)
Date: Mon, 20 Mar 2000 11:59:02 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc: Matthew Dillon <dillon@apollo.backplane.com>, current@FreeBSD.ORG
Subject: Re: patches for test / review
Message-ID: <20000320115902.C14789@fw.wintelcom.net>
References: <20000320111544.A14789@fw.wintelcom.net> <20102.953580112@critter.freebsd.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <20102.953580112@critter.freebsd.dk>; from phk@critter.freebsd.dk on Mon, Mar 20, 2000 at 08:21:52PM +0100
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

* Poul-Henning Kamp <phk@critter.freebsd.dk> [000320 11:45] wrote:
> In message <20000320111544.A14789@fw.wintelcom.net>, Alfred Perlstein writes:
> 
> >Keeping the currect cluster code is a bad idea, if the drivers were
> >taught how to traverse the linked list in the buf struct rather
> >than just notice "a big buffer" we could avoid a lot of page
> >twiddling and also allow for massive IO clustering ( > 64k ) 
> 
> Before we redesign the clustering, I would like to know if we
> actually have any recent benchmarks which prove that clustering
> is overall beneficial ?

Yes it is really benificial.

I'm not talking about a redesign of the clustering code as much as
making the drivers that take a callback from it actually traverse
the 'union cluster_info' rather than relying on the system to fake
the pages being contiguous via remapping.

There's nothing wrong with the clustering algorithms, it's just the
steps it has to take to work with the drivers.

> 
> I would think that track-caches and intelligent drives would gain
> much if not more of what clustering was designed to do gain.
> 
> I seem to remember Bruce saying that clustering could even hurt ?

Yes because of the gyrations it needs to go through to maintain backward
compatibility for devices that want to see "one big buffer" rather than
simply follow a linked list of io operations.

Not true, at least for 'devices' like NFS where large IO ops issued
save milliseconds in overhead.  Unless each device was to re-buffer
IO (which is silly) or scan the vp passed to it (violating the
adstraction and being really scary like my flopped super-commit
stuff for NFS) it would make NFS performance even worse for doing
commits.

Without clustering you'd have to issue a commit RPC for each 8k block
With the current clustering you have to issue a commit for each 64k
block
With an unbounded linked list, well there is only the limit that the
filesystem asks for.

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 11:42:54 2000
Delivered-To: freebsd-current@freebsd.org
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131])
	by hub.freebsd.org (Postfix) with ESMTP id ABAEB37B9DE
	for <current@FreeBSD.ORG>; Mon, 20 Mar 2000 11:40:55 -0800 (PST)
	(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1])
	by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id UAA20213;
	Mon, 20 Mar 2000 20:40:41 +0100 (CET)
	(envelope-from phk@critter.freebsd.dk)
To: Alfred Perlstein <bright@wintelcom.net>
Cc: Matthew Dillon <dillon@apollo.backplane.com>, current@FreeBSD.ORG
Subject: Re: patches for test / review 
In-reply-to: Your message of "Mon, 20 Mar 2000 11:59:02 PST."
             <20000320115902.C14789@fw.wintelcom.net> 
Date: Mon, 20 Mar 2000 20:40:41 +0100
Message-ID: <20211.953581241@critter.freebsd.dk>
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <20000320115902.C14789@fw.wintelcom.net>, Alfred Perlstein writes:
>* Poul-Henning Kamp <phk@critter.freebsd.dk> [000320 11:45] wrote:
>> In message <20000320111544.A14789@fw.wintelcom.net>, Alfred Perlstein writes:
>> 
>> >Keeping the currect cluster code is a bad idea, if the drivers were
>> >taught how to traverse the linked list in the buf struct rather
>> >than just notice "a big buffer" we could avoid a lot of page
>> >twiddling and also allow for massive IO clustering ( > 64k ) 
>> 
>> Before we redesign the clustering, I would like to know if we
>> actually have any recent benchmarks which prove that clustering
>> is overall beneficial ?
>
>Yes it is really benificial.

I would like to see some numbers if you have them.

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 11:47:11 2000
Delivered-To: freebsd-current@freebsd.org
Received: from veldy.net (veldy-host201.dsl.visi.com [208.42.48.201])
	by hub.freebsd.org (Postfix) with ESMTP
	id 9C89137B9DE; Mon, 20 Mar 2000 11:47:07 -0800 (PST)
	(envelope-from veldy@veldy.net)
Received: from veldy (cascade.veldy.net [192.168.0.1])
	by veldy.net (Postfix) with SMTP
	id B93701915; Mon, 20 Mar 2000 13:50:14 -0600 (CST)
Message-ID: <001e01bf92a5$41a2a320$0100a8c0@veldy.net>
From: "Thomas T. Veldhouse" <veldy@veldy.net>
To: "Dan Moschuk" <dan@freebsd.org>, <current@freebsd.org>
References: <Pine.GSO.4.10.10003191230190.3416-100000@isis.visi.com> <20000319155520.B82854@spirit.jaded.net> <20000320132433.B1790@spirit.jaded.net>
Subject: Re: emu10k1 (SB Live!) support under FreeBSD?
Date: Mon, 20 Mar 2000 13:48:25 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> 
> Cam's boredom out-weighed my initiative. 8)
> 
> http://www.freebsd.org/~cg/current.diff.gz contains a partial emu10k1
> driver (minus recording) which is need of debugging.  Give it a try!


How current is this?  Will it work against 4.0-STABLE?

Tom Veldhouse
veldy@visi.com



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 12: 4:59 2000
Delivered-To: freebsd-current@freebsd.org
Received: from norn.ca.eu.org (cr965240-b.abtsfd1.bc.wave.home.com [24.113.19.137])
	by hub.freebsd.org (Postfix) with ESMTP id A316337C641
	for <current@FreeBSD.ORG>; Mon, 20 Mar 2000 12:04:02 -0800 (PST)
	(envelope-from cpiazza@norn.ca.eu.org)
Received: by norn.ca.eu.org (Postfix, from userid 1000)
	id E4259199C; Mon, 20 Mar 2000 12:02:21 -0800 (PST)
Date: Mon, 20 Mar 2000 12:02:21 -0800
From: Chris Piazza <cpiazza@jaxon.net>
To: Visigoth <visigoth@telemere.net>
Cc: current@FreeBSD.ORG
Subject: Re: 75 second delay using telnet/ssh (ipv6 related)
Message-ID: <20000320120221.A517@norn.ca.eu.org>
References: <20000319150009.A404@norn.ca.eu.org> <Pine.BSF.4.21.0003201122310.25197-100000@www.telemere.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <Pine.BSF.4.21.0003201122310.25197-100000@www.telemere.net>; from visigoth@telemere.net on Mon, Mar 20, 2000 at 11:33:24AM -0600
X-Operating-System: FreeBSD 5.0-CURRENT i386
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Mon, Mar 20, 2000 at 11:33:24AM -0600, Visigoth wrote:
> 
> 
> On Sun, 19 Mar 2000, Chris Piazza wrote:
> 
> > If I use telnet or ssh (there might be more programs,
> > but I have only noticed these two so far), and supply a hostname to it,
> > my machine is constantly requesting AAAA records, and finally after
> > 75 seconds it requests and receives an A record from the nameserver.
> 
>     Could it be possible that you have "options inet6" in your
> /etc/resolv.conf file?  This options causes calls for only AAAA records at
> first and then if they fail, use A records. 
> 
> 	According to Mr. Stevens (Unix Network Programing Vol 1
> chapt 9.4) this option, or having the env. variable RES_OPTIONS=inet6 set
> will cause the behavior you are describing... 

No, neither of those.  FreeBSD searches inet6 first at the moment.
I don't know if I made this clear in my email, but this just started
happening... Hmm... it's fixed again:

12:01:15.622122 24.113.19.137.1253 > 24.2.10.36.53:  61892+ AAAA? beast.freebsd.org. (35)
12:01:15.706319 24.2.10.36.53 > 24.113.19.137.1253:  61892 1/1/0 (132)
12:01:15.707070 24.113.19.137.1254 > 24.2.10.36.53:  61893+ A? beast.freebsd.org. (35)
12:01:15.750017 24.2.10.36.53 > 24.113.19.137.1254:  61893 2/4/4 (238)

Weird.

> 
> > Using ssh -4 or telnet -4 makes it work right away (of course), but
> > I don't want to have to type that all the time. [program] ipv4address
> > also works.
> 
> Hmmm...  I don't know but it seems that ssh -4 set's its own family to
> AF_INET in all of it's calls to gethostbyname() rather than AF_INET6.
> Thereby telling the resolver to only return A records....

Right.

-Chris
-- 
cpiazza@jaxon.net   cpiazza@FreeBSD.org
        Abbotsford, BC, Canada


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 12:11:23 2000
Delivered-To: freebsd-current@freebsd.org
Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193])
	by hub.freebsd.org (Postfix) with ESMTP id 2967737C067
	for <freebsd-current@FreeBSD.ORG>; Mon, 20 Mar 2000 12:11:15 -0800 (PST)
	(envelope-from wollman@khavrinen.lcs.mit.edu)
Received: (from wollman@localhost)
	by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id PAA88925;
	Mon, 20 Mar 2000 15:11:04 -0500 (EST)
	(envelope-from wollman)
Date: Mon, 20 Mar 2000 15:11:04 -0500 (EST)
From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Message-Id: <200003202011.PAA88925@khavrinen.lcs.mit.edu>
To: Archie Cobbs <archie@whistle.com>
Cc: wollman@khavrinen.lcs.mit.edu (Garrett Wollman),
	freebsd-current@FreeBSD.ORG
Subject: Re: ICMP socket weirdness
In-Reply-To: <200003201903.LAA05714@bubba.whistle.com>
References: <200003181954.OAA77677@khavrinen.lcs.mit.edu>
	<200003201903.LAA05714@bubba.whistle.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

<<On Mon, 20 Mar 2000 11:03:07 -0800 (PST), Archie Cobbs <archie@whistle.com> said:

[Quoting my original description of icmp_input()'s behavior:]

>> The ICMP never passes certain packets up to raw listeners.  These
>> include ECHO REQUEST, TIMESTAMP REQUEST, and SUBNET MASK REQUEST
>> packets -- but not the corresponding replies!  So, when you ping the
>> local machine, you will see the ECHO REPLY packets on all raw
>> listners, but not the initial ECHO REQUESTs.  When you ping from a
>> remote machine, you never see the ECHO REQUEST packets because the
>> kernel takes care of them, and you never see the ECHO REPLY packets
>> because they are addressed to the other machine.

> Is this a FreeBSD-specific thing, or to other UNIX's have this
> same peculiar behavior?

It was the same in 4.3.  I don't have 4.2 sources handy so I can't
check there -- but in any case, the answers to your questions are
``no'' and ``yes''.  The raw ICMP socket is defined to only see the
traffic which the kernel is unable to handle itself.

-GAWollman



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 12:47: 2 2000
Delivered-To: freebsd-current@freebsd.org
Received: from pebkac.owp.csus.edu (pebkac.owp.csus.edu [130.86.232.245])
	by hub.freebsd.org (Postfix) with ESMTP id 672D137C89E
	for <current@FreeBSD.ORG>; Mon, 20 Mar 2000 12:27:13 -0800 (PST)
	(envelope-from joseph.scott@owp.csus.edu)
Received: from owp.csus.edu (mail.owp.csus.edu [130.86.232.247])
	by pebkac.owp.csus.edu (8.9.3/8.9.3) with ESMTP id MAA28361;
	Mon, 20 Mar 2000 12:27:01 -0800 (PST)
	(envelope-from joseph.scott@owp.csus.edu)
Message-ID: <38D68991.4ABDF92D@owp.csus.edu>
Date: Mon, 20 Mar 2000 12:26:57 -0800
From: Joseph Scott <joseph.scott@owp.csus.edu>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.36 i386)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Nick Johnson <freebsd@spatula.net>
Cc: current@FreeBSD.ORG
Subject: Re: syslogd_flags in /etc/defaults/rc.conf
References: <Pine.BSF.4.21.0003200935140.25240-100000@web2.sea.nwserv.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


Nick Johnson wrote:
> 
> I'm curious to see if anyone is like-minded with me that syslogd_flags in
> /etc/defaults/rc.conf should be "-ss" instead of "".  I reasoned that it
> should be, considering:
> 
>   1. Most people don't direct syslogs at other machines in my experience.

	While I am one of those people that does redirect syslogs to other
machines, I agree with your change.

>   2. Someone could conceivably DOS a machine by directing tons of crap at
>      port 121, which is also noted in the BUGS section of the syslogd
>      manpage.
>   3. Syslogd runs as root, and while it is a mature piece of code, I think
>      it preferable to minimize the number of root applications listening
>      on sockets.
> 
>    Nick

-- 

Joseph Scott
joseph.scott@owp.csus.edu
Office Of Water Programs - CSU Sacramento


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 12:47: 5 2000
Delivered-To: freebsd-current@freebsd.org
Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20])
	by hub.freebsd.org (Postfix) with ESMTP
	id 197E037C62C; Mon, 20 Mar 2000 12:30:44 -0800 (PST)
	(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
	by fw.wintelcom.net (8.10.0/8.10.0) id e2KKrIv02735;
	Mon, 20 Mar 2000 12:53:18 -0800 (PST)
Date: Mon, 20 Mar 2000 12:53:17 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc: Matthew Dillon <dillon@apollo.backplane.com>,
	current@FreeBSD.ORG, bde@FreeBSD.ORG
Subject: I/O clustering, Re: patches for test / review
Message-ID: <20000320125317.E14789@fw.wintelcom.net>
References: <20000320115902.C14789@fw.wintelcom.net> <20211.953581241@critter.freebsd.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <20211.953581241@critter.freebsd.dk>; from phk@critter.freebsd.dk on Mon, Mar 20, 2000 at 08:40:41PM +0100
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

* Poul-Henning Kamp <phk@critter.freebsd.dk> [000320 12:03] wrote:
> In message <20000320115902.C14789@fw.wintelcom.net>, Alfred Perlstein writes:
> >* Poul-Henning Kamp <phk@critter.freebsd.dk> [000320 11:45] wrote:
> >> In message <20000320111544.A14789@fw.wintelcom.net>, Alfred Perlstein writes:
> >> 
> >> >Keeping the currect cluster code is a bad idea, if the drivers were
> >> >taught how to traverse the linked list in the buf struct rather
> >> >than just notice "a big buffer" we could avoid a lot of page
> >> >twiddling and also allow for massive IO clustering ( > 64k ) 
> >> 
> >> Before we redesign the clustering, I would like to know if we
> >> actually have any recent benchmarks which prove that clustering
> >> is overall beneficial ?
> >
> >Yes it is really benificial.
> 
> I would like to see some numbers if you have them.

No I don't have numbers.

Committing a 64k block would require 8 times the overhead of bundling
up the RPC as well as transmission and reply, it may be possible
to pipeline these commits because you don't really need to wait
for one to complete before issueing another request, but it's still
8x the amount of traffic.

You also complicate and penalize drivers because not all drivers
can add an IO request to an already started transaction, those
devices will need to start new transactions for each buffer instead
of bundling up the list and passing it all along.

Maybe I'm missing something.

Is there something to provide a clean way to cluster IO, can you
suggest something that won't have this sort of impact on NFS (and
elsewhere) if the clustering code was removed?

Bruce, what part of the clustering code makes you think of it as
hurting us, I thought it was mapping code?

> --
> Poul-Henning Kamp             FreeBSD coreteam member
> phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
> FreeBSD -- It will take a long time before progress goes too far!

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 12:47: 6 2000
Delivered-To: freebsd-current@freebsd.org
Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87])
	by hub.freebsd.org (Postfix) with ESMTP id BA4BD37CC2C
	for <freebsd-current@FreeBSD.ORG>; Mon, 20 Mar 2000 12:30:01 -0800 (PST)
	(envelope-from dcs@newsguy.com)
Received: from newsguy.com (p39-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.104])
	by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id FAA20223;
	Tue, 21 Mar 2000 05:28:50 +0900 (JST)
Message-ID: <38D686BE.9CEABD0F@newsguy.com>
Date: Tue, 21 Mar 2000 05:14:54 +0900
From: "Daniel C. Sobral" <dcs@newsguy.com>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en,pt-BR,ja
MIME-Version: 1.0
To: Greg Lehey <grog@lemis.com>
Cc: Palle Girgensohn <girgen@partitur.se>,
	freebsd-current@FreeBSD.ORG
Subject: Re: 3 -> 4 when /usr is a vinum volume?
References: <38D2EB3E.C4548FCC@partitur.se> <20000319125700.D391@mojave.worldwide.lemis.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Greg Lehey wrote:
> 
> > Following the instructions in UPDATING, when rebooting to single
> > user mode, vinum wouldn't work since the kernel module was out of
> > date - no surprise.
> 
> Hmm.  After updating, you should have had new klds as well.  But
> that's probably not your fault.  Could you enter a PR about it,
> please?

make buildworld
make buildkernel
make installkernel
MAKEDEV
reboot single user
make -DNOINFO installworld
make installworld

As you see, the new klds don't get installed in the presently documented
procedure. I have read a report wrt to linux compatibility too, but with
vinum the problem is way bigger.

IIRC, the build/installkernel targets were first steps in getting
modules and loader dependencies handled correctly.

--
Daniel C. Sobral			(8-DCS)
dcs@newsguy.com
dcs@freebsd.org

	One Unix to rule them all, One Resolver to find them,
        One IP to bring them all and in the zone bind them.




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 12:47:28 2000
Delivered-To: freebsd-current@freebsd.org
Received: from peace.mahoroba.org (peace.calm.imasy.or.jp [202.227.26.34])
	by hub.freebsd.org (Postfix) with ESMTP id B546137BD0C
	for <current@FreeBSD.ORG>; Mon, 20 Mar 2000 12:39:15 -0800 (PST)
	(envelope-from ume@mahoroba.org)
Received: from localhost (IDENT:eF+08oQGN3mqtUXYLMqya8Ehh1agI5bWZQqKiYYQRhjazXJj6MFZzNfmxByagTQm@localhost [::1])
	by peace.mahoroba.org (8.10.0/3.7W-peace) with ESMTP id e2KKaNc07860;
	Tue, 21 Mar 2000 05:36:23 +0900 (JST)
	(envelope-from ume@mahoroba.org)
Date: Tue, 21 Mar 2000 05:36:23 +0900 (JST)
Message-Id: <200003202036.e2KKaNc07860@peace.mahoroba.org>
To: cpiazza@jaxon.net
Cc: visigoth@telemere.net, current@FreeBSD.ORG
Subject: Re: 75 second delay using telnet/ssh (ipv6 related)
In-Reply-To: <20000320120221.A517@norn.ca.eu.org>
References: <20000319150009.A404@norn.ca.eu.org>
	<Pine.BSF.4.21.0003201122310.25197-100000@www.telemere.net>
	<20000320120221.A517@norn.ca.eu.org>
X-Mailer: xcite1.20> Mew version 1.94.2 on Emacs 20.6 / Mule 4.0
 =?iso-2022-jp?B?KBskQjJWMWMbKEIp?=
X-PGP-Public-Key: http://www.imasy.org/~ume/publickey.asc
X-PGP-Fingerprint: 6B 0C 53 FC 5D D0 37 91  05 D0 B3 EF 36 9B 6A BC
X-URL: http://www.imasy.org/~ume/
X-OS: FreeBSD 5.0-CURRENT
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Hajimu UMEMOTO (=?ISO-2022-JP?B?GyRCR19LXBsoQiA=?=  =?ISO-2022-JP?B?GyRCSCUbKEI=?=) <ume@mahoroba.org>
X-Dispatcher: imput version 20000228(IM140)
Lines: 34
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

>>>>> On Mon, 20 Mar 2000 12:02:21 -0800
>>>>> Chris Piazza <cpiazza@jaxon.net> said:

> 	According to Mr. Stevens (Unix Network Programing Vol 1
> chapt 9.4) this option, or having the env. variable RES_OPTIONS=inet6 set
> will cause the behavior you are describing... 

It's a behavior of gethostbyname().  Ssh uses getaddrinfo() instead of
gethostbyname().  See RFC2553.

cpiazza> No, neither of those.  FreeBSD searches inet6 first at the moment.
cpiazza> I don't know if I made this clear in my email, but this just started
cpiazza> happening... Hmm... it's fixed again:

Don't you see packet loss or name server problem?  Your previous log
seems 128.189.4.1 didn't answer to AAAA RR query.

cpiazza> 12:01:15.622122 24.113.19.137.1253 > 24.2.10.36.53:  61892+ AAAA? beast.freebsd.org. (35)
cpiazza> 12:01:15.706319 24.2.10.36.53 > 24.113.19.137.1253:  61892 1/1/0 (132)
cpiazza> 12:01:15.707070 24.113.19.137.1254 > 24.2.10.36.53:  61893+ A? beast.freebsd.org. (35)
cpiazza> 12:01:15.750017 24.2.10.36.53 > 24.113.19.137.1254:  61893 2/4/4 (238)

Is it a log with `ssh -4'?  Why does ssh qurey AAAA RR with -4?

> > Using ssh -4 or telnet -4 makes it work right away (of course), but
> > I don't want to have to type that all the time. [program] ipv4address
> > also works.

How about `alias ssh "ssh -4"'?

--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
ume@mahoroba.org  ume@bisd.hitachi.co.jp  ume@FreeBSD.org
http://www.imasy.org/~ume/


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 12:47:36 2000
Delivered-To: freebsd-current@freebsd.org
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131])
	by hub.freebsd.org (Postfix) with ESMTP
	id 574D037C73D; Mon, 20 Mar 2000 12:33:37 -0800 (PST)
	(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1])
	by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id VAA20473;
	Mon, 20 Mar 2000 21:33:13 +0100 (CET)
	(envelope-from phk@critter.freebsd.dk)
To: Alfred Perlstein <bright@wintelcom.net>
Cc: Matthew Dillon <dillon@apollo.backplane.com>,
	current@FreeBSD.ORG, bde@FreeBSD.ORG
Subject: Re: I/O clustering, Re: patches for test / review 
In-reply-to: Your message of "Mon, 20 Mar 2000 12:53:17 PST."
             <20000320125317.E14789@fw.wintelcom.net> 
Date: Mon, 20 Mar 2000 21:33:13 +0100
Message-ID: <20471.953584393@critter.freebsd.dk>
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <20000320125317.E14789@fw.wintelcom.net>, Alfred Perlstein writes:

>> >> Before we redesign the clustering, I would like to know if we
>> >> actually have any recent benchmarks which prove that clustering
>> >> is overall beneficial ?
>> >
>> >Yes it is really benificial.
>> 
>> I would like to see some numbers if you have them.
>
>No I don't have numbers.
>
>Committing a 64k block would require 8 times the overhead of bundling
>up the RPC as well as transmission and reply, it may be possible
>to pipeline these commits because you don't really need to wait
>for one to complete before issueing another request, but it's still
>8x the amount of traffic.

I agree that it is obvious for NFS, but I don't see it as being
obvious at all for (modern) disks, so for that case I would like
to see numbers.

If running without clustering is just as fast for modern disks,
I think the clustering needs rethought.

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 13:20:20 2000
Delivered-To: freebsd-current@freebsd.org
Received: from camel.avias.com (camel.avias.com [195.14.38.87])
	by hub.freebsd.org (Postfix) with ESMTP
	id 6596437C2EE; Mon, 20 Mar 2000 12:51:46 -0800 (PST)
	(envelope-from camel@avias.com)
Received: from 192.168.2.2 ([192.168.2.2])
	by camel.avias.com (8.9.3/8.9.3) with ESMTP id XAA12951;
	Mon, 20 Mar 2000 23:51:45 +0300 (MSK)
	(envelope-from camel@avias.com)
Date: Mon, 20 Mar 2000 23:48:16 +0300
From: Ilya Naumov <camel@avias.com>
X-Mailer: The Bat! (v1.41) Educational
Reply-To: Ilya Naumov <camel@avias.com>
X-Priority: 3 (Normal)
Message-ID: <13991.000320@avias.com>
To: current@FreeBSD.ORG
Cc: ports@FreeBSD.ORG
Subject: XFree86 under -current - a bug report
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Hello,

i've tried to build XFree86 4.0 on my 5.0-CURRENT and 4.0-RELEASE box, and encountered
a problem.

"make all" finishes successfully, but "make install" fails with the
following error message:

making all in programs/Xserver/hw/xfree86/os-support/bsd...
rm -f bsd_mouse.o
cc -c -O -pipe  -ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith   -I../../../.
./../../programs/Xserver/hw/xfree86/common -I../../../../../../programs/Xserver/
hw/xfree86/os-support -I. -I../../../../../../programs/Xserver/include
  -I../../../../../../exports/include/X11 -I../../../../../../include/extensions
 -I../../../../../../programs/Xserver/mi -I           -I../../../../../.. -I../.
./../../../../exports/include  -DCSRG_BASED -DSHAPE  -DXKB -DLBX -DXAPPGROUP -DX
CSECURITY -DTOGCUP  -DXF86BIGFONT -DDPMSExtension  -DPIXPRIV -DPANORAMIX  -DGCCU
SESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFre
e86LOADER  -DXFree86Server -DXF86VIDMODE  -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DSMART
_SCHEDULE -DNDEBUG   -DFUNCPROTO=15 -DNARROWPROTO   -DPCCONS_SUPPORT -DSYSCONS_S
UPPORT -DPCVT_SUPPORT  -DUSE_DEV_IO -DUSESTDRES           -DHAS_MTRR_SUPPORT   b
sd_mouse.c
In file included from bsd_mouse.c:11:
../../../../../../programs/Xserver/hw/xfree86/common/xf86Xinput.h:99: syntax err
or before `xDeviceCtl'
*** Error code 1

Stop in /usr/ports/x11/XFree86-4/work/xc/programs/Xserver/hw/xfree86/os-support/
bsd.
*** Error code 1

Stop in /usr/ports/x11/XFree86-4/work/xc/programs/Xserver/hw/xfree86/os-support.
*** Error code 1

ports were cvsupped today, and kernel/world were built on Mar 15.

what should i try to do to cope with this?


-- 
Best regards,
 Ilya                          mailto:camel@avias.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 13:21:17 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP
	id 9ED0337BA83; Mon, 20 Mar 2000 13:17:10 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id NAA71771;
	Mon, 20 Mar 2000 13:17:08 -0800 (PST)
	(envelope-from dillon)
Date: Mon, 20 Mar 2000 13:17:08 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003202117.NAA71771@apollo.backplane.com>
To: Alfred Perlstein <bright@wintelcom.net>
Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, current@FreeBSD.ORG,
	bde@FreeBSD.ORG
Subject: Re: I/O clustering, Re: patches for test / review
References: <20000320115902.C14789@fw.wintelcom.net> <20211.953581241@critter.freebsd.dk> <20000320125317.E14789@fw.wintelcom.net>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


:
:* Poul-Henning Kamp <phk@critter.freebsd.dk> [000320 12:03] wrote:
:> In message <20000320115902.C14789@fw.wintelcom.net>, Alfred Perlstein writes:
:> >* Poul-Henning Kamp <phk@critter.freebsd.dk> [000320 11:45] wrote:
:> >> In message <20000320111544.A14789@fw.wintelcom.net>, Alfred Perlstein writes:
:> >> 
:> >> >Keeping the currect cluster code is a bad idea, if the drivers were
:> >> >taught how to traverse the linked list in the buf struct rather
:> >> >than just notice "a big buffer" we could avoid a lot of page
:> >> >twiddling and also allow for massive IO clustering ( > 64k ) 
:> >> 
:> >> Before we redesign the clustering, I would like to know if we
:> >> actually have any recent benchmarks which prove that clustering
:> >> is overall beneficial ?
:> >
:> >Yes it is really benificial.
:> 
:> I would like to see some numbers if you have them.
:
:No I don't have numbers.
:
:Committing a 64k block would require 8 times the overhead of bundling
:up the RPC as well as transmission and reply, it may be possible
:to pipeline these commits because you don't really need to wait

    Clustering is extremely beneficial.  DG and I and I think even BDE and
    Tor have done a lot of random tests in that area.  I did a huge amount
    of clustering related work while optimizing NFSv3 and fixing up the
    random/sequential I/O heuristics for 4.0 (for both NFS and UFS).

    The current clustering code does a pretty good job and I would hesitate
    to change it at this time.  The only real overhead comes from the KVA
    pte mappings for b_data in the pbuf that the clustering (and other)
    code uses.  I do not think that redoing the clustering will have 
    a beneficial result until *after* we optimize the I/O path as per
    my previous posting.

    Once we optimize the I/O path to make it more VM Object centric, it
    will make it a whole lot easier to remove *ALL* the artificial I/O size
    limitations.

						-Matt



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 13:27: 4 2000
Delivered-To: freebsd-current@freebsd.org
Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101])
	by hub.freebsd.org (Postfix) with ESMTP id D68B637C0AF
	for <current@FreeBSD.ORG>; Mon, 20 Mar 2000 13:24:14 -0800 (PST)
	(envelope-from dan@dan.emsphone.com)
Received: (from dan@localhost)
	by dan.emsphone.com (8.9.3/8.9.3) id PAA52707;
	Mon, 20 Mar 2000 15:23:31 -0600 (CST)
	(envelope-from dan)
Date: Mon, 20 Mar 2000 15:23:31 -0600
From: Dan Nelson <dnelson@emsphone.com>
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc: Alfred Perlstein <bright@wintelcom.net>,
	Matthew Dillon <dillon@apollo.backplane.com>, current@FreeBSD.ORG
Subject: Re: patches for test / review
Message-ID: <20000320152330.A48212@dan.emsphone.com>
References: <20000320115902.C14789@fw.wintelcom.net> <20211.953581241@critter.freebsd.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.1.5i
In-Reply-To: <20211.953581241@critter.freebsd.dk>; from "Poul-Henning Kamp" on Mon Mar 20 20:40:41 GMT 2000
X-OS: FreeBSD 5.0-CURRENT
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In the last episode (Mar 20), Poul-Henning Kamp said:
> In message <20000320115902.C14789@fw.wintelcom.net>, Alfred Perlstein writes:
> >* Poul-Henning Kamp <phk@critter.freebsd.dk> [000320 11:45] wrote:
> >> 
> >> Before we redesign the clustering, I would like to know if we
> >> actually have any recent benchmarks which prove that clustering is
> >> overall beneficial ?
> >
> >Yes it is really benificial.
> 
> I would like to see some numbers if you have them.

For hardware RAID arrays that support it, if you can get the system to
issue writes that are larger than the entire RAID-5 stripe size, your
immensely slow "read parity/recalc parity/write parity/write data"
operations turn into "recalc parity for entire stripe/write entire
stripe".  RAID-5 magically achieves RAID-0 write speeds!  Given 32k
granularity, and 8 disks per RAID group, you'll need a write
size of 32*7 = 224k.  Given 64K granularity and 27 disks, that's 1.6MB.

I have seen the jump in write throughput as I tuned an Oracle
database's parameters on both Solaris and DEC Unix boxes.  Get Oracle
to write blocks larger than a RAID-5 stripe, and it flies.

-- 
	Dan Nelson
	dnelson@emsphone.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 13:30: 2 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP
	id 7322937BA65; Mon, 20 Mar 2000 13:29:53 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id NAA71883;
	Mon, 20 Mar 2000 13:29:51 -0800 (PST)
	(envelope-from dillon)
Date: Mon, 20 Mar 2000 13:29:51 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003202129.NAA71883@apollo.backplane.com>
To: Julian Elischer <julian@elischer.org>
Cc: Poul-Henning Kamp <phk@FreeBSD.ORG>, current@FreeBSD.ORG
Subject: Re: B_WRITE cleanup patch, please test!
References: <20502.952948995@critter.freebsd.dk> <38CCEF68.41C67EA6@elischer.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

    I think the biggest win in regards to being able to arbitrarily stack
    devices is to NOT attempt to forward struct buf's between devices when
    non-trivial manipulation is required, and instead to make struct buf's
    cheap enough that a device can simply allocate a new one and copy the
    appropriate fields.  Here I am talking about situations where devices
    need callbacks (making forwarding impossible), need to split or combine
    requests, or do other non-trivial things.

    In particular I really hate all the various b_*blkno fields.  b_lblkno,
    b_blkno, and b_pblkno.  It is precisely due to the existance of these
    hacks that arbitrary device stacking is difficult.

    The key to making a struct buf cheap is to provide an I/O path that
    does not require the b_data KVA mapping.  Once we provide this path,
    I think everything else will fall into place quite neatly.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 13:30:31 2000
Delivered-To: freebsd-current@freebsd.org
Received: from implode.root.com (root.com [209.102.106.178])
	by hub.freebsd.org (Postfix) with ESMTP
	id A426A37B957; Mon, 20 Mar 2000 13:30:16 -0800 (PST)
	(envelope-from dg@implode.root.com)
Received: from implode.root.com (localhost [127.0.0.1])
	by implode.root.com (8.8.8/8.8.5) with ESMTP id NAA23630;
	Mon, 20 Mar 2000 13:24:10 -0800 (PST)
Message-Id: <200003202124.NAA23630@implode.root.com>
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc: Alfred Perlstein <bright@wintelcom.net>,
	Matthew Dillon <dillon@apollo.backplane.com>, current@FreeBSD.ORG,
	bde@FreeBSD.ORG
Subject: Re: I/O clustering, Re: patches for test / review 
In-reply-to: Your message of "Mon, 20 Mar 2000 21:33:13 +0100."
             <20471.953584393@critter.freebsd.dk> 
From: David Greenman <dg@root.com>
Reply-To: dg@root.com
Date: Mon, 20 Mar 2000 13:24:10 -0800
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

>>Committing a 64k block would require 8 times the overhead of bundling
>>up the RPC as well as transmission and reply, it may be possible
>>to pipeline these commits because you don't really need to wait
>>for one to complete before issueing another request, but it's still
>>8x the amount of traffic.
>
>I agree that it is obvious for NFS, but I don't see it as being
>obvious at all for (modern) disks, so for that case I would like
>to see numbers.
>
>If running without clustering is just as fast for modern disks,
>I think the clustering needs rethought.

   Depends on the type of disk drive and how it is configured. Some drives
perform badly (skip a revolution) with back-to-back writes. In all cases,
without aggregation of blocks, you pay the extra cost of additional interrupts
and I/O rundowns, which can be a significant factor. Also, unless the blocks
were originally written by the application in a chunk, they will likely be
mixed with blocks to varying locations, in which case for drives without
write caching enabled, you'll have additional seeks to write the blocks out.
Things like this don't show up when doing simplistic sequential write tests.

-DG

David Greenman
Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org
Creator of high-performance Internet servers - http://www.terasolutions.com
Pave the road of life with opportunities.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 13:40:18 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mail2.uunet.ca (mail2.uunet.ca [142.77.1.15])
	by hub.freebsd.org (Postfix) with ESMTP
	id 9045C37B510; Mon, 20 Mar 2000 13:39:59 -0800 (PST)
	(envelope-from matt@ARPA.MAIL.NET)
Received: from epsilon.lucida.qc.ca ([216.95.146.6]) by mail2.uunet.ca with ESMTP id <599488-18685>; Mon, 20 Mar 2000 16:34:51 -0500
Date: Mon, 20 Mar 2000 16:39:27 -0500
From: Matt Heckaman <matt@ARPA.MAIL.NET>
X-Sender: matt@epsilon.lucida.qc.ca
To: Ilya Naumov <camel@avias.com>
Cc: current@FreeBSD.ORG, ports@FreeBSD.ORG
Subject: Re: XFree86 under -current - a bug report
In-Reply-To: <13991.000320@avias.com>
Message-ID: <Pine.BSF.4.21.0003201638430.1034-100000@epsilon.lucida.qc.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

I can varify this on 4.0-STABLE as of March 19, ports cvsup the same time.
I had a look at it, and though I'm not much of a programmer, I cant see
where the parse error is.. maybe I'm blind.

Matt
--
Matt Heckaman [matt@arpa.mail.net|matt@relic.net] [Please do not send me]
!Powered by FreeBSD/x86! [http://www.freebsd.org] [any SPAM (UCE) e-mail]

On Mon, 20 Mar 2000, Ilya Naumov wrote:

: Date: Mon, 20 Mar 2000 15:48:16 -0500
: From: Ilya Naumov <camel@avias.com>
: To: current@FreeBSD.ORG
: Cc: ports@FreeBSD.ORG
: Subject: XFree86 under -current - a bug report
: 
: Hello,
: 
: i've tried to build XFree86 4.0 on my 5.0-CURRENT and 4.0-RELEASE box, and encountered
: a problem.
: 
: "make all" finishes successfully, but "make install" fails with the
: following error message:
: 
: making all in programs/Xserver/hw/xfree86/os-support/bsd...
: rm -f bsd_mouse.o
: cc -c -O -pipe  -ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith   -I../../../.
: ./../../programs/Xserver/hw/xfree86/common -I../../../../../../programs/Xserver/
: hw/xfree86/os-support -I. -I../../../../../../programs/Xserver/include
:   -I../../../../../../exports/include/X11 -I../../../../../../include/extensions
:  -I../../../../../../programs/Xserver/mi -I           -I../../../../../.. -I../.
: ./../../../../exports/include  -DCSRG_BASED -DSHAPE  -DXKB -DLBX -DXAPPGROUP -DX
: CSECURITY -DTOGCUP  -DXF86BIGFONT -DDPMSExtension  -DPIXPRIV -DPANORAMIX  -DGCCU
: SESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFre
: e86LOADER  -DXFree86Server -DXF86VIDMODE  -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DSMART
: _SCHEDULE -DNDEBUG   -DFUNCPROTO=15 -DNARROWPROTO   -DPCCONS_SUPPORT -DSYSCONS_S
: UPPORT -DPCVT_SUPPORT  -DUSE_DEV_IO -DUSESTDRES           -DHAS_MTRR_SUPPORT   b
: sd_mouse.c
: In file included from bsd_mouse.c:11:
: ../../../../../../programs/Xserver/hw/xfree86/common/xf86Xinput.h:99: syntax err
: or before `xDeviceCtl'
: *** Error code 1
: 
: Stop in /usr/ports/x11/XFree86-4/work/xc/programs/Xserver/hw/xfree86/os-support/
: bsd.
: *** Error code 1
: 
: Stop in /usr/ports/x11/XFree86-4/work/xc/programs/Xserver/hw/xfree86/os-support.
: *** Error code 1
: 
: ports were cvsupped today, and kernel/world were built on Mar 15.
: 
: what should i try to do to cope with this?
: 
: 
: -- 
: Best regards,
:  Ilya                          mailto:camel@avias.com
: 
: 
: 
: 
: To Unsubscribe: send mail to majordomo@FreeBSD.org
: with "unsubscribe freebsd-current" in the body of the message
: 



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 13:53:49 2000
Delivered-To: freebsd-current@freebsd.org
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131])
	by hub.freebsd.org (Postfix) with ESMTP id 6602337B78C
	for <current@FreeBSD.ORG>; Mon, 20 Mar 2000 13:53:26 -0800 (PST)
	(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1])
	by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id WAA21215;
	Mon, 20 Mar 2000 22:52:59 +0100 (CET)
	(envelope-from phk@critter.freebsd.dk)
To: Alfred Perlstein <bright@wintelcom.net>
Cc: Matthew Dillon <dillon@apollo.backplane.com>, current@FreeBSD.ORG
Subject: Re: patches for test / review 
In-reply-to: Your message of "Mon, 20 Mar 2000 11:59:02 PST."
             <20000320115902.C14789@fw.wintelcom.net> 
Date: Mon, 20 Mar 2000 22:52:59 +0100
Message-ID: <21213.953589179@critter.freebsd.dk>
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <20000320115902.C14789@fw.wintelcom.net>, Alfred Perlstein writes:
>* Poul-Henning Kamp <phk@critter.freebsd.dk> [000320 11:45] wrote:
>> In message <20000320111544.A14789@fw.wintelcom.net>, Alfred Perlstein writes:
>> 
>> >Keeping the currect cluster code is a bad idea, if the drivers were
>> >taught how to traverse the linked list in the buf struct rather
>> >than just notice "a big buffer" we could avoid a lot of page
>> >twiddling and also allow for massive IO clustering ( > 64k ) 
>> 
>> Before we redesign the clustering, I would like to know if we
>> actually have any recent benchmarks which prove that clustering
>> is overall beneficial ?
>
>Yes it is really benificial.
>
>I'm not talking about a redesign of the clustering code as much as
>making the drivers that take a callback from it actually traverse
>the 'union cluster_info' rather than relying on the system to fake
>the pages being contiguous via remapping.
>
>There's nothing wrong with the clustering algorithms, it's just the
>steps it has to take to work with the drivers.

Hmm, try to keep vinum/RAID5 in the picture when you look at this code,
it complicated matters a lot.

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 13:55:17 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id A4FE137B9A9
	for <current@FreeBSD.ORG>; Mon, 20 Mar 2000 13:55:12 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id NAA72035;
	Mon, 20 Mar 2000 13:55:05 -0800 (PST)
	(envelope-from dillon)
Date: Mon, 20 Mar 2000 13:55:05 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003202155.NAA72035@apollo.backplane.com>
To: Alfred Perlstein <bright@wintelcom.net>
Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, current@FreeBSD.ORG
Subject: Re: patches for test / review
References: <18039.953549289@critter.freebsd.dk> <200003201736.JAA70124@apollo.backplane.com> <20000320111544.A14789@fw.wintelcom.net>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


:> 	lock on the bp.  With a shared lock you are allowed to issue READ
:> 	I/O but you are not allowed to modify the contents of the buffer.
:> 	With an exclusive lock you are allowed to issue both READ and WRITE
:> 	I/O and you can modify the contents of the buffer.
:> 
:>       bread()  -> bread_sh() and bread_ex()
:> 
:> 	Obtain and validate (issue read I/O as appropriate) a bp.  bread_sh()
:> 	allows a buffer to be accessed but not modified or rewritten.
:> 	bread_ex() allows a buffer to be modified and written.
:
:This seems to allow for expressing intent to write to buffers,
:which would be an excellent place to cow the pages 'in software'
:rather than obsd's way of using cow'd pages to accomplish the same
:thing.

    Yes, absolutely.  DG (if I remember right) is rabid about not taking
    VM faults while sitting in the kernel and I tend to agree with him that
    it's a cop-out to use VM faults in the kernel to get around those
    sorts of problems.

:I'm not sure if you remeber what I brought up at BAFUG, but I'd
:like to see something along the lines of BX_BKGRDWRITE that Kirk
:is using for the bitmaps blocks in softupdates to be enabled on a
:system wide basis.  That way rewriting data that has been sent to
:the driver isn't blocked and at the same time we don't need to page
:protect during every strategy call.
:
:I may have misunderstood your intent, but using page protections
:on each IO would seem to introduce a lot of performance issues that
:the rest of these points are all trying to get rid of.

    At the low-level device there is no concept of page protections.
    If you pass an array of vm_page_t's then that is where the data
    will be taken from or written to.

    A background-write capability is actually much more easily implemented
    at the VM Object level then the buffer cache level.  If you think about
    it, all you need to do is add another VM Object layer *below* the 
    one representing the device.  Whenever a device write is initiated the
    pages are moved to the underlying layer.  If a process (or the kernel)
    needs to modify the pages while the write is in progress, a copy-on-write
    occurs through normal mechanisms.  On completion of the I/O the pages
    are moved back to the main VM Object device layer except for those that
    would conflict with any copy-on-write that occured (the original device
    pages in the conflict case simply get thrown away).  

    Problem solved.  Plus this deals with low-memory situations properly...
    we do not introduce any new deadlocks.

:>       The idea for the buffer cache is to shift its functionality to one that
:>       is solely used to issue device I/O and to keep track of dirty areas for
:>       proper sequencing of I/O (e.g. softupdate's use of the buffer cache 
:>       to placemark I/O will not change).  The core buffer cache code would
:...
:
:Keeping the currect cluster code is a bad idea, if the drivers were
:taught how to traverse the linked list in the buf struct rather
:than just notice "a big buffer" we could avoid a lot of page
:twiddling and also allow for massive IO clustering ( > 64k ) because
:we won't be limited by the size of the b_pages[] array for our
:upper bound on the amount of buffers we can issue effectively a
:scatter/gather on (since the drivers must VTOPHYS them anyway).

    This devolves down into how simple (or complex) an interface we
    are willing to use to talk to the low-level device.

    The reason I would hesitate to move to a 'linked list of buffers'
    methodology is that *ALL* of the current VM API's pass a single
    array of vm_page_t's... not just the current struct buf code, but also
    the VOP_PUTPAGES and VOP_GETPAGES API.

    I would much prefer to keep this simplicity intact in order to avoid
    introducing even more bugs into the source then we will when we try
    to do this stuff, which means changing the clustering code from:

	* copies vm_page_t's into the cluster pbuf's b_pages[] array
	* maps the pages into b_data

    to:


	* copies vm_page_t's into the cluster pbuf's b_pages[] array

    In otherwords, keeping the clustering changes as simple as possible.
    I think once the new I/O path is operational we can then start thinking
    about how to optimize it -- for example, by having a default (embedded)
    static array but also allowing the b_pages array to be dynamically
    allocated.

:To realize my "nfs super commit" stuff all we'd need to do is make
:the max cluster size something like 0-1 and instantly get an almost
:unbounded IO burst.
:
:-- 
:-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
:

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 13:57:36 2000
Delivered-To: freebsd-current@freebsd.org
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131])
	by hub.freebsd.org (Postfix) with ESMTP id 7842E37B95E
	for <current@FreeBSD.ORG>; Mon, 20 Mar 2000 13:57:30 -0800 (PST)
	(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1])
	by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id WAA21292;
	Mon, 20 Mar 2000 22:57:08 +0100 (CET)
	(envelope-from phk@critter.freebsd.dk)
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: Julian Elischer <julian@elischer.org>, current@FreeBSD.ORG
Subject: Re: B_WRITE cleanup patch, please test! 
In-reply-to: Your message of "Mon, 20 Mar 2000 13:29:51 PST."
             <200003202129.NAA71883@apollo.backplane.com> 
Date: Mon, 20 Mar 2000 22:57:08 +0100
Message-ID: <21290.953589428@critter.freebsd.dk>
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <200003202129.NAA71883@apollo.backplane.com>, Matthew Dillon writes:
>    I think the biggest win in regards to being able to arbitrarily stack
>    devices is to NOT attempt to forward struct buf's between devices when
>    non-trivial manipulation is required, and instead to make struct buf's
>    cheap enough that a device can simply allocate a new one and copy the
>    appropriate fields.
>
>    In particular I really hate all the various b_*blkno fields.  b_lblkno,
>    b_blkno, and b_pblkno.  It is precisely due to the existance of these
>    hacks that arbitrary device stacking is difficult.

This is basically what the stuff I'm doing addresses.

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 14: 4:58 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id 8372D37BA14
	for <current@FreeBSD.ORG>; Mon, 20 Mar 2000 14:04:54 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id OAA72087;
	Mon, 20 Mar 2000 14:04:48 -0800 (PST)
	(envelope-from dillon)
Date: Mon, 20 Mar 2000 14:04:48 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003202204.OAA72087@apollo.backplane.com>
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc: current@FreeBSD.ORG
Subject: Re: patches for test / review 
References:  <20074.953579833@critter.freebsd.dk>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


:
:In message <200003201846.KAA70820@apollo.backplane.com>, Matthew Dillon writes:
:
:>    Well, let me tell you what the fuzzy goal is first and then maybe we
:>    can work backwards.
:>
:>    Eventually all physical I/O needs a physical address.  The quickest
:>    way to get to a physical address is to be given an array of vm_page_t's
:>    (which can be trivially translated to physical addresses).
:
:Not all:
:PIO access to ATA needs virtual access.
:RAID5 needs virtual access to calculate parity.

    ... which means that the initial implementation for PIO and RAID5
    utilizes the mapped-buffer bioops interface rather then the b_pages[]
    bioops interface.

    But here's the point:  We need to require that all entries *INTO* the
    bio system start with at least b_pages[] and then generate b_data only
    when necessary.  If a particular device needs a b_data mapping, it
    can get one, but I think it would be a huge mistake to allow entry into
    the device subsystem to utilize *either* a b_data mapping *or* a 
    b_pages[] mapping.  Big mistake.  There has to be a lowest common
    denominator that the entire system can count on and it pretty much has
    to be an array of vm_page_t's.

    If a particular subsystem needs b_data, then that subsystem is obviously
    willing to take the virtual mapping / unmapping hit.  If you look at 
    Greg's current code this is, in fact, what is occuring.... the critical
    path through the buffer cache in a heavily loaded system tends to require
    a KVA mapping *AND* a KVA unmapping on every buffer access (just that the
    unmappings tend to be for unrelated buffers).  The reason this occurs
    is because even with the larger amount of KVA we made available to the
    buffer cache in 4.x, there still isn't enough to leave mappings intact
    for long periods of time.  A 'systat -vm 1' will show you precisely
    what I mean (also sysctl -a | fgrep bufspace).  

    So we will at least not be any worse off then we are now, and probably
    better off since many of the buffers in the new system will not have
    to be mapped.  For example, when vinum's RAID5 breaks up a request
    and issues a driveio() it passes a buffer which is assigned to b_data
    which must be translated (through page table lookups) to physical
    addresses anyway, so the fact that that vinum does not populate 
    b_pages[] does *NOT* help it in the least.  It actually makes the job
    harder.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>

:--
:Poul-Henning Kamp             FreeBSD coreteam member
:phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
:FreeBSD -- It will take a long time before progress goes too far!
:



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 14:15:25 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP
	id 9C2AF37BD62; Mon, 20 Mar 2000 14:15:16 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id OAA72219;
	Mon, 20 Mar 2000 14:15:09 -0800 (PST)
	(envelope-from dillon)
Date: Mon, 20 Mar 2000 14:15:09 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003202215.OAA72219@apollo.backplane.com>
To: David Greenman <dg@root.com>
Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>,
	Alfred Perlstein <bright@wintelcom.net>, current@FreeBSD.ORG,
	bde@FreeBSD.ORG
Subject: Re: I/O clustering, Re: patches for test / review 
References:  <200003202124.NAA23630@implode.root.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

:>
:>I agree that it is obvious for NFS, but I don't see it as being
:>obvious at all for (modern) disks, so for that case I would like
:>to see numbers.
:>
:>If running without clustering is just as fast for modern disks,
:>I think the clustering needs rethought.
:
:   Depends on the type of disk drive and how it is configured. Some drives
:perform badly (skip a revolution) with back-to-back writes. In all cases,
:without aggregation of blocks, you pay the extra cost of additional interrupts
:and I/O rundowns, which can be a significant factor. Also, unless the blocks
:were originally written by the application in a chunk, they will likely be
:mixed with blocks to varying locations, in which case for drives without
:write caching enabled, you'll have additional seeks to write the blocks out.
:Things like this don't show up when doing simplistic sequential write tests.
:
:-DG
:
:David Greenman
:Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org

   I have an excellent example of this related to NFS.  It's still applicable
   even though the NFS point has already been conceeded.

   As part of the performance enhancements package I extended the sequential
   detection heuristic to the NFS server side code and turned on clustering.
   On the server, mind you, not the client.

   Read performance went up drastically.  My 100BaseTX network instantly
   maxed out and, more importantly, the server side cpu use went down
   drastically.  Here is the relevant email from my archives describing the
   performance gains:

:From:	 dillon
:To:       Alfred Perlstein <bright@wintelcom.net>
:Cc:       Alan Cox <alc@cs.rice.edu>, Julian Elischer <julian@whistle.com>
:Date:     Sun Dec 12 10:11:06 1999
:
:...
:    This proposed patch allows us to maintain a sequential read heuristic
:    on the server side.  I noticed that the NFS server side reads only 8K
:    blocks from the physical media even when the NFS client is reading a
:    file sequentially.
:
:    With this heuristic in place I can now get 9.5 to 10 MBytes/sec reading
:    over NFS on a 100BaseTX network, and the server winds up being 80% 
:    idle.  Under -stable the same test runs 72% idle and 8.4 MBytes/sec.

    This is in spite of the fact that in this sequential test the hard
    drives were caching the read data ahead anyway.  The reduction in
    command/response/interrupt overhead on the server by going from 8K read
    I/O's to 64K read I/O's in the sequential case made an obvious beneficial
    impact on the cpu.  I almost halved the cpu overhead on the server!

    So while on-disk caching makes a lot of sense, it is in no way able
    to replace software clustering.  Having both working together is a
    killer combination.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 14:32:52 2000
Delivered-To: freebsd-current@freebsd.org
Received: from scam.xcf.berkeley.edu (scam.XCF.Berkeley.EDU [128.32.43.201])
	by hub.freebsd.org (Postfix) with SMTP id A619E37B95E
	for <freebsd-current@freebsd.org>; Mon, 20 Mar 2000 14:32:42 -0800 (PST)
	(envelope-from nordwick@scam.xcf.berkeley.edu)
Received: (qmail 83833 invoked by uid 27268); 20 Mar 2000 22:32:31 -0000
Message-ID: <20000320223231.83832.qmail@scam.xcf.berkeley.edu>
To: freebsd-current@freebsd.org
Subject: /etc/rc.firewall not reading /etc/rc.conf
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <83831.953591551.1@scam.XCF.Berkeley.EDU>
Date: Mon, 20 Mar 2000 14:32:31 -0800
From: Jason <nordwick@scam.xcf.berkeley.edu>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In my 4.0 cvsupped from 3/20 /etc/rc.firewall says this:

	# Suck in the configuration variables.
	if [ -r /etc/defaults/rc.conf ]; then
		. /etc/defaults/rc.conf
	elif [ -r /etc/rc.conf ]; then
		. /etc/rc.conf
	fi

which would be fine, but /etc/defaults/rc.conf says this at the top:

	# This is rc.conf - a file full of useful variables that you can set 
	# to change the default startup behavior of your system.  You should
	# not edit this file!  Put any overrides into one of the ${rc_conf_files}
	# instead and you will be able to update these defaults later without
	# spamming your local configuration information.
	#

So, following directions, I put my changes in /etc/rc.conf, but rc.firewall
only looks at /etc/defaults/rc.conf.

Should /etc/rc.firewall be changed to read:

	# Suck in the configuration variables.
	if [ -r /etc/defaults/rc.conf ]; then
		. /etc/defaults/rc.conf
	fi
	if [ -r /etc/rc.conf ]; then
		. /etc/rc.conf
	fi

-jason



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 14:35: 9 2000
Delivered-To: freebsd-current@freebsd.org
Received: from maile.telia.com (maile.telia.com [194.22.190.16])
	by hub.freebsd.org (Postfix) with ESMTP id 85C4A37BA52
	for <freebsd-current@FreeBSD.ORG>; Mon, 20 Mar 2000 14:34:47 -0800 (PST)
	(envelope-from girgen@partitur.se)
Received: from d1o90.telia.com (root@d1o90.telia.com [195.67.216.241])
	by maile.telia.com (8.9.3/8.9.3) with ESMTP id XAA24146;
	Mon, 20 Mar 2000 23:34:30 +0100 (CET)
Received: from stordatan.telia.com (t1o90p109.telia.com [195.67.216.109])
	by d1o90.telia.com (8.8.8/8.8.8) with ESMTP id XAA24136;
	Mon, 20 Mar 2000 23:34:29 +0100 (CET)
Received: from partitur.se (localhost [127.0.0.1])
	by stordatan.telia.com (8.9.3/8.9.1) with ESMTP id XAA07254;
	Mon, 20 Mar 2000 23:34:07 +0100 (CET)
	(envelope-from girgen@partitur.se)
Message-ID: <38D6A75F.1FA1FFA@partitur.se>
Date: Mon, 20 Mar 2000 23:34:07 +0100
From: Palle Girgensohn <girgen@partitur.se>
Organization: Partitur
X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-CURRENT i386)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: Alfred Perlstein <bright@wintelcom.net>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: 3 -> 4 when /usr is a vinum volume?
References: <38D2EB3E.C4548FCC@partitur.se> <20000317195953.B14789@fw.wintelcom.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Alfred Perlstein wrote:
> 
> Yowch, please wrap lines at 70 characters. :)

Oops! Sorry about that. I had fiddled with the settings for a
specific purpose, and forgot to set them back. :-/

> Read the loader page carefully and you should be able to boot 3.x
> kernels with 3.x modules and 4.0 modules with a 4.0 kernel without
> too much voodoo.

Thanks for the tip. I'm not sure I read it close enough, for I
set the module_path and it didn't help. Still, after installing
all of the klds, I never really had to go back to the 3.x kernel,
so it was ok anyway.

The problem is of course that the UPDATING documentation lack
info about installing the klds, and I didn't think about it.

/Palle


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 14:36:28 2000
Delivered-To: freebsd-current@freebsd.org
Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228])
	by hub.freebsd.org (Postfix) with ESMTP id 4E56B37BA33
	for <freebsd-current@FreeBSD.ORG>; Mon, 20 Mar 2000 14:36:25 -0800 (PST)
	(envelope-from jkh@zippy.cdrom.com)
Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1])
	by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id OAA28552;
	Mon, 20 Mar 2000 14:36:42 -0800 (PST)
	(envelope-from jkh@zippy.cdrom.com)
To: Jason <nordwick@scam.xcf.berkeley.edu>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: /etc/rc.firewall not reading /etc/rc.conf 
In-reply-to: Your message of "Mon, 20 Mar 2000 14:32:31 PST."
             <20000320223231.83832.qmail@scam.xcf.berkeley.edu> 
Date: Mon, 20 Mar 2000 14:36:42 -0800
Message-ID: <28549.953591802@zippy.cdrom.com>
From: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> In my 4.0 cvsupped from 3/20 /etc/rc.firewall says this:
> 
> 	# Suck in the configuration variables.
> 	if [ -r /etc/defaults/rc.conf ]; then
> 		. /etc/defaults/rc.conf
> 	elif [ -r /etc/rc.conf ]; then
> 		. /etc/rc.conf
> 	fi
> 
> which would be fine, but /etc/defaults/rc.conf says this at the top:

It is fine, since /etc/defaults/rc.conf also says this at the bottom:

##############################################################
### Allow local configuration override at the very end here ##
##############################################################
#
#
for i in ${rc_conf_files}; do
	if [ -f $i ]; then
        	. $i
	fi
done

and rc_conf_files is set to "/etc/rc.conf /etc/rc.conf.local"
by default.

- Jordan


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 14:37:44 2000
Delivered-To: freebsd-current@freebsd.org
Received: from holly.calldei.com (adsl-208-191-146-189.dsl.hstntx.swbell.net [208.191.146.189])
	by hub.freebsd.org (Postfix) with ESMTP id 0048837B98E
	for <freebsd-current@FreeBSD.ORG>; Mon, 20 Mar 2000 14:37:34 -0800 (PST)
	(envelope-from chris@holly.calldei.com)
Received: (from chris@localhost)
	by holly.calldei.com (8.9.3/8.9.3) id QAA89406;
	Mon, 20 Mar 2000 16:36:33 -0600 (CST)
	(envelope-from chris)
Date: Mon, 20 Mar 2000 16:36:32 -0600
From: Chris Costello <chris@calldei.com>
To: Jason <nordwick@scam.xcf.berkeley.edu>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: /etc/rc.firewall not reading /etc/rc.conf
Message-ID: <20000320163632.H24374@holly.calldei.com>
Reply-To: chris@calldei.com
References: <20000320223231.83832.qmail@scam.xcf.berkeley.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/0.96.4i
In-Reply-To: <20000320223231.83832.qmail@scam.xcf.berkeley.edu>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Monday, March 20, 2000, Jason wrote:
> Should /etc/rc.firewall be changed to read:
> 
> 	# Suck in the configuration variables.
> 	if [ -r /etc/defaults/rc.conf ]; then
> 		. /etc/defaults/rc.conf
> 	fi
> 	if [ -r /etc/rc.conf ]; then
> 		. /etc/rc.conf
> 	fi

   No.  See /etc/defaults/rc.conf:

     rc_conf_files="/etc/rc.conf /etc/rc.conf.local"

   and at the very bottom,

     for i in ${rc_conf_files}; do
             if [ -f $i ]; then
                     . $i
             fi
     done

   So /etc/rc.conf is read in by /etc/defaults/rc.conf.

-- 
|Chris Costello <chris@calldei.com>
|I must have slipped a disk; my pack hurts.
`------------------------------------------


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 14:40: 6 2000
Delivered-To: freebsd-current@freebsd.org
Received: from veldy.net (veldy-host201.dsl.visi.com [208.42.48.201])
	by hub.freebsd.org (Postfix) with ESMTP
	id C8EBA37B75B; Mon, 20 Mar 2000 14:39:50 -0800 (PST)
	(envelope-from veldy@fuggle.veldy.net)
Received: by veldy.net (Postfix, from userid 1000)
	id 1719F1923; Mon, 20 Mar 2000 16:42:56 -0600 (CST)
Received: from localhost (localhost [127.0.0.1])
	by veldy.net (Postfix) with ESMTP
	id 09E6D1921; Mon, 20 Mar 2000 16:42:56 -0600 (CST)
Date: Mon, 20 Mar 2000 16:42:55 -0600 (CST)
From: "Thomas T. Veldhouse" <veldy@fuggle.veldy.net>
To: freebsd-stable <freebsd-stable@freebsd.org>,
	freebsd-current <freebsd-current@freebsd.org>
Subject: compat3x in 4.0-STABLE?
Message-ID: <Pine.BSF.4.21.0003201642001.5188-100000@fuggle.veldy.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Where did the compat3x install files go in the latest 4.0-STABLE
snapshot?  They seem to be missing.

Tom Veldhouse
veldy@veldy.net



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 14:43:57 2000
Delivered-To: freebsd-current@freebsd.org
Received: from spirit.jaded.net (spirit.jaded.net [216.94.113.12])
	by hub.freebsd.org (Postfix) with ESMTP id 527CD37B75B
	for <current@FreeBSD.ORG>; Mon, 20 Mar 2000 14:43:47 -0800 (PST)
	(envelope-from dan@spirit.jaded.net)
Received: (from dan@localhost)
	by spirit.jaded.net (8.9.3/8.9.3) id QAA07741;
	Mon, 20 Mar 2000 16:58:18 -0500 (EST)
Date: Mon, 20 Mar 2000 16:58:18 -0500
From: Dan Moschuk <dan@FreeBSD.ORG>
To: "Thomas T. Veldhouse" <veldy@veldy.net>
Cc: current@FreeBSD.ORG
Subject: Re: emu10k1 (SB Live!) support under FreeBSD?
Message-ID: <20000320165818.B4876@spirit.jaded.net>
References: <Pine.GSO.4.10.10003191230190.3416-100000@isis.visi.com> <20000319155520.B82854@spirit.jaded.net> <20000320132433.B1790@spirit.jaded.net> <001e01bf92a5$41a2a320$0100a8c0@veldy.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <001e01bf92a5$41a2a320$0100a8c0@veldy.net>; from veldy@veldy.net on Mon, Mar 20, 2000 at 01:48:25PM -0600
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


| > http://www.freebsd.org/~cg/current.diff.gz contains a partial emu10k1
| > driver (minus recording) which is need of debugging.  Give it a try!
| 
| How current is this?  Will it work against 4.0-STABLE?

I haven't tested it, but I believe so.

-- 
Dan Moschuk (TFreak!dan@freebsd.org)
"Waste not fresh tears on old griefs."


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 14:53:48 2000
Delivered-To: freebsd-current@freebsd.org
Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20])
	by hub.freebsd.org (Postfix) with ESMTP id AF37E37BA51
	for <current@FreeBSD.ORG>; Mon, 20 Mar 2000 14:53:27 -0800 (PST)
	(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
	by fw.wintelcom.net (8.10.0/8.10.0) id e2KNGSA06466;
	Mon, 20 Mar 2000 15:16:28 -0800 (PST)
Date: Mon, 20 Mar 2000 15:16:28 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, current@FreeBSD.ORG
Subject: Re: patches for test / review
Message-ID: <20000320151628.F14789@fw.wintelcom.net>
References: <18039.953549289@critter.freebsd.dk> <200003201736.JAA70124@apollo.backplane.com> <20000320111544.A14789@fw.wintelcom.net> <200003202155.NAA72035@apollo.backplane.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200003202155.NAA72035@apollo.backplane.com>; from dillon@apollo.backplane.com on Mon, Mar 20, 2000 at 01:55:05PM -0800
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

* Matthew Dillon <dillon@apollo.backplane.com> [000320 14:18] wrote:
> 
> :> 	lock on the bp.  With a shared lock you are allowed to issue READ
> :> 	I/O but you are not allowed to modify the contents of the buffer.
> :> 	With an exclusive lock you are allowed to issue both READ and WRITE
> :> 	I/O and you can modify the contents of the buffer.
> :> 
> :>       bread()  -> bread_sh() and bread_ex()
> :> 
> :> 	Obtain and validate (issue read I/O as appropriate) a bp.  bread_sh()
> :> 	allows a buffer to be accessed but not modified or rewritten.
> :> 	bread_ex() allows a buffer to be modified and written.
> :
> :This seems to allow for expressing intent to write to buffers,
> :which would be an excellent place to cow the pages 'in software'
> :rather than obsd's way of using cow'd pages to accomplish the same
> :thing.
> 
>     Yes, absolutely.  DG (if I remember right) is rabid about not taking
>     VM faults while sitting in the kernel and I tend to agree with him that
>     it's a cop-out to use VM faults in the kernel to get around those
>     sorts of problems.

ok, so we're on the same page then. :)

> 
> :I'm not sure if you remeber what I brought up at BAFUG, but I'd
> :like to see something along the lines of BX_BKGRDWRITE that Kirk
> :is using for the bitmaps blocks in softupdates to be enabled on a
> :system wide basis.  That way rewriting data that has been sent to
> :the driver isn't blocked and at the same time we don't need to page
> :protect during every strategy call.
> :
> :I may have misunderstood your intent, but using page protections
> :on each IO would seem to introduce a lot of performance issues that
> :the rest of these points are all trying to get rid of.
> 
>     At the low-level device there is no concept of page protections.
>     If you pass an array of vm_page_t's then that is where the data
>     will be taken from or written to.
> 
>     A background-write capability is actually much more easily implemented
>     at the VM Object level then the buffer cache level.  If you think about
>     it, all you need to do is add another VM Object layer *below* the 
>     one representing the device.  Whenever a device write is initiated the
>     pages are moved to the underlying layer.  If a process (or the kernel)
>     needs to modify the pages while the write is in progress, a copy-on-write
>     occurs through normal mechanisms.  On completion of the I/O the pages
>     are moved back to the main VM Object device layer except for those that
>     would conflict with any copy-on-write that occured (the original device
>     pages in the conflict case simply get thrown away).  
> 
>     Problem solved.  Plus this deals with low-memory situations properly...
>     we do not introduce any new deadlocks.

That does sound a lot better, using the buffer system for anything more
than describing an IO is a hack and I'd like to see an implementation such
as this be possible.

> 
> :>       The idea for the buffer cache is to shift its functionality to one that
> :>       is solely used to issue device I/O and to keep track of dirty areas for
> :>       proper sequencing of I/O (e.g. softupdate's use of the buffer cache 
> :>       to placemark I/O will not change).  The core buffer cache code would
> :...
> :
> :Keeping the currect cluster code is a bad idea, if the drivers were
> :taught how to traverse the linked list in the buf struct rather
> :than just notice "a big buffer" we could avoid a lot of page
> :twiddling and also allow for massive IO clustering ( > 64k ) because
> :we won't be limited by the size of the b_pages[] array for our
> :upper bound on the amount of buffers we can issue effectively a
> :scatter/gather on (since the drivers must VTOPHYS them anyway).
> 
>     This devolves down into how simple (or complex) an interface we
>     are willing to use to talk to the low-level device.
> 
>     The reason I would hesitate to move to a 'linked list of buffers'
>     methodology is that *ALL* of the current VM API's pass a single
>     array of vm_page_t's... not just the current struct buf code, but also
>     the VOP_PUTPAGES and VOP_GETPAGES API.
> 
>     I would much prefer to keep this simplicity intact in order to avoid
>     introducing even more bugs into the source then we will when we try
>     to do this stuff, which means changing the clustering code from:
> 
> 	* copies vm_page_t's into the cluster pbuf's b_pages[] array
> 	* maps the pages into b_data
> 
>     to:
> 
> 
> 	* copies vm_page_t's into the cluster pbuf's b_pages[] array
> 
>     In otherwords, keeping the clustering changes as simple as possible.
>     I think once the new I/O path is operational we can then start thinking
>     about how to optimize it -- for example, by having a default (embedded)
>     static array but also allowing the b_pages array to be dynamically
>     allocated.

Why?  Why allocate a special buffer pbuf just for all of this, problems
can develop where you may have implemented this, and now clustering can grow
without (nearly) any bounds, however now you totall have this really inane
complexity for the pbuf which locks down _all_ the buffers associated with
it until the entire pbuf is marked done, I really don't think that is what
you want.

The abstraction is sort of nice, but let's break down the annoyances of
pbufs:

  an extra allocation that can fail when the system is issueing a lot of IO
    (exactly when we need more of them)
  an array fill to track the buffers
  a possible additional allocation for the b_pages if that gets implemented
  buffer lockdown (which although addressed above, is still something to avoid)
  other stuff to make sure the rest of the kernel only sees the pbuf.
  
If anything perhaps a zone for b_pages to allow for easy use of GET/PUT_PAGES
then copying it into the list of buffers.

It's really up to you as you have the time and clue to do this, but I
wanted to bring up the issues I had with the current implementation
as well as an alternate suggestion.

Since you're actually doing the work and I do agree with the direction
it's going I wish you and Kirk the best of luck.

I have to get back to my html/php/db stuff (kill me now). :)

Thanks for taking the time to go over it.

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 15: 1:57 2000
Delivered-To: freebsd-current@freebsd.org
Received: from rover.village.org (rover.village.org [204.144.255.49])
	by hub.freebsd.org (Postfix) with ESMTP id 556F637BA68
	for <freebsd-current@FreeBSD.ORG>; Mon, 20 Mar 2000 15:01:40 -0800 (PST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (harmony.village.org [10.0.0.6])
	by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA19940;
	Mon, 20 Mar 2000 16:01:33 -0700 (MST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA18285; Mon, 20 Mar 2000 16:01:23 -0700 (MST)
Message-Id: <200003202301.QAA18285@harmony.village.org>
To: "Tim Ryder" <tim@freeride.com>
Subject: Re: PCMCIA Maker Modem 
Cc: freebsd-current@FreeBSD.ORG
In-reply-to: Your message of "Mon, 20 Mar 2000 11:12:00 EST."
		<007001bf9287$13b78de0$380aa8c0@tryder.freeride.com> 
References: <007001bf9287$13b78de0$380aa8c0@tryder.freeride.com>  
Date: Mon, 20 Mar 2000 16:01:23 -0700
From: Warner Losh <imp@village.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <007001bf9287$13b78de0$380aa8c0@tryder.freeride.com> "Tim Ryder" writes:
: My pcmcia modem seems to show up as sio4 which does not exist on my system. 

You have two choices.  

First, is to cd /dev and do a 
	MAKEDEV ttyd4 cua4
which will make it possible to use the modem as /dev/ttyd4 and /dev/cuaa4.

Second, you can remove the sio2 and sio3 entries in your config file.

Warner


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 15: 2:43 2000
Delivered-To: freebsd-current@freebsd.org
Received: from rover.village.org (rover.village.org [204.144.255.49])
	by hub.freebsd.org (Postfix) with ESMTP id 3A20C37B9F9
	for <freebsd-current@FreeBSD.ORG>; Mon, 20 Mar 2000 15:02:39 -0800 (PST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (harmony.village.org [10.0.0.6])
	by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA19957;
	Mon, 20 Mar 2000 16:02:36 -0700 (MST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA18314; Mon, 20 Mar 2000 16:02:26 -0700 (MST)
Message-Id: <200003202302.QAA18314@harmony.village.org>
To: Julian Elischer <julian@elischer.org>
Subject: Re: PCMCIA Maker Modem 
Cc: Tim Ryder <tim@freeride.com>, Tim Ryder <tim@mail.freeride.com>,
	freebsd-current@FreeBSD.ORG
In-reply-to: Your message of "Mon, 20 Mar 2000 08:44:23 PST."
		<Pine.BSF.4.10.10003200842000.71150-100000@InterJet.elischer.org> 
References: <Pine.BSF.4.10.10003200842000.71150-100000@InterJet.elischer.org>  
Date: Mon, 20 Mar 2000 16:02:26 -0700
From: Warner Losh <imp@village.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <Pine.BSF.4.10.10003200842000.71150-100000@InterJet.elischer.org> Julian Elischer writes:
: you can also look at the pccard.conf file in /etc
: and rename it to make sio2 if you want.

That isn't guaranteed to work.  Like you note later in your note, if
sio2 is already in the kernel, you won't be able to attach it on
pccard.

The device numbers in /etc/pccard.conf are at best a weak hint.

Warner


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 15: 7:21 2000
Delivered-To: freebsd-current@freebsd.org
Received: from rover.village.org (rover.village.org [204.144.255.49])
	by hub.freebsd.org (Postfix) with ESMTP id 787F337BA6D
	for <freebsd-current@FreeBSD.ORG>; Mon, 20 Mar 2000 15:07:15 -0800 (PST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (harmony.village.org [10.0.0.6])
	by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA19991;
	Mon, 20 Mar 2000 16:07:01 -0700 (MST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA18377; Mon, 20 Mar 2000 16:06:51 -0700 (MST)
Message-Id: <200003202306.QAA18377@harmony.village.org>
To: "Daniel C. Sobral" <dcs@newsguy.com>
Subject: Re: 3 -> 4 when /usr is a vinum volume? 
Cc: Greg Lehey <grog@lemis.com>,
	Palle Girgensohn <girgen@partitur.se>, freebsd-current@FreeBSD.ORG
In-reply-to: Your message of "Tue, 21 Mar 2000 05:14:54 +0900."
		<38D686BE.9CEABD0F@newsguy.com> 
References: <38D686BE.9CEABD0F@newsguy.com>  <38D2EB3E.C4548FCC@partitur.se> <20000319125700.D391@mojave.worldwide.lemis.com> 
Date: Mon, 20 Mar 2000 16:06:51 -0700
From: Warner Losh <imp@village.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <38D686BE.9CEABD0F@newsguy.com> "Daniel C. Sobral" writes:
: make buildworld
: make buildkernel
: make installkernel
: MAKEDEV
: reboot single user
: make -DNOINFO installworld
: make installworld
: 
: As you see, the new klds don't get installed in the presently documented
: procedure. I have read a report wrt to linux compatibility too, but with
: vinum the problem is way bigger.

They are installed as part of the installworld, which is too late.

Warner


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 15:17:45 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mailc.telia.com (mailc.telia.com [194.22.190.4])
	by hub.freebsd.org (Postfix) with ESMTP id DD42F37BA6D
	for <freebsd-current@FreeBSD.ORG>; Mon, 20 Mar 2000 15:17:36 -0800 (PST)
	(envelope-from girgen@partitur.se)
Received: from d1o90.telia.com (d1o90.telia.com [195.67.216.241])
	by mailc.telia.com (8.9.3/8.9.3) with ESMTP id AAA10171;
	Tue, 21 Mar 2000 00:17:22 +0100 (CET)
Received: from stordatan.telia.com (t2o90p43.telia.com [195.67.216.163])
	by d1o90.telia.com (8.8.8/8.8.8) with ESMTP id AAA07839;
	Tue, 21 Mar 2000 00:17:21 +0100 (CET)
Received: from partitur.se (localhost [127.0.0.1])
	by stordatan.telia.com (8.9.3/8.9.1) with ESMTP id AAA07318;
	Tue, 21 Mar 2000 00:16:58 +0100 (CET)
	(envelope-from girgen@partitur.se)
Message-ID: <38D6B16A.93861BD4@partitur.se>
Date: Tue, 21 Mar 2000 00:16:58 +0100
From: Palle Girgensohn <girgen@partitur.se>
Organization: Partitur
X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-CURRENT i386)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: Greg Lehey <grog@lemis.com>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: 3 -> 4 when /usr is a vinum volume?
References: <38D2EB3E.C4548FCC@partitur.se> <20000319125700.D391@mojave.worldwide.lemis.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Greg Lehey wrote:
> 
> [Format recovered--see http://www.lemis.com/email/email-format.html]
> 
> On Saturday, 18 March 2000 at  3:34:38 +0100, Palle Girgensohn wrote:
> > Hi!
> 
> Please don't send messages one line per paragraph.  It's a pain to
> reformat.

Yeah, I had had fiddled with the setting for a specific purpose,
but forgot to set them back. Sorry about that!

> > Following the instructions in UPDATING, when rebooting to single
> > user mode, vinum wouldn't work since the kernel module was out of
> > date - no surprise.
> 
> Hmm.  After updating, you should have had new klds as well.  But
> that's probably not your fault.  Could you enter a PR about it,
> please?

Yes. It's a documentation bug, as has been pointed out by Daniel
C. Sobral.

> > So, I copied a fresh vinum.ko in there and tried again. This time,
> > vinum loaded fine, but complained that it couldn't get the list from
> > disk (or similiar).
> 
> How similar?  That statement doesn't really help very much.  Vinum
> produces error messages to help pinpoint problems.

Unfortunately, I didn't write it down. I regret it. Here's
briefly what happened: since 'start' didn't work, I tried to read
the configurations off the disks one by one, which wasn't a very
good idea, apparently, for since they weren't all started at
once(?), some plexes were marked a faulty. I rebooted the
kernel-3.x and started vinum with the old kld. It started and
read all disks, but some were still marked faulty or flaky. I
stopped and restarted the plexes/disks/subdisks quite a bit
before got them all up again. It seems to me that vinum sometimes
isn't quite logical about its decisions as to whether a
disk/plex/sd is up or flaky. Is there a trick with the restarting
sequence if a disk is marked flaky? I got the error 16(?) (device
busy) a lot, and had to reboot again to get rid of them.

After installing all klds and remaking the devices, I got the
kernel-4.0 to read all the disks with the start command.

> > 3-stable kernel, make first installed the make binary itself, and

OK. Here's another documentation bug, imho. I missed moving the
/etc/rc.conf.local away. make all depends on target
upgrade_checks and it installs make if the test target fails. I
think there should be a note to run make test before
installworld. My make binary was blown away with no warning, and
I was lucky to have another 3.x system left to fetch it from...

> It looks like you shot yourself in the foot.

Yeah, that's one way to put it :)

> I'd have to find out what went wrong first.  It looks as if it should
> have worked modulo the problems installing the klds.

Yep. I'm preparing a pr for documentation bugs.

Thanks for your time.

/Palle


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 16: 0:57 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6])
	by hub.freebsd.org (Postfix) with ESMTP id ED45737B874
	for <freebsd-current@FreeBSD.ORG>; Mon, 20 Mar 2000 16:00:49 -0800 (PST)
	(envelope-from girgen@partitur.se)
Received: from d1o90.telia.com (d1o90.telia.com [195.67.216.241])
	by mailb.telia.com (8.9.3/8.9.3) with ESMTP id AAA16079;
	Tue, 21 Mar 2000 00:59:56 +0100 (CET)
Received: from stordatan.telia.com (t2o90p43.telia.com [195.67.216.163])
	by d1o90.telia.com (8.8.8/8.8.8) with ESMTP id AAA21998;
	Tue, 21 Mar 2000 00:59:56 +0100 (CET)
Received: from partitur.se (localhost [127.0.0.1])
	by stordatan.telia.com (8.9.3/8.9.1) with ESMTP id AAA07770;
	Tue, 21 Mar 2000 00:59:33 +0100 (CET)
	(envelope-from girgen@partitur.se)
Message-ID: <38D6BB65.2C36E3@partitur.se>
Date: Tue, 21 Mar 2000 00:59:33 +0100
From: Palle Girgensohn <girgen@partitur.se>
Organization: Partitur
X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-CURRENT i386)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: Warner Losh <imp@village.org>
Cc: "Daniel C. Sobral" <dcs@newsguy.com>,
	Greg Lehey <grog@lemis.com>, freebsd-current@FreeBSD.ORG
Subject: Re: 3 -> 4 when /usr is a vinum volume?
References: <38D686BE.9CEABD0F@newsguy.com>  <38D2EB3E.C4548FCC@partitur.se> <20000319125700.D391@mojave.worldwide.lemis.com> <200003202306.QAA18377@harmony.village.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Warner Losh wrote:
> 
> In message <38D686BE.9CEABD0F@newsguy.com> "Daniel C. Sobral" writes:
> : make buildworld
> : make buildkernel
> : make installkernel
> : MAKEDEV
> : reboot single user
> : make -DNOINFO installworld
> : make installworld
> :
> : As you see, the new klds don't get installed in the presently documented
> : procedure. I have read a report wrt to linux compatibility too, but with
> : vinum the problem is way bigger.
> 
> They are installed as part of the installworld, which is too late.
> 

It in docs/17518 now.

/Palle


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 16: 1:40 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [194.217.50.228])
	by hub.freebsd.org (Postfix) with ESMTP id 532D137B98E
	for <current@FreeBSD.ORG>; Mon, 20 Mar 2000 16:01:32 -0800 (PST)
	(envelope-from paul@originative.co.uk)
Received: from originative.co.uk (lobster.originative.co.uk [194.217.50.241])
	by mailgate.originative.co.uk (Postfix) with ESMTP
	id 61DE31D131; Tue, 21 Mar 2000 00:01:27 +0000 (GMT)
Message-ID: <38D6BBD7.DA4B950B@originative.co.uk>
Date: Tue, 21 Mar 2000 00:01:27 +0000
From: Paul Richards <paul@originative.co.uk>
Organization: Originative Solutions Ltd
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 4.0-CURRENT i386)
X-Accept-Language: en-GB, en
MIME-Version: 1.0
To: Alfred Perlstein <bright@wintelcom.net>
Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>,
	Matthew Dillon <dillon@apollo.backplane.com>, current@FreeBSD.ORG,
	richard@starburst.demon.co.uk, richard@netcraft.com
Subject: Re: patches for test / review
References: <20000320111544.A14789@fw.wintelcom.net> <20102.953580112@critter.freebsd.dk> <20000320115902.C14789@fw.wintelcom.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Alfred Perlstein wrote:
> 
> * Poul-Henning Kamp <phk@critter.freebsd.dk> [000320 11:45] wrote:
> > In message <20000320111544.A14789@fw.wintelcom.net>, Alfred Perlstein writes:
> >
> > >Keeping the currect cluster code is a bad idea, if the drivers were
> > >taught how to traverse the linked list in the buf struct rather
> > >than just notice "a big buffer" we could avoid a lot of page
> > >twiddling and also allow for massive IO clustering ( > 64k )
> >
> > Before we redesign the clustering, I would like to know if we
> > actually have any recent benchmarks which prove that clustering
> > is overall beneficial ?
> 
> Yes it is really benificial.

Yes, I've seen stats that show the degradation when clustering is
switched off.
Richard Wendlake (who wrote the OS detection code for the Netcraft web
server survey) did a lot of testing in this area because of some
pathological behavior he was seeing using Gnu's dbm package. 

Richard, do you want to post a summary of your tests?

> 
> I'm not talking about a redesign of the clustering code as much as
> making the drivers that take a callback from it actually traverse
> the 'union cluster_info' rather than relying on the system to fake
> the pages being contiguous via remapping.
> 
> There's nothing wrong with the clustering algorithms, it's just the
> steps it has to take to work with the drivers.

Well, there is something wrong with our clustering algorithm. It always
starts a new cluster when the first block of a file is written to. I
found this when trying to explain some of the pathological behavior that
Richard was seeing.

Imagine an algorithm that will write blocks 0,5,2,7,4,1,6,3,0,...

The clustering algorithm starts a new cluster if the block is at the
beginning
of the file, so writing block 0 will always start a new cluster. When
block 5 is written out, the clustering code will try and add it to the
existing cluster, will fail and so will flush the existing cluster which
only has block 0 in it and then start another cluster, with block 5 in
it. This continues, with the previous cluster being flushed and a new
cluster being created with the current block in it. Eventually, we get
to the point where 7 blocks have been flushed and the current cluster
contains block 3. When it comes to write out the next block 0 the
clustering algorithm doesn't bother trying to add the block to the
existing cluster but immediately starts a new one so the cluster with
block 3 in it *never gets flushed*.


Paul.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 16: 1:51 2000
Delivered-To: freebsd-current@freebsd.org
Received: from rover.village.org (rover.village.org [204.144.255.49])
	by hub.freebsd.org (Postfix) with ESMTP id 5681937C116
	for <freebsd-current@FreeBSD.ORG>; Mon, 20 Mar 2000 16:01:47 -0800 (PST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (harmony.village.org [10.0.0.6])
	by rover.village.org (8.9.3/8.9.3) with ESMTP id RAA20230;
	Mon, 20 Mar 2000 17:01:45 -0700 (MST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id RAA18890; Mon, 20 Mar 2000 17:01:34 -0700 (MST)
Message-Id: <200003210001.RAA18890@harmony.village.org>
To: Palle Girgensohn <girgen@partitur.se>
Subject: Re: 3 -> 4 when /usr is a vinum volume? 
Cc: "Daniel C. Sobral" <dcs@newsguy.com>,
	Greg Lehey <grog@lemis.com>, freebsd-current@FreeBSD.ORG
In-reply-to: Your message of "Tue, 21 Mar 2000 00:59:33 +0100."
		<38D6BB65.2C36E3@partitur.se> 
References: <38D6BB65.2C36E3@partitur.se>  <38D686BE.9CEABD0F@newsguy.com> <38D2EB3E.C4548FCC@partitur.se> <20000319125700.D391@mojave.worldwide.lemis.com> <200003202306.QAA18377@harmony.village.org> 
Date: Mon, 20 Mar 2000 17:01:34 -0700
From: Warner Losh <imp@village.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <38D6BB65.2C36E3@partitur.se> Palle Girgensohn writes:
: It in docs/17518 now.

Thanks!

Warner


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 16: 4:37 2000
Delivered-To: freebsd-current@freebsd.org
Received: from thematrix.gigabell.net (thematrix.gigabell.net [195.211.161.106])
	by hub.freebsd.org (Postfix) with SMTP id BAA1337B874
	for <current@freebsd.org>; Mon, 20 Mar 2000 16:04:29 -0800 (PST)
	(envelope-from czmok@thematrix.gigabell.net)
Received: (qmail 68783 invoked by uid 1011); 21 Mar 2000 00:04:30 -0000
Date: Tue, 21 Mar 2000 01:04:30 +0100
From: Jan Ahrent Czmok <czmok@thematrix.gigabell.net>
To: current@freebsd.org
Subject: PRoblems with more than 4 gif devices
Message-ID: <20000321010430.A68769@thematrix.gigabell.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.1.7i
Organization: Gigabell AG
X-NCC-RegID: de.ipf
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Help!

I am trying to use more than 4 gif devices for ipv6.

i have set the appropiate values in config.h but still
only can configure gif0 - gif3.

Any help appreciated.

Please respond OFF-List !

Jan



-- 
Jan Ahrent Czmok
Head of International Peering Department
Gigabell AG
http://www.gigabell.net
phone: +49 69 17084-716



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 16:13:38 2000
Delivered-To: freebsd-current@freebsd.org
Received: from relay.ipf.net (relay.gigabell.net [195.211.211.23])
	by hub.freebsd.org (Postfix) with SMTP id 813F537BA60
	for <freebsd-current@FreeBSD.ORG>; Mon, 20 Mar 2000 16:13:31 -0800 (PST)
	(envelope-from koellmann@gmx.net)
Received: (qmail 37291 invoked from network); 21 Mar 2000 00:13:29 -0000
Received: from dialin-194-29-33-7.hamburg.gigabell.net (HELO server.home.net) (194.29.33.7)
  by relay.gigabell.net with SMTP; 21 Mar 2000 00:13:29 -0000
Received: (qmail 58388 invoked from network); 20 Mar 2000 23:45:14 -0000
Received: from desk.home.net (192.168.1.2)
  by server.home.net with SMTP; 20 Mar 2000 23:45:14 -0000
Received: by desk.home.net (Postfix, from userid 1002)
	id E1DA5934E4; Tue, 21 Mar 2000 00:44:49 +0100 (CET)
Date: Tue, 21 Mar 2000 00:44:49 +0100
From: =?iso-8859-1?Q?Thomas_K=F6llmann?= <koellmann@gmx.net>
To: David O'Brien <obrien@FreeBSD.ORG>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: gcc -Os optimisation broken (RELENG_4)
Message-ID: <20000321004449.A310@home.net>
References: <20000317125045.A15480@schumann.cx> <Pine.BSF.4.21.0003170922440.9372-100000@mammalia.sea> <20000318031845.A1816@home.net> <20000318110022.A60879@dragon.nuxi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 1.0.1i
In-Reply-To: <20000318110022.A60879@dragon.nuxi.com>; from obrien@FreeBSD.ORG on Sat, Mar 18, 2000 at 11:00:22AM -0800
X-Operating-System: FreeBSD 4.0-STABLE
X-PGP-KeyID: 8C45AC01
X-PGP-Fingerprint: C5 F0 DE B2 AD 70 B9 45  B0 F9 0C D3 58 19 48 C8
Organization: =?iso-8859-1?Q?Hamburger_Gesellschaft_mit_beschr=E4nkter_Hoffnung?=
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

David O'Brien wrote/schrieb (Saturday, March 18, 2000):

| On Sat, Mar 18, 2000 at 03:18:45AM +0100, Thomas Köllmann wrote:
| > | Perhaps this is a bit off topic, but can the pentium optimisations be
| > | used for AMD K6 processors?
| > 
| > I did a `make world' yesterday with 
| >         CFLAGS=         -O2 -pipe -march=pentium
| >         COPTFLAGS=      -O2 -pipe -march=pentium
| ..snip..
| > If it doesn't I'll probably try `-03 -pipe -march=pentium' come next
| 
| What are people hoping to get by doing this?  Are you actually doing a
| scientific performance evaluation between the various optimization
| options???  

This is just playing, the machine I was talking about has it's
backups in order and can afford downtime; I mentioned that already,
and I was only answering somebody's question. 

| Are are people just being macho, and thinking they are
| getting all this non-existent performance increase?  

You _are_ feeling strong about this, aren't you? :-)

| "-O" is the only globally safe optimization on FreeBSD.  -O2, etc..
| causes various problems for various people in various ports, and parts of
| /usr/src/.  If people are using these options just for fun, that is fine,

Yes, just for fun, David, just for fun.

| BUT if you experience *any* problems with compiling using -O2, etc..
| don't bug this list -- go bug the GCC people.

Are they a bunch of machos themselves? :-)

Thanks for your point of view.
Gruß
 - Thomas

-- 
Walking to the car, she takes his hand and puts it, for a moment,
lightly between her moving legs. Roger's heart grows erect, and comes.
That's really how it feels. -- Thomas Pynchon, Gravity's Rainbow
# PGP key sent on request / PGP key auf Wunsch per e-mail


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 16:26:40 2000
Delivered-To: freebsd-current@freebsd.org
Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161])
	by hub.freebsd.org (Postfix) with ESMTP
	id 3A30637B943; Mon, 20 Mar 2000 16:26:30 -0800 (PST)
	(envelope-from doconnor@gsoft.com.au)
Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97])
	by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id KAA05206;
	Tue, 21 Mar 2000 10:56:26 +1030 (CST)
	(envelope-from doconnor@gsoft.com.au)
Message-ID: <XFMail.000321105626.doconnor@gsoft.com.au>
X-Mailer: XFMail 1.4.0 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <20000320165818.B4876@spirit.jaded.net>
Date: Tue, 21 Mar 2000 10:56:26 +1030 (CST)
From: "Daniel O'Connor" <doconnor@gsoft.com.au>
To: Dan Moschuk <dan@FreeBSD.ORG>
Subject: Re: emu10k1 (SB Live!) support under FreeBSD?
Cc: current@FreeBSD.ORG, "Thomas T. Veldhouse" <veldy@veldy.net>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


On 20-Mar-00 Dan Moschuk wrote:
> | How current is this?  Will it work against 4.0-STABLE?
>  I haven't tested it, but I believe so.

I applied the patch to a machine which is *just* pre 4/5 split and it patched
fine.

I used it to get my ALS120 to work.

---
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 16:31:59 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.184])
	by hub.freebsd.org (Postfix) with ESMTP
	id 825F537BAAA; Mon, 20 Mar 2000 16:31:55 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Received: from mass.cdrom.com (localhost [127.0.0.1])
	by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id QAA03921;
	Mon, 20 Mar 2000 16:33:40 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Message-Id: <200003210033.QAA03921@mass.cdrom.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To: Alfred Perlstein <bright@wintelcom.net>
Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>,
	Matthew Dillon <dillon@apollo.backplane.com>, current@FreeBSD.ORG,
	bde@FreeBSD.ORG
Subject: Re: I/O clustering, Re: patches for test / review 
In-reply-to: Your message of "Mon, 20 Mar 2000 12:53:17 PST."
             <20000320125317.E14789@fw.wintelcom.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 20 Mar 2000 16:33:40 -0800
From: Mike Smith <msmith@freebsd.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


Just as a perhaps interesting aside on this topic; it'd be quite 
neat for controllers that understand scatter/gather to be able to 
simply suck N regions of buffer cache which were due for committing 
directly into an S/G list...

(wishlist item, I guess 8)

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
\\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 16:36:52 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.184])
	by hub.freebsd.org (Postfix) with ESMTP
	id 4E16537B9F1; Mon, 20 Mar 2000 16:35:03 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Received: from mass.cdrom.com (localhost [127.0.0.1])
	by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id QAA03987;
	Mon, 20 Mar 2000 16:37:09 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Message-Id: <200003210037.QAA03987@mass.cdrom.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc: Alfred Perlstein <bright@wintelcom.net>,
	Matthew Dillon <dillon@apollo.backplane.com>, current@FreeBSD.ORG,
	bde@FreeBSD.ORG
Subject: Re: I/O clustering, Re: patches for test / review 
In-reply-to: Your message of "Mon, 20 Mar 2000 21:33:13 +0100."
             <20471.953584393@critter.freebsd.dk> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 20 Mar 2000 16:37:08 -0800
From: Mike Smith <msmith@freebsd.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> I agree that it is obvious for NFS, but I don't see it as being
> obvious at all for (modern) disks, so for that case I would like
> to see numbers.
> 
> If running without clustering is just as fast for modern disks,
> I think the clustering needs rethought.

I think it should be pretty obvious, actually.  Command overhead is large 
(and not getting much smaller), and clustering primarily serves to reduce 
the number of commands and thus the ratio of command time vs. data time.

So unless the clustering implementation is extremely poor, it's 
worthwhile.
-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
\\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 17:44:30 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.184])
	by hub.freebsd.org (Postfix) with ESMTP id 04E6837B81D
	for <freebsd-current@freebsd.org>; Mon, 20 Mar 2000 17:44:27 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Received: from mass.cdrom.com (localhost [127.0.0.1])
	by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id RAA15576;
	Mon, 20 Mar 2000 17:46:50 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Message-Id: <200003210146.RAA15576@mass.cdrom.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To: "John W. DeBoskey" <jwd@unx.sas.com>
Cc: freebsd-current@freebsd.org
Subject: Re: AMI MegaRAID lockup? not accepting commands. 
In-reply-to: Your message of "Sun, 19 Mar 2000 21:00:35 EST."
             <200003200200.VAA11571@bb01f39.unx.sas.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 20 Mar 2000 17:46:50 -0800
From: Mike Smith <msmith@freebsd.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

>    We have a system with a new AMI card in it controlling a pair
> of shelves from Dell (fbsd dated: 4.0-20000313-SNAP).
> 
>    The relevant dmesg output is below: (complete dmesg at end)
> 
> amr0: <AMI MegaRAID> mem 0xf6c00000-0xf6ffffff irq 14 at device 10.1 on pci2
> amr0: firmware 1.01 bios 1p00  128MB memory
> amrd0: <MegaRAID logical drive> on amr0
> amrd0: 172780MB (353853440 sectors) RAID 5 (optimal)
> 
>    The adapter does not lockup while testing with bonnie and such.

Try running 20 or so bonnie processes in parallel; I can usually get it 
to lock up with this configuration.  I'm wondering which controller 
you've got there though - I don't recognise the BIOS/firmware versions.

> However, we have a 50Gig CVS repository sitting on the raid
> volume. When we do a 'cvs co' of -HEAD, it causes it to lockup.
> The following messages are repeating continuously:
> 
> Mar 19 16:02:59 cvs /kernel: amr0: controller wedged (not taking commands)

I'm not sure why this happens; the controller isn't coming ready even 
though we haven't hit any sort of limit that we're aware of.  I've been 
considering some workarounds involving deferring the command until the 
controller gives us back an interrupt, but I'm still surprised that we 
get to this point at all.

Unfortunately, I'm not able to spend any time on this at the moment; if 
someone wants to do a little experimenting I'd be very happy to talk them 
through what I think should be done (will require some programming 
ability).


-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
\\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 17:50: 4 2000
Delivered-To: freebsd-current@freebsd.org
Received: from fgwmail7.fujitsu.co.jp (fgwmail7.fujitsu.co.jp [192.51.44.37])
	by hub.freebsd.org (Postfix) with ESMTP id F0D0F37B88F
	for <current@FreeBSD.ORG>; Mon, 20 Mar 2000 17:49:56 -0800 (PST)
	(envelope-from shin@nd.net.fujitsu.co.jp)
Received: from m2.gw.fujitsu.co.jp by fgwmail7.fujitsu.co.jp (8.9.3/3.7W-MX0002-Fujitsu Gateway)
	id KAA20099; Tue, 21 Mar 2000 10:49:31 +0900 (JST)
	(envelope-from shin@nd.net.fujitsu.co.jp)
Received: from chisato.nd.net.fujitsu.co.jp by m2.gw.fujitsu.co.jp (8.9.3/3.7W-0002-Fujitsu Domain Master)
	id KAA24388; Tue, 21 Mar 2000 10:49:29 +0900 (JST)
Received: from localhost (dhcp7173.nd.net.fujitsu.co.jp [10.18.7.173]) by chisato.nd.net.fujitsu.co.jp (8.8.5+2.7Wbeta5/3.3W8chisato-970826) with ESMTP id KAA03436; Tue, 21 Mar 2000 10:49:27 +0900 (JST)
To: cpiazza@jaxon.net
Cc: current@FreeBSD.ORG
Subject: Re: 75 second delay using telnet/ssh (ipv6 related)
In-Reply-To: <20000319150009.A404@norn.ca.eu.org>
References: <20000319150009.A404@norn.ca.eu.org>
X-Mailer: Mew version 1.94 on Emacs 20.4 / Mule 4.0 (HANANOEN)
X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000321105026G.shin@nd.net.fujitsu.co.jp>
Date: Tue, 21 Mar 2000 10:50:26 +0900
From: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 24
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> Hi.

Hi,

> This is kind of weird, so I want to see if anyone else has noticed
> this or has a solution to it.
> 
> If I use telnet or ssh (there might be more programs,
> but I have only noticed these two so far), and supply a hostname to it,
> my machine is constantly requesting AAAA records, and finally after
> 75 seconds it requests and receives an A record from the nameserver.

Currently, using -4 option is a workaround for the problem,
but I think this should be fixed by a resolver change as
discussed on this list before.

The change is from,
  all AAAA trial, then all A trial,
to
  try AAAA and A for each trial.

Sorry for the inconvenience and I'll try the fix.

Yoshinobu Inoue


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 18:57:52 2000
Delivered-To: freebsd-current@freebsd.org
Received: from lamb.sas.com (lamb.sas.com [192.35.83.8])
	by hub.freebsd.org (Postfix) with ESMTP
	id 92DA637C330; Mon, 20 Mar 2000 18:56:08 -0800 (PST)
	(envelope-from jwd@unx.sas.com)
Received: from mozart (mozart.unx.sas.com [149.173.6.8])
	by lamb.sas.com (8.9.3/8.9.1) with SMTP id VAA27384;
	Mon, 20 Mar 2000 21:55:58 -0500 (EST)
Received: from bb01f39.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90)
	id AA07732; Mon, 20 Mar 2000 21:55:27 -0500
Received: (from jwd@localhost)
	by bb01f39.unx.sas.com (8.9.3/8.9.1) id VAA24932;
	Mon, 20 Mar 2000 21:55:27 -0500 (EST)
	(envelope-from jwd)
From: "John W. DeBoskey" <jwd@unx.sas.com>
Message-Id: <200003210255.VAA24932@bb01f39.unx.sas.com>
Subject: Re: AMI MegaRAID lockup? not accepting commands.
In-Reply-To: <200003210146.RAA15576@mass.cdrom.com> from Mike Smith at "Mar 20,
 2000 05:46:50 pm"
To: Mike Smith <msmith@freebsd.org>
Date: Mon, 20 Mar 2000 21:55:27 -0500 (EST)
Cc: freebsd-current@freebsd.org, Brad Chisholm <sasblc@unx.sas.com>
X-Mailer: ELM [version 2.4ME+ PL61 (25)]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Hi,

   The controller is new. Dell calls it a Perc2/dc and it has 128Meg
of memory installed in it. I'm not sitting infront of the
machine right now. More detailed information is available
when the machines is booted and you enter the bios setup
on the adapter card.

> >    We have a system with a new AMI card in it controlling a pair
> > of shelves from Dell (fbsd dated: 4.0-20000313-SNAP).
> > 
> >    The relevant dmesg output is below: (complete dmesg at end)
> > 
> > amr0: <AMI MegaRAID> mem 0xf6c00000-0xf6ffffff irq 14 at device 10.1 on pci2
> > amr0: firmware 1.01 bios 1p00  128MB memory
> > amrd0: <MegaRAID logical drive> on amr0
> > amrd0: 172780MB (353853440 sectors) RAID 5 (optimal)
> > 
> >    The adapter does not lockup while testing with bonnie and such.
> 
> Try running 20 or so bonnie processes in parallel; I can usually get it 
> to lock up with this configuration.  I'm wondering which controller 
> you've got there though - I don't recognise the BIOS/firmware versions.
> 
> > However, we have a 50Gig CVS repository sitting on the raid
> > volume. When we do a 'cvs co' of -HEAD, it causes it to lockup.
> > The following messages are repeating continuously:
> > 
> > Mar 19 16:02:59 cvs /kernel: amr0: controller wedged (not taking commands)
> 
> I'm not sure why this happens; the controller isn't coming ready even 
> though we haven't hit any sort of limit that we're aware of.  I've been 
> considering some workarounds involving deferring the command until the 
> controller gives us back an interrupt, but I'm still surprised that we 
> get to this point at all.

   Well, we've been playing around in amr.c/amr_start in the following
code sequence:

    /* spin waiting for the mailbox */
    debug("wait for mailbox");
    for (i = 10000, done = 0, worked = 0; (i > 0) && !done; i--) {
        s = splbio();

        /* is the mailbox free? */
        if (sc->amr_mailbox->mb_busy == 0) {
            debug("got mailbox");
            sc->amr_mailbox64->mb64_segment = 0;
            bcopy(&ac->ac_mailbox, sc->amr_mailbox, AMR_MBOX_CMDSIZE);
            sc->amr_submit_command(sc);
            done = 1;
            sc->amr_workcount++;
            TAILQ_INSERT_TAIL(&sc->amr_work, ac, ac_link);

            /* not free, try to clean up while we wait */
        } else {
-->>       printf("%s: busy flag %x\n", __FUNCTION__, sc->amr_mailbox->mb_busy);
            debug("busy flag %x\n", sc->amr_mailbox->mb_busy);
            worked = amr_done(sc); 
        }
        splx(s);
    }




   Note the addition of the printf statement in the else clause. Two
interesting things happen. One, we are unable to cause the controller
to lock up. Two, the following messages showup in syslog:

Mar 20 12:55:15 cvsstage /kernel: amr_start: busy flag 1
Mar 20 12:55:46 cvsstage last message repeated 1057 times
Mar 20 12:57:47 cvsstage last message repeated 5574 times
Mar 20 12:59:26 cvsstage last message repeated 5431 times
Mar 20 12:59:26 cvsstage /kernel: amr_start: busy flag 0

   If I understand the sequence correctly, we enter splbio() and
then check the mailbox. Most of the time, we take the else clause
and the busy flag is 1 as it should be. However, once every 10 to 12
thousand loops, mb_busy is checked as being 1, but by the time we
get to the else clause, it's 0.

   I wonder if there is some sort of timing issue since the
addition of the printf allows the card to operate correctly. I
haven't traced the kernel printf code, but it could change the
spl level thus allowing the mb_busy flag to be modified.

   Comments?

> 
> Unfortunately, I'm not able to spend any time on this at the moment; if 
> someone wants to do a little experimenting I'd be very happy to talk them 
> through what I think should be done (will require some programming 
> ability).

   We're more than willing to try. Just point us in the right
direction.

> -- 
> \\ Give a man a fish, and you feed him for a day. \\  Mike Smith
> \\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
> \\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com

-John




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 19: 9:54 2000
Delivered-To: freebsd-current@freebsd.org
Received: from tardis.patho.gen.nz (tardis.patho.gen.nz [203.97.2.226])
	by hub.freebsd.org (Postfix) with ESMTP id 5AA4237BB05
	for <current@freebsd.org>; Mon, 20 Mar 2000 19:09:49 -0800 (PST)
	(envelope-from jabley@tardis.patho.gen.nz)
Received: (from jabley@localhost)
	by tardis.patho.gen.nz (8.9.3/8.9.3) id PAA13406
	for current@freebsd.org; Tue, 21 Mar 2000 15:09:45 +1200 (NZST)
Date: Tue, 21 Mar 2000 15:09:43 +1200
From: Joe Abley <jabley@patho.gen.nz>
To: current@freebsd.org
Subject: 4.0-RELEASE boot.flp fails to boot on K6/2
Message-ID: <20000321150940.A13226@patho.gen.nz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
X-Files: the Truth is Out There
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Problem report booting 4.0-RELEASE follows.

  /boot.config: -P
  Keyboard: yes

  BTX loader 1.00  BTX version is 1.01
  Console: internal video/keyboard
  BIOS drive A: is disk0
  BIOS drive C: is disk1
  BIOS 639kB/56256kB available memory

  FreeBSD/i386 bootstrap loader, Revision 0.7
  (jkh@monster.cdrom.com, Wed Mar 15 01:23:43 GMT 2000)
  |
  Hit [Enter] to boot immediately, or any other key for command prompt.
  Booting [kernel]...
  /kernel text=0x1d56fe data=0x2f4ca0+0x1a718 zf_read: fill error

  elf_loadexec: archsw.readin failed
  can't load 'kernel'
  no bootable kernel
  \

  Type '?' for a list of commands, 'help' for more detailed help.
  ok

What does this mean? If this is a -questions question, then please feel
free to flame me privately (just thought it sounded -currentish). If
there are any useful diags I can type, let me know.

Hardware is 350MHz K6/2, generic-looking Asus motherboard with
integrated video and audio, no-name PCI 10baseT ethernet adapter,
floppy, single 20G IDE disk, 64M RAM. No other peripherals.

Have tried different floppies. Recent OpenBSD snapshot floppy works
just fine, by way of crude hardware sanity check.



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 19:11:23 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mauibuilt.com (mauibuilt.com [205.166.249.50])
	by hub.freebsd.org (Postfix) with ESMTP
	id E6B2337B7E1; Mon, 20 Mar 2000 19:11:11 -0800 (PST)
	(envelope-from freebsd@mauibuilt.com)
Received: (from freebsd@localhost)
	by mauibuilt.com (8.9.3/8.9.3) id RAA00995;
	Mon, 20 Mar 2000 17:11:58 -1000 (HST)
	(envelope-from freebsd)
From: FreeBSD MAIL <freebsd@mauibuilt.com>
Message-Id: <200003210311.RAA00995@mauibuilt.com>
Subject: Davicam dc0 driver
To: freebsd-hackers@freebsd.org
Date: Mon, 20 Mar 2000 17:11:56 -1000 (HST)
Cc: freebsd-current@freebsd.org
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

I have a BookPC with a built in Davi Comm 10/100 ethernet card.

I am always getting

/kernel: dc0: watchdog timeout

every few minutes..

Can thease errors be stopped?


Thank you for any reply

RP
puga@mauibuilt.com



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 19:16:11 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.184])
	by hub.freebsd.org (Postfix) with ESMTP
	id 6977E37BDB6; Mon, 20 Mar 2000 19:16:05 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Received: from mass.cdrom.com (localhost [127.0.0.1])
	by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id TAA64793;
	Mon, 20 Mar 2000 19:18:50 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Message-Id: <200003210318.TAA64793@mass.cdrom.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To: "John W. DeBoskey" <jwd@unx.sas.com>
Cc: Mike Smith <msmith@freebsd.org>, freebsd-current@freebsd.org,
	Brad Chisholm <sasblc@unx.sas.com>
Subject: Re: AMI MegaRAID lockup? not accepting commands. 
In-reply-to: Your message of "Mon, 20 Mar 2000 21:55:27 EST."
             <200003210255.VAA24932@bb01f39.unx.sas.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 20 Mar 2000 19:18:50 -0800
From: Mike Smith <msmith@freebsd.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

>    The controller is new. Dell calls it a Perc2/dc and it has 128Meg
> of memory installed in it. I'm not sitting infront of the
> machine right now. More detailed information is available
> when the machines is booted and you enter the bios setup
> on the adapter card.

Ok.  From some rumours coming out of Dell, I get the impression that this 
is an Enterprise 1400 or 1500 with only two channels loaded.  I guess I 
need a better way of telling these controllers apart. 8(

> > >    We have a system with a new AMI card in it controlling a pair
> > > of shelves from Dell (fbsd dated: 4.0-20000313-SNAP).
> > > 
> > >    The relevant dmesg output is below: (complete dmesg at end)
> > > 
> > > amr0: <AMI MegaRAID> mem 0xf6c00000-0xf6ffffff irq 14 at device 10.1 on pci2
> > > amr0: firmware 1.01 bios 1p00  128MB memory
> > > amrd0: <MegaRAID logical drive> on amr0
> > > amrd0: 172780MB (353853440 sectors) RAID 5 (optimal)
> > > 
> > >    The adapter does not lockup while testing with bonnie and such.
> > 
> > Try running 20 or so bonnie processes in parallel; I can usually get it 
> > to lock up with this configuration.  I'm wondering which controller 
> > you've got there though - I don't recognise the BIOS/firmware versions.
> > 
> > > However, we have a 50Gig CVS repository sitting on the raid
> > > volume. When we do a 'cvs co' of -HEAD, it causes it to lockup.
> > > The following messages are repeating continuously:
> > > 
> > > Mar 19 16:02:59 cvs /kernel: amr0: controller wedged (not taking commands)
> > 
> > I'm not sure why this happens; the controller isn't coming ready even 
> > though we haven't hit any sort of limit that we're aware of.  I've been 
> > considering some workarounds involving deferring the command until the 
> > controller gives us back an interrupt, but I'm still surprised that we 
> > get to this point at all.
> 
>    Well, we've been playing around in amr.c/amr_start in the following
> code sequence:
> 
>     /* spin waiting for the mailbox */
>     debug("wait for mailbox");
>     for (i = 10000, done = 0, worked = 0; (i > 0) && !done; i--) {
>         s = splbio();
> 
>         /* is the mailbox free? */
>         if (sc->amr_mailbox->mb_busy == 0) {
>             debug("got mailbox");
>             sc->amr_mailbox64->mb64_segment = 0;
>             bcopy(&ac->ac_mailbox, sc->amr_mailbox, AMR_MBOX_CMDSIZE);
>             sc->amr_submit_command(sc);
>             done = 1;
>             sc->amr_workcount++;
>             TAILQ_INSERT_TAIL(&sc->amr_work, ac, ac_link);
> 
>             /* not free, try to clean up while we wait */
>         } else {
> -->>       printf("%s: busy flag %x\n", __FUNCTION__, sc->amr_mailbox->mb_busy);
>             debug("busy flag %x\n", sc->amr_mailbox->mb_busy);
>             worked = amr_done(sc); 
>         }
>         splx(s);
>     }
> 
> 
> 
> 
>    Note the addition of the printf statement in the else clause. Two
> interesting things happen. One, we are unable to cause the controller
> to lock up. Two, the following messages showup in syslog:
> 
> Mar 20 12:55:15 cvsstage /kernel: amr_start: busy flag 1
> Mar 20 12:55:46 cvsstage last message repeated 1057 times
> Mar 20 12:57:47 cvsstage last message repeated 5574 times
> Mar 20 12:59:26 cvsstage last message repeated 5431 times
> Mar 20 12:59:26 cvsstage /kernel: amr_start: busy flag 0
> 
>    If I understand the sequence correctly, we enter splbio() and
> then check the mailbox. Most of the time, we take the else clause
> and the busy flag is 1 as it should be. However, once every 10 to 12
> thousand loops, mb_busy is checked as being 1, but by the time we
> get to the else clause, it's 0.
> 
>    I wonder if there is some sort of timing issue since the
> addition of the printf allows the card to operate correctly. I
> haven't traced the kernel printf code, but it could change the
> spl level thus allowing the mb_busy flag to be modified.
> 
>    Comments?

The mb_busy flag is in system memory, but it's maintained by the card 
itself (it will bus-master and update it according to its internal state).
Thus, when you see it printed as 0, somewhere between the test and the 
printf the controller has updated the flag and indicated it's busy. 

You probably only see this quite rarely because the code path from the 
if() to the printf() is very short (a jump) while the code path the rest of
the way 'round is much longer (through printf(), amr_done(), splx(),
splbio() etc.).

Adding the printfs massively slows the loop down; you might try 
increasing the timeout (initial value of 'i') by an order of magnitude 
instead.  The real problem here is the spinloop - because the flag is in 
system memory, the loop runs entirely in the cache and thus executes 
insanely quickly.  If it wasn't for the fact that this code is called 
both with interrupts enabled and disabled, I'd use a much shorter loop 
and simply defer the command if the controller didn't come ready almost 
immediately.  Some strategic use of DELAY() might also help.  The Linux 
driver uses the following code:

/*==================================================*/
/* Wait until the controller's mailbox is available */
/*==================================================*/
static int mega_busyWaitMbox (mega_host_config * megaCfg)
{
  mega_mailbox *mbox = (mega_mailbox *) megaCfg->mbox;
  long counter;

  for (counter = 0; counter < 10000; counter++) {
    if (!mbox->busy) {
      return 0;
    }
    udelay (100);
    barrier();
  }
  return -1;                    /* give up after 1 second */
}

I'd be guessing that the current loop (100k iterations) is probably 
completing far sooner than 1s.  You could confirm this by grabbing a 
timestamp at the beginning of amr_start and then checking again at the 
point where it bails out.  If that's the case, try cutting the initial 
value of i down to 10,000 and insert a DELAY(100) in the "did not get 
mailbox" case.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
\\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 19:22:25 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.184])
	by hub.freebsd.org (Postfix) with ESMTP
	id 77FED37BA75; Mon, 20 Mar 2000 19:22:17 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Received: from mass.cdrom.com (localhost [127.0.0.1])
	by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id TAA70819;
	Mon, 20 Mar 2000 19:25:08 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Message-Id: <200003210325.TAA70819@mass.cdrom.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To: Mike Smith <msmith@freebsd.org>
Cc: "John W. DeBoskey" <jwd@unx.sas.com>,
	freebsd-current@freebsd.org, Brad Chisholm <sasblc@unx.sas.com>
Subject: Re: AMI MegaRAID lockup? not accepting commands. 
In-reply-to: Your message of "Mon, 20 Mar 2000 19:18:50 PST."
             <200003210318.TAA64793@mass.cdrom.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 20 Mar 2000 19:25:08 -0800
From: Mike Smith <msmith@freebsd.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


A couple of clarifications on the last message:

> Thus, when you see it printed as 0, somewhere between the test and the 
> printf the controller has updated the flag and indicated it's busy. 

That should of course be "not busy".

> I'd be guessing that the current loop (100k iterations) is probably 
> completing far sooner than 1s.  You could confirm this by grabbing a 
> timestamp at the beginning of amr_start and then checking again at the 
> point where it bails out.  If that's the case, try cutting the initial 
> value of i down to 10,000 and insert a DELAY(100) in the "did not get 
> mailbox" case.

I didn't use DELAY() initially because I wasn't sure it would work 
correctly if called before interrupts are enabled.  That was probably a 
stupid mistake; I would try the above suggestion first as I suspect it'll 
get you going.

Not that I consider this particuarly optimal; busy-waiting for the 
controller is a terrible waste of the host CPU.  A better solution would 
probably defer the command and try again a short time later, but let's 
see if this works first.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
\\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 19:36:25 2000
Delivered-To: freebsd-current@freebsd.org
Received: from lynx.aba.net.au (lynx.esec.com.au [203.21.84.1])
	by hub.freebsd.org (Postfix) with SMTP id 1680937BC0A
	for <freebsd-current@freebsd.org>; Mon, 20 Mar 2000 19:35:51 -0800 (PST)
	(envelope-from tim@esec.com.au)
Received: (qmail 20327 invoked from network); 21 Mar 2000 03:33:46 -0000
Received: from feline.esec.com.au (203.21.85.202)
  by lynx.esec.com.au with SMTP; 21 Mar 2000 03:33:46 -0000
Received: from esec.com.au (localhost [127.0.0.1])
	by feline.esec.com.au (8.9.3/8.9.3) with ESMTP id OAA00274
	for <freebsd-current@freebsd.org>; Tue, 21 Mar 2000 14:36:23 +1100 (EST)
	(envelope-from tim@esec.com.au)
Message-ID: <38D6EE37.BE29789D@esec.com.au>
Date: Tue, 21 Mar 2000 14:36:23 +1100
From: Tim Liddelow <tim@esec.com.au>
Organization: eSec Ltd
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: freebsd-current@freebsd.org
Subject: Re: Duplicate inodes, filesystem weirdness
References: <38D188A5.14471919@esec.com.au>
Content-Type: multipart/mixed;
 boundary="------------52A4979F061D6BD5496D38BD"
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

This is a multi-part message in MIME format.
--------------52A4979F061D6BD5496D38BD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


I have a followup fsck listing related to the above issue.

Basically, it only seems to happen with my cvsup area(s).   I don't know
why this is, but cvsup craps out with 'can't create directory' and I find
that a directory is now a file, with heaps of errors on the disk.

I have attached a read-only fsck of my /usr (which is where all the problems
are).

Does anyone have any idea what this is ?  Oh, and before you say it,
no, it's _not_ hardware related.  The disk in question runs fine under the
old wd driver.

Cheers
Tim.


--------------52A4979F061D6BD5496D38BD
Content-Type: text/plain; charset=iso-8859-1;
 name="fsck.out"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline;
 filename="fsck.out"

2819383 DUP I=3D6826572819384 DUP I=3D6826582819385 DUP I=3D6826592819386=
 DUP I=3D6826602819387 DUP I=3D6826612819388 DUP I=3D6826622819389 DUP I=3D=
6826632819390 DUP I=3D6826642819391 DUP I=3D6826652819392 DUP I=3D6826662=
819393 DUP I=3D6826672819394 DUP I=3D6826682819395 DUP I=3D6826692819396 =
DUP I=3D6826692819397 DUP I=3D6826702819398 DUP I=3D6826712819399 DUP I=3D=
6826722819400 DUP I=3D6826732819372 DUP I=3D6826742819402 DUP I=3D6826752=
819403 DUP I=3D6826762819404 DUP I=3D6826772819405 DUP I=3D6826772819406 =
DUP I=3D6826782819407 DUP I=3D6826792819408 DUP I=3D6826802819409 DUP I=3D=
6826812819410 DUP I=3D6826822819411 DUP I=3D6826832819412 DUP I=3D6826842=
819413 DUP I=3D6826842819414 DUP I=3D6826852819415 DUP I=3D6826862819416 =
DUP I=3D6826872819382 DUP I=3D6832572819382 DUP I=3D6826242819383 DUP I=3D=
6826252819384 DUP I=3D6826262819385 DUP I=3D6826272819386 DUP I=3D6826282=
819387 DUP I=3D6826292819388 DUP I=3D6826302819389 DUP I=3D6826312819390 =
DUP I=3D6826322819391 DUP I=3D6826332819392 DUP I=3D6826342819393 DUP I=3D=
6826352819394 DUP I=3D6826362819395 DUP I=3D6826372819396 DUP I=3D6826372=
819397 DUP I=3D6826382819398 DUP I=3D6826392819399 DUP I=3D6826402819400 =
DUP I=3D6826412819372 DUP I=3D6826422819402 DUP I=3D6826432819403 DUP I=3D=
6826442819404 DUP I=3D6826452819405 DUP I=3D6826452819406 DUP I=3D6826462=
819407 DUP I=3D6826472819408 DUP I=3D6826482819409 DUP I=3D6826492819410 =
DUP I=3D6826502819411 DUP I=3D6826512819412 DUP I=3D6826522819413 DUP I=3D=
6826522819414 DUP I=3D6826532819415 DUP I=3D6826542819416 DUP I=3D682655D=
UP/BAD FILE=3D/lost+found/#0682677
BAD TYPE VALUE FILE=3D/lost+found/#0682677
ZERO LENGTH DIRECTORY DIR=3D/ports/graphics/tgif-nls/patches
ZERO LENGTH DIRECTORY DIR=3D/ports/graphics/pgplot/scripts
ZERO LENGTH DIRECTORY DIR=3D/ports/irc/irssi/pkg
ZERO LENGTH DIRECTORY DIR=3D/ports/java/jfc
ZERO LENGTH DIRECTORY DIR=3D/ports/lang/intel2gas/pkg
ZERO LENGTH DIRECTORY DIR=3D/ports/graphics/Cgraph/pkg
DUP/BAD FILE=3D/ports/lang/squeak1/patches
BAD TYPE VALUE FILE=3D/ports/lang/squeak1/patches
ZERO LENGTH DIRECTORY DIR=3D/ports/japanese/ndtpd/pkg
ZERO LENGTH DIRECTORY DIR=3D/ports/print/trueprint/pkg
DUP/BAD FILE=3D/ports/mail/exim/files
BAD TYPE VALUE FILE=3D/ports/mail/exim/files
DUP/BAD FILE=3D/ports/print/trueprint/pkg/COMMENT
ZERO LENGTH DIRECTORY DIR=3D/ports/print/trueprint/pkg/DESCR
BAD TYPE VALUE DIR=3D/ports/print/trueprint/pkg/DESCR
DUP/BAD FILE=3D/ports/print/trueprint/pkg/PLIST
BAD INODE NUMBER FOR '.' DIR=3D?
? IS AN EXTRANEOUS HARD LINK TO DIRECTORY ?
BAD TYPE VALUE DIR=3D?
DUP/BAD FILE=3D/ports/games/xoids/pkg/DESCR
DUP/BAD FILE=3D/ports/games/xoids/pkg/PLIST
DUP/BAD FILE=3D/ports/graphics/Cgraph/pkg/COMMENT
DUP/BAD FILE=3D/ports/graphics/Cgraph/pkg/DESCR
DUP/BAD FILE=3D/ports/graphics/Cgraph/pkg/PLIST
BAD INODE NUMBER FOR '.' DIR=3D?
? IS AN EXTRANEOUS HARD LINK TO DIRECTORY ?/files
? IS AN EXTRANEOUS HARD LINK TO DIRECTORY ?/pkg
DUP/BAD FILE=3D?
DUP/BAD FILE=3D?
BAD INODE NUMBER FOR '.' DIR=3D?
? IS AN EXTRANEOUS HARD LINK TO DIRECTORY /ports/graphics/gview/files
? IS AN EXTRANEOUS HARD LINK TO DIRECTORY /ports/graphics/gview/pkg
DUP/BAD FILE=3D/ports/graphics/pgplot/scripts/configure
DUP/BAD FILE=3D/ports/graphics/pgplot/scripts/COMMENT
BAD INODE NUMBER FOR '.' DIR=3D?
DUP/BAD FILE=3D/ports/graphics/tgif-nls/patches/patch-aa
DUP/BAD FILE=3D/ports/graphics/tgif-nls/patches/patch-ab
BAD INODE NUMBER FOR '.' DIR=3D?
DUP/BAD FILE=3D/ports/irc/irssi/pkg/COMMENT
DUP/BAD FILE=3D/ports/irc/irssi/pkg/DESCR
DUP/BAD FILE=3D/ports/irc/irssi/pkg/PLIST
BAD INODE NUMBER FOR '.' DIR=3D?
DUP/BAD FILE=3D?
DUP/BAD FILE=3D?
DUP/BAD FILE=3D?
DUP/BAD FILE=3D?
DUP/BAD FILE=3D?
BAD INODE NUMBER FOR '.' DIR=3D?
DUP/BAD FILE=3D/ports/japanese/ndtpd/pkg/COMMENT
DUP/BAD FILE=3D/ports/japanese/ndtpd/pkg/DESCR
DUP/BAD FILE=3D/ports/japanese/ndtpd/pkg/INSTALL
DUP/BAD FILE=3D/ports/japanese/ndtpd/pkg/MESSAGE
DUP/BAD FILE=3D/ports/japanese/ndtpd/pkg/PLIST
BAD INODE NUMBER FOR '.' DIR=3D?
DUP/BAD FILE=3D?
BAD INODE NUMBER FOR '.' DIR=3D?
? IS AN EXTRANEOUS HARD LINK TO DIRECTORY /ports/japanese/vfghostscript5/=
files
? IS AN EXTRANEOUS HARD LINK TO DIRECTORY /ports/japanese/vfghostscript5/=
patches
? IS AN EXTRANEOUS HARD LINK TO DIRECTORY /ports/japanese/vfghostscript5/=
pkg
? IS AN EXTRANEOUS HARD LINK TO DIRECTORY /ports/japanese/vfghostscript5/=
scripts
DUP/BAD FILE=3D/ports/misc/amanda/patches
BAD TYPE VALUE FILE=3D/ports/misc/amanda/patches
ZERO LENGTH DIRECTORY DIR=3D/ports/graphics/gview
DUP/BAD FILE=3D/ports/security/zombiezapper/files
BAD TYPE VALUE FILE=3D/ports/security/zombiezapper/files
ZERO LENGTH DIRECTORY DIR=3D/ports/japanese/vfghostscript5
ZERO LENGTH DIRECTORY DIR=3D/ports/japanese/gn-gnspool/files
BAD INODE NUMBER FOR '..' DIR=3D?
BAD INODE NUMBER FOR '..' DIR=3D?
BAD INODE NUMBER FOR '..' DIR=3D?/files
BAD INODE NUMBER FOR '..' DIR=3D?
BAD INODE NUMBER FOR '..' DIR=3D/ports/java/jfc
BAD INODE NUMBER FOR '..' DIR=3D?
BAD INODE NUMBER FOR '..' DIR=3D/ports/lang/intel2gas/pkg
BAD INODE NUMBER FOR '..' DIR=3D?/pkg
BAD INODE NUMBER FOR '..' DIR=3D?
UNREF DIR UNREF DIR UNREF DIR UNREF DIR UNREF DIR UNREF DIR UNREF DIR LIN=
K COUNT DIRLINK COUNT DIRLINK COUNT DIRLINK COUNT DIRLINK COUNT DIRLINK C=
OUNT DIRLINK COUNT DIRLINK COUNT DIRLINK COUNT DIRLINK COUNT DIRLINK COUN=
T DIRLINK COUNT DIRLINK COUNT DIRLINK COUNT DIRLINK COUNT DIRLINK COUNT D=
IRLINK COUNT FILEUNREF FILE ** /dev/ad0s1f (NO WRITE)
** Last Mounted on /usr
** Phase 1 - Check Blocks and Sizes



































** Phase 1b - Rescan For More DUPS



































** Phase 2 - Check Pathnames
 I=3D682677  OWNER=3Droot MODE=3D100644
SIZE=3D1378 MTIME=3DJan 15 09:19 1999 =


REMOVE? no

 I=3D682677  OWNER=3Droot MODE=3D100644
SIZE=3D1378 MTIME=3DJan 15 09:19 1999 =


FIX? no

 I=3D682635  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:00 2000 =


REMOVE? no

 I=3D682633  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:00 2000 =


REMOVE? no

 I=3D682638  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 15 14:40 2000 =


REMOVE? no

 I=3D682658  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 21 13:26 2000 =


REMOVE? no

 I=3D682665  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 21 13:27 2000 =


REMOVE? no

 I=3D682626  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 20:59 2000 =


REMOVE? no

 I=3D682669  OWNER=3Droot MODE=3D100644
SIZE=3D1277 MTIME=3DJan 22 14:16 2000 =


REMOVE? no

 I=3D682669  OWNER=3Droot MODE=3D100644
SIZE=3D1277 MTIME=3DJan 22 14:16 2000 =


FIX? no

 I=3D682649  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:00 2000 =


REMOVE? no

 I=3D682642  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 15 14:46 2000 =


REMOVE? no

 I=3D682671  OWNER=3Droot MODE=3D100644
SIZE=3D52 MTIME=3DAug 14 19:05 1999 =


REMOVE? no

 I=3D682671  OWNER=3Droot MODE=3D100644
SIZE=3D52 MTIME=3DAug 14 19:05 1999 =


FIX? no

 I=3D682661  OWNER=3Droot MODE=3D100644
SIZE=3D479 MTIME=3DDec 24 18:10 1998 =


REMOVE? no

 I=3D682662  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:00 2000 =


REMOVE? no

 I=3D682662  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:00 2000 =


FIX? no

 I=3D682663  OWNER=3Droot MODE=3D100644
SIZE=3D942 MTIME=3DJan  2 09:56 2000 =


REMOVE? no

 I=3D682674  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 15 14:46 2000 =


FIX? no


REMOVE? no

 I=3D682662  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:00 2000 =


FIX? no

 I=3D682624  OWNER=3Droot MODE=3D100644
SIZE=3D792 MTIME=3DApr 27 15:01 1998 =


REMOVE? no

 I=3D682625  OWNER=3Droot MODE=3D100644
SIZE=3D56 MTIME=3DAug 13 12:23 1998 =


REMOVE? no

 I=3D682627  OWNER=3Droot MODE=3D100644
SIZE=3D35 MTIME=3DDec 24 18:10 1998 =


REMOVE? no

 I=3D682628  OWNER=3Droot MODE=3D100644
SIZE=3D376 MTIME=3DDec 24 18:10 1998 =


REMOVE? no

 I=3D682629  OWNER=3Droot MODE=3D100644
SIZE=3D479 MTIME=3DDec 24 18:10 1998 =


REMOVE? no

 I=3D682658  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 21 13:26 2000 =


FIX? no


REMOVE? no


REMOVE? no

 I=3D682631  OWNER=3Droot MODE=3D100644
SIZE=3D942 MTIME=3DJan  2 09:56 2000 =


REMOVE? no

 I=3D682632  OWNER=3Droot MODE=3D100644
SIZE=3D1024 MTIME=3DFeb  9 15:30 2000 =


REMOVE? no

 I=3D682662  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:00 2000 =


FIX? no


REMOVE? no


REMOVE? no

 I=3D682634  OWNER=3Droot MODE=3D100644
SIZE=3D289 MTIME=3DDec 22 15:36 1996 =


REMOVE? no

 I=3D683257  OWNER=3Droot MODE=3D100644
SIZE=3D61 MTIME=3DJun 27 04:40 1999 =


REMOVE? no

 I=3D682665  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 21 13:27 2000 =


FIX? no

 I=3D682636  OWNER=3Droot MODE=3D100644
SIZE=3D247 MTIME=3DJan 22 14:16 2000 =


REMOVE? no

 I=3D682637  OWNER=3Droot MODE=3D100644
SIZE=3D1277 MTIME=3DJan 22 14:16 2000 =


REMOVE? no

 I=3D682667  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:00 2000 =


FIX? no

 I=3D682639  OWNER=3Droot MODE=3D100644
SIZE=3D52 MTIME=3DAug 14 19:05 1999 =


REMOVE? no

 I=3D682640  OWNER=3Droot MODE=3D100644
SIZE=3D306 MTIME=3DAug 14 17:11 1999 =


REMOVE? no

 I=3D682641  OWNER=3Droot MODE=3D100644
SIZE=3D761 MTIME=3DJan 25 07:34 2000 =


REMOVE? no

 I=3D682670  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 15 14:40 2000 =


FIX? no

 I=3D682644  OWNER=3Droot MODE=3D100644
SIZE=3D481 MTIME=3DJun  5 00:47 1998 =


REMOVE? no

 I=3D682645  OWNER=3Droot MODE=3D100644
SIZE=3D1378 MTIME=3DJan 15 09:19 1999 =


REMOVE? no

 I=3D682646  OWNER=3Droot MODE=3D100644
SIZE=3D237 MTIME=3DFeb 15 22:09 1997 =


REMOVE? no

 I=3D682647  OWNER=3Droot MODE=3D100644
SIZE=3D56 MTIME=3DJan 15 09:19 1999 =


REMOVE? no

 I=3D682648  OWNER=3Droot MODE=3D100644
SIZE=3D644 MTIME=3DJun  5 00:47 1998 =


REMOVE? no

 I=3D682675  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:00 2000 =


FIX? no

 I=3D682650  OWNER=3Droot MODE=3D100644
SIZE=3D44 MTIME=3DJun 27 03:50 1999 =


REMOVE? no

 I=3D682651  OWNER=3Droot MODE=3D100644
SIZE=3D632 MTIME=3DAug 19 20:50 1999 =


REMOVE? no

 I=3D682652  OWNER=3Droot MODE=3D100644
SIZE=3D1388 MTIME=3DAug 19 20:50 1999 =


REMOVE? no

 I=3D682653  OWNER=3Droot MODE=3D100644
SIZE=3D882 MTIME=3DJan 22 17:40 2000 =


REMOVE? no

 I=3D682654  OWNER=3Droot MODE=3D100644
SIZE=3D365 MTIME=3DJan 22 17:40 2000 =


REMOVE? no

 I=3D682681  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:00 2000 =


FIX? no

 I=3D682657  OWNER=3Droot MODE=3D100644
SIZE=3D56 MTIME=3DAug 13 12:23 1998 =


REMOVE? no

 I=3D682687  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:01 2000 =


FIX? no


REMOVE? no


REMOVE? no


REMOVE? no


REMOVE? no

 I=3D682685  OWNER=3Droot MODE=3D100644
SIZE=3D882 MTIME=3DJan 22 17:40 2000 =


REMOVE? no

 I=3D682685  OWNER=3Droot MODE=3D100644
SIZE=3D882 MTIME=3DJan 22 17:40 2000 =


FIX? no

 I=3D682630  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:00 2000 =


REMOVE? no

 I=3D682664  OWNER=3Droot MODE=3D100644
SIZE=3D1024 MTIME=3DFeb  9 15:30 2000 =


REMOVE? no

 I=3D682664  OWNER=3Droot MODE=3D100644
SIZE=3D1024 MTIME=3DFeb  9 15:30 2000 =


FIX? no

 I=3D682655  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 21 13:25 2000 =


REMOVE? no

 I=3D682643  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:00 2000 =


REMOVE? no

 I=3D365215  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:01 2000 =


FIX? no

 I=3D508063  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:01 2000 =


FIX? no

 I=3D627078  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:00 2000 =


FIX? no

 I=3D674719  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:01 2000 =


FIX? no

 I=3D682658  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 21 13:26 2000 =


FIX? no

 I=3D682662  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:00 2000 =


FIX? no

 I=3D682665  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 21 13:27 2000 =


FIX? no

 I=3D698472  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:00 2000 =


FIX? no

 I=3D1087391  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:01 2000 =


FIX? no

** Phase 3 - Check Connectivity
 I=3D1087391  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:01 2000 =

RECONNECT? no

 I=3D1031842  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:01 2000 =

RECONNECT? no

 I=3D944546  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:01 2000 =

RECONNECT? no

 I=3D682662  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:00 2000 =

RECONNECT? no

 I=3D674719  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:01 2000 =

RECONNECT? no

 I=3D508063  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:01 2000 =

RECONNECT? no

 I=3D365215  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:01 2000 =

RECONNECT? no

** Phase 4 - Check Reference Counts
 I=3D587  OWNER=3Droot MODE=3D41777
SIZE=3D17408 MTIME=3DMar 16 09:14 2000  COUNT 60 SHOULD BE 59
ADJUST? no

 I=3D31883  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:00 2000  COUNT 5 SHOULD BE 6
ADJUST? no

 I=3D262025  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:00 2000  COUNT 6 SHOULD BE 7
ADJUST? no

 I=3D365215  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:01 2000  COUNT 2 SHOULD BE 3
ADJUST? no

 I=3D396942  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 15 14:40 2000  COUNT 5 SHOULD BE 6
ADJUST? no

 I=3D436641  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 15 14:42 2000  COUNT 25 SHOULD BE 24
ADJUST? no

 I=3D460457  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:01 2000  COUNT 5 SHOULD BE 4
ADJUST? no

 I=3D492162  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 20:59 2000  COUNT 5 SHOULD BE 6
ADJUST? no

 I=3D492205  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 15 14:42 2000  COUNT 5 SHOULD BE 4
ADJUST? no

 I=3D508057  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:00 2000  COUNT 4 SHOULD BE 5
ADJUST? no

 I=3D508063  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:01 2000  COUNT 2 SHOULD BE 3
ADJUST? no

 I=3D508116  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 15 14:46 2000  COUNT 5 SHOULD BE 6
ADJUST? no

 I=3D564199  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 21 13:27 2000  COUNT 2 SHOULD BE 3
ADJUST? no

 I=3D627078  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:00 2000  COUNT 2 SHOULD BE 3
ADJUST? no

 I=3D674719  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:01 2000  COUNT 2 SHOULD BE 3
ADJUST? no

 I=3D674735  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 15 14:43 2000  COUNT 5 SHOULD BE 4
ADJUST? no

 I=3D682606  OWNER=3Droot MODE=3D100644
SIZE=3D964 MTIME=3DMar 15 14:40 2000  COUNT 1 SHOULD BE 2
ADJUST? no

 I=3D682612  OWNER=3Droot MODE=3D100644
SIZE=3D20LINK COUNT FILELINK COUNT FILELINK COUNT FILELINK COUNT DIRLINK =
COUNT FILELINK COUNT FILELINK COUNT FILELINK COUNT FILELINK COUNT FILELIN=
K COUNT FILELINK COUNT FILELINK COUNT FILELINK COUNT DIRLINK COUNT FILELI=
NK COUNT FILELINK COUNT FILELINK COUNT FILELINK COUNT FILELINK COUNT FILE=
LINK COUNT FILELINK COUNT FILELINK COUNT FILELINK COUNT FILELINK COUNT DI=
RLINK COUNT FILELINK COUNT FILELINK COUNT DIRBAD/DUP FILEBAD/DUP FILELINK=
 COUNT FILELINK COUNT DIRLINK COUNT FILEBAD/DUP FILEBAD/DUP DIRBAD/DUP FI=
LEBAD/DUP DIRBAD/DUP FILEBAD/DUP FILEBAD/DUP DIRBAD/DUP DIRBAD/DUP FILEBA=
D/DUP FILEBAD/DUP FILEBAD/DUP FILEBAD/DUP DIRBAD/DUP FILEBAD/DUP FILEBAD/=
DUP FILEBAD/DUP FILEBAD/DUP DIRUNREF FILE UNREF FILE UNREF FILE UNREF FIL=
E LINK COUNT FILELINK COUNT FILELINK COUNT FILELINK COUNT FILELINK COUNT =
DIRLINK COUNT DIRLINK COUNT DIRLINK COUNT DIRLINK COUNT DIRLINK COUNT DIR=
LINK COUNT DIRUNREF FILEUNREF FILELINK COUNT DIRLINK COUNT DIRLINK COUNT =
DIRFREE BLK COUNT(S) WRONG IN SUPERBLKSUMMARY INFORMATION BADBLK(S) MISSI=
NG IN BIT MAPS132607 files, 1373499 used, 4221194 free 610 MTIME=3DMar 15=
 14:43 2000 =

RECONNECT? no


CLEAR? no

 I=3D682627  OWNER=3Droot MODE=3D100644
SIZE=3D35 MTIME=3DDec 24 18:10 1998  COUNT 1 SHOULD BE 2
ADJUST? no

 I=3D682628  OWNER=3Droot MODE=3D100644
SIZE=3D376 MTIME=3DDec 24 18:10 1998  COUNT 1 SHOULD BE 2
ADJUST? no

 I=3D682629  OWNER=3Droot MODE=3D100644
SIZE=3D479 MTIME=3DDec 24 18:10 1998  COUNT 1 SHOULD BE 2
ADJUST? no

 I=3D682630  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:00 2000  COUNT 4 SHOULD BE 1
ADJUST? no

 I=3D682631  OWNER=3Droot MODE=3D100644
SIZE=3D942 MTIME=3DJan  2 09:56 2000  COUNT 1 SHOULD BE 2
ADJUST? no

 I=3D682632  OWNER=3Droot MODE=3D100644
SIZE=3D1024 MTIME=3DFeb  9 15:30 2000  COUNT 1 SHOULD BE 2
ADJUST? no

 I=3D682634  OWNER=3Droot MODE=3D100644
SIZE=3D289 MTIME=3DDec 22 15:36 1996  COUNT 1 SHOULD BE 2
ADJUST? no

 I=3D682636  OWNER=3Droot MODE=3D100644
SIZE=3D247 MTIME=3DJan 22 14:16 2000  COUNT 1 SHOULD BE 2
ADJUST? no

 I=3D682637  OWNER=3Droot MODE=3D100644
SIZE=3D1277 MTIME=3DJan 22 14:16 2000  COUNT 1 SHOULD BE 2
ADJUST? no

 I=3D682639  OWNER=3Droot MODE=3D100644
SIZE=3D52 MTIME=3DAug 14 19:05 1999  COUNT 1 SHOULD BE 2
ADJUST? no

 I=3D682640  OWNER=3Droot MODE=3D100644
SIZE=3D306 MTIME=3DAug 14 17:11 1999  COUNT 1 SHOULD BE 2
ADJUST? no

 I=3D682641  OWNER=3Droot MODE=3D100644
SIZE=3D761 MTIME=3DJan 25 07:34 2000  COUNT 1 SHOULD BE 2
ADJUST? no

 I=3D682643  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:00 2000  COUNT 2 SHOULD BE 1
ADJUST? no

 I=3D682644  OWNER=3Droot MODE=3D100644
SIZE=3D481 MTIME=3DJun  5 00:47 1998  COUNT 1 SHOULD BE 2
ADJUST? no

 I=3D682645  OWNER=3Droot MODE=3D100644
SIZE=3D1378 MTIME=3DJan 15 09:19 1999  COUNT 1 SHOULD BE 2
ADJUST? no

 I=3D682646  OWNER=3Droot MODE=3D100644
SIZE=3D237 MTIME=3DFeb 15 22:09 1997  COUNT 1 SHOULD BE 2
ADJUST? no

 I=3D682647  OWNER=3Droot MODE=3D100644
SIZE=3D56 MTIME=3DJan 15 09:19 1999  COUNT 1 SHOULD BE 2
ADJUST? no

 I=3D682648  OWNER=3Droot MODE=3D100644
SIZE=3D644 MTIME=3DJun  5 00:47 1998  COUNT 1 SHOULD BE 2
ADJUST? no

 I=3D682650  OWNER=3Droot MODE=3D100644
SIZE=3D44 MTIME=3DJun 27 03:50 1999  COUNT 1 SHOULD BE 2
ADJUST? no

 I=3D682651  OWNER=3Droot MODE=3D100644
SIZE=3D632 MTIME=3DAug 19 20:50 1999  COUNT 1 SHOULD BE 2
ADJUST? no

 I=3D682652  OWNER=3Droot MODE=3D100644
SIZE=3D1388 MTIME=3DAug 19 20:50 1999  COUNT 1 SHOULD BE 2
ADJUST? no

 I=3D682653  OWNER=3Droot MODE=3D100644
SIZE=3D882 MTIME=3DJan 22 17:40 2000  COUNT 1 SHOULD BE 2
ADJUST? no

 I=3D682654  OWNER=3Droot MODE=3D100644
SIZE=3D365 MTIME=3DJan 22 17:40 2000  COUNT 1 SHOULD BE 2
ADJUST? no

 I=3D682655  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 21 13:25 2000  COUNT 6 SHOULD BE 1
ADJUST? no

 I=3D682656  OWNER=3Droot MODE=3D100644
SIZE=3D1508 MTIME=3DOct  7 14:35 1999  COUNT 1 SHOULD BE 2
ADJUST? no

 I=3D682657  OWNER=3Droot MODE=3D100644
SIZE=3D56 MTIME=3DAug 13 12:23 1998  COUNT 1 SHOULD BE 2
ADJUST? no

 I=3D682658  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 21 13:26 2000  COUNT 4 SHOULD BE 6
ADJUST? no

 I=3D682659  OWNER=3Droot MODE=3D100644
SIZE=3D35 MTIME=3DDec 24 18:10 1998 =

CLEAR? no

 I=3D682660  OWNER=3Droot MODE=3D100644
SIZE=3D376 MTIME=3DDec 24 18:10 1998 =

CLEAR? no

 I=3D682661  OWNER=3Droot MODE=3D100644
SIZE=3D479 MTIME=3DDec 24 18:10 1998  COUNT 1 SHOULD BE 2
ADJUST? no

 I=3D682662  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:00 2000  COUNT 4 SHOULD BE 3
ADJUST? no

 I=3D682663  OWNER=3Droot MODE=3D100644
SIZE=3D942 MTIME=3DJan  2 09:56 2000  COUNT 1 SHOULD BE 2
ADJUST? no

 I=3D682666  OWNER=3Droot MODE=3D100644
SIZE=3D289 MTIME=3DDec 22 15:36 1996 =

CLEAR? no

 I=3D682667  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:00 2000 =

CLEAR? no

 I=3D682668  OWNER=3Droot MODE=3D100644
SIZE=3D247 MTIME=3DJan 22 14:16 2000 =

CLEAR? no

 I=3D682670  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 15 14:40 2000 =

CLEAR? no

 I=3D682672  OWNER=3Droot MODE=3D100644
SIZE=3D306 MTIME=3DAug 14 17:11 1999 =

CLEAR? no

 I=3D682673  OWNER=3Droot MODE=3D100644
SIZE=3D761 MTIME=3DJan 25 07:34 2000 =

CLEAR? no

 I=3D682674  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 15 14:46 2000 =

CLEAR? no

 I=3D682675  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:00 2000 =

CLEAR? no

 I=3D682676  OWNER=3Droot MODE=3D100644
SIZE=3D481 MTIME=3DJun  5 00:47 1998 =

CLEAR? no

 I=3D682678  OWNER=3Droot MODE=3D100644
SIZE=3D237 MTIME=3DFeb 15 22:09 1997 =

CLEAR? no

 I=3D682679  OWNER=3Droot MODE=3D100644
SIZE=3D56 MTIME=3DJan 15 09:19 1999 =

CLEAR? no

 I=3D682680  OWNER=3Droot MODE=3D100644
SIZE=3D644 MTIME=3DJun  5 00:47 1998 =

CLEAR? no

 I=3D682681  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:00 2000 =

CLEAR? no

 I=3D682682  OWNER=3Droot MODE=3D100644
SIZE=3D44 MTIME=3DJun 27 03:50 1999 =

CLEAR? no

 I=3D682683  OWNER=3Droot MODE=3D100644
SIZE=3D632 MTIME=3DAug 19 20:50 1999 =

CLEAR? no

 I=3D682684  OWNER=3Droot MODE=3D100644
SIZE=3D1388 MTIME=3DAug 19 20:50 1999 =

CLEAR? no

 I=3D682686  OWNER=3Droot MODE=3D100644
SIZE=3D365 MTIME=3DJan 22 17:40 2000 =

CLEAR? no

 I=3D682687  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:01 2000 =

CLEAR? no

 I=3D682688  OWNER=3Droot MODE=3D100644
SIZE=3D1143 MTIME=3DDec 24 03:18 1999 =

RECONNECT? no


CLEAR? no

 I=3D682689  OWNER=3Droot MODE=3D100644
SIZE=3D507 MTIME=3DDec 24 03:18 1999 =

RECONNECT? no


CLEAR? no

 I=3D682690  OWNER=3Droot MODE=3D100644
SIZE=3D448 MTIME=3DDec 24 03:18 1999 =

RECONNECT? no


CLEAR? no

 I=3D682691  OWNER=3Droot MODE=3D100644
SIZE=3D685 MTIME=3DDec 24 03:18 1999 =

RECONNECT? no


CLEAR? no

 I=3D683256  OWNER=3Droot MODE=3D100644
SIZE=3D8215 MTIME=3DAug 25 15:27 1999  COUNT 1 SHOULD BE 2
ADJUST? no

 I=3D683257  OWNER=3Droot MODE=3D100644
SIZE=3D61 MTIME=3DJun 27 04:40 1999  COUNT 1 SHOULD BE 2
ADJUST? no

 I=3D683258  OWNER=3Droot MODE=3D100644
SIZE=3D770 MTIME=3DJun 11 10:13 1999  COUNT 1 SHOULD BE 2
ADJUST? no

 I=3D683259  OWNER=3Droot MODE=3D100644
SIZE=3D2035 MTIME=3DJun 11 10:13 1999  COUNT 1 SHOULD BE 2
ADJUST? no

 I=3D698472  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:00 2000  COUNT 2 SHOULD BE 3
ADJUST? no

 I=3D944546  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:01 2000  COUNT 2 SHOULD BE 1
ADJUST? no

 I=3D1031842  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:01 2000  COUNT 2 SHOULD BE 1
ADJUST? no

 I=3D1071549  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:02 2000  COUNT 5 SHOULD BE 4
ADJUST? no

 I=3D1087391  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:01 2000  COUNT 2 SHOULD BE 3
ADJUST? no

 I=3D1150850  OWNER=3Droot MODE=3D40755
SIZE=3D3584 MTIME=3DMar 17 12:39 2000  COUNT 185 SHOULD BE 186
ADJUST? no

 I=3D1158882  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 15 14:47 2000  COUNT 5 SHOULD BE 4
ADJUST? no

 I=3D1166606  OWNER=3Droot MODE=3D100555
SIZE=3D20576 MTIME=3DFeb  9 17:29 2000 =

CLEAR? no

 I=3D1166629  OWNER=3Droot MODE=3D100555
SIZE=3D72136 MTIME=3DFeb  9 17:29 2000 =

CLEAR? no

 I=3D1285764  OWNER=3Droot MODE=3D40755
SIZE=3D6656 MTIME=3DMar 17 14:26 2000  COUNT 313 SHOULD BE 314
ADJUST? no

 I=3D1349849  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 21 13:26 2000  COUNT 2 SHOULD BE 3
ADJUST? no

 I=3D1373075  OWNER=3Droot MODE=3D40755
SIZE=3D512 MTIME=3DMar 10 21:00 2000  COUNT 5 SHOULD BE 6
ADJUST? no

** Phase 5 - Check Cyl groups

SALVAGE? no


SALVAGE? no


SALVAGE? no

(38834 frags, 522795 blocks, 0.7% fragmentation)

--------------52A4979F061D6BD5496D38BD--



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 21: 1:57 2000
Delivered-To: freebsd-current@freebsd.org
Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157])
	by hub.freebsd.org (Postfix) with ESMTP
	id A9B0737B96C; Mon, 20 Mar 2000 21:01:46 -0800 (PST)
	(envelope-from asami@cs.berkeley.edu)
Received: from silvia.hip.berkeley.edu (sji-ca6-109.ix.netcom.com [205.186.213.109])
	by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id AAA26453;
	Tue, 21 Mar 2000 00:01:25 -0500 (EST)
Received: (from asami@localhost) by silvia.hip.berkeley.edu (8.9.3/8.6.9) id VAA96598; Mon, 20 Mar 2000 21:00:59 -0800 (PST)
To: "Thomas T. Veldhouse" <veldy@fuggle.veldy.net>
Cc: freebsd-stable <freebsd-stable@freebsd.org>,
	freebsd-current <freebsd-current@freebsd.org>
Subject: Re: compat3x in 4.0-STABLE?
References: <Pine.BSF.4.21.0003201642001.5188-100000@fuggle.veldy.net>
From: asami@freebsd.org (Satoshi - Ports Wraith - Asami)
Date: 20 Mar 2000 20:59:46 -0800
In-Reply-To: "Thomas T. Veldhouse"'s message of "Mon, 20 Mar 2000 16:42:55 -0600 (CST)"
Message-ID: <vqc4sa0x6il.fsf@silvia.hip.berkeley.edu>
Lines: 10
X-Mailer: Gnus v5.7/Emacs 20.6
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

 * From: "Thomas T. Veldhouse" <veldy@fuggle.veldy.net>

 * Where did the compat3x install files go in the latest 4.0-STABLE
 * snapshot?  They seem to be missing.

That was actually a 3.4-STABLE snapshot that ended up in a directory
with a wrong name.  Jordan fixed it (and deleted the offending
snapshot) so new ones, when they get built, should be fine.

Satoshi


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 21:15:37 2000
Delivered-To: freebsd-current@freebsd.org
Received: from ws-ilmar.ints.ru (ws-ilmar.ints.ru [194.67.173.16])
	by hub.freebsd.org (Postfix) with ESMTP id 67A0637B9F3
	for <freebsd-current@freebsd.org>; Mon, 20 Mar 2000 21:14:34 -0800 (PST)
	(envelope-from ilmar@ints.ru)
Received: from localhost (localhost [127.0.0.1])
	by ws-ilmar.ints.ru (8.9.3/8.9.3) with ESMTP id IAA00725
	for <freebsd-current@freebsd.org>; Tue, 21 Mar 2000 08:14:29 +0300 (MSK)
Date: Tue, 21 Mar 2000 08:14:28 +0300 (MSK)
From: "Ilmar S. Habibulin" <ilmar@ints.ru>
To: freebsd-current@freebsd.org
Subject: -current sudden panics :(
Message-ID: <Pine.BSF.4.21.0003210801280.223-300000@ws-ilmar.ints.ru>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="0-1910392243-953615668=:223"
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--0-1910392243-953615668=:223
Content-Type: TEXT/PLAIN; charset=US-ASCII


After upgrading from 4.0-current (09.03) to 5.0-current(16.03,17.03) i've
got subj. Machine panics and reboots. And i was not always near
it. Finally i traced it:

Fatal 12 trap: page fault while in kernel mode
fault virtual address   = 0x8
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc01843fc
stack pointer           = 0x10:0xc026bd64 
frame pointer           = 0x10:0xc026bd64 
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = Idle
interrupt mask          =
kernel: type 12 trap, code=0
Stopped at      arpintr+0x9c:  movl    0x8(%ebx),%ecx

trace gave this:
arpint(c022537b,0,10,10,c0220010) at arpintr+0x9c
swi_net_next() at awi_net_next

I'm sending kernel config and dmesg in the attachment. I have INET6 there,
but it is not configured by ifconfig.

What's this and how can i avoid this panics?

--0-1910392243-953615668=:223
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=dmesg
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.BSF.4.21.0003210814281.223@ws-ilmar.ints.ru>
Content-Description: 
Content-Disposition: attachment; filename=dmesg

Q29weXJpZ2h0IChjKSAxOTkyLTIwMDAgVGhlIEZyZWVCU0QgUHJvamVjdC4N
CkNvcHlyaWdodCAoYykgMTk4MiwgMTk4NiwgMTk4OSwgMTk5MSwgMTk5Mw0K
CVRoZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEu
IEFsbCByaWdodHMgcmVzZXJ2ZWQuDQpGcmVlQlNEIDUuMC1DVVJSRU5UICMx
OiBTYXQgTWFyIDE4IDEwOjIxOjIxIE1TSyAyMDAwDQogICAgcm9vdEB3cy1p
bG1hci5pbnRzLnJ1Oi91c3Ivc3JjL3N5cy9jb21waWxlL1dTX0lMTUFSDQpU
aW1lY291bnRlciAiaTgyNTQiICBmcmVxdWVuY3kgMTE5MzE4MiBIeg0KQ1BV
OiBQZW50aXVtIElJL1BlbnRpdW0gSUkgWGVvbi9DZWxlcm9uICgzNjcuNTAt
TUh6IDY4Ni1jbGFzcyBDUFUpDQogIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwi
ICBJZCA9IDB4NjYwICBTdGVwcGluZyA9IDANCiAgRmVhdHVyZXM9MHgxODNm
OWZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsU0VQLE1U
UlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixNTVgsRlhTUj4NCnJlYWwgbWVt
b3J5ICA9IDEzNDE1MjE5MiAoMTMxMDA4SyBieXRlcykNCmF2YWlsIG1lbW9y
eSA9IDEyNzAyOTI0OCAoMTI0MDUySyBieXRlcykNClByZWxvYWRlZCBlbGYg
a2VybmVsICJrZXJuZWwiIGF0IDB4YzAyZjQwMDAuDQpQZW50aXVtIFBybyBN
VFJSIHN1cHBvcnQgZW5hYmxlZA0KbWQwOiBNYWxsb2MgZGlzaw0KbnB4MDog
PG1hdGggcHJvY2Vzc29yPiBvbiBtb3RoZXJib2FyZA0KbnB4MDogSU5UIDE2
IGludGVyZmFjZQ0KcGNpYjA6IDxJbnRlbCA4MjQ0M0JYICg0NDAgQlgpIGhv
c3QgdG8gUENJIGJyaWRnZT4gb24gbW90aGVyYm9hcmQNCnBjaTA6IDxQQ0kg
YnVzPiBvbiBwY2liMA0KcGNpYjE6IDxJbnRlbCA4MjQ0M0JYICg0NDAgQlgp
IFBDSS1QQ0kgKEFHUCkgYnJpZGdlPiBhdCBkZXZpY2UgMS4wIG9uIHBjaTAN
CnBjaTE6IDxQQ0kgYnVzPiBvbiBwY2liMQ0KaXNhYjA6IDxJbnRlbCA4MjM3
MUFCIFBDSSB0byBJU0EgYnJpZGdlPiBhdCBkZXZpY2UgNy4wIG9uIHBjaTAN
CmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMA0KYXRhcGNpMDogPEludGVsIFBJ
SVg0IEFUQTMzIGNvbnRyb2xsZXI+IHBvcnQgMHhmMDAwLTB4ZjAwZiBhdCBk
ZXZpY2UgNy4xIG9uIHBjaTANCmF0YTA6IGF0IDB4MWYwIGlycSAxNCBvbiBh
dGFwY2kwDQphdGExOiBhdCAweDE3MCBpcnEgMTUgb24gYXRhcGNpMA0KcGNp
MDogPEludGVsIDgyMzcxQUIvRUIgKFBJSVg0KSBVU0IgY29udHJvbGxlcj4g
YXQgNy4yIGlycSAxMQ0KY2hpcDE6IDxJbnRlbCA4MjM3MUFCIFBvd2VyIG1h
bmFnZW1lbnQgY29udHJvbGxlcj4gcG9ydCAweDUwMDAtMHg1MDBmIGF0IGRl
dmljZSA3LjMgb24gcGNpMA0KcGNpMDogPE1hdHJveCBNR0EgTWlsbGVubml1
bSAyMDY0VyBncmFwaGljcyBhY2NlbGVyYXRvcj4gYXQgOS4wIGlycSA5DQpy
bDA6IDxSZWFsVGVrIDgxMzkgMTAvMTAwQmFzZVRYPiBwb3J0IDB4ZTQwMC0w
eGU0N2YgbWVtIDB4ZTcwMDAwMDAtMHhlNzAwMDA3ZiBpcnEgMTEgYXQgZGV2
aWNlIDExLjAgb24gcGNpMA0KcmwwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDpj
MDpkZjoyMzo2MDplMg0KbWlpYnVzMDogPE1JSSBidXM+IG9uIHJsMA0Kcmxw
aHkwOiA8UmVhbFRlayBpbnRlcm5hbCBtZWRpYSBpbnRlcmZhY2U+IG9uIG1p
aWJ1czANCnJscGh5MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNl
VFgsIDEwMGJhc2VUWC1GRFgsIGF1dG8NCnJsMDogc3VwcGx5aW5nIEVVSTY0
OiAwMDpjMDpkZjpmZjpmZToyMzo2MDplMg0KZmRjMDogPE5FQyA3MjA2NUIg
b3IgY2xvbmU+IGF0IHBvcnQgMHgzZjAtMHgzZjUsMHgzZjcgaXJxIDYgZHJx
IDIgb24gaXNhMA0KZmRjMDogRklGTyBlbmFibGVkLCA4IGJ5dGVzIHRocmVz
aG9sZA0KZmQwOiA8MTQ0MC1LQiAzLjUiIGRyaXZlPiBvbiBmZGMwIGRyaXZl
IDANCmF0a2JkYzA6IDxrZXlib2FyZCBjb250cm9sbGVyIChpODA0Mik+IGF0
IHBvcnQgMHg2MC0weDZmIG9uIGlzYTANCmF0a2JkMDogPEFUIEtleWJvYXJk
PiBpcnEgMSBvbiBhdGtiZGMwDQp2Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBh
dCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBp
c2EwDQpzYzA6IDxTeXN0ZW0gY29uc29sZT4gb24gaXNhMA0Kc2MwOiBWR0Eg
PDE2IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MjAwPg0Kc2lvMCBhdCBw
b3J0IDB4M2Y4LTB4M2ZmIGlycSA0IGZsYWdzIDB4MTAgb24gaXNhMA0Kc2lv
MDogdHlwZSAxNjU1MEENCnNpbzEgYXQgcG9ydCAweDJmOC0weDJmZiBpcnEg
MyBvbiBpc2EwDQpzaW8xOiB0eXBlIDE2NTUwQQ0KcHBjMDogPFBhcmFsbGVs
IHBvcnQ+IGF0IHBvcnQgMHgzNzgtMHgzN2YgaXJxIDcgb24gaXNhMA0KcHBj
MDogR2VuZXJpYyBjaGlwc2V0IChOSUJCTEUtb25seSkgaW4gQ09NUEFUSUJM
RSBtb2RlDQpwcGkwOiA8UGFyYWxsZWwgSS9PPiBvbiBwcGJ1czANCmxwdDA6
IDxQcmludGVyPiBvbiBwcGJ1czANCmxwdDA6IEludGVycnVwdC1kcml2ZW4g
cG9ydA0KcGxpcDA6IDxQTElQIG5ldHdvcmsgaW50ZXJmYWNlPiBvbiBwcGJ1
czANCnVua25vd24wOiA8RVNTIEVTMTg2OCBQbHVnIGFuZCBQbGF5IEF1ZGlv
RHJpdmU+IGF0IHBvcnQgMHg4MDAtMHg4MDcgb24gaXNhMA0KdW5rbm93bjE6
IDxFU1MgRVMxODY4IFBsdWcgYW5kIFBsYXkgQXVkaW9Ecml2ZT4gYXQgcG9y
dCAweDIyMC0weDIyZiwweDM4OC0weDM4YiwweDMzMC0weDMzMSBpcnEgNSBk
cnEgMSwwIG9uIGlzYTANCnVua25vd24yOiA8RVNTIEVTMTg2OCBQbHVnIGFu
ZCBQbGF5IEF1ZGlvRHJpdmU+IGF0IHBvcnQgMHgyMDEgb24gaXNhMA0KdW5r
bm93bjM6IDxHZW5lcmljIEVTREkvSURFL0FUQSBjb250cm9sbGVyPiBhdCBw
b3J0IDB4MTY4LTB4MTZmLDB4MzZlLTB4MzZmIGlycSAxMiBvbiBpc2EwDQph
ZDA6IDMwNzdNQiA8U1QzMzIzMkE+IFs2MjUzLzE2LzYzXSBhdCBhdGEwLW1h
c3RlciB1c2luZyBVRE1BMzMNCmFkMjogMTk1NzRNQiA8SUJNLURQVEEtMzcy
MDUwPiBbMzk3NzAvMTYvNjNdIGF0IGF0YTEtbWFzdGVyIHVzaW5nIFVETUEz
Mw0KYWNkMDogQ0RST00gPEhJVEFDSEkgQ0RSLTgzMzU+IGF0IGF0YTEtc2xh
dmUgdXNpbmcgV0RNQTINCk1vdW50aW5nIHJvb3QgZnJvbSB1ZnM6L2Rldi93
ZDBzMmENCldBUk5JTkc6IC8gd2FzIG5vdCBwcm9wZXJseSBkaXNtb3VudGVk
DQpybDA6IHN0YXJ0aW5nIERBRCBmb3IgZmU4MDowMDAxOjowMmMwOmRmZmY6
ZmUyMzo2MGUyDQpybDA6IERBRCBjb21wbGV0ZSBmb3IgZmU4MDowMDAxOjow
MmMwOmRmZmY6ZmUyMzo2MGUyIC0gbm8gZHVwbGljYXRlcyBmb3VuZA0K
--0-1910392243-953615668=:223
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=WS_ILMAR
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.BSF.4.21.0003210814282.223@ws-ilmar.ints.ru>
Content-Description: 
Content-Disposition: attachment; filename=WS_ILMAR

Iw0KIyBHRU5FUklDIC0tIEdlbmVyaWMga2VybmVsIGNvbmZpZ3VyYXRpb24g
ZmlsZSBmb3IgRnJlZUJTRC9pMzg2DQojDQojIEZvciBtb3JlIGluZm9ybWF0
aW9uIG9uIHRoaXMgZmlsZSwgcGxlYXNlIHJlYWQgdGhlIGhhbmRib29rIHNl
Y3Rpb24gb24NCiMgS2VybmVsIENvbmZpZ3VyYXRpb24gRmlsZXM6DQojDQoj
ICAgIGh0dHA6Ly93d3cuZnJlZWJzZC5vcmcvaGFuZGJvb2sva2VybmVsY29u
ZmlnLWNvbmZpZy5odG1sDQojDQojIFRoZSBoYW5kYm9vayBpcyBhbHNvIGF2
YWlsYWJsZSBsb2NhbGx5IGluIC91c3Ivc2hhcmUvZG9jL2hhbmRib29rDQoj
IGlmIHlvdSd2ZSBpbnN0YWxsZWQgdGhlIGRvYyBkaXN0cmlidXRpb24sIG90
aGVyd2lzZSBhbHdheXMgc2VlIHRoZQ0KIyBGcmVlQlNEIFdvcmxkIFdpZGUg
V2ViIHNlcnZlciAoaHR0cDovL3d3dy5GcmVlQlNELk9SRy8pIGZvciB0aGUN
CiMgbGF0ZXN0IGluZm9ybWF0aW9uLg0KIw0KIyBBbiBleGhhdXN0aXZlIGxp
c3Qgb2Ygb3B0aW9ucyBhbmQgbW9yZSBkZXRhaWxlZCBleHBsYW5hdGlvbnMg
b2YgdGhlDQojIGRldmljZSBsaW5lcyBpcyBhbHNvIHByZXNlbnQgaW4gdGhl
IC4vTElOVCBjb25maWd1cmF0aW9uIGZpbGUuIElmIHlvdSBhcmUNCiMgaW4g
ZG91YnQgYXMgdG8gdGhlIHB1cnBvc2Ugb3IgbmVjZXNzaXR5IG9mIGEgbGlu
ZSwgY2hlY2sgZmlyc3QgaW4gTElOVC4NCiMNCiMgJEZyZWVCU0Q6IHNyYy9z
eXMvaTM4Ni9jb25mL0dFTkVSSUMsdiAxLjI0NyAyMDAwLzAzLzE2IDA5OjE2
OjA2IG5faGlibWEgRXhwICQNCg0KbWFjaGluZQkJaTM4Ng0KY3B1CQlJNjg2
X0NQVQ0KaWRlbnQJCVdTX0lMTUFSDQptYXh1c2VycwkzMg0KDQojbWFrZW9w
dGlvbnMJREVCVUc9LWcJCSNCdWlsZCBrZXJuZWwgd2l0aCBnZGIoMSkgZGVi
dWcgc3ltYm9scw0KDQojb3B0aW9ucyAJTUFUSF9FTVVMQVRFCQkjU3VwcG9y
dCBmb3IgeDg3IGVtdWxhdGlvbg0Kb3B0aW9ucyAJSU5FVAkJCSNJbnRlck5F
VHdvcmtpbmcNCm9wdGlvbnMgCUlORVQ2CQkJI0lQdjYgY29tbXVuaWNhdGlv
bnMgcHJvdG9jb2xzDQpvcHRpb25zIAlGRlMJCQkjQmVya2VsZXkgRmFzdCBG
aWxlc3lzdGVtDQpvcHRpb25zIAlGRlNfUk9PVAkJI0ZGUyB1c2FibGUgYXMg
cm9vdCBkZXZpY2UgW2tlZXAgdGhpcyFdDQpvcHRpb25zIAlNRlMJCQkjTWVt
b3J5IEZpbGVzeXN0ZW0NCiNvcHRpb25zIAlNRF9ST09UCQkJI01EIGlzIGEg
cG90ZW50aWFsIHJvb3QgZGV2aWNlDQpvcHRpb25zIAlORlMJCQkjTmV0d29y
ayBGaWxlc3lzdGVtDQojb3B0aW9ucyAJTkZTX1JPT1QJCSNORlMgdXNhYmxl
IGFzIHJvb3QgZGV2aWNlLCBORlMgcmVxdWlyZWQNCm9wdGlvbnMgCU1TRE9T
RlMJCQkjTVNET1MgRmlsZXN5c3RlbQ0Kb3B0aW9ucyAJQ0Q5NjYwCQkJI0lT
TyA5NjYwIEZpbGVzeXN0ZW0NCiNvcHRpb25zIAlDRDk2NjBfUk9PVAkJI0NE
LVJPTSB1c2FibGUgYXMgcm9vdCwgQ0Q5NjYwIHJlcXVpcmVkDQpvcHRpb25z
IAlQUk9DRlMJCQkjUHJvY2VzcyBmaWxlc3lzdGVtDQpvcHRpb25zIAlDT01Q
QVRfNDMJCSNDb21wYXRpYmxlIHdpdGggQlNEIDQuMyBbS0VFUCBUSElTIV0N
CiNvcHRpb25zIAlTQ1NJX0RFTEFZPTE1MDAwCSNEZWxheSAoaW4gbXMpIGJl
Zm9yZSBwcm9iaW5nIFNDU0kNCm9wdGlvbnMgCVVDT05TT0xFCQkjQWxsb3cg
dXNlcnMgdG8gZ3JhYiB0aGUgY29uc29sZQ0Kb3B0aW9ucyAJVVNFUkNPTkZJ
RwkJI2Jvb3QgLWMgZWRpdG9yDQpvcHRpb25zIAlWSVNVQUxfVVNFUkNPTkZJ
RwkjdmlzdWFsIGJvb3QgLWMgZWRpdG9yDQpvcHRpb25zIAlLVFJBQ0UJCQkj
a3RyYWNlKDEpIHN1cHBvcnQNCm9wdGlvbnMgCVNZU1ZTSE0JCQkjU1lTVi1z
dHlsZSBzaGFyZWQgbWVtb3J5DQpvcHRpb25zIAlTWVNWTVNHCQkJI1NZU1Yt
c3R5bGUgbWVzc2FnZSBxdWV1ZXMNCm9wdGlvbnMgCVNZU1ZTRU0JCQkjU1lT
Vi1zdHlsZSBzZW1hcGhvcmVzDQpvcHRpb25zIAlQMTAwM18xQgkJI1Bvc2l4
IFAxMDAzXzFCIHJlYWwtdGltZSBleHRlbnRpb25zDQpvcHRpb25zIAlfS1BP
U0lYX1BSSU9SSVRZX1NDSEVEVUxJTkcNCm9wdGlvbnMJCUlDTVBfQkFORExJ
TQkJI1JhdGUgbGltaXQgYmFkIHJlcGxpZXMNCg0KIyBUbyBtYWtlIGFuIFNN
UCBrZXJuZWwsIHRoZSBuZXh0IHR3byBhcmUgbmVlZGVkDQojb3B0aW9ucyAJ
U01QCQkJIyBTeW1tZXRyaWMgTXVsdGlQcm9jZXNzb3IgS2VybmVsDQojb3B0
aW9ucyAJQVBJQ19JTwkJCSMgU3ltbWV0cmljIChBUElDKSBJL08NCiMgT3B0
aW9uYWxseSB0aGVzZSBtYXkgbmVlZCB0d2Vha2VkLCAoZGVmYXVsdHMgc2hv
d24pOg0KI29wdGlvbnMgCU5DUFU9MgkJCSMgbnVtYmVyIG9mIENQVXMNCiNv
cHRpb25zIAlOQlVTPTQJCQkjIG51bWJlciBvZiBidXNzZXMNCiNvcHRpb25z
IAlOQVBJQz0xCQkJIyBudW1iZXIgb2YgSU8gQVBJQ3MNCiNvcHRpb25zIAlO
SU5UUj0yNAkJIyBudW1iZXIgb2YgSU5Ucw0KDQpkZXZpY2UJCWlzYQ0KI2Rl
dmljZQkJZWlzYQ0KZGV2aWNlCQlwY2kNCg0KIyBGbG9wcHkgZHJpdmVzDQpk
ZXZpY2UJCWZkYzAJYXQgaXNhPyBwb3J0IElPX0ZEMSBpcnEgNiBkcnEgMg0K
ZGV2aWNlCQlmZDAJYXQgZmRjMCBkcml2ZSAwDQpkZXZpY2UJCWZkMQlhdCBm
ZGMwIGRyaXZlIDENCg0KIyBBVEEgYW5kIEFUQVBJIGRldmljZXMNCmRldmlj
ZQkJYXRhMAlhdCBpc2E/IHBvcnQgSU9fV0QxIGlycSAxNA0KZGV2aWNlCQlh
dGExCWF0IGlzYT8gcG9ydCBJT19XRDIgaXJxIDE1DQpkZXZpY2UJCWF0YQ0K
ZGV2aWNlCQlhdGFkaXNrCQkJIyBBVEEgZGlzayBkcml2ZXMNCmRldmljZQkJ
YXRhcGljZAkJCSMgQVRBUEkgQ0RST00gZHJpdmVzDQojZGV2aWNlCQlhdGFw
aWZkCQkJIyBBVEFQSSBmbG9wcHkgZHJpdmVzDQojZGV2aWNlCQlhdGFwaXN0
CQkJIyBBVEFQSSB0YXBlIGRyaXZlcw0Kb3B0aW9ucyAJQVRBX1NUQVRJQ19J
RAkJI1N0YXRpYyBkZXZpY2UgbnVtYmVyaW5nDQpvcHRpb25zIAlBVEFfRU5B
QkxFX0FUQVBJX0RNQQkjRW5hYmxlIERNQSBvbiBBVEFQSSBkZXZpY2VzDQoN
CiMgU0NTSSBDb250cm9sbGVycw0KI2RldmljZQkJYWhiCQkjIEVJU0EgQUhB
MTc0MiBmYW1pbHkNCiNkZXZpY2UJCWFoYwkJIyBBSEEyOTQwIGFuZCBvbmJv
YXJkIEFJQzd4eHggZGV2aWNlcw0KI2RldmljZQkJYW1kCQkjIEFNRCA1M0M5
NzQgKFRlY2tyYW0gREMtMzkwKFQpKQ0KI2RldmljZQkJZHB0CQkjIERQVCBT
bWFydGNhY2hlIC0gU2VlIExJTlQgZm9yIG9wdGlvbnMhDQojZGV2aWNlCQlp
c3AJCSMgUWxvZ2ljIGZhbWlseQ0KI2RldmljZQkJbmNyCQkjIE5DUi9TeW1i
aW9zIExvZ2ljDQojZGV2aWNlCQlzeW0JCSMgTkNSL1N5bWJpb3MgTG9naWMg
KG5ld2VyIGNoaXBzZXRzKQ0KDQojZGV2aWNlCQlhZHYwCWF0IGlzYT8NCiNk
ZXZpY2UJCWFkdw0KI2RldmljZQkJYnQwCWF0IGlzYT8NCiNkZXZpY2UJCWFo
YTAJYXQgaXNhPw0KI2RldmljZQkJYWljMAlhdCBpc2E/DQoNCiMgU0NTSSBw
ZXJpcGhlcmFscw0KI2RldmljZQkJc2NidXMJCSMgU0NTSSBidXMgKHJlcXVp
cmVkKQ0KI2RldmljZQkJZGEJCSMgRGlyZWN0IEFjY2VzcyAoZGlza3MpDQoj
ZGV2aWNlCQlzYQkJIyBTZXF1ZW50aWFsIEFjY2VzcyAodGFwZSBldGMpDQoj
ZGV2aWNlCQljZAkJIyBDRA0KI2RldmljZQkJcGFzcwkJIyBQYXNzdGhyb3Vn
aCBkZXZpY2UgKGRpcmVjdCBTQ1NJIGFjY2VzcykNCg0KIyBSQUlEIGNvbnRy
b2xsZXJzDQojZGV2aWNlCQlpZGEJCSMgQ29tcGFxIFNtYXJ0IFJBSUQNCiNk
ZXZpY2UJCWFtcgkJIyBBTUkgTWVnYVJBSUQNCiNkZXZpY2UJCW1seAkJIyBN
eWxleCBEQUM5NjAgZmFtaWx5DQoNCiMgYXRrYmRjMCBjb250cm9scyBib3Ro
IHRoZSBrZXlib2FyZCBhbmQgdGhlIFBTLzIgbW91c2UNCmRldmljZQkJYXRr
YmRjMAlhdCBpc2E/IHBvcnQgSU9fS0JEDQpkZXZpY2UJCWF0a2JkMAlhdCBh
dGtiZGM/IGlycSAxDQojZGV2aWNlCQlwc20wCWF0IGF0a2JkYz8gaXJxIDEy
DQoNCmRldmljZQkJdmdhMAlhdCBpc2E/DQoNCiMgc3BsYXNoIHNjcmVlbi9z
Y3JlZW4gc2F2ZXINCnBzZXVkby1kZXZpY2UJc3BsYXNoDQoNCiMgc3lzY29u
cyBpcyB0aGUgZGVmYXVsdCBjb25zb2xlIGRyaXZlciwgcmVzZW1ibGluZyBh
biBTQ08gY29uc29sZQ0KZGV2aWNlCQlzYzAJYXQgaXNhPw0KDQojIEVuYWJs
ZSB0aGlzIGFuZCBQQ1ZUX0ZSRUVCU0QgZm9yIHBjdnQgdnQyMjAgY29tcGF0
aWJsZSBjb25zb2xlIGRyaXZlcg0KI2RldmljZQkJdnQwCWF0IGlzYT8NCiNv
cHRpb25zIAlYU0VSVkVSCQkJIyBzdXBwb3J0IGZvciBYIHNlcnZlciBvbiBh
IHZ0IGNvbnNvbGUNCiNvcHRpb25zIAlGQVRfQ1VSU09SCQkjIHN0YXJ0IHdp
dGggYmxvY2sgY3Vyc29yDQojIElmIHlvdSBoYXZlIGEgVGhpbmtQQUQsIHVu
Y29tbWVudCB0aGlzIGFsb25nIHdpdGggdGhlIHJlc3Qgb2YgdGhlIFBDVlQg
bGluZXMNCiNvcHRpb25zIAlQQ1ZUX1NDQU5TRVQ9MgkJIyBJQk0ga2V5Ym9h
cmRzIGFyZSBub24tc3RkDQoNCiMgRmxvYXRpbmcgcG9pbnQgc3VwcG9ydCAt
IGRvIG5vdCBkaXNhYmxlLg0KZGV2aWNlCQlucHgwCWF0IG5leHVzPyBwb3J0
IElPX05QWCBpcnEgMTMNCg0KIyBQb3dlciBtYW5hZ2VtZW50IHN1cHBvcnQg
KHNlZSBMSU5UIGZvciBtb3JlIG9wdGlvbnMpDQpkZXZpY2UJCWFwbTAgICAg
YXQgbmV4dXM/IGRpc2FibGUgZmxhZ3MgMHgyMCAjIEFkdmFuY2VkIFBvd2Vy
IE1hbmFnZW1lbnQNCg0KIyBQQ0NBUkQgKFBDTUNJQSkgc3VwcG9ydA0KI2Rl
dmljZQkJY2FyZA0KI2RldmljZQkJcGNpYzAJYXQgaXNhPyBpcnEgMTAgcG9y
dCAweDNlMCBpb21lbSAweGQwMDAwDQojZGV2aWNlCQlwY2ljMQlhdCBpc2E/
IGlycSAxMSBwb3J0IDB4M2UyIGlvbWVtIDB4ZDQwMDAgZGlzYWJsZQ0KDQoj
IFNlcmlhbCAoQ09NKSBwb3J0cw0KZGV2aWNlCQlzaW8wCWF0IGlzYT8gcG9y
dCBJT19DT00xIGZsYWdzIDB4MTAgaXJxIDQNCmRldmljZQkJc2lvMQlhdCBp
c2E/IHBvcnQgSU9fQ09NMiBpcnEgMw0KI2RldmljZQkJc2lvMglhdCBpc2E/
IGRpc2FibGUgcG9ydCBJT19DT00zIGlycSA1DQojZGV2aWNlCQlzaW8zCWF0
IGlzYT8gZGlzYWJsZSBwb3J0IElPX0NPTTQgaXJxIDkNCg0KIyBQYXJhbGxl
bCBwb3J0DQpkZXZpY2UJCXBwYzAJYXQgaXNhPyBpcnEgNw0KZGV2aWNlCQlw
cGJ1cwkJIyBQYXJhbGxlbCBwb3J0IGJ1cyAocmVxdWlyZWQpDQpkZXZpY2UJ
CWxwdAkJIyBQcmludGVyDQpkZXZpY2UJCXBsaXAJCSMgVENQL0lQIG92ZXIg
cGFyYWxsZWwNCmRldmljZQkJcHBpCQkjIFBhcmFsbGVsIHBvcnQgaW50ZXJm
YWNlIGRldmljZQ0KI2RldmljZQkJdnBvCQkjIFJlcXVpcmVzIHNjYnVzIGFu
ZCBkYQ0KDQoNCiMgUENJIEV0aGVybmV0IE5JQ3MuDQojZGV2aWNlCQlkZQkJ
IyBERUMvSW50ZWwgREMyMXg0eCAoYGBUdWxpcCcnKQ0KI2RldmljZQkJZnhw
CQkjIEludGVsIEV0aGVyRXhwcmVzcyBQUk8vMTAwQiAoODI1NTcsIDgyNTU4
KQ0KI2RldmljZQkJdHgJCSMgU01DIDk0MzJUWCAoODNjMTcwIGBgRVBJQycn
KQ0KI2RldmljZQkJdngJCSMgM0NvbSAzYzU5MCwgM2M1OTUgKGBgVm9ydGV4
JycpDQojZGV2aWNlCQl3eAkJIyBJbnRlbCBHaWdhYml0IEV0aGVybmV0IENh
cmQgKGBgV2lzZW1hbicnKQ0KDQojIFBDSSBFdGhlcm5ldCBOSUNzIHRoYXQg
dXNlIHRoZSBjb21tb24gTUlJIGJ1cyBjb250cm9sbGVyIGNvZGUuDQpkZXZp
Y2UJCW1paWJ1cwkJIyBNSUkgYnVzIHN1cHBvcnQNCiNkZXZpY2UJCWRjCQkj
IERFQy9JbnRlbCAyMTE0MyBhbmQgdmFyaW91cyB3b3JrYWxpa2VzDQpkZXZp
Y2UJCXJsCQkjIFJlYWxUZWsgODEyOS84MTM5DQojZGV2aWNlCQlzZgkJIyBB
ZGFwdGVjIEFJQy02OTE1IChgYFN0YXJmaXJlJycpDQojZGV2aWNlCQlzaXMJ
CSMgU2lsaWNvbiBJbnRlZ3JhdGVkIFN5c3RlbXMgU2lTIDkwMC9TaVMgNzAx
Ng0KI2RldmljZQkJc3RlCQkjIFN1bmRhbmNlIFNUMjAxIChELUxpbmsgREZF
LTU1MFRYKQ0KI2RldmljZQkJdGwJCSMgVGV4YXMgSW5zdHJ1bWVudHMgVGh1
bmRlckxBTg0KI2RldmljZQkJdnIJCSMgVklBIFJoaW5lLCBSaGluZSBJSQ0K
I2RldmljZQkJd2IJCSMgV2luYm9uZCBXODlDODQwRg0KI2RldmljZQkJeGwJ
CSMgM0NvbSAzYzkweCAoYGBCb29tZXJhbmcnJywgYGBDeWNsb25lJycpDQoN
CiMgSVNBIEV0aGVybmV0IE5JQ3MuDQojZGV2aWNlCQllZDAJYXQgaXNhPyBw
b3J0IDB4MjgwIGlycSAxMCBpb21lbSAweGQ4MDAwDQojZGV2aWNlCQlleA0K
I2RldmljZQkJZXANCiMgV2F2ZUxBTi9JRUVFIDgwMi4xMSB3aXJlbGVzcyBO
SUNzLiBOb3RlOiB0aGUgV2F2ZUxBTi9JRUVFIHJlYWxseQ0KIyBleGlzdHMg
b25seSBhcyBhIFBDTUNJQSBkZXZpY2UsIHNvIHRoZXJlIGlzIG5vIElTQSBh
dHRhdGVtZW50IG5lZWRlZA0KIyBhbmQgcmVzb3VyY2VzIHdpbGwgYWx3YXlz
IGJlIGR5bmFtaWNhbGx5IGFzc2lnbmVkIGJ5IHRoZSBwY2NhcmQgY29kZS4N
CiNkZXZpY2UJCXdpDQojIEFpcm9uZXQgNDUwMC80ODAwIDgwMi4xMSB3aXJl
bGVzcyBOSUNzLiBOb3RlOiB0aGUgZGVjbGFyYXRpb24gYmVsb3cgd2lsbA0K
IyB3b3JrIGZvciBQQ01DSUEgYW5kIFBDSSBjYXJkcywgYXMgd2VsbCBhcyBJ
U0EgY2FyZHMgc2V0IHRvIElTQSBQblANCiMgbW9kZSAodGhlIGZhY3Rvcnkg
ZGVmYXVsdCkuIElmIHlvdSBzZXQgdGhlIHN3aXRjaGVzIG9uIHlvdXIgSVNB
DQojIGNhcmQgZm9yIGEgbWFudWFsbHkgY2hvc2VuIEkvTyBhZGRyZXNzIGFu
ZCBJUlEsIHlvdSBtdXN0IHNwZWNpZnkNCiMgdGhvc2UgcGFyZW1ldGVycyBo
ZXJlLg0KI2RldmljZQkJYW4NCiMgVGhlIHByb2JlIG9yZGVyIG9mIHRoZXNl
IGlzIHByZXNlbnRseSBkZXRlcm1pbmVkIGJ5IGkzODYvaXNhL2lzYV9jb21w
YXQuYy4NCiNkZXZpY2UJCWllMAlhdCBpc2E/IHBvcnQgMHgzMDAgaXJxIDEw
IGlvbWVtIDB4ZDAwMDANCiNkZXZpY2UJCWZlMAlhdCBpc2E/IHBvcnQgMHgz
MDANCiNkZXZpY2UJCWxlMAlhdCBpc2E/IHBvcnQgMHgzMDAgaXJxIDUgaW9t
ZW0gMHhkMDAwMA0KI2RldmljZQkJbG5jMAlhdCBpc2E/IHBvcnQgMHgyODAg
aXJxIDEwIGRycSAwDQojZGV2aWNlCQljczAJYXQgaXNhPyBwb3J0IDB4MzAw
DQojZGV2aWNlCQlzbjAJYXQgaXNhPyBwb3J0IDB4MzAwIGlycSAxMA0KIyBy
ZXF1aXJlcyBQQ0NBUkQgKFBDTUNJQSkgc3VwcG9ydCB0byBiZSBhY3RpdmF0
ZWQNCiNkZXZpY2UJCXhlMAlhdCBpc2E/DQoNCiMgUHNldWRvIGRldmljZXMg
LSB0aGUgbnVtYmVyIGluZGljYXRlcyBob3cgbWFueSB1bml0cyB0byBhbGxv
Y2F0ZWQuDQpwc2V1ZG8tZGV2aWNlCWxvb3AJCSMgTmV0d29yayBsb29wYmFj
aw0KcHNldWRvLWRldmljZQlldGhlcgkJIyBFdGhlcm5ldCBzdXBwb3J0DQoj
cHNldWRvLWRldmljZQlzbAkxCSMgS2VybmVsIFNMSVANCiNwc2V1ZG8tZGV2
aWNlCXBwcAkxCSMgS2VybmVsIFBQUA0KcHNldWRvLWRldmljZQl0dW4JCSMg
UGFja2V0IHR1bm5lbC4NCnBzZXVkby1kZXZpY2UJcHR5CQkjIFBzZXVkby10
dHlzICh0ZWxuZXQgZXRjKQ0KcHNldWRvLWRldmljZQltZAkJIyBNZW1vcnkg
ImRpc2tzIg0KcHNldWRvLWRldmljZQlnaWYJNAkjIElQdjYgYW5kIElQdjQg
dHVubmVsaW5nDQpwc2V1ZG8tZGV2aWNlCWZhaXRoCTEJIyBJUHY2LXRvLUlQ
djQgcmVsYXlpbmcgKHRyYW5zbGF0aW9uKQ0KDQojIFRoZSBgYnBmJyBwc2V1
ZG8tZGV2aWNlIGVuYWJsZXMgdGhlIEJlcmtlbGV5IFBhY2tldCBGaWx0ZXIu
DQojIEJlIGF3YXJlIG9mIHRoZSBhZG1pbmlzdHJhdGl2ZSBjb25zZXF1ZW5j
ZXMgb2YgZW5hYmxpbmcgdGhpcyENCnBzZXVkby1kZXZpY2UJYnBmCQkjQmVy
a2VsZXkgcGFja2V0IGZpbHRlcg0KDQojIFVTQiBzdXBwb3J0DQojZGV2aWNl
CQl1aGNpCQkjIFVIQ0kgUENJLT5VU0IgaW50ZXJmYWNlDQojZGV2aWNlCQlv
aGNpCQkjIE9IQ0kgUENJLT5VU0IgaW50ZXJmYWNlDQojZGV2aWNlCQl1c2IJ
CSMgVVNCIEJ1cyAocmVxdWlyZWQpDQojZGV2aWNlCQl1Z2VuCQkjIEdlbmVy
aWMNCiNkZXZpY2UJCXVoaWQJCSMgIkh1bWFuIEludGVyZmFjZSBEZXZpY2Vz
Ig0KI2RldmljZQkJdWtiZAkJIyBLZXlib2FyZA0KI2RldmljZQkJdWxwdAkJ
IyBQcmludGVyDQojZGV2aWNlCQl1bWFzcwkJIyBEaXNrcy9NYXNzIHN0b3Jh
Z2UgLSBSZXF1aXJlcyBzY2J1cyBhbmQgZGENCiNkZXZpY2UJCXVtcwkJIyBN
b3VzZQ0KI2RldmljZQkJdXJpbwkJIyBEaWFtb25kIFJpbyA1MDAgTVAzIHBs
YXllcg0KIyBVU0IgRXRoZXJuZXQsIHJlcXVpcmVzIG1paQ0KI2RldmljZQkJ
YXVlCQkjIEFETXRlayBVU0IgZXRoZXJuZXQNCiNkZXZpY2UJCWN1ZQkJIyBD
QVRDIFVTQiBldGhlcm5ldA0KI2RldmljZQkJa3VlCQkjIEthd2FzYWtpIExT
SSBVU0IgZXRoZXJuZXQNCg0KIw0KIyBFbmFibGUgdGhlIGtlcm5lbCBkZWJ1
Z2dlci4NCiMNCm9wdGlvbnMgCUREQg0KDQojDQojIERvbid0IGRyb3AgaW50
byBEREIgZm9yIGEgcGFuaWMuIEludGVuZGVkIGZvciB1bmF0dGVuZGVkIG9w
ZXJhdGlvbg0KIyB3aGVyZSB5b3UgbWF5IHdhbnQgdG8gZHJvcCB0byBEREIg
ZnJvbSB0aGUgY29uc29sZSwgYnV0IHN0aWxsIHdhbnQNCiMgdGhlIG1hY2hp
bmUgdG8gcmVjb3ZlciBmcm9tIGEgcGFuaWMNCiMNCiNvcHRpb25zIAlEREJf
VU5BVFRFTkRFRA0KDQojDQojIElmIHVzaW5nIEdEQiByZW1vdGUgbW9kZSB0
byBkZWJ1ZyB0aGUga2VybmVsLCB0aGVyZSdzIGEgbm9uLXN0YW5kYXJkDQoj
IGV4dGVuc2lvbiB0byB0aGUgcmVtb3RlIHByb3RvY29sIHRoYXQgY2FuIGJl
IHVzZWQgdG8gdXNlIHRoZSBzZXJpYWwNCiMgcG9ydCBhcyBib3RoIHRoZSBk
ZWJ1Z2dpbmcgcG9ydCBhbmQgdGhlIHN5c3RlbSBjb25zb2xlLiAgSXQncyBu
b24tDQojIHN0YW5kYXJkIGFuZCB5b3UncmUgb24geW91ciBvd24gaWYgeW91
IGVuYWJsZSBpdC4gIFNlZSBhbHNvIHRoZQ0KIyAicmVtb3RlY2hhdCIgdmFy
aWFibGVzIGluIHRoZSBGcmVlQlNEIHNwZWNpZmljIHZlcnNpb24gb2YgZ2Ri
Lg0KIw0KI29wdGlvbnMgCUdEQl9SRU1PVEVfQ0hBVA0KDQojDQojIEtUUkFD
RSBlbmFibGVzIHRoZSBzeXN0ZW0tY2FsbCB0cmFjaW5nIGZhY2lsaXR5IGt0
cmFjZSgyKS4NCiMNCm9wdGlvbnMgCUtUUkFDRQkJCSNrZXJuZWwgdHJhY2lu
Zw0KDQojDQojIFRoZSBJTlZBUklBTlRTIG9wdGlvbiBpcyB1c2VkIGluIGEg
bnVtYmVyIG9mIHNvdXJjZSBmaWxlcyB0byBlbmFibGUNCiMgZXh0cmEgc2Fu
aXR5IGNoZWNraW5nIG9mIGludGVybmFsIHN0cnVjdHVyZXMuICBUaGlzIHN1
cHBvcnQgaXMgbm90DQojIGVuYWJsZWQgYnkgZGVmYXVsdCBiZWNhdXNlIG9m
IHRoZSBleHRyYSB0aW1lIGl0IHdvdWxkIHRha2UgdG8gY2hlY2sNCiMgZm9y
IHRoZXNlIGNvbmRpdGlvbnMsIHdoaWNoIGNhbiBvbmx5IG9jY3VyIGFzIGEg
cmVzdWx0IG9mDQojIHByb2dyYW1taW5nIGVycm9ycy4NCiMNCm9wdGlvbnMg
CUlOVkFSSUFOVFMNCg0KIw0KIyBUaGUgSU5WQVJJQU5UX1NVUFBPUlQgb3B0
aW9uIG1ha2VzIHVzIGNvbXBpbGUgaW4gc3VwcG9ydCBmb3INCiMgdmVyaWZ5
aW5nIHNvbWUgb2YgdGhlIGludGVybmFsIHN0cnVjdHVyZXMuICBJdCBpcyBh
IHByZXJlcXVpc2l0ZSBmb3INCiMgJ0lOVkFSSUFOVFMnLCBhcyBlbmFibGlu
ZyAnSU5WQVJJQU5UUycgd2lsbCBtYWtlIHRoZXNlIGZ1bmN0aW9ucyBiZQ0K
IyBjYWxsZWQuICBUaGUgaW50ZW50IGlzIHRoYXQgeW91IGNhbiBzZXQgJ0lO
VkFSSUFOVFMnIGZvciBzaW5nbGUNCiMgc291cmNlIGZpbGVzIChieSBjaGFu
Z2luZyB0aGUgc291cmNlIGZpbGUgb3Igc3BlY2lmeWluZyBpdCBvbiB0aGUN
CiMgY29tbWFuZCBsaW5lKSBpZiB5b3UgaGF2ZSAnSU5WQVJJQU5UX1NVUFBP
UlQnIGVuYWJsZWQuDQojDQpvcHRpb25zIAlJTlZBUklBTlRfU1VQUE9SVA0K
DQojDQojIFRoZSBESUFHTk9TVElDIG9wdGlvbiBpcyB1c2VkIHRvIGVuYWJs
ZSBleHRyYSBkZWJ1Z2dpbmcgaW5mb3JtYXRpb24NCiMgZnJvbSBzb21lIHBh
cnRzIG9mIHRoZSBrZXJuZWwuICBBcyB0aGlzIG1ha2VzIGV2ZXJ5dGhpbmcg
bW9yZSBub2lzeSwNCiMgaXQgaXMgZGlzYWJsZWQgYnkgZGVmYXVsdC4NCiMN
Cm9wdGlvbnMgCURJQUdOT1NUSUMNCg0KIw0KIyBQRVJGTU9OIGNhdXNlcyB0
aGUgZHJpdmVyIGZvciBQZW50aXVtL1BlbnRpdW0gUHJvIHBlcmZvcm1hbmNl
IGNvdW50ZXJzDQojIHRvIGJlIGNvbXBpbGVkLiAgU2VlIHBlcmZtb24oNCkg
Zm9yIG1vcmUgaW5mb3JtYXRpb24uDQojDQpvcHRpb25zIAlQRVJGTU9ODQoN
Cg==
--0-1910392243-953615668=:223--


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 22:57:29 2000
Delivered-To: freebsd-current@freebsd.org
Received: from lafontaine.cybercable.fr (lafontaine.cybercable.fr [212.198.0.202])
	by hub.freebsd.org (Postfix) with SMTP id C1DC937B933
	for <current@freebsd.org>; Mon, 20 Mar 2000 22:56:24 -0800 (PST)
	(envelope-from herbelot@cybercable.fr)
Received: (qmail 6524227 invoked from network); 21 Mar 2000 06:56:23 -0000
Received: from d016.paris-30.cybercable.fr (HELO cybercable.fr) ([212.198.30.16]) (envelope-sender <herbelot@cybercable.fr>)
          by lafontaine.cybercable.fr (qmail-ldap-1.03) with SMTP
          for <jabley@patho.gen.nz>; 21 Mar 2000 06:56:23 -0000
Message-ID: <38D71C22.62A29CCE@cybercable.fr>
Date: Tue, 21 Mar 2000 07:52:18 +0100
From: "Thierry.herbelot" <herbelot@cybercable.fr>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Joe Abley <jabley@patho.gen.nz>
Cc: current@freebsd.org
Subject: Re: 4.0-RELEASE boot.flp fails to boot on K6/2
References: <20000321150940.A13226@patho.gen.nz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Joe Abley wrote:
> 
> Problem report booting 4.0-RELEASE follows.
> 
>   /boot.config: -P
>   Keyboard: yes
> 
>   BTX loader 1.00  BTX version is 1.01
>   Console: internal video/keyboard
>   BIOS drive A: is disk0
>   BIOS drive C: is disk1
>   BIOS 639kB/56256kB available memory
> 
>   FreeBSD/i386 bootstrap loader, Revision 0.7
>   (jkh@monster.cdrom.com, Wed Mar 15 01:23:43 GMT 2000)
>   |
>   Hit [Enter] to boot immediately, or any other key for command prompt.
>   Booting [kernel]...
>   /kernel text=0x1d56fe data=0x2f4ca0+0x1a718 zf_read: fill error

Hello,

I had the exact same error message trying to boot from a floppy where I
had tried to dd the full boot.flp (2,8 Megs is just too much for a
normal floppy), instead of kern.flp (and dd does not give error messages
..)

	TfH

> 
>   elf_loadexec: archsw.readin failed
>   can't load 'kernel'
>   no bootable kernel
>   \
> 
>   Type '?' for a list of commands, 'help' for more detailed help.
>   ok
> 
> What does this mean? If this is a -questions question, then please feel
> free to flame me privately (just thought it sounded -currentish). If
> there are any useful diags I can type, let me know.
> 
> Hardware is 350MHz K6/2, generic-looking Asus motherboard with
> integrated video and audio, no-name PCI 10baseT ethernet adapter,
> floppy, single 20G IDE disk, 64M RAM. No other peripherals.
> 
> Have tried different floppies. Recent OpenBSD snapshot floppy works
> just fine, by way of crude hardware sanity check.
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message

-- 
Thierry Herbelot                        ASCII RIBBON CAMPAIGN   /"\
mailto:herbelot@cybercable.fr          AGAINST HTML MAIL & NEWS \ /
http://perso.cybercable.fr/herbelot           PAS DE HTML DANS   X 
Hiroshima 45, Tchernobyl 86, Windows 95...      LES COURRIELS   / \


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 23: 6:59 2000
Delivered-To: freebsd-current@freebsd.org
Received: from tardis.patho.gen.nz (tardis.patho.gen.nz [203.97.2.226])
	by hub.freebsd.org (Postfix) with ESMTP id 1882C37BBAF
	for <current@freebsd.org>; Mon, 20 Mar 2000 23:06:53 -0800 (PST)
	(envelope-from jabley@tardis.patho.gen.nz)
Received: (from jabley@localhost)
	by tardis.patho.gen.nz (8.9.3/8.9.3) id TAA10107;
	Tue, 21 Mar 2000 19:06:43 +1200 (NZST)
Date: Tue, 21 Mar 2000 19:06:41 +1200
From: Joe Abley <jabley@patho.gen.nz>
To: "Thierry.herbelot" <herbelot@cybercable.fr>
Cc: current@freebsd.org
Subject: Re: 4.0-RELEASE boot.flp fails to boot on K6/2
Message-ID: <20000321190638.A22074@patho.gen.nz>
References: <20000321150940.A13226@patho.gen.nz> <38D71C22.62A29CCE@cybercable.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <38D71C22.62A29CCE@cybercable.fr>; from herbelot@cybercable.fr on Tue, Mar 21, 2000 at 07:52:18AM +0100
X-Files: the Truth is Out There
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Tue, Mar 21, 2000 at 07:52:18AM +0100, Thierry.herbelot wrote:
> Joe Abley wrote:
> > 
> > Problem report booting 4.0-RELEASE follows.
> > 
> I had the exact same error message trying to boot from a floppy where I
> had tried to dd the full boot.flp (2,8 Megs is just too much for a
> normal floppy), instead of kern.flp (and dd does not give error messages
> ..)

Oh, how hideously embarassing. Thank you, Thierry, and please excuse
me as I shoot myself in the head.



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 23:52:10 2000
Delivered-To: freebsd-current@freebsd.org
Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12])
	by hub.freebsd.org (Postfix) with ESMTP id 1E0F037B5C1
	for <current@FreeBSD.ORG>; Mon, 20 Mar 2000 23:52:02 -0800 (PST)
	(envelope-from wilko@yedi.iaf.nl)
Received: from yedi.iaf.nl (uucp@localhost)
	  by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id IAA29845;
	  Tue, 21 Mar 2000 08:26:05 +0100 (MET)
Received: (from wilko@localhost)
	by yedi.iaf.nl (8.9.3/8.9.3) id AAA21609;
	Tue, 21 Mar 2000 00:04:37 +0100 (CET)
	(envelope-from wilko)
Date: Tue, 21 Mar 2000 00:04:37 +0100
From: Wilko Bulte <wilko@yedi.iaf.nl>
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc: Alfred Perlstein <bright@wintelcom.net>,
	Matthew Dillon <dillon@apollo.backplane.com>, current@FreeBSD.ORG
Subject: Re: patches for test / review
Message-ID: <20000321000435.A8143@yedi.iaf.nl>
Reply-To: wilko@FreeBSD.ORG
References: <20000320111544.A14789@fw.wintelcom.net> <20102.953580112@critter.freebsd.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <20102.953580112@critter.freebsd.dk>; from phk@critter.freebsd.dk on Mon, Mar 20, 2000 at 08:21:52PM +0100
X-OS: FreeBSD 3.4-STABLE
X-PGP: finger wilko@freebsd.org
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Mon, Mar 20, 2000 at 08:21:52PM +0100, Poul-Henning Kamp wrote:
> In message <20000320111544.A14789@fw.wintelcom.net>, Alfred Perlstein writes:
> 
> >Keeping the currect cluster code is a bad idea, if the drivers were
> >taught how to traverse the linked list in the buf struct rather
> >than just notice "a big buffer" we could avoid a lot of page
> >twiddling and also allow for massive IO clustering ( > 64k ) 
> 
> Before we redesign the clustering, I would like to know if we
> actually have any recent benchmarks which prove that clustering
> is overall beneficial ?
> 
> I would think that track-caches and intelligent drives would gain
> much if not more of what clustering was designed to do gain.

Hm. But I'd think that even with modern drives a smaller number of bigger
I/Os is preferable over lots of very small I/Os. Or have I missed the point?

-- 
Wilko Bulte 			Arnhem, The Netherlands	  
http://www.tcja.nl  		The FreeBSD Project: http://www.freebsd.org


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Mon Mar 20 23:55: 2 2000
Delivered-To: freebsd-current@freebsd.org
Received: from feral.com (feral.com [192.67.166.1])
	by hub.freebsd.org (Postfix) with ESMTP
	id 990DA37BBC3; Mon, 20 Mar 2000 23:54:58 -0800 (PST)
	(envelope-from mjacob@feral.com)
Received: from beppo.feral.com (beppo [192.67.166.79])
	by feral.com (8.9.3/8.9.3) with ESMTP id XAA00369;
	Mon, 20 Mar 2000 23:54:58 -0800
Date: Mon, 20 Mar 2000 23:54:58 -0800 (PST)
From: Matthew Jacob <mjacob@feral.com>
Reply-To: mjacob@feral.com
To: wilko@FreeBSD.ORG
Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>,
	Alfred Perlstein <bright@wintelcom.net>,
	Matthew Dillon <dillon@apollo.backplane.com>, current@FreeBSD.ORG
Subject: Re: patches for test / review
In-Reply-To: <20000321000435.A8143@yedi.iaf.nl>
Message-ID: <Pine.BSF.4.10.10003202353460.8524-100000@beppo.feral.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> 
> Hm. But I'd think that even with modern drives a smaller number of bigger
> I/Os is preferable over lots of very small I/Os.

Not necessarily. It depends upon overhead costs per-i/o. With larger I/Os, you
do pay in interference costs (you can't transfer data for request N because
the 256Kbytes of request M is still in the pipe).





To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  0:39:55 2000
Delivered-To: freebsd-current@freebsd.org
Received: from wint.itfs.nsk.su (wint.itfs.nsk.su [212.20.32.43])
	by hub.freebsd.org (Postfix) with ESMTP id 14E8B37BBC6
	for <current@freebsd.org>; Tue, 21 Mar 2000 00:39:49 -0800 (PST)
	(envelope-from nnd@wint.itfs.nsk.su)
Received: (from nnd@localhost)
	by wint.itfs.nsk.su (8.9.3/8.9.3) id OAA01544;
	Tue, 21 Mar 2000 14:38:11 +0600 (NOVT)
	(envelope-from nnd)
Date: Tue, 21 Mar 2000 14:38:11 +0600 (NOVT)
Message-Id: <200003210838.OAA01544@wint.itfs.nsk.su>
From: Nickolay Dudorov <nnd@mail.nsk.ru>
To: current@freebsd.org
Subject: 'machine/param.h' required for 'sys/socket.h'
User-Agent: tin/1.4.2-20000123 ("Polish") (UNIX) (FreeBSD/5.0-CURRENT (i386))
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

	After the following commit:

>shin        2000/03/03 03:13:13 PST
>
>  Modified files:
>    lib/libc/net         rthdr.c 
>    sys/sys              socket.h 
>    sys/kern             uipc_socket2.c 
>    sys/netinet6         ip6_output.c 
>    usr.bin/telnet       commands.c 
>    sbin/ping            ping.c 
>  Log:
>  CMSG_XXX macros alignment fixes to follow RFC2292.
>  
>  Approved by: jkh
>  
>  Submitted by: Partly from tech@openbsd
>  Reviewed by: itojun
>  
>  Revision  Changes    Path
>  1.2       +19 -7     src/lib/libc/net/rthdr.c
>  1.38      +8 -13     src/sys/sys/socket.h
>  1.55      +4 -5      src/sys/kern/uipc_socket2.c
>  1.12      +3 -3      src/sys/netinet6/ip6_output.c
>  1.21      +13 -15    src/usr.bin/telnet/commands.c
>  1.52      +2 -2      src/sbin/ping/ping.c

	'sys/scocket.h' header file start using ALIGN macro 
defined in 'machine/param.h' header file while the man page
for "socket" only mentioned 'sys/types.h' as the prerequisite
for 'sys/socket.h'.

	As a result the 'net/pchar' port is now broken.

	What must be done to solve this ? 
Is it possible to '#include <sys/param.h>' in 'sys/socket.h' OR
the man page must be corrected to explicitly state 'param.h'
(sys/ or machine/ ?) as the prerequisite to 'sys/socket.h' and
all the programms using it patched accordingly ?

	N.Dudorov


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  0:47:11 2000
Delivered-To: freebsd-current@freebsd.org
Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11])
	by hub.freebsd.org (Postfix) with SMTP id 08C4237B79F
	for <current@freebsd.org>; Tue, 21 Mar 2000 00:47:02 -0800 (PST)
	(envelope-from dwmalone@maths.tcd.ie)
Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP
          id <aa00165@salmon>; 21 Mar 2000 08:47:00 +0000 (GMT)
To: current@freebsd.org
Subject: Floating point exceptions.
X-Request-Do: 
Date: Tue, 21 Mar 2000 08:47:00 +0000
From: David Malone <dwmalone@maths.tcd.ie>
Message-ID:  <200003210847.aa00165@salmon.maths.tcd.ie>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Floating point exceptions seem to have been turned off by default:

	gonzo 13% uname -r
	5.0-CURRENT
	gonzo 14% cat a.c
	double div(double x,double y) { return x/y; }
	int main() { double x; x = div(1.0,0.0); printf("%f\n",x); }
	gonzo 15% gcc -o a a.c
	gonzo 16% ./a
	Inf

This seems to produce an SIGFPE on 3.0, which I would have thought
was the correct thing to do:

	walton 12% uname -r
	3.4-STABLE
	walton 13% cat a.c
	double div(double x,double y) { return x/y; }
	int main() { double x; x = div(1.0,0.0); printf("%f\n",x); }
	walton 14% gcc -o a a.c
	walton 15% ./a
	Floating exception (core dumped)

There was a discussion on one of the list about what to do for
floating point excpetions recently, and I thought people decided
that causing a signal by default was a right thing? I presume this
was caused by the commit below?

	David.

cracauer    2000/03/10 09:56:33 PST

  Modified files:
    sys/i386/include     npx.h 
  Log:
  Change the default FPU control word so that exceptions for new
  processes are now masked until set by fpsetmask(3).
  
  Submitted by: bde
  Approved by:  jkh, bde
  
  Revision  Changes    Path
  1.18      +5 -35     src/sys/i386/include/npx.h



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  0:50:33 2000
Delivered-To: freebsd-current@freebsd.org
Received: from knight.cons.org (knight.cons.org [194.233.237.86])
	by hub.freebsd.org (Postfix) with ESMTP id 0BB6E37B748
	for <current@FreeBSD.ORG>; Tue, 21 Mar 2000 00:50:29 -0800 (PST)
	(envelope-from cracauer@knight.cons.org)
Received: (from cracauer@localhost)
	by knight.cons.org (8.9.3/8.9.3) id JAA01307;
	Tue, 21 Mar 2000 09:50:24 +0100 (CET)
Date: Tue, 21 Mar 2000 09:50:24 +0100
From: Martin Cracauer <cracauer@cons.org>
To: David Malone <dwmalone@maths.tcd.ie>
Cc: current@FreeBSD.ORG
Subject: Re: Floating point exceptions.
Message-ID: <20000321095024.A1011@cons.org>
References: <200003210847.aa00165@salmon.maths.tcd.ie>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200003210847.aa00165@salmon.maths.tcd.ie>; from dwmalone@maths.tcd.ie on Tue, Mar 21, 2000 at 08:47:00AM +0000
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In <200003210847.aa00165@salmon.maths.tcd.ie>, David Malone wrote: 
> Floating point exceptions seem to have been turned off by default:
[...]
> There was a discussion on one of the list about what to do for
> floating point excpetions recently, and I thought people decided
> that causing a signal by default was a right thing?

The outcome was that applications that care must set the control word
themself and that we go the way of least resistance for the rest.

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/
  Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  1:12:31 2000
Delivered-To: freebsd-current@freebsd.org
Received: from popserver-02.iinet.net.au (popserver-02.iinet.net.au [203.59.24.148])
	by hub.freebsd.org (Postfix) with ESMTP id 600E537BA4E
	for <current@FreeBSD.ORG>; Tue, 21 Mar 2000 01:12:01 -0800 (PST)
	(envelope-from julian@elischer.org)
Received: from jules.elischer.org (reggae-01-126.nv.iinet.net.au [203.59.62.126])
	by popserver-02.iinet.net.au (8.9.3/8.9.3) with SMTP id RAA12690;
	Tue, 21 Mar 2000 17:11:06 +0800
Message-ID: <38D73C75.15FB7483@elischer.org>
Date: Tue, 21 Mar 2000 01:10:13 -0800
From: Julian Elischer <julian@elischer.org>
X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386)
MIME-Version: 1.0
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc: Matthew Dillon <dillon@apollo.backplane.com>, current@FreeBSD.ORG
Subject: Re: B_WRITE cleanup patch, please test!
References: <21290.953589428@critter.freebsd.dk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Poul-Henning Kamp wrote:
> 
> In message <200003202129.NAA71883@apollo.backplane.com>, Matthew Dillon writes:
> >    I think the biggest win in regards to being able to arbitrarily stack
> >    devices is to NOT attempt to forward struct buf's between devices when
> >    non-trivial manipulation is required, and instead to make struct buf's
> >    cheap enough that a device can simply allocate a new one and copy the
> >    appropriate fields.
> >
> >    In particular I really hate all the various b_*blkno fields.  b_lblkno,
> >    b_blkno, and b_pblkno.  It is precisely due to the existance of these
> >    hacks that arbitrary device stacking is difficult.
> 
> This is basically what the stuff I'm doing addresses.

I have been advocating since 1991 that the memory involved with IO
should be referenced as a vector of page/offset/length
triplets (physical addresses), and that all drivers should take
that as input. IF he driver needs to do programmed IO only then should
it map the page into KV space.

> 
> --
> Poul-Henning Kamp             FreeBSD coreteam member
> phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
> FreeBSD -- It will take a long time before progress goes too far!

-- 
      __--_|\  Julian Elischer
     /       \ julian@elischer.org
    (   OZ    ) World tour 2000
---> X_.---._/  presently in:  Perth
            v


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  1:14:50 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mail.palmerharvey.co.uk (mail.palmerharvey.co.uk [62.172.109.58])
	by hub.freebsd.org (Postfix) with ESMTP
	id 9E03037BC66; Tue, 21 Mar 2000 01:14:35 -0800 (PST)
	(envelope-from Dom.Mitchell@palmerharvey.co.uk)
Received: from ho-nt-01.pandhm.co.uk (unverified) by mail.palmerharvey.co.uk
 (Content Technologies SMTPRS 4.0.1) with ESMTP id <B3eac6d3a4b153095b0@mail.palmerharvey.co.uk>;
 Tue, 21 Mar 2000 09:14:12 +0000
Received: from ADMIN ([10.100.1.20]) by ho-nt-01.pandhm.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id G3Y8SZH7; Tue, 21 Mar 2000 09:12:36 -0000
Received: from [10.100.35.12] (helo=voodoo.pandhm.co.uk)
	by admin with esmtp (Exim 1.92 #1)
	id 12XKkA-0007NX-00; Tue, 21 Mar 2000 09:14:30 +0000
Received: by voodoo.pandhm.co.uk (Postfix, from userid 104)
	id 86999189; Tue, 21 Mar 2000 09:14:30 +0000 (GMT)
Date: Tue, 21 Mar 2000 09:14:30 +0000
To: Ilya Naumov <camel@avias.com>
Cc: current@FreeBSD.ORG, ports@FreeBSD.ORG
Subject: Re: XFree86 under -current - a bug report
Message-ID: <20000321091429.A913@voodoo.pandhm.co.uk>
References: <13991.000320@avias.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <13991.000320@avias.com>; from camel@avias.com on Mon, Mar 20, 2000 at 11:48:16PM +0300
X-Warning: Go away or I will replace you with a very small shell script.
X-OS: FreeBSD 3.4-STABLE i386
X-Uptime: 5:01PM  up  1:18, 8 users, load averages: 0.06, 0.11, 0.19
From: Dom.Mitchell@palmerharvey.co.uk (Dominic Mitchell)
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Mon, Mar 20, 2000 at 11:48:16PM +0300, Ilya Naumov wrote:
> i've tried to build XFree86 4.0 on my 5.0-CURRENT and 4.0-RELEASE box, and encountered
> a problem.
> 
> "make all" finishes successfully, but "make install" fails with the
> following error message:
> 
> making all in programs/Xserver/hw/xfree86/os-support/bsd...
> rm -f bsd_mouse.o
> cc -c -O -pipe  -ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith   -I../../../.
> ./../../programs/Xserver/hw/xfree86/common -I../../../../../../programs/Xserver/
> hw/xfree86/os-support -I. -I../../../../../../programs/Xserver/include
>   -I../../../../../../exports/include/X11 -I../../../../../../include/extensions
>  -I../../../../../../programs/Xserver/mi -I           -I../../../../../.. -I../.
> ./../../../../exports/include  -DCSRG_BASED -DSHAPE  -DXKB -DLBX -DXAPPGROUP -DX
> CSECURITY -DTOGCUP  -DXF86BIGFONT -DDPMSExtension  -DPIXPRIV -DPANORAMIX  -DGCCU
> SESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFre
> e86LOADER  -DXFree86Server -DXF86VIDMODE  -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DSMART
> _SCHEDULE -DNDEBUG   -DFUNCPROTO=15 -DNARROWPROTO   -DPCCONS_SUPPORT -DSYSCONS_S
> UPPORT -DPCVT_SUPPORT  -DUSE_DEV_IO -DUSESTDRES           -DHAS_MTRR_SUPPORT   b
> sd_mouse.c
> In file included from bsd_mouse.c:11:
> ../../../../../../programs/Xserver/hw/xfree86/common/xf86Xinput.h:99: syntax err
> or before `xDeviceCtl'
> *** Error code 1
> 
> Stop in /usr/ports/x11/XFree86-4/work/xc/programs/Xserver/hw/xfree86/os-support/
> bsd.
> *** Error code 1

Try enabling the XIE (or was it XInput) extension when you configure it.
That seemed to do the trick for me.  After that, it's all up and running
nicely.  Finally, I can easily get at TT fonts! (just wish they included
ttkmfdir...)

-- 
Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator

	``Putting the doh! into dot-com.''


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  1:24:16 2000
Delivered-To: freebsd-current@freebsd.org
Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11])
	by hub.freebsd.org (Postfix) with SMTP id 5954937B6DC
	for <current@freebsd.org>; Tue, 21 Mar 2000 01:24:10 -0800 (PST)
	(envelope-from dwmalone@maths.tcd.ie)
Received: from hamilton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP
          id <aa02305@salmon>; 21 Mar 2000 09:24:09 +0000 (GMT)
To: Martin Cracauer <cracauer@cons.org>
Cc: current@FreeBSD.ORG
Subject: Re: Floating point exceptions. 
In-reply-to: Your message of "Tue, 21 Mar 2000 09:50:24 +0100."
             <20000321095024.A1011@cons.org> 
X-Request-Do: 
Date: Tue, 21 Mar 2000 09:24:09 +0000
From: David Malone <dwmalone@maths.tcd.ie>
Message-ID:  <200003210924.aa02305@salmon.maths.tcd.ie>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> > There was a discussion on one of the list about what to do for
> > floating point excpetions recently, and I thought people decided
> > that causing a signal by default was a right thing?
> 
> The outcome was that applications that care must set the control word
> themself and that we go the way of least resistance for the rest.

OK - I just did a quick scout around. Digital Unix gives a SIGFPE;
Solaris, AIX and Redhat print some captalisation of "Inf"; HP/UX
prints "++.000000" ;-)

Is there a way of setting the control word which is in any sense
portable? Most machines I've looked at seem to have no documented
way of setting what exceptions should be masked, and each one that
does has a different set of calls.

	David.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  1:28:50 2000
Delivered-To: freebsd-current@freebsd.org
Received: from knight.cons.org (knight.cons.org [194.233.237.86])
	by hub.freebsd.org (Postfix) with ESMTP id 0B8C637B6DC
	for <current@FreeBSD.ORG>; Tue, 21 Mar 2000 01:28:47 -0800 (PST)
	(envelope-from cracauer@knight.cons.org)
Received: (from cracauer@localhost)
	by knight.cons.org (8.9.3/8.9.3) id KAA01477;
	Tue, 21 Mar 2000 10:28:44 +0100 (CET)
Date: Tue, 21 Mar 2000 10:28:43 +0100
From: Martin Cracauer <cracauer@cons.org>
To: David Malone <dwmalone@maths.tcd.ie>
Cc: Martin Cracauer <cracauer@cons.org>, current@FreeBSD.ORG
Subject: Re: Floating point exceptions.
Message-ID: <20000321102843.A1455@cons.org>
References: <20000321095024.A1011@cons.org> <200003210924.aa02305@salmon.maths.tcd.ie>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200003210924.aa02305@salmon.maths.tcd.ie>; from dwmalone@maths.tcd.ie on Tue, Mar 21, 2000 at 09:24:09AM +0000
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In <200003210924.aa02305@salmon.maths.tcd.ie>, David Malone wrote: 
> > > There was a discussion on one of the list about what to do for
> > > floating point excpetions recently, and I thought people decided
> > > that causing a signal by default was a right thing?
> > 
> > The outcome was that applications that care must set the control word
> > themself and that we go the way of least resistance for the rest.
> 
> OK - I just did a quick scout around. Digital Unix gives a SIGFPE;
> Solaris, AIX and Redhat print some captalisation of "Inf"; HP/UX
> prints "++.000000" ;-)
> 
> Is there a way of setting the control word which is in any sense
> portable? 

It is an i386 assembler instruction. Obviously, operating system
vendors thought it's not their business, but the compiler's.
Unfortunately, gcc doesn't care (although most other native compilers
like SRC m3, CMUCL, SML/NJ do).

FreeBSD's fpsetmask(3) stuff is simple inline assembler that I
personally used in Linux, it should be relativly easy to carry it
around with your application on i386 machines.

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/
  Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  2:53: 3 2000
Delivered-To: freebsd-current@freebsd.org
Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184])
	by hub.freebsd.org (Postfix) with ESMTP id A426037B80C
	for <current@freebsd.org>; Tue, 21 Mar 2000 02:52:57 -0800 (PST)
	(envelope-from luigi@info.iet.unipi.it)
Received: (from luigi@localhost)
	by info.iet.unipi.it (8.9.3/8.9.3) id LAA27866;
	Tue, 21 Mar 2000 11:51:08 +0100 (CET)
	(envelope-from luigi)
From: Luigi Rizzo <luigi@info.iet.unipi.it>
Message-Id: <200003211051.LAA27866@info.iet.unipi.it>
Subject: Reading from bad disk ?
To: current@freebsd.org
Date: Tue, 21 Mar 2000 11:51:08 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL61 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Hi,

sometimes i get IDE disks with hard errors on some sectors

	(status 59<rdy,seekdone,drq,err> error 40<uncorr>)

and of course this makes it problematic to use a filesystem on it.
I wonder, is there a way to fetch the data from these sectors
(even if partly erroneous) ?

I am asking because a strategy which often 'fixes' the
problem for me is to overwrite the erroneous sector with some data.
Of course i can use a zero-filled block but this is kind of risky,
and maybe it is preferable to use a portion of the original data
and hope that fsck is able to fix this.

And related: is there a way to tell fsck that in such cases
it should try and adopt the same method ? Otherwise it is
really boring to run my locally modified version of dd
(which is able to use 'skip' over character devices) to
try read the bad sector and write it back.

	cheers
	luigi
-----------------------------------+-------------------------------------
  Luigi RIZZO, luigi@iet.unipi.it  . Dip. di Ing. dell'Informazione
  http://www.iet.unipi.it/~luigi/  . Universita` di Pisa
  TEL/FAX: +39-050-568.533/522     . via Diotisalvi 2, 56126 PISA (Italy)
  Mobile   +39-347-0373137
-----------------------------------+-------------------------------------


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  3:37:17 2000
Delivered-To: freebsd-current@freebsd.org
Received: from camtech.net.au (goliath.camtech.net.au [203.5.73.2])
	by hub.freebsd.org (Postfix) with SMTP
	id 7200C37B900; Tue, 21 Mar 2000 03:37:12 -0800 (PST)
	(envelope-from me@camtech.net.au)
Received: from dialup-ad-10-82.camtech.net.au ([203.28.1.210]) by camtech.net.au ; Tue, 21 Mar 2000 22:07:07 +1030
Date: Tue, 21 Mar 2000 22:07:01 +1030 (CST)
From: Matthew Sean Thyer <me@camtech.net.au>
X-Sender: me@dx4.my-unregistered-domain.com
Reply-To: thyerm@camtech.net.au
To: Mike Smith <msmith@freebsd.org>
Cc: l.farr@epcdirect.co.uk, freebsd-current@freebsd.org
Subject: Re: Mylex Support 
In-Reply-To: <200003102325.PAA01007@mass.cdrom.com>
Message-ID: <Pine.BSF.4.21.0003212200350.8769-100000@dx4.my-unregistered-domain.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Are there any particular preparation processes one should go through
when setting up a Mylex DAC960 RAID array ?
(if so give me a pointer to the docs)

Can I just purchase all the hardware, plug in the disks and boot the
FreeBSD-4 install floppies ?  (for a system to be booting from the
array with no internal ATA devices)

or Should I have an internal ATA hard disk with some evil OS on it
such as Lose 9X or NT so as to run any kind of Mylex DOS/Windows
preparation utilities ?

On Fri, 10 Mar 2000, Mike Smith wrote:

> > I have 4 different Mylex DAC960 controllers that I cannot install Current
> > onto. (Tried from Late December to 20000307). Sysinstall seems to get the
> > geometry wrong, and even telling sysinstall the "correct" geometry, it gives
> > a "tied to write beyond end of drive" error. Booting from a running -current
> > and formatting does the same. They all have the latest BIOS, and they have
> > been tried with various drive combinations. Has anyone else got this to work
> > successfully or is it just me?.
> 
> Obviously; you're actually the _only_ person I've heard from with this 
> problem.
> 
> > And if it is just me, anyone got any ideas? I have been pestering Mike Smith
> > about this for ages, and have probably driven him mad!
> 
> More or less.  As I've said - I have no idea what's going on for you at 
> the moment; everything here "just works" like it should.
> 
> 



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  3:47:43 2000
Delivered-To: freebsd-current@freebsd.org
Received: from trinity.skynet.be (trinity.skynet.be [195.238.2.38])
	by hub.freebsd.org (Postfix) with ESMTP
	id 478E037B861; Tue, 21 Mar 2000 03:47:40 -0800 (PST)
	(envelope-from blk@skynet.be)
Received: from [195.238.1.121] (brad.techos.skynet.be [195.238.1.121])
	by trinity.skynet.be (Postfix) with ESMTP
	id D881D180A5; Tue, 21 Mar 2000 12:47:23 +0100 (MET)
Mime-Version: 1.0
X-Sender: blk@pop.skynet.be
Message-Id: <v04220801b4fcf066fdde@[195.238.1.121]>
In-Reply-To: <200003210325.TAA70819@mass.cdrom.com>
References: <200003210325.TAA70819@mass.cdrom.com>
Date: Tue, 21 Mar 2000 10:25:53 +0100
To: Mike Smith <msmith@FreeBSD.ORG>
From: Brad Knowles <blk@skynet.be>
Subject: Re: AMI MegaRAID lockup? not accepting commands.
Cc: "John W. DeBoskey" <jwd@unx.sas.com>,
	freebsd-current@FreeBSD.ORG, Brad Chisholm <sasblc@unx.sas.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

At 7:25 PM -0800 2000/3/20, Mike Smith wrote:

>  Not that I consider this particuarly optimal; busy-waiting for the
>  controller is a terrible waste of the host CPU.  A better solution would
>  probably defer the command and try again a short time later, but let's
>  see if this works first.

	Since this is a device driver, I guess you can't usleep() and 
then check again?  Is there anything else useful you could be doing 
during that period of time -- other than busy waiting?

--
   These are my opinions -- not to be taken as official Skynet policy
======================================================================
Brad Knowles, <blk@skynet.be>                || 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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  3:48:35 2000
Delivered-To: freebsd-current@freebsd.org
Received: from trinity.skynet.be (trinity.skynet.be [195.238.2.38])
	by hub.freebsd.org (Postfix) with ESMTP id 0CC2037B762
	for <current@FreeBSD.ORG>; Tue, 21 Mar 2000 03:48:31 -0800 (PST)
	(envelope-from blk@skynet.be)
Received: from [195.238.1.121] (brad.techos.skynet.be [195.238.1.121])
	by trinity.skynet.be (Postfix) with ESMTP
	id 0F0F9180A9; Tue, 21 Mar 2000 12:48:15 +0100 (MET)
Mime-Version: 1.0
X-Sender: blk@pop.skynet.be
Message-Id: <v0422080db4fd0463b4e5@[195.238.1.121]>
In-Reply-To: <20000321102843.A1455@cons.org>
References: <20000321095024.A1011@cons.org>
 <200003210924.aa02305@salmon.maths.tcd.ie>
 <20000321102843.A1455@cons.org>
Date: Tue, 21 Mar 2000 11:51:13 +0100
To: Martin Cracauer <cracauer@cons.org>,
	David Malone <dwmalone@maths.tcd.ie>
From: Brad Knowles <blk@skynet.be>
Subject: Re: Floating point exceptions.
Cc: Martin Cracauer <cracauer@cons.org>, current@FreeBSD.ORG
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

At 10:28 AM +0100 2000/3/21, Martin Cracauer wrote:

>  It is an i386 assembler instruction. Obviously, operating system
>  vendors thought it's not their business, but the compiler's.
>  Unfortunately, gcc doesn't care (although most other native compilers
>  like SRC m3, CMUCL, SML/NJ do).

	Note that I have recently heard some complaints about Perl in 
this respect -- Perl considers it to be a hardware issue, and code 
that depends on a SIGFPE will not necessarily function the same under 
the same version of Perl, running on different OSes.

--
   These are my opinions -- not to be taken as official Skynet policy
======================================================================
Brad Knowles, <blk@skynet.be>                || 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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  4: 2:30 2000
Delivered-To: freebsd-current@freebsd.org
Received: from freebsd.dk (freebsd.dk [212.242.42.178])
	by hub.freebsd.org (Postfix) with ESMTP id 847F537BA51
	for <current@FreeBSD.ORG>; Tue, 21 Mar 2000 04:02:22 -0800 (PST)
	(envelope-from sos@freebsd.dk)
Received: (from sos@localhost)
	by freebsd.dk (8.9.3/8.9.1) id NAA60968;
	Tue, 21 Mar 2000 13:02:12 +0100 (CET)
	(envelope-from sos)
From: Soren Schmidt <sos@freebsd.dk>
Message-Id: <200003211202.NAA60968@freebsd.dk>
Subject: Re: Reading from bad disk ?
In-Reply-To: <200003211051.LAA27866@info.iet.unipi.it> from Luigi Rizzo at "Mar 21, 2000 11:51:08 am"
To: luigi@info.iet.unipi.it (Luigi Rizzo)
Date: Tue, 21 Mar 2000 13:02:12 +0100 (CET)
Cc: current@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

It seems Luigi Rizzo wrote:
> Hi,
> 
> sometimes i get IDE disks with hard errors on some sectors
> 
> 	(status 59<rdy,seekdone,drq,err> error 40<uncorr>)
> 
> and of course this makes it problematic to use a filesystem on it.
> I wonder, is there a way to fetch the data from these sectors
> (even if partly erroneous) ?
> 
> I am asking because a strategy which often 'fixes' the
> problem for me is to overwrite the erroneous sector with some data.
> Of course i can use a zero-filled block but this is kind of risky,
> and maybe it is preferable to use a portion of the original data
> and hope that fsck is able to fix this.

Erhm, I would get a new disk :), you dont intend to trust any
data to this setup do you ??

Anyhow, I dont remember if it is possible to actually get at the data on
a transfer that the drive marked bad, but I can check up when I get 
to my doc shelf. But I wouldn't trust that data for _anything_ it is 
likely to be totally corrupted due to the drive trying to ECC correct 
it and what not...

-Søren


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  4:10: 0 2000
Delivered-To: freebsd-current@freebsd.org
Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184])
	by hub.freebsd.org (Postfix) with ESMTP id E498837B524
	for <current@FreeBSD.ORG>; Tue, 21 Mar 2000 04:09:26 -0800 (PST)
	(envelope-from luigi@info.iet.unipi.it)
Received: (from luigi@localhost)
	by info.iet.unipi.it (8.9.3/8.9.3) id NAA28180;
	Tue, 21 Mar 2000 13:07:13 +0100 (CET)
	(envelope-from luigi)
From: Luigi Rizzo <luigi@info.iet.unipi.it>
Message-Id: <200003211207.NAA28180@info.iet.unipi.it>
Subject: Re: Reading from bad disk ?
In-Reply-To: <200003211202.NAA60968@freebsd.dk> from Soren Schmidt at "Mar 21,
 2000 01:02:12 pm"
To: Soren Schmidt <sos@freebsd.dk>
Date: Tue, 21 Mar 2000 13:07:13 +0100 (CET)
Cc: current@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL61 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> > I am asking because a strategy which often 'fixes' the
...
> Erhm, I would get a new disk :), you dont intend to trust any
> data to this setup do you ??

of course, but i need to recover the old stuff first!

A comment: this is a 18GB IBM 7200 RPM disk and i noticed it tends
to become very hot compared to other disks when mounted in the
same machine (on a removable frame). Do others have the same
experience ?

> Anyhow, I dont remember if it is possible to actually get at the data on
> a transfer that the drive marked bad, but I can check up when I get 
> to my doc shelf. But I wouldn't trust that data for _anything_ it is 
> likely to be totally corrupted due to the drive trying to ECC correct 
> it and what not...

still might be useful for visual inspection.

	cheers
	luigi
-----------------------------------+-------------------------------------
  Luigi RIZZO, luigi@iet.unipi.it  . Dip. di Ing. dell'Informazione
  http://www.iet.unipi.it/~luigi/  . Universita` di Pisa
  TEL/FAX: +39-050-568.533/522     . via Diotisalvi 2, 56126 PISA (Italy)
  Mobile   +39-347-0373137
-----------------------------------+-------------------------------------


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  4:17:25 2000
Delivered-To: freebsd-current@freebsd.org
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131])
	by hub.freebsd.org (Postfix) with ESMTP id 9DE8D37B6B2
	for <current@FreeBSD.ORG>; Tue, 21 Mar 2000 04:17:16 -0800 (PST)
	(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1])
	by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id NAA25232;
	Tue, 21 Mar 2000 13:16:34 +0100 (CET)
	(envelope-from phk@critter.freebsd.dk)
To: Luigi Rizzo <luigi@info.iet.unipi.it>
Cc: Soren Schmidt <sos@freebsd.dk>, current@FreeBSD.ORG
Subject: Re: Reading from bad disk ? 
In-reply-to: Your message of "Tue, 21 Mar 2000 13:07:13 +0100."
             <200003211207.NAA28180@info.iet.unipi.it> 
Date: Tue, 21 Mar 2000 13:16:34 +0100
Message-ID: <25230.953640994@critter.freebsd.dk>
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <200003211207.NAA28180@info.iet.unipi.it>, Luigi Rizzo writes:
>> > I am asking because a strategy which often 'fixes' the
>...
>> Erhm, I would get a new disk :), you dont intend to trust any
>> data to this setup do you ??
>
>of course, but i need to recover the old stuff first!
>
>A comment: this is a 18GB IBM 7200 RPM disk and i noticed it tends
>to become very hot compared to other disks when mounted in the
>same machine (on a removable frame). Do others have the same
>experience ?

You need a fan in the removable frame for those, they do run very hot.

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  4:17:54 2000
Delivered-To: freebsd-current@freebsd.org
Received: from freebsd.dk (freebsd.dk [212.242.42.178])
	by hub.freebsd.org (Postfix) with ESMTP id 7A11337B581
	for <current@FreeBSD.ORG>; Tue, 21 Mar 2000 04:17:43 -0800 (PST)
	(envelope-from sos@freebsd.dk)
Received: (from sos@localhost)
	by freebsd.dk (8.9.3/8.9.1) id NAA64412;
	Tue, 21 Mar 2000 13:16:41 +0100 (CET)
	(envelope-from sos)
From: Soren Schmidt <sos@freebsd.dk>
Message-Id: <200003211216.NAA64412@freebsd.dk>
Subject: Re: Reading from bad disk ?
In-Reply-To: <200003211207.NAA28180@info.iet.unipi.it> from Luigi Rizzo at "Mar 21, 2000 01:07:13 pm"
To: luigi@info.iet.unipi.it (Luigi Rizzo)
Date: Tue, 21 Mar 2000 13:16:41 +0100 (CET)
Cc: current@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

It seems Luigi Rizzo wrote:
> > > I am asking because a strategy which often 'fixes' the
> ...
> > Erhm, I would get a new disk :), you dont intend to trust any
> > data to this setup do you ??
> 
> of course, but i need to recover the old stuff first!

Hmm, right...

> A comment: this is a 18GB IBM 7200 RPM disk and i noticed it tends
> to become very hot compared to other disks when mounted in the
> same machine (on a removable frame). Do others have the same
> experience ?

If that is a plastic frame and there is no fan in the drawer it
will get hot, in my boxes its enough to take of top and bottom
covers on the drawers, that allows enough airflow to keep the
disks at an accceptable temp...

-Søren


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  4:48:28 2000
Delivered-To: freebsd-current@freebsd.org
Received: from argon.blackdawn.com (deepspace9.dcds.edu [207.231.151.2])
	by hub.freebsd.org (Postfix) with ESMTP id B9FE837B6CB
	for <current@FreeBSD.ORG>; Tue, 21 Mar 2000 04:48:25 -0800 (PST)
	(envelope-from will@blackdawn.com)
Received: by argon.blackdawn.com (Postfix, from userid 1000)
	id 9BA0718DA; Tue, 21 Mar 2000 07:48:22 -0500 (EST)
Date: Tue, 21 Mar 2000 07:48:22 -0500
From: Will Andrews <andrews@technologist.com>
To: Nick Johnson <freebsd@spatula.net>
Cc: current@FreeBSD.ORG
Subject: Re: syslogd_flags in /etc/defaults/rc.conf
Message-ID: <20000321074822.C401@argon.blackdawn.com>
References: <Pine.BSF.4.21.0003200935140.25240-100000@web2.sea.nwserv.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <Pine.BSF.4.21.0003200935140.25240-100000@web2.sea.nwserv.com>; from freebsd@spatula.net on Mon, Mar 20, 2000 at 09:45:49AM -0800
X-Operating-System: FreeBSD 5.0-CURRENT i386
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Mon, Mar 20, 2000 at 09:45:49AM -0800, Nick Johnson wrote:
> I'm curious to see if anyone is like-minded with me that syslogd_flags in
> /etc/defaults/rc.conf should be "-ss" instead of "".  I reasoned that it
> should be, considering:
> 
>   1. Most people don't direct syslogs at other machines in my experience.
>   2. Someone could conceivably DOS a machine by directing tons of crap at 
>      port 121, which is also noted in the BUGS section of the syslogd
>      manpage.
>   3. Syslogd runs as root, and while it is a mature piece of code, I think
>      it preferable to minimize the number of root applications listening
>      on sockets.

This seems like a reasonable change. Thanks for pointing this out! :)

-- 
Will Andrews <andrews@technologist.com>
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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  5:31:51 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by hub.freebsd.org (Postfix) with ESMTP id 0E5EE37B79A
	for <current@FreeBSD.ORG>; Tue, 21 Mar 2000 05:31:47 -0800 (PST)
	(envelope-from bde@zeta.org.au)
Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102])
	by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id AAA25934;
	Wed, 22 Mar 2000 00:38:44 +1100
Date: Wed, 22 Mar 2000 00:31:01 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-Sender: bde@alphplex.bde.org
To: David Malone <dwmalone@maths.tcd.ie>
Cc: Martin Cracauer <cracauer@cons.org>, current@FreeBSD.ORG
Subject: Re: Floating point exceptions. 
In-Reply-To: <200003210924.aa02305@salmon.maths.tcd.ie>
Message-ID: <Pine.BSF.4.21.0003220006510.4280-100000@alphplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Tue, 21 Mar 2000, David Malone wrote:

> Is there a way of setting the control word which is in any sense
> portable? Most machines I've looked at seem to have no documented
> way of setting what exceptions should be masked, and each one that
> does has a different set of calls.

No.  C99 provides an (optional) portable way of setting the rounding
mode (fesetround() corresponds to fpsetround()), but doesn't provide
a portable way to set the precision or exception masks.  It only
provides fesetenv(), and the only portable args for fesetenv() are
FE_DFL_ENV (which gives the default environment) and a pointer to
a result filled in by a previous call to fegetenv().

Bruce



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  5:49: 8 2000
Delivered-To: freebsd-current@freebsd.org
Received: from elbas.partitur.se (elbas.partitur.se [193.219.246.222])
	by hub.freebsd.org (Postfix) with ESMTP id B0EEB37B68A
	for <freebsd-current@freebsd.org>; Tue, 21 Mar 2000 05:48:58 -0800 (PST)
	(envelope-from girgen@partitur.se)
Received: from partitur.se (localhost [127.0.0.1])
	by elbas.partitur.se (8.9.3/8.9.3) with ESMTP id OAA03319;
	Tue, 21 Mar 2000 14:48:55 +0100 (CET)
	(envelope-from girgen@partitur.se)
Message-ID: <38D77DC7.7F161FCB@partitur.se>
Date: Tue, 21 Mar 2000 14:48:55 +0100
From: Palle Girgensohn <girgen@partitur.se>
Organization: Partitur
X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-STABLE i386)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: freebsd-current@freebsd.org
Subject: can't dump vinum volumes after upgrading
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Hi!

I'm having a strange problem after upgrading: There are no raw
devices created for vinum volumes. This makes dump(8) puke.


This is a 3.4 system:

ls -laF /dev/vinum
...
crwxr-xr--  1 root  wheel   91,   1  2 Jul  1999 rusr*
drwxr-xr-x  2 root  wheel       512  2 Jul  1999 rvol/
...
brwxr-xr--  1 root  wheel   25,   1  2 Jul  1999 usr*
drwxr-xr-x  4 root  wheel       512  2 Jul  1999 vol/
...

and here's a 4.0:

crw-r-----   1 root  wheel   91,   0 21 Mar 13:40 usr
drwxr-xr-x  11 root  wheel       512 21 Mar 13:40 vol/


vinum makedev doesn't help. what gives?

/Palle


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  6:24:43 2000
Delivered-To: freebsd-current@freebsd.org
Received: from veldy.net (veldy-host201.dsl.visi.com [208.42.48.201])
	by hub.freebsd.org (Postfix) with ESMTP
	id 8138637B6F0; Tue, 21 Mar 2000 06:24:40 -0800 (PST)
	(envelope-from veldy@veldy.net)
Received: from 95CTJ (unknown [208.238.139.52])
	by veldy.net (Postfix) with SMTP
	id D62421902; Tue, 21 Mar 2000 08:27:58 -0600 (CST)
Message-ID: <004501bf9341$1aa63240$dd29680a@tgt.com>
From: "Thomas T. Veldhouse" <veldy@veldy.net>
To: "Daniel O'Connor" <doconnor@gsoft.com.au>,
	"Dan Moschuk" <dan@FreeBSD.ORG>
Cc: <current@FreeBSD.ORG>
References: <XFMail.000321105626.doconnor@gsoft.com.au>
Subject: Re: emu10k1 (SB Live!) support under FreeBSD?
Date: Tue, 21 Mar 2000 08:24:01 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

What kind of drivers are these?  Are these ports of the ALSA drivers, or are
they more OSS?

Tom Veldhouse
veldy@veldy.net

> I applied the patch to a machine which is *just* pre 4/5 split and it
patched
> fine.
>
> I used it to get my ALS120 to work.
>
>



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  7:42:36 2000
Delivered-To: freebsd-current@freebsd.org
Received: from pluto.freemail.ru (www.freemail.ru [194.87.13.61])
	by hub.freebsd.org (Postfix) with ESMTP id E132A37B933
	for <freebsd-current@freebsd.org>; Tue, 21 Mar 2000 07:42:32 -0800 (PST)
	(envelope-from alterego@pluto.freemail.ru)
Received: from pluto.freemail.ru (localhost [127.0.0.1])
	by pluto.freemail.ru (8.9.3/8.9.3) with ESMTP id SAA17781
	for <freebsd-current@freebsd.org>; Tue, 21 Mar 2000 18:42:29 +0300 (MSK)
Message-Id: <200003211542.SAA17781@pluto.freemail.ru>
Content-Type: text/plain; charset="koi8-r"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Mime-Version: 1.0
X-Mailer: wmh-0.1
To: freebsd-current@freebsd.org
Subject: subscribe
Organization: http://www.freemail.ru
Date: Tue, 21 Mar 2000 18:42:29 +0300
From: alterego <alterego@freemail.ru>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

subscribe



-----------------------------------------
Get Your e-mail at http://www.freemail.ru


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  7:51: 5 2000
Delivered-To: freebsd-current@freebsd.org
Received: from fgwmail5.fujitsu.co.jp (fgwmail5.fujitsu.co.jp [192.51.44.35])
	by hub.freebsd.org (Postfix) with ESMTP id A817F37B9D6
	for <freebsd-current@FreeBSD.ORG>; Tue, 21 Mar 2000 07:51:01 -0800 (PST)
	(envelope-from shin@nd.net.fujitsu.co.jp)
Received: from m3.gw.fujitsu.co.jp by fgwmail5.fujitsu.co.jp (8.9.3/3.7W-MX0002-Fujitsu Gateway)
	id AAA11569; Wed, 22 Mar 2000 00:50:39 +0900 (JST)
	(envelope-from shin@nd.net.fujitsu.co.jp)
Received: from incapgw.fujitsu.co.jp by m3.gw.fujitsu.co.jp (8.9.3/3.7W-0002-Fujitsu Domain Master)
	id AAA03840; Wed, 22 Mar 2000 00:50:39 +0900 (JST)
Received: from localhost ([192.168.245.44]) by incapgw.fujitsu.co.jp (8.9.3/3.7W-0002)
	id AAA01187; Wed, 22 Mar 2000 00:50:37 +0900 (JST)
To: ilmar@ints.ru
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: -current sudden panics :(
In-Reply-To: <Pine.BSF.4.21.0003210801280.223-300000@ws-ilmar.ints.ru>
References: <Pine.BSF.4.21.0003210801280.223-300000@ws-ilmar.ints.ru>
X-Mailer: Mew version 1.94 on Emacs 20.4 / Mule 4.0 (HANANOEN)
X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000322005136H.shin@nd.net.fujitsu.co.jp>
Date: Wed, 22 Mar 2000 00:51:36 +0900
From: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 36
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Hello,

> Fatal 12 trap: page fault while in kernel mode
> fault virtual address   = 0x8
> fault code              = supervisor read, page not present
> instruction pointer     = 0x8:0xc01843fc
> stack pointer           = 0x10:0xc026bd64 
> frame pointer           = 0x10:0xc026bd64 
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, def32 1, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = Idle
> interrupt mask          =
> kernel: type 12 trap, code=0
> Stopped at      arpintr+0x9c:  movl    0x8(%ebx),%ecx
> 
> trace gave this:
> arpint(c022537b,0,10,10,c0220010) at arpintr+0x9c
> swi_net_next() at awi_net_next
> 
> I'm sending kernel config and dmesg in the attachment. I have INET6 there,
> but it is not configured by ifconfig.
> 
> What's this and how can i avoid this panics?

Do you have any other hints for the problem?, because at least
I couldn't reproduce it in my 4.0 and 5.0 machines.

  -Any kernel crash dump?
  -Is there any typical situation or condition where the
   problem happens?
  -What is your LAN card?


Thanks,
Yoshinobu Inoue


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  8: 0:11 2000
Delivered-To: freebsd-current@freebsd.org
Received: from got.wedgie.org (got.wedgie.org [216.181.169.146])
	by hub.freebsd.org (Postfix) with ESMTP id 7DD3137B99D
	for <current@freebsd.org>; Tue, 21 Mar 2000 08:00:07 -0800 (PST)
	(envelope-from jgarman@got.wedgie.org)
Received: by got.wedgie.org (Postfix, from userid 1000)
	id 5BCA4D905; Tue, 21 Mar 2000 11:00:08 -0500 (EST)
Date: Tue, 21 Mar 2000 11:00:08 -0500
From: Jason Garman <jgarman@wedgie.org>
To: current@freebsd.org
Subject: breakage on amd in latest current
Message-ID: <20000321110008.A1044@got.wedgie.org>
Reply-To: jgarman@wedgie.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4i
X-Phase-Of-Moon: The Moon is Waning Gibbous (98% of Full)
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

From today's -current:

cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline
-Wcast-qual  -fformat-extensions -ansi  -nostdinc -I- -I. -I../..
-I../../../include  -D_KERNEL -include opt_global.h -elf
-mpreferred-stack-boundary=2  ../../pci/amd.c
../../pci/amd.c:168: variable `amd_device' has initializer but incomplete
type
../../pci/amd.c:170: warning: excess elements in struct initializer
../../pci/amd.c:170: warning: (near initialization for `amd_device')
../../pci/amd.c:171: warning: excess elements in struct initializer
../../pci/amd.c:171: warning: (near initialization for `amd_device')
../../pci/amd.c:172: warning: excess elements in struct initializer
../../pci/amd.c:172: warning: (near initialization for `amd_device')
../../pci/amd.c:173: warning: excess elements in struct initializer
../../pci/amd.c:173: warning: (near initialization for `amd_device')
../../pci/amd.c:175: warning: excess elements in struct initializer
../../pci/amd.c:175: warning: (near initialization for `amd_device')
../../pci/amd.c:899: warning: `amd_timeout' defined but not used
../../pci/amd.c:857: warning: `amd_reset' defined but not used
*** Error code 1

Stop in /usr/src/sys/compile/JASONLAP.


-- 
Jason Garman                                         http://web.wedgie.org/
Student, University of Maryland                          jgarman@wedgie.org
From fortune(1):                                              Whois: JAG145
  "... Had this been an actual emergency, we would have fled in terror,
   and you would not have been informed."


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  8: 6:27 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mail.rdc1.ne.home.com (ha1.rdc1.ne.home.com [24.2.4.66])
	by hub.freebsd.org (Postfix) with ESMTP id 3503337B76D
	for <current@FreeBSD.org>; Tue, 21 Mar 2000 08:06:24 -0800 (PST)
	(envelope-from jgowdy@home.com)
Received: from cx443070a ([24.4.93.90]) by mail.rdc1.ne.home.com
          (InterMail v4.01.01.00 201-229-111) with SMTP
          id <20000321160623.DSLQ14878.mail.rdc1.ne.home.com@cx443070a>
          for <current@FreeBSD.org>; Tue, 21 Mar 2000 08:06:23 -0800
Message-ID: <012401bf9350$a55a79a0$0100000a@vista1.sdca.home.com>
From: "Jeremiah Gowdy" <jgowdy@home.com>
To: <current@FreeBSD.org>
Subject: 
Date: Tue, 21 Mar 2000 08:15:16 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

subscribe jgowdy@home.com



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  8:20: 9 2000
Delivered-To: freebsd-current@freebsd.org
Received: from matrix.eurocontrol.fr (matrix.eurocontrol.fr [147.196.254.254])
	by hub.freebsd.org (Postfix) with ESMTP id 54C0837B996
	for <freebsd-current@FreeBSD.ORG>; Tue, 21 Mar 2000 08:19:57 -0800 (PST)
	(envelope-from roberto@eurocontrol.fr)
Received: from caerdonn.eurocontrol.fr (caerdonn.eurocontrol.fr [147.196.5.62])
	by matrix.eurocontrol.fr (Postfix) with ESMTP id 7810731F8
	for <freebsd-current@FreeBSD.ORG>; Tue, 21 Mar 2000 17:19:56 +0100 (CET)
	(envelope-from roberto@caerdonn.eurocontrol.fr)
Received: by caerdonn.eurocontrol.fr (Postfix, from userid 1193)
	id 965644E47; Tue, 21 Mar 2000 17:19:55 +0100 (CET)
Date: Tue, 21 Mar 2000 17:19:55 +0100
From: Ollivier Robert <roberto@eurocontrol.fr>
To: FreeBSD Current Users' list <freebsd-current@FreeBSD.ORG>
Subject: /boot/loader is making my VAIO reboot
Message-ID: <20000321171955.R93580@caerdonn.eurocontrol.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
X-Operating-System: FreeBSD 5.0-CURRENT
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Since after the Feb. 25th, /boot/loader is rebooting the machine during
boot. I can't get to the prompt at all. The only version that works is the
25th one (I didn't upgrade between the Feb. 25th and March, 17th).

Nothing in the BIOS configuration changed during that period...

-r-xr-xr-x  1 root  wheel  143360 Mar 21 16:39 loader           REBOOTS
-r-xr-xr-x  2 root  wheel  143360 Feb 25 20:03 loader.old       WORKS

This is on my VAIO laptop (Z505SX, PII/366, 128 MB).

Any idea ?
-- 
Ollivier ROBERT -=- Eurocontrol EEC/TEC -=- Ollivier.Robert@eurocontrol.fr
The Postman hits! The Postman hits! You have new mail.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  8:26:51 2000
Delivered-To: freebsd-current@freebsd.org
Received: from Draculina.otdel-1.org (Draculina.Otdel-1.ORG [195.230.65.30])
	by hub.freebsd.org (Postfix) with ESMTP id 7D80537BA91
	for <freebsd-current@FreeBSD.ORG>; Tue, 21 Mar 2000 08:26:45 -0800 (PST)
	(envelope-from nms@otdel-1.org)
Received: by Draculina.otdel-1.org (Postfix, from userid 1002)
	id 8C171198; Tue, 21 Mar 2000 19:26:42 +0300 (MSK)
Date: Tue, 21 Mar 2000 19:26:42 +0300
From: Nikolai Saoukh <nms@otdel-1.org>
To: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>
Cc: ilmar@ints.ru, freebsd-current@FreeBSD.ORG
Subject: Re: -current sudden panics :(
Message-ID: <20000321192642.B8237@Draculina.otdel-1.org>
References: <Pine.BSF.4.21.0003210801280.223-300000@ws-ilmar.ints.ru> <20000322005136H.shin@nd.net.fujitsu.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <20000322005136H.shin@nd.net.fujitsu.co.jp>; from shin@nd.net.fujitsu.co.jp on Wed, Mar 22, 2000 at 12:51:36AM +0900
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Wed, Mar 22, 2000 at 12:51:36AM +0900, Yoshinobu Inoue wrote:

> > trace gave this:
> > arpint(c022537b,0,10,10,c0220010) at arpintr+0x9c
> > swi_net_next() at awi_net_next
> > 
> > I'm sending kernel config and dmesg in the attachment. I have INET6 there,
> > but it is not configured by ifconfig.
> > 
> > What's this and how can i avoid this panics?
> 
> Do you have any other hints for the problem?, because at least
> I couldn't reproduce it in my 4.0 and 5.0 machines.
> 
>   -Any kernel crash dump?
>   -Is there any typical situation or condition where the
>    problem happens?
>   -What is your LAN card?

The driver for his card does not set packet header pointer, thus
arp stuff see NULL pointer. small patch will cure this problem
(at least I hope so).

*** if_ed.c.old	Tue Mar 21 19:21:40 2000
--- if_ed.c	Tue Mar 21 19:23:27 2000
***************
*** 2728,2733 ****
--- 2728,2734 ----
  	 */
  	m->m_pkthdr.len = m->m_len = len - sizeof(struct ether_header);
  	m->m_data += sizeof(struct ether_header);
+ 	m->m_pkthdr.header = (void *)eh;
  
  	ether_input(&sc->arpcom.ac_if, eh, m);
  	return;


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  8:34:42 2000
Delivered-To: freebsd-current@freebsd.org
Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36])
	by hub.freebsd.org (Postfix) with ESMTP id E766E37BA6B
	for <current@FreeBSD.ORG>; Tue, 21 Mar 2000 08:34:35 -0800 (PST)
	(envelope-from shin@nd.net.fujitsu.co.jp)
Received: from m3.gw.fujitsu.co.jp by fgwmail6.fujitsu.co.jp (8.9.3/3.7W-MX0002-Fujitsu Gateway)
	id BAA14365; Wed, 22 Mar 2000 01:34:02 +0900 (JST)
	(envelope-from shin@nd.net.fujitsu.co.jp)
Received: from incapgw.fujitsu.co.jp by m3.gw.fujitsu.co.jp (8.9.3/3.7W-0002-Fujitsu Domain Master)
	id BAA10047; Wed, 22 Mar 2000 01:34:01 +0900 (JST)
Received: from localhost ([192.168.245.71]) by incapgw.fujitsu.co.jp (8.9.3/3.7W-0002)
	id BAA02667; Wed, 22 Mar 2000 01:34:00 +0900 (JST)
To: nnd@mail.nsk.ru
Cc: current@FreeBSD.ORG
Subject: Re: 'machine/param.h' required for 'sys/socket.h'
In-Reply-To: <200003210838.OAA01544@wint.itfs.nsk.su>
References: <200003210838.OAA01544@wint.itfs.nsk.su>
X-Mailer: Mew version 1.94 on Emacs 20.4 / Mule 4.0 (HANANOEN)
X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000322013459L.shin@nd.net.fujitsu.co.jp>
Date: Wed, 22 Mar 2000 01:34:59 +0900
From: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 28
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Hello,

> 	'sys/scocket.h' header file start using ALIGN macro 
> defined in 'machine/param.h' header file while the man page
> for "socket" only mentioned 'sys/types.h' as the prerequisite
> for 'sys/socket.h'.
> 
> 	As a result the 'net/pchar' port is now broken.

Yes, this problem is already found by Bruce A. Mah and some
mail is exchanged between related people.

> 	What must be done to solve this ? 
> Is it possible to '#include <sys/param.h>' in 'sys/socket.h' OR
> the man page must be corrected to explicitly state 'param.h'
> (sys/ or machine/ ?) as the prerequisite to 'sys/socket.h' and
> all the programms using it patched accordingly ?

As itojun's experience, including machine/param.h in socket.h
also cause problems in some other apps.

I feel requesting inclusion of machine/param.h for any apps
which use socket is better. But if there are any other smarter
solution, please let me know and I'll appreciate it much.

Thanks,
Yoshinobu Inoue



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  8:51:16 2000
Delivered-To: freebsd-current@freebsd.org
Received: from fgwmail7.fujitsu.co.jp (fgwmail7.fujitsu.co.jp [192.51.44.37])
	by hub.freebsd.org (Postfix) with ESMTP id 01DC737BA2F
	for <freebsd-current@FreeBSD.ORG>; Tue, 21 Mar 2000 08:51:14 -0800 (PST)
	(envelope-from shin@nd.net.fujitsu.co.jp)
Received: from m5.gw.fujitsu.co.jp by fgwmail7.fujitsu.co.jp (8.9.3/3.7W-MX0002-Fujitsu Gateway)
	id BAA03283; Wed, 22 Mar 2000 01:50:56 +0900 (JST)
	(envelope-from shin@nd.net.fujitsu.co.jp)
Received: from incapgw.fujitsu.co.jp by m5.gw.fujitsu.co.jp (8.9.3/3.7W-0002-Fujitsu Domain Master)
	id BAA11898; Wed, 22 Mar 2000 01:50:55 +0900 (JST)
Received: from localhost ([192.168.245.144]) by incapgw.fujitsu.co.jp (8.9.3/3.7W-0002)
	id BAA03189; Wed, 22 Mar 2000 01:50:54 +0900 (JST)
To: nms@otdel-1.org
Cc: ilmar@ints.ru, freebsd-current@FreeBSD.ORG
Subject: Re: -current sudden panics :(
In-Reply-To: <20000321192642.B8237@Draculina.otdel-1.org>
References: <Pine.BSF.4.21.0003210801280.223-300000@ws-ilmar.ints.ru>
	<20000322005136H.shin@nd.net.fujitsu.co.jp>
	<20000321192642.B8237@Draculina.otdel-1.org>
X-Mailer: Mew version 1.94 on Emacs 20.4 / Mule 4.0 (HANANOEN)
X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000322015153F.shin@nd.net.fujitsu.co.jp>
Date: Wed, 22 Mar 2000 01:51:53 +0900
From: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 25
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> >   -What is your LAN card?

Woops, I often do a needless query. That should be using rl
driver as the kernel log.

> The driver for his card does not set packet header pointer, thus
> arp stuff see NULL pointer. small patch will cure this problem
> (at least I hope so).
> 
> *** if_ed.c.old	Tue Mar 21 19:21:40 2000
> --- if_ed.c	Tue Mar 21 19:23:27 2000
> ***************
> *** 2728,2733 ****
> --- 2728,2734 ----
>   	 */
>   	m->m_pkthdr.len = m->m_len = len - sizeof(struct ether_header);
>   	m->m_data += sizeof(struct ether_header);
> + 	m->m_pkthdr.header = (void *)eh;
>   
>   	ether_input(&sc->arpcom.ac_if, eh, m);
>   	return;

But shouldn't it be sys/pci/if_rl.c ?

Yoshinobu Inoue


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  8:57:46 2000
Delivered-To: freebsd-current@freebsd.org
Received: from Draculina.otdel-1.org (Draculina.Otdel-1.ORG [195.230.65.30])
	by hub.freebsd.org (Postfix) with ESMTP id 821ED37BB94
	for <freebsd-current@FreeBSD.ORG>; Tue, 21 Mar 2000 08:57:40 -0800 (PST)
	(envelope-from nms@otdel-1.org)
Received: by Draculina.otdel-1.org (Postfix, from userid 1002)
	id A6BE41A7; Tue, 21 Mar 2000 19:57:37 +0300 (MSK)
Date: Tue, 21 Mar 2000 19:57:37 +0300
From: Nikolai Saoukh <nms@otdel-1.org>
To: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>
Cc: ilmar@ints.ru, freebsd-current@FreeBSD.ORG
Subject: Re: -current sudden panics :(
Message-ID: <20000321195737.A8366@Draculina.otdel-1.org>
References: <Pine.BSF.4.21.0003210801280.223-300000@ws-ilmar.ints.ru> <20000322005136H.shin@nd.net.fujitsu.co.jp> <20000321192642.B8237@Draculina.otdel-1.org> <20000322015153F.shin@nd.net.fujitsu.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <20000322015153F.shin@nd.net.fujitsu.co.jp>; from shin@nd.net.fujitsu.co.jp on Wed, Mar 22, 2000 at 01:51:53AM +0900
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Wed, Mar 22, 2000 at 01:51:53AM +0900, Yoshinobu Inoue wrote:

> But shouldn't it be sys/pci/if_rl.c ?

Sorry,
it is mea culpa. I mixed his case with my (token ring).


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  8:58:39 2000
Delivered-To: freebsd-current@freebsd.org
Received: from veldy.net (veldy-host201.dsl.visi.com [208.42.48.201])
	by hub.freebsd.org (Postfix) with ESMTP id 4EA4737B99D
	for <freebsd-current@FreeBSD.ORG>; Tue, 21 Mar 2000 08:58:36 -0800 (PST)
	(envelope-from veldy@veldy.net)
Received: from 95CTJ (unknown [208.238.139.52])
	by veldy.net (Postfix) with SMTP
	id 47FFF1921; Tue, 21 Mar 2000 11:01:54 -0600 (CST)
Message-ID: <00ad01bf9356$9a7ee060$dd29680a@tgt.com>
From: "Thomas T. Veldhouse" <veldy@veldy.net>
To: "David Murphy" <drjolt+freebsd-stable@redbrick.dcu.ie>,
	<freebsd-current@FreeBSD.ORG>
References: <001a01bf91c1$7f62a4b0$0304020a@NENYA> <200003191838.KAA40955@rah.star-gate.com> <20000319220453.A65973@ipass.net> <005d01bf9221$4660ac60$0304020a@NENYA> <20000320153429.A1373@ipass.net> <v04220803b4fcf1e15773@[195.238.1.121]> <20000321121048.E49550@enigma.redbrick.dcu.ie> <v04220815b4fd1c95611c@[195.238.1.121]> <20000321141055.E5367@enigma.redbrick.dcu.ie> <v04220821b4fd4f825554@[195.238.1.121]> <20000321163707.L5367@enigma.redbrick.dcu.ie>
Subject: Re: Voxware is toast.  Get used to it.  (Re: Suggestions for improving newpcm performance?)
Date: Tue, 21 Mar 2000 10:57:55 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

This is an old debate.  However, if the user is not smart enough to know
that a "not" release is new and should be tested, well, that speaks volumes
itself doesn't it?

Tom Veldhouse
veldy@veldy.net

----- Original Message -----
From: David Murphy <drjolt+freebsd-stable@redbrick.dcu.ie>
To: Brad Knowles <blk@skynet.be>
Cc: <stable@FreeBSD.ORG>
Sent: Tuesday, March 21, 2000 10:37 AM
Subject: Re: Voxware is toast. Get used to it. (Re: Suggestions for
improving newpcm performance?)


> Quoting <v04220821b4fd4f825554@[195.238.1.121]>
> by Brad Knowles <blk@skynet.be>:
>
> > We just got our official shrink-wrapped versions of Solaris 8 from
> > Sun.  Do you think we're actually going to be stupid enough to try
> > to put this into production any time within the next few months?
>
> > It's an x.0 release from Sun, and we're going to treat it just like
> > we do with x.0 releases from *any* vendor.  We may play with it on
> > our desktops, we may do some prototyping with it, etc....
>
> Right, and if you try to upgrade your Solaris 7 desktop, which, while
> not a production server, is a machine you personally need to do your
> job, to Solaris 8, and it fails, and you call Sun about it, and they
> tell you "Hey, what do you think you're doing? That's not ready for
> real use yet!". You wouldn't be too impressed, would you? That's
> basically the scenario I'm seeing with FreeBSD.
>
> > Thing is, it's *not* a beta anymore.  It's more like a gamma
> > version.
>
> Call it -GAMMA then. Bascially, I'm saying I think it should be called
> something other than -RELEASE until the average user can install it,
> and upgrade to it from the prior version.
>
> > The *only* way to proceed from here is to actually release the
> > thing, let people start trying to use it, and then report bugs back.
> > But we wouldn't be acting in good faith if we didn't at least warn
> > people that it's not quite ready for use on production servers.
>
> IMHO the place for that warning is the release announcement and the
> release notes, and it wasn't in either last I looked.




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  9: 7:24 2000
Delivered-To: freebsd-current@freebsd.org
Received: from nimitz.ca.sandia.gov (nimitz.ca.sandia.gov [146.246.243.56])
	by hub.freebsd.org (Postfix) with ESMTP id 8E91037B8D3
	for <current@FreeBSD.ORG>; Tue, 21 Mar 2000 09:07:17 -0800 (PST)
	(envelope-from bmah@nimitz.ca.sandia.gov)
Received: (from bmah@localhost)
	by nimitz.ca.sandia.gov (8.10.0/8.10.0) id e2LH6YJ86200;
	Tue, 21 Mar 2000 09:06:34 -0800 (PST)
	(envelope-from bmah)
Message-Id: <200003211706.e2LH6YJ86200@nimitz.ca.sandia.gov>
X-Mailer: exmh version 2.1.1-cvs 10/15/1999
To: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>
Cc: nnd@mail.nsk.ru, current@FreeBSD.ORG
Subject: Re: 'machine/param.h' required for 'sys/socket.h' 
In-Reply-To: <20000322013459L.shin@nd.net.fujitsu.co.jp> 
References: <200003210838.OAA01544@wint.itfs.nsk.su> <20000322013459L.shin@nd.net.fujitsu.co.jp>
Comments: In-reply-to Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>
   message dated "Wed, 22 Mar 2000 01:34:59 +0900."
From: bmah@CA.Sandia.GOV (Bruce A. Mah)
Reply-To: bmah@CA.Sandia.GOV
X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5<Pi&akO)o^8;[r
 %l(8ZHlbF`dD>v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A
 2V%N&+
X-Url: http://www.ca.sandia.gov/~bmah/
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-389727046P";
	 micalg=pgp-sha1; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Tue, 21 Mar 2000 09:06:34 -0800
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

--==_Exmh_-389727046P
Content-Type: text/plain; charset=us-ascii

If memory serves me right, Yoshinobu Inoue wrote:

> 
> > 	'sys/scocket.h' header file start using ALIGN macro 
> > defined in 'machine/param.h' header file while the man page
> > for "socket" only mentioned 'sys/types.h' as the prerequisite
> > for 'sys/socket.h'.
> > 
> > 	As a result the 'net/pchar' port is now broken.
> 
> Yes, this problem is already found by Bruce A. Mah and some
> mail is exchanged between related people.

I'm doing a pointrev to pchar to "fix" this problem...see below.

> > 	What must be done to solve this ? 
> > Is it possible to '#include <sys/param.h>' in 'sys/socket.h' OR
> > the man page must be corrected to explicitly state 'param.h'
> > (sys/ or machine/ ?) as the prerequisite to 'sys/socket.h' and
> > all the programms using it patched accordingly ?
> 
> As itojun's experience, including machine/param.h in socket.h
> also cause problems in some other apps.
> 
> I feel requesting inclusion of machine/param.h for any apps
> which use socket is better. But if there are any other smarter
> solution, please let me know and I'll appreciate it much.

Just speaking as the slightly whiny developer of pchar:  What bothers me
is that out of all the platforms where pchar can do IPv6 support, recent
FreeBSD versions seem the *only* case where I need to include machine/
param.h in order to use the CMSG* macros.  This means that FreeBSD is
forcing me to make some code changes that aren't required for *any*
other platform.  According to itojun's earlier mail, I can't just
blindly include machine/param.h either.  So I need to figure out at
compile-time or configure-time whether or not I need machine/param.h.

Personally, I think this is a lose.  Unfortunately I don't have any
better suggestion than "back out your last commit".

In the specific case of pchar, I need to make code changes in order to
work with 4.0-RELEASE, now that it's been shipped with the header files
as we've discussed.  So I wrote a bunch of autoconf code to detect this
breakage and fix it.  I'll probably roll in some Solaris fixes also and
call this pchar-1.1.2 or something like that.

Bruce.




--==_Exmh_-389727046P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: 3uCh5X62cIbIdDoqZ//j08o34NzF4+46

iQA/AwUBONesGdjKMXFboFLDEQJU2QCgxSDcOInXsdYhVmzsijyMDyv03TsAoIaw
FZQHXjJyqthiooRftebXdDtF
=FUFT
-----END PGP SIGNATURE-----

--==_Exmh_-389727046P--


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  9:14:28 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP
	id 61EB237B865; Tue, 21 Mar 2000 09:14:26 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id JAA81010;
	Tue, 21 Mar 2000 09:14:14 -0800 (PST)
	(envelope-from dillon)
Date: Tue, 21 Mar 2000 09:14:14 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003211714.JAA81010@apollo.backplane.com>
To: Brad Knowles <blk@skynet.be>
Cc: Mike Smith <msmith@FreeBSD.ORG>,
	"John W. DeBoskey" <jwd@unx.sas.com>, freebsd-current@FreeBSD.ORG,
	Brad Chisholm <sasblc@unx.sas.com>
Subject: Re: AMI MegaRAID lockup? not accepting commands.
References: <200003210325.TAA70819@mass.cdrom.com> <v04220801b4fcf066fdde@[195.238.1.121]>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

:At 7:25 PM -0800 2000/3/20, Mike Smith wrote:
:
:>  Not that I consider this particuarly optimal; busy-waiting for the
:>  controller is a terrible waste of the host CPU.  A better solution would
:>  probably defer the command and try again a short time later, but let's
:>  see if this works first.
:
:	Since this is a device driver, I guess you can't usleep() and 
:then check again?  Is there anything else useful you could be doing 
:during that period of time -- other than busy waiting?
:
:--
:   These are my opinions -- not to be taken as official Skynet policy
:======================================================================
:Brad Knowles, <blk@skynet.be>                || Belgacom Skynet SA/NV
:Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124

    For situations that aren't in the critical path and don't happen often,
    it may be beneficial to do a voluntary context switch inside the loop.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  9:20:11 2000
Delivered-To: freebsd-current@freebsd.org
Received: from bilby.prth.tensor.pgs.com (bilby.prth.tensor.pgs.com [157.147.232.237])
	by hub.freebsd.org (Postfix) with ESMTP id 7899F37BC26
	for <current@freebsd.org>; Tue, 21 Mar 2000 09:20:03 -0800 (PST)
	(envelope-from shocking@bandicoot.prth.tensor.pgs.com)
Received: from bandicoot.prth.tensor.pgs.com (bandicoot.prth.tensor.pgs.com [157.147.224.1])
	by bilby.prth.tensor.pgs.com (8.9.3/8.8.8) with ESMTP id BAA17830
	for <current@freebsd.org>; Wed, 22 Mar 2000 01:17:35 +0800 (WST)
Received: (from shocking@localhost)
	by bandicoot.prth.tensor.pgs.com (8.9.3/8.8.8) id BAA06234
	for current@freebsd.org; Wed, 22 Mar 2000 01:19:43 +0800 (WST)
Date: Wed, 22 Mar 2000 01:19:43 +0800 (WST)
From: Stephen Hocking-Senior Programmer PGS SPS Perth <shocking@prth.pgs.com>
Message-Id: <200003211719.BAA06234@bandicoot.prth.tensor.pgs.com>
To: current@freebsd.org
Subject: Crash on current at cvs-cur.6182
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


The back trace reads ...

#0  boot (howto=260) at ../../kern/kern_shutdown.c:304
#1  0xc013d7e5 in panic (fmt=0xc0273514 "from debugger")
    at ../../kern/kern_shutdown.c:554
#2  0xc01265bd in db_panic (addr=-1071292651, have_addr=0, count=-1, 
    modif=0xc5ec6ce4 "") at ../../ddb/db_command.c:433
#3  0xc012655d in db_command (last_cmdp=0xc02abc0c, cmd_table=0xc02aba6c, 
    aux_cmd_tablep=0xc02e4514) at ../../ddb/db_command.c:333
#4  0xc0126622 in db_command_loop () at ../../ddb/db_command.c:455
#5  0xc0128733 in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
#6  0xc0255cb5 in kdb_trap (type=3, code=0, regs=0xc5ec6dec)
    at ../../i386/i386/db_interface.c:158
#7  0xc0262680 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 0, 
      tf_esi = 256, tf_ebp = -974361036, tf_isp = -974361064, 
      tf_ebx = -1071048832, tf_edx = 0, tf_ecx = -1070604608, tf_eax = 18, 
      tf_trapno = 3, tf_err = 0, tf_eip = -1071292651, tf_cs = 8, 
      tf_eflags = 582, tf_esp = -1070994113, tf_ss = -1071158909})
    at ../../i386/i386/trap.c:549
#8  0xc0255f15 in Debugger (msg=0xc0276983 "panic") at machine/cpufunc.h:64
#9  0xc013d7dc in panic (
    fmt=0xc0291780 "vm_object_terminate: freeing busy page %p\n")
    at ../../kern/kern_shutdown.c:552
#10 0xc02143f3 in vm_object_terminate (object=0xc5ebee40)
    at ../../vm/vm_object.c:442
#11 0xc0214314 in vm_object_deallocate (object=0xc5ebee40)
    at ../../vm/vm_object.c:377
#12 0xc02117f7 in vm_map_entry_delete (map=0xc5982980, entry=0xc5ec2270)
    at ../../vm/vm_map.c:1727
#13 0xc0211979 in vm_map_delete (map=0xc5982980, start=0, end=3217031168)
    at ../../vm/vm_map.c:1830
#14 0xc0211a06 in vm_map_remove (map=0xc5982980, start=0, end=3217031168)
    at ../../vm/vm_map.c:1855
#15 0xc0136908 in exit1 (p=0xc597d860, rv=0) at ../../kern/kern_exit.c:216
#16 0xc01366e8 in exit1 (p=0xc597d860, rv=-979883648)
    at ../../kern/kern_exit.c:103
#17 0xc0262f22 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, 
      tf_edi = 0, tf_esi = -1, tf_ebp = -1077937864, tf_isp = -974360620, 
      tf_ebx = 405762436, tf_edx = 405819424, tf_ecx = 10, tf_eax = 1, 
      tf_trapno = 12, tf_err = 2, tf_eip = 405482552, tf_cs = 31, 
      tf_eflags = 647, tf_esp = -1077937908, tf_ss = 47})
    at ../../i386/i386/trap.c:1073


Machine was under heavy NFS & disk load. Have also noticed odd problems,
such as X refusing to allow connections and then crashing.


	Stephen
(who has been away for 2months and just came back to a bad spot. Sigh)


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  9:26:48 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP
	id 79B7A37BC2F; Tue, 21 Mar 2000 09:26:44 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id JAA81137;
	Tue, 21 Mar 2000 09:26:42 -0800 (PST)
	(envelope-from dillon)
Date: Tue, 21 Mar 2000 09:26:42 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003211726.JAA81137@apollo.backplane.com>
To: Matthew Jacob <mjacob@feral.com>
Cc: wilko@FreeBSD.ORG, Poul-Henning Kamp <phk@critter.freebsd.dk>,
	Alfred Perlstein <bright@wintelcom.net>, current@FreeBSD.ORG
Subject: Re: patches for test / review
References:  <Pine.BSF.4.10.10003202353460.8524-100000@beppo.feral.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


:> Hm. But I'd think that even with modern drives a smaller number of bigger
:> I/Os is preferable over lots of very small I/Os.
:
:Not necessarily. It depends upon overhead costs per-i/o. With larger I/Os, you
:do pay in interference costs (you can't transfer data for request N because
:the 256Kbytes of request M is still in the pipe).

    This problem has scaled over the last few years.  With 5 MB/sec SCSI
    busses it was a problem.  With 40, 80, and 160 MB/sec it isn't as big
    an issue any more.

	256K @ 40 MBytes/sec = 6.25 mS.
	256K @ 80 MBytes/sec = 3.125 mS.

    When you add in write-decoupling (take softupdates, for example), the
    issue become even less of a problem.

    The biggest single item that does not scale well is command/response 
    overhead.  I think it has been successfully argued (but I forgot who
    made the point) that 64K is not quite into the sweet spot - that 256K
    is closer to the mark.  But one has to be careful to only issue large
    requests for things that are actually going to be used.  If you read
    256K but only use 8K of it, you just wasted a whole lot of cpu and bus
    bandwidth.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  9:30:10 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id 47E1037BC0E
	for <current@FreeBSD.ORG>; Tue, 21 Mar 2000 09:30:06 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id JAA81170;
	Tue, 21 Mar 2000 09:29:56 -0800 (PST)
	(envelope-from dillon)
Date: Tue, 21 Mar 2000 09:29:56 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003211729.JAA81170@apollo.backplane.com>
To: Wilko Bulte <wilko@yedi.iaf.nl>
Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>,
	Alfred Perlstein <bright@wintelcom.net>, current@FreeBSD.ORG
Subject: Re: patches for test / review
References: <20000320111544.A14789@fw.wintelcom.net> <20102.953580112@critter.freebsd.dk> <20000321000435.A8143@yedi.iaf.nl>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

:> 
:> I would think that track-caches and intelligent drives would gain
:> much if not more of what clustering was designed to do gain.
:
:Hm. But I'd think that even with modern drives a smaller number of bigger
:I/Os is preferable over lots of very small I/Os. Or have I missed the point?
:
:-- 
:Wilko Bulte 			Arnhem, The Netherlands	  
:http://www.tcja.nl  		The FreeBSD Project: http://www.freebsd.org

    As long as you do not blow away the drive's cache with your big I/O's,
    and as long as you actually use all the returned data, it's definitely 
    more efficient to issue larger I/O's.

    If you generate requests that are too large - say over 1/4 the size of
    the drive's cache, the drive will not be able to optimize parallel 
    requests as well.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  9:35:34 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by hub.freebsd.org (Postfix) with ESMTP id BC00337BD47
	for <current@FreeBSD.ORG>; Tue, 21 Mar 2000 09:35:29 -0800 (PST)
	(envelope-from bde@zeta.org.au)
Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102])
	by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id EAA04343;
	Wed, 22 Mar 2000 04:42:45 +1100
Date: Wed, 22 Mar 2000 04:35:01 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-Sender: bde@alphplex.bde.org
To: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>
Cc: nnd@mail.nsk.ru, current@FreeBSD.ORG
Subject: Re: 'machine/param.h' required for 'sys/socket.h'
In-Reply-To: <20000322013459L.shin@nd.net.fujitsu.co.jp>
Message-ID: <Pine.BSF.4.21.0003220428230.4710-100000@alphplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Wed, 22 Mar 2000, Yoshinobu Inoue wrote:

> I feel requesting inclusion of machine/param.h for any apps
> which use socket is better. But if there are any other smarter
> solution, please let me know and I'll appreciate it much.

<machine/param.h> should never be included by applications since
it is an implementation detail.

Specify including <sys/param.h> in apps which use the CMSG*() macros.
<sys/socket.h> doesn't depend on <*/param.h> unless these macros are used.
Since these macros are undocumented, applications that use them should
expect problems :-).

Bruce



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  9:37: 6 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP
	id 6E38C37B95F; Tue, 21 Mar 2000 09:37:01 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id JAA81344;
	Tue, 21 Mar 2000 09:36:38 -0800 (PST)
	(envelope-from dillon)
Date: Tue, 21 Mar 2000 09:36:38 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003211736.JAA81344@apollo.backplane.com>
To: FreeBSD MAIL <freebsd@mauibuilt.com>
Cc: freebsd-hackers@FreeBSD.ORG, freebsd-current@FreeBSD.ORG
Subject: Re: Davicam dc0 driver
References:  <200003210311.RAA00995@mauibuilt.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

:I have a BookPC with a built in Davi Comm 10/100 ethernet card.
:
:I am always getting
:
:/kernel: dc0: watchdog timeout
:
:every few minutes..
:
:Can thease errors be stopped?
:
:
:Thank you for any reply
:
:RP
:puga@mauibuilt.com

    If you've got a kernel build environment setup, try the following
    patch to if_dc (suggested to me by Bill Paul a few months ago).  I
    would be interested in knowing if it reduces the number of wdog 
    timeouts you get.  It seems to help mine.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>

Index: if_dc.c
===================================================================
RCS file: /home/ncvs/src/sys/pci/if_dc.c,v
retrieving revision 1.7
diff -u -r1.7 if_dc.c
--- if_dc.c	2000/01/24 17:19:37	1.7
+++ if_dc.c	2000/01/26 23:27:20
@@ -1548,7 +1548,7 @@
 		break;
 	case DC_DEVICEID_82C115:
 		sc->dc_type = DC_TYPE_PNICII;
-		sc->dc_flags |= DC_TX_POLL|DC_TX_USE_TX_INTR;
+		sc->dc_flags |= DC_TX_POLL|DC_TX_INTR_ALWAYS;
 		break;
 	case DC_DEVICEID_82C168:
 		sc->dc_type = DC_TYPE_PNIC;


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  9:48:54 2000
Delivered-To: freebsd-current@freebsd.org
Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36])
	by hub.freebsd.org (Postfix) with ESMTP id 6638637BB85
	for <current@FreeBSD.ORG>; Tue, 21 Mar 2000 09:48:51 -0800 (PST)
	(envelope-from shin@nd.net.fujitsu.co.jp)
Received: from m4.gw.fujitsu.co.jp by fgwmail6.fujitsu.co.jp (8.9.3/3.7W-MX0002-Fujitsu Gateway)
	id CAA18227; Wed, 22 Mar 2000 02:48:14 +0900 (JST)
	(envelope-from shin@nd.net.fujitsu.co.jp)
Received: from incapgw.fujitsu.co.jp by m4.gw.fujitsu.co.jp (8.9.3/3.7W-0002-Fujitsu Domain Master)
	id CAA05589; Wed, 22 Mar 2000 02:48:14 +0900 (JST)
Received: from localhost ([192.168.245.168]) by incapgw.fujitsu.co.jp (8.9.3/3.7W-0002)
	id CAA04671; Wed, 22 Mar 2000 02:48:12 +0900 (JST)
To: bde@zeta.org.au
Cc: nnd@mail.nsk.ru, current@FreeBSD.ORG
Subject: Re: 'machine/param.h' required for 'sys/socket.h'
In-Reply-To: <Pine.BSF.4.21.0003220428230.4710-100000@alphplex.bde.org>
References: <20000322013459L.shin@nd.net.fujitsu.co.jp>
	<Pine.BSF.4.21.0003220428230.4710-100000@alphplex.bde.org>
X-Mailer: Mew version 1.94 on Emacs 20.4 / Mule 4.0 (HANANOEN)
X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000322024911Q.shin@nd.net.fujitsu.co.jp>
Date: Wed, 22 Mar 2000 02:49:11 +0900
From: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 27
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> > I feel requesting inclusion of machine/param.h for any apps
> > which use socket is better. But if there are any other smarter
> > solution, please let me know and I'll appreciate it much.
> 
> <machine/param.h> should never be included by applications since
> it is an implementation detail.
> 
> Specify including <sys/param.h> in apps which use the CMSG*() macros.
> <sys/socket.h> doesn't depend on <*/param.h> unless these macros are used.
> Since these macros are undocumented, applications that use them should
> expect problems :-).
> 
> Bruce

After reading bmah's message, now I am inclined to including
machine/param.h from sys/socket.h for maximum portability, if
there is no spec for it, and if all other platforms doing it.

Of course, I think enough testing for it is necessary.  I can
test make world for it. And if it is OK, then I think it
should be once just committed and checked if any other ports
build problem happens for it, or any other person claim
another problem.

Any more comments for this approach?

Yoshinobu Inoue


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21  9:59:55 2000
Delivered-To: freebsd-current@freebsd.org
Received: from elbas.partitur.se (elbas.partitur.se [193.219.246.222])
	by hub.freebsd.org (Postfix) with ESMTP id 900C837BC3F
	for <freebsd-current@freebsd.org>; Tue, 21 Mar 2000 09:59:42 -0800 (PST)
	(envelope-from girgen@partitur.se)
Received: from partitur.se (localhost [127.0.0.1])
	by elbas.partitur.se (8.9.3/8.9.3) with ESMTP id SAA04066;
	Tue, 21 Mar 2000 18:59:30 +0100 (CET)
	(envelope-from girgen@partitur.se)
Message-ID: <38D7B882.58B9A036@partitur.se>
Date: Tue, 21 Mar 2000 18:59:30 +0100
From: Palle Girgensohn <girgen@partitur.se>
Organization: Partitur
X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-STABLE i386)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: freebsd-current@freebsd.org
Subject: Re: can't dump vinum volumes after upgrading
References: <38D77DC7.7F161FCB@partitur.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Hello again.

I did some rtfm and src digging, it appears the listing I gave is
correct; the raw devices are in the rvinum dircetory. Problem is,
dump looks in vinum/r*. There seems that vinum introduces a bug
here, since dump's rawname function replaces the last '/' in the
device name with '/r'. In my 3.4 systems I have both rvinum and
vinum/r* in my /dev directory.

One solution is for vinum to create symlinks /dev/vinum/rplex ->
/dev/rvinum/plex, to help dump find the raw device from the fstab
entry. That's what I'm doing manually now to get my filesystems
dumped. This should probably be handled by vinum somehow?

/Palle


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 10: 2:27 2000
Delivered-To: freebsd-current@freebsd.org
Received: from user1.bind.com (user1.bind.com [207.76.173.4])
	by hub.freebsd.org (Postfix) with ESMTP id 9507437BA07
	for <freebsd-current@freebsd.org>; Tue, 21 Mar 2000 10:02:24 -0800 (PST)
	(envelope-from aaronh@bind.com)
Received: from user1.bind.com (aaronh@user1.bind.com [207.76.173.4])
	by user1.bind.com (8.9.3/8.9.3) with ESMTP id NAA02877
	for <freebsd-current@freebsd.org>; Tue, 21 Mar 2000 13:02:12 -0500 (EST)
	(envelope-from aaronh@bind.com)
Date: Tue, 21 Mar 2000 13:02:11 -0500 (EST)
From: Aaron Hughes <aaronh@bind.com>
To: freebsd-current@freebsd.org
Subject: Found problem with pcm
Message-ID: <Pine.BSF.4.21.0003211259330.598-100000@user1.bind.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


pcm0: <AudioPCI ES1371> port 0xef00-0xef3f irq 7 at device 16.0 on pci0

When running esd, works for 10-15 minutes, and then system complely
freezes, no errors, no core.

I can reproduce this if more info is needed.


- Aaron Hughes 
- aaronh@bind.com
- For public PGP key: finger aaronh@bind.com 
- Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8





To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 10: 6:21 2000
Delivered-To: freebsd-current@freebsd.org
Received: from elbas.partitur.se (elbas.partitur.se [193.219.246.222])
	by hub.freebsd.org (Postfix) with ESMTP id EC67537BA2F
	for <freebsd-current@freebsd.org>; Tue, 21 Mar 2000 10:06:14 -0800 (PST)
	(envelope-from girgen@partitur.se)
Received: from partitur.se (localhost [127.0.0.1])
	by elbas.partitur.se (8.9.3/8.9.3) with ESMTP id TAA04091;
	Tue, 21 Mar 2000 19:06:12 +0100 (CET)
	(envelope-from girgen@partitur.se)
Message-ID: <38D7BA13.83F2913@partitur.se>
Date: Tue, 21 Mar 2000 19:06:11 +0100
From: Palle Girgensohn <girgen@partitur.se>
Organization: Partitur
X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-STABLE i386)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: freebsd-current@freebsd.org
Subject: Re: can't dump vinum volumes after upgrading
References: <38D77DC7.7F161FCB@partitur.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

This fixes it for me. Is my installation faulty, or is this
something that vinum fails to do when creating its devices?

#! /bin/sh
cd /dev/vinum
for i in ../rvinum/*; do ln -s $i r`basename $i`; done


/Palle


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 10:32:32 2000
Delivered-To: freebsd-current@freebsd.org
Received: from server.baldwin.cx (jobaldwi.campus.vt.edu [198.82.67.146])
	by hub.freebsd.org (Postfix) with ESMTP
	id AD43A37BCF1; Tue, 21 Mar 2000 10:32:28 -0800 (PST)
	(envelope-from jhb@FreeBSD.org)
Received: from john.baldwin.cx (john [10.0.0.2])
	by server.baldwin.cx (8.9.3/8.9.3) with ESMTP id NAA05075;
	Tue, 21 Mar 2000 13:32:19 -0500 (EST)
	(envelope-from jhb@FreeBSD.org)
Message-Id: <200003211832.NAA05075@server.baldwin.cx>
X-Mailer: XFMail 1.4.0 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <20000321171955.R93580@caerdonn.eurocontrol.fr>
Date: Tue, 21 Mar 2000 13:32:19 -0500 (EST)
From: John Baldwin <jhb@FreeBSD.org>
To: Ollivier Robert <roberto@eurocontrol.fr>, dcs@FreeBSD.org
Subject: RE: /boot/loader is making my VAIO reboot
Cc: "FreeBSD Current Users' list" <freebsd-current@FreeBSD.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


On 21-Mar-00 Ollivier Robert wrote:
> Since after the Feb. 25th, /boot/loader is rebooting the machine during
> boot. I can't get to the prompt at all. The only version that works is the
> 25th one (I didn't upgrade between the Feb. 25th and March, 17th).

The only changes in sys/boot in that time period are the loader bcache
fixes.  Can you see how far into the loader it is getting?  Also, what
is in your /boot/loader.rc.  Try booting with an empty loader.rc and see
if you can get a prompt, please.

> Nothing in the BIOS configuration changed during that period...
> 
> -r-xr-xr-x  1 root  wheel  143360 Mar 21 16:39 loader           REBOOTS
> -r-xr-xr-x  2 root  wheel  143360 Feb 25 20:03 loader.old       WORKS
> 
> This is on my VAIO laptop (Z505SX, PII/366, 128 MB).
> 
> Any idea ?
> -- 
> Ollivier ROBERT -=- Eurocontrol EEC/TEC -=- Ollivier.Robert@eurocontrol.fr
> The Postman hits! The Postman hits! You have new mail.

-- 

John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 10:54: 4 2000
Delivered-To: freebsd-current@freebsd.org
Received: from nimitz.ca.sandia.gov (nimitz.ca.sandia.gov [146.246.243.56])
	by hub.freebsd.org (Postfix) with ESMTP id 7E59837BA3C
	for <current@FreeBSD.ORG>; Tue, 21 Mar 2000 10:53:58 -0800 (PST)
	(envelope-from bmah@nimitz.ca.sandia.gov)
Received: (from bmah@localhost)
	by nimitz.ca.sandia.gov (8.10.0/8.10.0) id e2LIrUg87051;
	Tue, 21 Mar 2000 10:53:30 -0800 (PST)
	(envelope-from bmah)
Message-Id: <200003211853.e2LIrUg87051@nimitz.ca.sandia.gov>
X-Mailer: exmh version 2.1.1-cvs 10/15/1999
To: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>
Cc: bde@zeta.org.au, nnd@mail.nsk.ru, current@FreeBSD.ORG
Subject: Re: 'machine/param.h' required for 'sys/socket.h' 
In-Reply-To: <20000322024911Q.shin@nd.net.fujitsu.co.jp> 
References: <20000322013459L.shin@nd.net.fujitsu.co.jp> <Pine.BSF.4.21.0003220428230.4710-100000@alphplex.bde.org> <20000322024911Q.shin@nd.net.fujitsu.co.jp>
Comments: In-reply-to Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>
   message dated "Wed, 22 Mar 2000 02:49:11 +0900."
From: bmah@CA.Sandia.GOV (Bruce A. Mah)
Reply-To: bmah@CA.Sandia.GOV
X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5<Pi&akO)o^8;[r
 %l(8ZHlbF`dD>v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A
 2V%N&+
X-Url: http://www.ca.sandia.gov/~bmah/
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_789141986P";
	 micalg=pgp-sha1; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Tue, 21 Mar 2000 10:53:30 -0800
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

--==_Exmh_789141986P
Content-Type: text/plain; charset=us-ascii

If memory serves me right, Yoshinobu Inoue wrote:
> > > I feel requesting inclusion of machine/param.h for any apps
> > > which use socket is better. But if there are any other smarter
> > > solution, please let me know and I'll appreciate it much.
> > 
> > <machine/param.h> should never be included by applications since
> > it is an implementation detail.
> > 
> > Specify including <sys/param.h> in apps which use the CMSG*() macros.
> > <sys/socket.h> doesn't depend on <*/param.h> unless these macros are used.
> > Since these macros are undocumented, applications that use them should
> > expect problems :-).
> > 
> > Bruce
> 
> After reading bmah's message, now I am inclined to including
> machine/param.h from sys/socket.h for maximum portability, if
> there is no spec for it, and if all other platforms doing it.

Arrgh.  Now it seems I might need to reverse my position.  I looked
through some code fragments in UNIX Network Programming (Volume 1,
Second Edition, pp. 362-365), and there's some precedent for needing
<sys/param.h> with the CMSG*() macros.

On the other hand, RFC 2292 and draft-ietf-ipngwg-rfc2292bis (the
references I was originally working from) don't mention this requirement
at all; they just say that CMSG*() are defined with <sys/socket.h>.  I'm
slightly confused by now.

I'm going to send off a note to the authors of 
draft-ietf-ipngwg-rfc229bis asking for some clarification.  In the 
meantime, maybe we should hold off on doing any changes.

Bruce.



--==_Exmh_789141986P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: 8v9hQWl8rwWL3H+0/R4zKr2stejjn8GI

iQA/AwUBONfFKdjKMXFboFLDEQIF8wCgqspEwzh/iJt8yOjlp7OO3nNtguYAoJNy
PxqIQxugikuNZkB7sJ3YBnUC
=5SBz
-----END PGP SIGNATURE-----

--==_Exmh_789141986P--


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 11: 0:40 2000
Delivered-To: freebsd-current@freebsd.org
Received: from yana.lemis.com (yana.lemis.com [192.109.197.140])
	by hub.freebsd.org (Postfix) with ESMTP id 7416737BD01
	for <freebsd-current@FreeBSD.ORG>; Tue, 21 Mar 2000 11:00:35 -0800 (PST)
	(envelope-from grog@mojave.worldwide.lemis.com)
Received: from mojave.worldwide.lemis.com ([216.88.157.130])
	by yana.lemis.com (8.8.8/8.8.8) with ESMTP id FAA14338;
	Wed, 22 Mar 2000 05:30:29 +1030 (CST)
	(envelope-from grog@mojave.worldwide.lemis.com)
Received: (from grog@localhost)
	by mojave.worldwide.lemis.com (8.9.3/8.9.3) id LAA01937;
	Tue, 21 Mar 2000 11:00:24 -0800 (PST)
	(envelope-from grog)
Date: Tue, 21 Mar 2000 11:00:24 -0800
From: Greg Lehey <grog@lemis.com>
To: Palle Girgensohn <girgen@partitur.se>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: can't dump vinum volumes after upgrading
Message-ID: <20000321110023.E1731@mojave.worldwide.lemis.com>
Reply-To: Greg Lehey <grog@lemis.com>
References: <38D77DC7.7F161FCB@partitur.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <38D77DC7.7F161FCB@partitur.se>; from girgen@partitur.se on Tue, Mar 21, 2000 at 02:48:55PM +0100
WWW-Home-Page: http://www.lemis.com/~grog
X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF  13 24 52 F8 6D A4 95 EF
Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8286
Fax: +61-8-8388-8725
Mobile: +61-41-739-7062
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Tuesday, 21 March 2000 at 14:48:55 +0100, Palle Girgensohn wrote:
> Hi!
>
> I'm having a strange problem after upgrading: There are no raw
> devices created for vinum volumes.

Indeed there are.  You list them below.  There are no longer any block
devices.

> This makes dump(8) puke.
>
> This is a 3.4 system:
>
> ls -laF /dev/vinum
> ...
> crwxr-xr--  1 root  wheel   91,   1  2 Jul  1999 rusr*
> drwxr-xr-x  2 root  wheel       512  2 Jul  1999 rvol/
> ...
> brwxr-xr--  1 root  wheel   25,   1  2 Jul  1999 usr*

This was a block device.

> drwxr-xr-x  4 root  wheel       512  2 Jul  1999 vol/
> ...
>
> and here's a 4.0:
>
> crw-r-----   1 root  wheel   91,   0 21 Mar 13:40 usr

This is now a character device.

> drwxr-xr-x  11 root  wheel       512 21 Mar 13:40 vol/
>
> vinum makedev doesn't help. what gives?

You don't describe what dump has to say.  I know that they put in a
fix recently, but you don't say how old your system is.

Greg
--
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 11:39:41 2000
Delivered-To: freebsd-current@freebsd.org
Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12])
	by hub.freebsd.org (Postfix) with ESMTP id 4013A37C0E7
	for <current@freebsd.org>; Tue, 21 Mar 2000 11:39:34 -0800 (PST)
	(envelope-from wilko@yedi.iaf.nl)
Received: from yedi.iaf.nl (uucp@localhost)
	  by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id UAA05057;
	  Tue, 21 Mar 2000 20:25:40 +0100 (MET)
Received: (from wilko@localhost)
	by yedi.iaf.nl (8.9.3/8.9.3) id UAA01311;
	Tue, 21 Mar 2000 20:04:38 +0100 (CET)
	(envelope-from wilko)
Date: Tue, 21 Mar 2000 20:04:38 +0100
From: Wilko Bulte <wilko@yedi.iaf.nl>
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>,
	Alfred Perlstein <bright@wintelcom.net>, current@freebsd.org
Subject: Re: patches for test / review
Message-ID: <20000321200438.F966@yedi.iaf.nl>
Reply-To: wilko@freebsd.org
References: <20000320111544.A14789@fw.wintelcom.net> <20102.953580112@critter.freebsd.dk> <20000321000435.A8143@yedi.iaf.nl> <200003211729.JAA81170@apollo.backplane.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200003211729.JAA81170@apollo.backplane.com>; from dillon@apollo.backplane.com on Tue, Mar 21, 2000 at 09:29:56AM -0800
X-OS: FreeBSD 3.4-STABLE
X-PGP: finger wilko@freebsd.org
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Tue, Mar 21, 2000 at 09:29:56AM -0800, Matthew Dillon wrote:
> :> 
> :> I would think that track-caches and intelligent drives would gain
> :> much if not more of what clustering was designed to do gain.
> :
> :Hm. But I'd think that even with modern drives a smaller number of bigger
> :I/Os is preferable over lots of very small I/Os. Or have I missed the point?

>     As long as you do not blow away the drive's cache with your big I/O's,
>     and as long as you actually use all the returned data, it's definitely 
>     more efficient to issue larger I/O's.

Prefetching data that is never used is obviously a waste. 256K might be a
bit big, I was thinking of something like 64-128Kb 

Drive caches tend to be 0.5-1Mbyte (on SCSI disks) for modern drives. 

I happen to hate write-caching on disk drives so I did not consider that as
a factor.

>     If you generate requests that are too large - say over 1/4 the size of
>     the drive's cache, the drive will not be able to optimize parallel 
>     requests as well.

True.

-- 
Wilko Bulte 			Arnhem, The Netherlands	  
http://www.tcja.nl  		The FreeBSD Project: http://www.freebsd.org


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 11:40:29 2000
Delivered-To: freebsd-current@freebsd.org
Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12])
	by hub.freebsd.org (Postfix) with ESMTP
	id 01C0337C175; Tue, 21 Mar 2000 11:40:03 -0800 (PST)
	(envelope-from wilko@yedi.iaf.nl)
Received: from yedi.iaf.nl (uucp@localhost)
	  by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id UAA05067;
	  Tue, 21 Mar 2000 20:26:05 +0100 (MET)
Received: (from wilko@localhost)
	by yedi.iaf.nl (8.9.3/8.9.3) id TAA01185;
	Tue, 21 Mar 2000 19:53:24 +0100 (CET)
	(envelope-from wilko)
Date: Tue, 21 Mar 2000 19:53:24 +0100
From: Wilko Bulte <wilko@yedi.iaf.nl>
To: Matthew Jacob <mjacob@feral.com>
Cc: wilko@freebsd.org, Poul-Henning Kamp <phk@critter.freebsd.dk>,
	Alfred Perlstein <bright@wintelcom.net>,
	Matthew Dillon <dillon@apollo.backplane.com>, current@freebsd.org
Subject: Re: patches for test / review
Message-ID: <20000321195324.D966@yedi.iaf.nl>
Reply-To: wilko@freebsd.org
References: <20000321000435.A8143@yedi.iaf.nl> <Pine.BSF.4.10.10003202353460.8524-100000@beppo.feral.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <Pine.BSF.4.10.10003202353460.8524-100000@beppo.feral.com>; from mjacob@feral.com on Mon, Mar 20, 2000 at 11:54:58PM -0800
X-OS: FreeBSD 3.4-STABLE
X-PGP: finger wilko@freebsd.org
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Mon, Mar 20, 2000 at 11:54:58PM -0800, Matthew Jacob wrote:
> > 
> > Hm. But I'd think that even with modern drives a smaller number of bigger
> > I/Os is preferable over lots of very small I/Os.
> 
> Not necessarily. It depends upon overhead costs per-i/o. With larger I/Os, you
> do pay in interference costs (you can't transfer data for request N because
> the 256Kbytes of request M is still in the pipe).

OK. 256K might be a bit on the high side. 

-- 
Wilko Bulte 			Arnhem, The Netherlands	  
http://www.tcja.nl  		The FreeBSD Project: http://www.freebsd.org


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 11:59:50 2000
Delivered-To: freebsd-current@freebsd.org
Received: from trinity.skynet.be (trinity.skynet.be [195.238.2.38])
	by hub.freebsd.org (Postfix) with ESMTP id 39F8A37C1A9
	for <freebsd-current@freebsd.org>; Tue, 21 Mar 2000 11:59:40 -0800 (PST)
	(envelope-from blk@skynet.be)
Received: from [195.238.1.121] (brad.techos.skynet.be [195.238.1.121])
	by trinity.skynet.be (Postfix) with ESMTP
	id 7AE4D182CB; Tue, 21 Mar 2000 20:57:06 +0100 (MET)
Mime-Version: 1.0
X-Sender: blk@pop.skynet.be
Message-Id: <v0422082cb4fd812c0511@[195.238.1.121]>
Date: Tue, 21 Mar 2000 20:53:24 +0100
To: Greg Lehey <grog@lemis.com>
From: Brad Knowles <blk@skynet.be>
Subject: Problems with vinum and/or rawio?
Cc: FreeBSD-CURRENT Mailing List <freebsd-current@freebsd.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Greg,

	Running 4.0-STABLE (cvsup'ed a couple of days ago), I'm having a 
problem with a vinum striped volume that I've set up.  The machine is 
a dual-CPU Pentium III/450 (Dell 1300) with 1GB of RAM and 512KB L2 
cache per processor, on an IBM DDRS-39130D DC2 8GB hard drive.

	The external drive array is a Comparex D1400 (Hitachi DF400), 
with four separate logical units (one for each row of disks), and two 
logical units exported exclusively through one interface on one 
controller, which is attached exclusively to one Adaptec 2940U2W host 
adaptor.  The IBM drive with the OS, etc... is attached to the 
on-board Adaptec AIC-7980 controller chip.


	The command I had run was:

		rawio -c 128 -p 16 -n 65536 -r -R  /dev/vinum/news

	I got part way through the output being generated, when I started 
getting a lot of errors like this:

Mar 21 20:48:46 audrey /kernel: (da4:ahc1:0:6:0): SCB 0x20 - timed 
out in Data-in phase, SEQADDR == 0x5d
Mar 21 20:48:46 audrey /kernel: (da4:ahc1:0:6:0): SCB 0x20 - timed 
out in Data-in phase, SEQADDR == 0x5d
Mar 21 20:48:46 audrey /kernel: (da4:ahc1:0:6:0): BDR message in message buffer
Mar 21 20:48:46 audrey /kernel: (da4:ahc1:0:6:0): BDR message in message buffer
Mar 21 20:48:48 audrey /kernel: (da4:ahc1:0:6:0): SCB 0x20 - timed 
out in Data-in phase, SEQADDR == 0x5d
Mar 21 20:48:48 audrey /kernel: (da4:ahc1:0:6:0): SCB 0x20 - timed 
out in Data-in phase, SEQADDR == 0x5d
Mar 21 20:48:48 audrey /kernel: (da4:ahc1:0:6:0): no longer in 
timeout, status = 34b
Mar 21 20:48:48 audrey /kernel: (da4:ahc1:0:6:0): no longer in 
timeout, status = 34b
Mar 21 20:48:48 audrey /kernel: ahc1: Issued Channel A Bus Reset. 11 
SCBs aborted
Mar 21 20:48:48 audrey /kernel: ahc1: Issued Channel A Bus Reset. 11 
SCBs aborted

	Once this happened, all of the rawio processes were in "physst", 
but the system had 100% idle time.


	Do you need to see my kernel configuration?  Beyond the vinum 
configuration and the output of dmesg, is there any other 
configuration details you need?


	Thanks!




	My /etc/vinum.conf:

		drive d1 device /dev/da2s1e
		drive d2 device /dev/da3s1e
		drive d3 device /dev/da4s1e
		drive d4 device /dev/da5s1e
		volume news
         	plex org striped 512k
             	    sd length 0 drive d1
                 	sd length 0 drive d2
                 	sd length 0 drive d3
                 	sd length 0 drive d4

	dmesg:

$ dmesg
Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
         The Regents of the University of California. All rights reserved.
FreeBSD 4.0-STABLE #0: Mon Mar 20 21:06:56 CET 2000
     root@audrey.skynet.be:/usr/src/sys/compile/AUDREY
Timecounter "i8254"  frequency 1193182 Hz
CPU: Pentium III/Pentium III Xeon (448.62-MHz 686-class CPU)
   Origin = "GenuineIntel"  Id = 0x673  Stepping = 3
 
Features=0x383fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PG 
E,MCA,CMOV,PAT,PSE36,MMX,FXSR,XMM>
real memory  = 1073741824 (1048576K bytes)
config> di sn0
No such device: sn0
Invalid command or syntax.  Type `?' for help.
config> di lnc0
No such device: lnc0
Invalid command or syntax.  Type `?' for help.
config> di le0
No such device: le0
Invalid command or syntax.  Type `?' for help.
config> di ie0
No such device: ie0
Invalid command or syntax.  Type `?' for help.
config> di fe0
No such device: fe0
Invalid command or syntax.  Type `?' for help.
config> di ed0
No such device: ed0
Invalid command or syntax.  Type `?' for help.
config> di cs0
No such device: cs0
Invalid command or syntax.  Type `?' for help.
config> q
avail memory = 1038483456 (1014144K bytes)
Programming 24 pins in IOAPIC #0
IOAPIC #0 intpin 2 -> irq 0
FreeBSD/SMP: Multiprocessor motherboard
  cpu0 (BSP): apic id:  1, version: 0x00040011, at 0xfee00000
  cpu1 (AP):  apic id:  0, version: 0x00040011, at 0xfee00000
  io0 (APIC): apic id:  2, version: 0x00170011, at 0xfec00000
Preloaded elf kernel "kernel" at 0xc0399000.
Preloaded userconfig_script "/boot/kernel.conf" at 0xc039909c.
ccd0-3: Concatenated disk drivers
Pentium Pro MTRR support enabled
md1: Malloc disk
npx0: <math processor> on motherboard
npx0: INT 16 interface
pcib0: <Intel 82443BX (440 BX) host to PCI bridge> on motherboard
pci0: <PCI bus> on pcib0
pcib1: <Intel 82443BX (440 BX) PCI-PCI (AGP) bridge> at device 1.0 on pci0
pci1: <PCI bus> on pcib1
pci1: <ATI Mach64-GW graphics accelerator> at 0.0
pcib2: <DEC 21152 PCI-PCI bridge> at device 2.0 on pci0
pci2: <PCI bus> on pcib2
ahc0: <Adaptec 2940 Ultra2 SCSI adapter> port 0xdc00-0xdcff mem 
0xf9fff000-0xf9ffffff irq 21 at device 9.0 on pci2
ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs
ahc1: <Adaptec 2940 Ultra2 SCSI adapter> port 0xd800-0xd8ff mem 
0xf9ffe000-0xf9ffefff irq 22 at device 10.0 on pci2
ahc1: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs
ahc2: <Adaptec aic7890/91 Ultra2 SCSI adapter> port 0xd400-0xd4ff mem 
0xf9ffd000-0xf9ffdfff irq 16 at device 11.0 on pci2
ahc2: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs
isab0: <Intel 82371AB PCI to ISA bridge> at device 7.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel PIIX4 ATA33 controller> port 0xffa0-0xffaf at device 
7.1 on pci0
ata1: at 0x170 irq 15 on atapci0
pci0: <Intel 82371AB/EB (PIIX4) USB controller> at 7.2 irq 19
Timecounter "PIIX"  frequency 3579545 Hz
intpm0: <Intel 82371AB Power management controller> port 0x850-0x85f 
irq 9 at device 7.3 on pci0
intpm0: I/O mapped 850
intpm0: intr IRQ 9 enabled revision 0
smbus0: <System Management Bus> on intsmb0
smb0: <SMBus general purpose I/O> on smbus0
intpm0: PM I/O mapped 800
fxp0: <Intel EtherExpress Pro 10/100B Ethernet> port 0xccc0-0xccdf 
mem 0xfe000000-0xfe0fffff,0xf7000000-0xf7000fff irq 19 at device 16.0 
on pci0
fxp0: Ethernet address 00:90:27:99:13:1a
fxp0: supplying EUI64: 00:90:27:ff:fe:99:13:1a
vt0 on isa0
vt0: generic, 80 col, color, 9 scr, unknown kbd, [R3.20-b24]
vt0: driver is using old-style compatability shims
atkbdc0: <keyboard controller (i8042)> at port 0x60-0x6f on isa0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
vga0: <Generic ISA VGA> at port 0x3b0-0x3df iomem 0xa0000-0xbffff on isa0
sc0: <System console> on isa0
sc0: VGA <16 virtual consoles, flags=0x200>
fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A esp_port has com 3
  esp_port has com 3
  esp_port has com 3

pcf0: <PCF8584 I2C bus controller> at port 0x320-0x321 irq 5 on isa0
iicbus0: <Philips I2C bus> on pcf0 addr 0xaa
iicsmb0: <I2C to SMB bridge> on iicbus0
smbus1: <System Management Bus> on iicsmb0
smb1: <SMBus general purpose I/O> on smbus1
iic0: <I2C general purpose I/O> on iicbus0
ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/8 bytes threshold
APIC_IO: Testing 8254 interrupt delivery
APIC_IO: routing 8254 via IOAPIC #0 intpin 2
IP packet filtering initialized, divert enabled, rule-based 
forwarding enabled, default to accept, logging limited to 100 
packets/entry by default
DUMMYNET initialized (000106)
BRIDGE 990810, have 9 interfaces
-- index 1  type 6 phy 0 addrl 6 addr 00.90.27.99.13.1a
IPsec: Initialized Security Association Processing.
IPv6 packet filtering initialized, default to accept, logging limited 
to 100 packets/entry
SMP: AP CPU #1 Launched!
Waiting 5 seconds for SCSI devices to settle
da2 at ahc0 bus 0 target 5 lun 0
da2: <HITACHI DF400 0000> Fixed Direct Access SCSI-2 device
da2: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged 
Queueing Enabled
da2: 68235MB (139745280 512 byte sectors: 255H 63S/T 8698C)
da4 at ahc1 bus 0 target 6 lun 0
da4: <HITACHI DF400 0000> Fixed Direct Access SCSI-2 device
da4: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged 
Queueing Enabled
da4: 68235MB (139745280 512 byte sectors: 255H 63S/T 8698C)
da0 at ahc2 bus 0 target 0 lun 0
da0: <QUANTUM ATLAS IV 9 WLS 0707> Fixed Direct Access SCSI-3 device
da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged 
Queueing Enabled
da0: 8683MB (17783249 512 byte sectors: 255H 63S/T 1106C)
da3 at ahc0 bus 0 target 5 lun 1
da3: <HITACHI DF400 0000> Fixed Direct Access SCSI-2 device
da3: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged 
Queueing Enabled
da3: 68235MB (139745280 512 byte sectors: 255H 63S/T 8698C)
da5 at ahc1 bus 0 target 6 lun 1
da5: <HITACHI DF400 0000> Fixed Direct Access SCSI-2 device
da5: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged 
Queueing Enabled
da5: 68235MB (139745280 512 byte sectors: 255H 63S/T 8698C)
Mounting root from ufs:/dev/da1s1a
da1 at ahc2 bus 0 target 1 lun 0
da1: <IBM DDRS-39130D DC2A> Fixed Direct Access SCSI-2 device
da1: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged 
Queueing Enabled
da1: 8715MB (17850000 512 byte sectors: 255H 63S/T 1111C)
fxp0: starting DAD for fe80:0001::0290:27ff:fe99:131a
fxp0: DAD complete for fe80:0001::0290:27ff:fe99:131a - no duplicates found
vinum: loaded
vinum: drive d1 is up
vinum: drive d2 is up
vinum: drive d3 is up
vinum: drive d4 is up
vinum: removing 1840 blocks of partial stripe at the end of news.p0
vinum: news.p0.s0 is up
vinum: news.p0.s1 is up
vinum: news.p0.s2 is up
vinum: news.p0.s3 is up
vinum: news.p0 is up
vinum: news is up
(da4:ahc1:0:6:0): SCB 0x36 - timed out in Data-in phase, SEQADDR == 0x5e
(da4:ahc1:0:6:0): BDR message in message buffer
(da4:ahc1:0:6:0): SCB 0x36 - timed out in Data-in phase, SEQADDR == 0x5e
(da4:ahc1:0:6:0): no longer in timeout, status = 34b
ahc1: Issued Channel A Bus Reset. 16 SCBs aborted
(da4:ahc1:0:6:0): SCB 0x36 - timed out in Data-in phase, SEQADDR == 0x5d
(da4:ahc1:0:6:0): BDR message in message buffer
(da4:ahc1:0:6:0): SCB 0x36 - timed out in Data-in phase, SEQADDR == 0x5e
(da4:ahc1:0:6:0): no longer in timeout, status = 34b
ahc1: Issued Channel A Bus Reset. 16 SCBs aborted
(da4:ahc1:0:6:0): SCB 0x36 - timed out in Data-in phase, SEQADDR == 0x5d
(da4:ahc1:0:6:0): BDR message in message buffer
(da4:ahc1:0:6:0): SCB 0x36 - timed out in Data-in phase, SEQADDR == 0x5d
(da4:ahc1:0:6:0): no longer in timeout, status = 34b
ahc1: Issued Channel A Bus Reset. 16 SCBs aborted
(da4:ahc1:0:6:0): SCB 0x36 - timed out in Data-in phase, SEQADDR == 0x5e
(da4:ahc1:0:6:0): BDR message in message buffer
(da4:ahc1:0:6:0): SCB 0x36 - timed out in Data-in phase, SEQADDR == 0x5d
(da4:ahc1:0:6:0): no longer in timeout, status = 34b
ahc1: Issued Channel A Bus Reset. 16 SCBs aborted
(da4:ahc1:0:6:0): SCB 0x36 - timed out in Data-in phase, SEQADDR == 0x5e
(da4:ahc1:0:6:0): BDR message in message buffer
(da4:ahc1:0:6:0): SCB 0x36 - timed out in Data-in phase, SEQADDR == 0x5e
(da4:ahc1:0:6:0): no longer in timeout, status = 34b
ahc1: Issued Channel A Bus Reset. 16 SCBs aborted
news.p0.s2: fatal read I/O error
vinum: news.p0.s2 is crashed by force
vinum: news.p0 is corrupt
(da4:ahc1:0:6:0): SCB 0x29 - timed out in Data-in phase, SEQADDR == 0x5e
(da4:ahc1:0:6:0): BDR message in message buffer
(da4:ahc1:0:6:0): SCB 0x29 - timed out in Data-in phase, SEQADDR == 0x5d
(da4:ahc1:0:6:0): no longer in timeout, status = 34b
ahc1: Issued Channel A Bus Reset. 15 SCBs aborted
(da4:ahc1:0:6:0): SCB 0x29 - timed out in Data-in phase, SEQADDR == 0x5d
(da4:ahc1:0:6:0): BDR message in message buffer
(da4:ahc1:0:6:0): SCB 0x29 - timed out in Data-in phase, SEQADDR == 0x5d
(da4:ahc1:0:6:0): no longer in timeout, status = 34b
ahc1: Issued Channel A Bus Reset. 15 SCBs aborted
(da4:ahc1:0:6:0): SCB 0x29 - timed out in Data-in phase, SEQADDR == 0x5d
(da4:ahc1:0:6:0): BDR message in message buffer
(da4:ahc1:0:6:0): SCB 0x29 - timed out in Data-in phase, SEQADDR == 0x5e
(da4:ahc1:0:6:0): no longer in timeout, status = 34b
ahc1: Issued Channel A Bus Reset. 15 SCBs aborted
(da4:ahc1:0:6:0): SCB 0x29 - timed out in Data-in phase, SEQADDR == 0x5e
(da4:ahc1:0:6:0): BDR message in message buffer
(da4:ahc1:0:6:0): SCB 0x29 - timed out in Data-in phase, SEQADDR == 0x5d
(da4:ahc1:0:6:0): no longer in timeout, status = 34b
ahc1: Issued Channel A Bus Reset. 15 SCBs aborted
(da4:ahc1:0:6:0): SCB 0x29 - timed out in Data-in phase, SEQADDR == 0x5d
(da4:ahc1:0:6:0): BDR message in message buffer
(da4:ahc1:0:6:0): SCB 0x29 - timed out in Data-in phase, SEQADDR == 0x5d
(da4:ahc1:0:6:0): no longer in timeout, status = 34b
ahc1: Issued Channel A Bus Reset. 15 SCBs aborted
news.p0.s2: fatal read I/O error
(da4:ahc1:0:6:0): SCB 0x16 - timed out in Data-in phase, SEQADDR == 0x5e
(da4:ahc1:0:6:0): BDR message in message buffer
(da4:ahc1:0:6:0): SCB 0x16 - timed out in Data-in phase, SEQADDR == 0x5e
(da4:ahc1:0:6:0): no longer in timeout, status = 34b
ahc1: Issued Channel A Bus Reset. 13 SCBs aborted
(da4:ahc1:0:6:0): SCB 0x16 - timed out in Data-in phase, SEQADDR == 0x5e
(da4:ahc1:0:6:0): BDR message in message buffer
(da4:ahc1:0:6:0): SCB 0x16 - timed out in Data-in phase, SEQADDR == 0x5d
(da4:ahc1:0:6:0): no longer in timeout, status = 34b
ahc1: Issued Channel A Bus Reset. 13 SCBs aborted
(da4:ahc1:0:6:0): SCB 0x16 - timed out in Data-in phase, SEQADDR == 0x5e
(da4:ahc1:0:6:0): BDR message in message buffer
(da4:ahc1:0:6:0): SCB 0x16 - timed out in Data-in phase, SEQADDR == 0x5d
(da4:ahc1:0:6:0): no longer in timeout, status = 34b
ahc1: Issued Channel A Bus Reset. 13 SCBs aborted
(da4:ahc1:0:6:0): SCB 0x16 - timed out in Data-in phase, SEQADDR == 0x5d
(da4:ahc1:0:6:0): BDR message in message buffer
(da4:ahc1:0:6:0): SCB 0x16 - timed out in Data-in phase, SEQADDR == 0x5e
(da4:ahc1:0:6:0): no longer in timeout, status = 34b
ahc1: Issued Channel A Bus Reset. 13 SCBs aborted
(da4:ahc1:0:6:0): SCB 0x16 - timed out in Data-in phase, SEQADDR == 0x5e
(da4:ahc1:0:6:0): BDR message in message buffer
(da4:ahc1:0:6:0): SCB 0x16 - timed out in Data-in phase, SEQADDR == 0x5d
(da4:ahc1:0:6:0): no longer in timeout, status = 34b
ahc1: Issued Channel A Bus Reset. 13 SCBs aborted
news.p0.s2: fatal read I/O error
(da4:ahc1:0:6:0): SCB 0x20 - timed out in Data-in phase, SEQADDR == 0x5d
(da4:ahc1:0:6:0): BDR message in message buffer
(da4:ahc1:0:6:0): SCB 0x20 - timed out in Data-in phase, SEQADDR == 0x5d
(da4:ahc1:0:6:0): no longer in timeout, status = 34b
ahc1: Issued Channel A Bus Reset. 11 SCBs aborted

--
   These are my opinions -- not to be taken as official Skynet policy
======================================================================
Brad Knowles, <blk@skynet.be>                || 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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 12:10:39 2000
Delivered-To: freebsd-current@freebsd.org
Received: from morpheus.skynet.be (morpheus.skynet.be [195.238.2.39])
	by hub.freebsd.org (Postfix) with ESMTP id 97F7C37BC83
	for <freebsd-current@FreeBSD.ORG>; Tue, 21 Mar 2000 12:10:36 -0800 (PST)
	(envelope-from blk@skynet.be)
Received: from [195.238.1.121] (brad.techos.skynet.be [195.238.1.121])
	by morpheus.skynet.be (Postfix) with ESMTP
	id 7E36BF23A; Tue, 21 Mar 2000 21:08:41 +0100 (MET)
Mime-Version: 1.0
X-Sender: blk@pop.skynet.be
Message-Id: <v0422082fb4fd861f307e@[195.238.1.121]>
In-Reply-To: <38D7B882.58B9A036@partitur.se>
References: <38D77DC7.7F161FCB@partitur.se>
 <38D7B882.58B9A036@partitur.se>
Date: Tue, 21 Mar 2000 21:04:05 +0100
To: Palle Girgensohn <girgen@partitur.se>,
	freebsd-current@FreeBSD.ORG
From: Brad Knowles <blk@skynet.be>
Subject: Re: can't dump vinum volumes after upgrading
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

At 6:59 PM +0100 2000/3/21, Palle Girgensohn wrote:

>  I did some rtfm and src digging, it appears the listing I gave is
>  correct; the raw devices are in the rvinum dircetory.

	How did you get an /dev/rvinum?  I don't have one....

--
   These are my opinions -- not to be taken as official Skynet policy
======================================================================
Brad Knowles, <blk@skynet.be>                || 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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 12:14:34 2000
Delivered-To: freebsd-current@freebsd.org
Received: from gvr.gvr.org (gvr.gvr.org [194.151.74.97])
	by hub.freebsd.org (Postfix) with ESMTP id 40C4A37BDDA
	for <freebsd-current@freebsd.org>; Tue, 21 Mar 2000 12:14:32 -0800 (PST)
	(envelope-from guido@gvr.org)
Received: by gvr.gvr.org (Postfix, from userid 657)
	id CB2B8A85C; Tue, 21 Mar 2000 21:14:30 +0100 (CET)
Date: Tue, 21 Mar 2000 21:14:30 +0100
From: Guido van Rooij <guido@gvr.org>
To: freebsd-current@freebsd.org
Subject: problem with reboot on 5.0-current with VAIO
Message-ID: <20000321211430.A65060@gvr.gvr.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.6i
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

When I use reboot(8) to reboot my Vaio z505sx, it waits nicely for
the bufdaeon and the syncer to stop. Then the screen goes blank
and the system completely hangs. Unplugging the battery and power
is the only way to gte it booting again. It used to work fine with a 
4.0-current of some 3 weeks ago but a 5.0-current from today gives the above
result. 
Does anyone have a clue?

-Guido


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 12:17:48 2000
Delivered-To: freebsd-current@freebsd.org
Received: from neodymium.btinternet.com (neodymium.btinternet.com [194.73.73.83])
	by hub.freebsd.org (Postfix) with ESMTP
	id 793B137BD57; Tue, 21 Mar 2000 12:17:42 -0800 (PST)
	(envelope-from mark@ukug.uk.freebsd.org)
Received: from [213.1.141.242] (helo=parish.my.domain)
	by neodymium.btinternet.com with esmtp (Exim 2.05 #1)
	id 12XV5e-0002XH-00; Tue, 21 Mar 2000 20:17:24 +0000
Received: (from mark@localhost)
	by parish.my.domain (8.9.3/8.9.3) id UAA06612;
	Tue, 21 Mar 2000 20:15:29 GMT
	(envelope-from mark)
Date: Tue, 21 Mar 2000 20:15:29 +0000
From: Mark Ovens <mark@ukug.uk.freebsd.org>
To: questions@freebsd.org
Cc: current@freebsd.org
Subject: SCSI errors from xmcd
Message-ID: <20000321201528.A6493@parish>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
Organization: Total lack of
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Since u/g to 4.0 I've had problems with audio CD players and my
Toshiba XM6201 SCSI CD drive, cdcontrol and xmcd. Re-MAKEDEV'ing all
the cd devices has got cdcontrol working but still xmcd (v2.6)
doesn't. It all worked fine under 3.4-STABLE

Starting it with ``-debug'' yields a constant (one every few seconds)
stream  of:

SCSI CDB bytes (dev=/dev/rcd0c rw=0 to=20):
0000    00 00 00 00 00 00 -- --  -- -- -- -- -- -- -- --    ................
CD audio: SCSI command fault on /dev/rcd0c:
Status=0x16

Is this because xmcd needs updating to work with the new CAM system,
or something else?

% uname -a
FreeBSD parish 4.0-STABLE FreeBSD 4.0-STABLE #1: Sat Mar 18 18:53:40 GMT 2000     mark@parish:/usr/src/sys/compile/PARISH  i386

Thanks.

-- 
Seminars, n.:
       From "semi" and "arse", hence, any half-assed discussion.
________________________________________________________________
      FreeBSD - The Power To Serve http://www.freebsd.org
      My Webpage http://ukug.uk.freebsd.org/~mark/
mailto:mark@ukug.uk.freebsd.org             http://www.radan.com



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 12:22:47 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mail-03-real.cdsnet.net (mail-03-real.cdsnet.net [204.118.244.93])
	by hub.freebsd.org (Postfix) with SMTP id CCDD437BEF6
	for <current@freebsd.org>; Tue, 21 Mar 2000 12:22:44 -0800 (PST)
	(envelope-from mrcpu@internetcds.com)
Received: (qmail 54780 invoked from network); 21 Mar 2000 20:22:40 -0000
Received: from schizo.cdsnet.net (204.118.244.32)
  by mail-03-real.cdsnet.net with SMTP; 21 Mar 2000 20:22:39 -0000
Date: Tue, 21 Mar 2000 12:19:07 -0800 (PST)
From: Jaye Mathisen <mrcpu@internetcds.com>
X-Sender: mrcpu@schizo.cdsnet.net
To: current@freebsd.org
Subject: Minor snit in UPDATING.
Message-ID: <Pine.BSF.4.21.0003211218340.10991-100000@schizo.cdsnet.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


19991204:
        The dc interface has replaced al, ax, dm, pn and mx.  The former
        have been removed.

I believe former should be latter.



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 12:23:38 2000
Delivered-To: freebsd-current@freebsd.org
Received: from gvr.gvr.org (gvr.gvr.org [194.151.74.97])
	by hub.freebsd.org (Postfix) with ESMTP id D985C37BDD5
	for <freebsd-current@freebsd.org>; Tue, 21 Mar 2000 12:23:32 -0800 (PST)
	(envelope-from guido@gvr.org)
Received: by gvr.gvr.org (Postfix, from userid 657)
	id B0B27A85C; Tue, 21 Mar 2000 21:23:28 +0100 (CET)
Date: Tue, 21 Mar 2000 21:23:28 +0100
From: Guido van Rooij <guido@gvr.org>
To: freebsd-current@freebsd.org
Subject: Re: problem with reboot on 5.0-current with VAIO
Message-ID: <20000321212328.A65223@gvr.gvr.org>
References: <20000321211430.A65060@gvr.gvr.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.6i
In-Reply-To: <20000321211430.A65060@gvr.gvr.org>; from Guido van Rooij on Tue, Mar 21, 2000 at 09:14:30PM +0100
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Tue, Mar 21, 2000 at 09:14:30PM +0100, Guido van Rooij wrote:
> When I use reboot(8) to reboot my Vaio z505sx, it waits nicely for
> the bufdaeon and the syncer to stop. Then the screen goes blank
> and the system completely hangs. Unplugging the battery and power
> is the only way to gte it booting again. It used to work fine with a 
> 4.0-current of some 3 weeks ago but a 5.0-current from today gives the above
> result. 
> Does anyone have a clue?

This might be a false alarm due to old modules hanging around.

Would it be possible to have some kind of kernel vrsion check when
loading modules and at least issue a warning of some kind if a
module build for 4.0 is loaded in a younger kernel?

-Guido


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 12:25:41 2000
Delivered-To: freebsd-current@freebsd.org
Received: from gvr.gvr.org (gvr.gvr.org [194.151.74.97])
	by hub.freebsd.org (Postfix) with ESMTP id 424E637BD24
	for <freebsd-current@FreeBSD.ORG>; Tue, 21 Mar 2000 12:25:36 -0800 (PST)
	(envelope-from guido@gvr.org)
Received: by gvr.gvr.org (Postfix, from userid 657)
	id 83A36A85A; Tue, 21 Mar 2000 21:25:34 +0100 (CET)
Date: Tue, 21 Mar 2000 21:25:34 +0100
From: Guido van Rooij <guido@gvr.org>
To: Ollivier Robert <roberto@eurocontrol.fr>
Cc: FreeBSD Current Users' list <freebsd-current@FreeBSD.ORG>
Subject: Re: /boot/loader is making my VAIO reboot
Message-ID: <20000321212534.B65223@gvr.gvr.org>
References: <20000321171955.R93580@caerdonn.eurocontrol.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.6i
In-Reply-To: <20000321171955.R93580@caerdonn.eurocontrol.fr>; from Ollivier Robert on Tue, Mar 21, 2000 at 05:19:55PM +0100
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Tue, Mar 21, 2000 at 05:19:55PM +0100, Ollivier Robert wrote:
> Since after the Feb. 25th, /boot/loader is rebooting the machine during
> boot. I can't get to the prompt at all. The only version that works is the
> 25th one (I didn't upgrade between the Feb. 25th and March, 17th).
> 
> Nothing in the BIOS configuration changed during that period...
> 
> -r-xr-xr-x  1 root  wheel  143360 Mar 21 16:39 loader           REBOOTS
> -r-xr-xr-x  2 root  wheel  143360 Feb 25 20:03 loader.old       WORKS
> 
> This is on my VAIO laptop (Z505SX, PII/366, 128 MB).
> 
> Any idea ?

Strange. I have just done a make install with the new loader and it works
for me:
-r-xr-xr-x  1 root  wheel  143360 Mar 21 19:50 loader 

made with todays cvsup. Perhaps you have some non default config files in
there?

-Guido


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 12:54:10 2000
Delivered-To: freebsd-current@freebsd.org
Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169])
	by hub.freebsd.org (Postfix) with ESMTP
	id 35A1F37BAB7; Tue, 21 Mar 2000 12:53:58 -0800 (PST)
	(envelope-from ken@panzer.kdm.org)
Received: (from ken@localhost)
	by panzer.kdm.org (8.9.3/8.9.1) id NAA41375;
	Tue, 21 Mar 2000 13:50:46 -0700 (MST)
	(envelope-from ken)
Date: Tue, 21 Mar 2000 13:50:46 -0700
From: "Kenneth D. Merry" <ken@kdm.org>
To: Mark Ovens <mark@dogma.freebsd-uk.eu.org>
Cc: questions@FreeBSD.ORG, current@FreeBSD.ORG
Subject: Re: SCSI errors from xmcd
Message-ID: <20000321135046.A41348@panzer.kdm.org>
References: <20000321201528.A6493@parish>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <20000321201528.A6493@parish>; from mark@dogma.freebsd-uk.eu.org on Tue, Mar 21, 2000 at 08:15:29PM +0000
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Tue, Mar 21, 2000 at 20:15:29 +0000, Mark Ovens wrote:
> Since u/g to 4.0 I've had problems with audio CD players and my
> Toshiba XM6201 SCSI CD drive, cdcontrol and xmcd. Re-MAKEDEV'ing all
> the cd devices has got cdcontrol working but still xmcd (v2.6)
> doesn't. It all worked fine under 3.4-STABLE
> 
> Starting it with ``-debug'' yields a constant (one every few seconds)
> stream  of:
> 
> SCSI CDB bytes (dev=/dev/rcd0c rw=0 to=20):
> 0000    00 00 00 00 00 00 -- --  -- -- -- -- -- -- -- --    ................
> CD audio: SCSI command fault on /dev/rcd0c:
> Status=0x16
> 
> Is this because xmcd needs updating to work with the new CAM system,
> or something else?

You need to recompile xmcd.

Ken
-- 
Kenneth Merry
ken@kdm.org


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 13: 5:47 2000
Delivered-To: freebsd-current@freebsd.org
Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169])
	by hub.freebsd.org (Postfix) with ESMTP
	id 44E9937BC24; Tue, 21 Mar 2000 13:05:38 -0800 (PST)
	(envelope-from ken@panzer.kdm.org)
Received: (from ken@localhost)
	by panzer.kdm.org (8.9.3/8.9.1) id OAA41537;
	Tue, 21 Mar 2000 14:02:57 -0700 (MST)
	(envelope-from ken)
Date: Tue, 21 Mar 2000 14:02:57 -0700
From: "Kenneth D. Merry" <ken@kdm.org>
To: Mark Ovens <mark@dogma.freebsd-uk.eu.org>
Cc: questions@FreeBSD.ORG, current@FreeBSD.ORG
Subject: Re: SCSI errors from xmcd
Message-ID: <20000321140257.A41481@panzer.kdm.org>
References: <20000321201528.A6493@parish> <20000321135046.A41348@panzer.kdm.org> <20000321205717.C6493@parish>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <20000321205717.C6493@parish>; from mark@dogma.freebsd-uk.eu.org on Tue, Mar 21, 2000 at 08:57:17PM +0000
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Tue, Mar 21, 2000 at 20:57:17 +0000, Mark Ovens wrote:
> On Tue, Mar 21, 2000 at 01:50:46PM -0700, Kenneth D. Merry wrote:
> > On Tue, Mar 21, 2000 at 20:15:29 +0000, Mark Ovens wrote:
> > > Is this because xmcd needs updating to work with the new CAM system,
> > > or something else?
> > 
> > You need to recompile xmcd.
> > 
> 
> In that case I need to wait for the package to be updated. xmcd needs
> Motif, which I don't have, so I use the binary package.

There's an xmcd package for 4.0 here:

ftp://ftp.FreeBSD.ORG/pub/FreeBSD/ports/i386/packages-4.0-release/audio/xmcd-2.6.tgz

What package are you waiting for?

Ken
-- 
Kenneth Merry
ken@kdm.org


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 13: 6: 8 2000
Delivered-To: freebsd-current@freebsd.org
Received: from relay.globe.cz (relay.globe.cz [212.27.196.13])
	by hub.freebsd.org (Postfix) with ESMTP
	id 532E037BECF; Tue, 21 Mar 2000 13:05:49 -0800 (PST)
	(envelope-from m.papezik@post.cz)
Received: (from root@localhost)
	by relay.globe.cz (8.9.3/8.9.3) id WAA04562;
	Tue, 21 Mar 2000 22:05:35 +0100
Date: Tue, 21 Mar 2000 22:05:35 +0100
From: m.papezik@post.cz
Message-Id: <200003212105.WAA04562@relay.globe.cz>
To: freebsd-hardware@freebsd.org, freebsd-current@freebsd.org
Reply-To: m.papezik@post.cz
X-mailer: POST.CZ mailer v1.2
Subject: Supported CardBus controllers?
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

 Hi all,

I saw a few messages about missing CardBus support in current
and I am wondering what is current status?

If someone is activelly working on this
I can try to test things on ThinkPad 600E
(with TI 1251 controller and SMC/Megahertz NIC).

Pehaps the list of PCcard and CardBus controllers used
in ThinkPad systems will help too:

http://www.pc.ibm.com/qtechinfo/YAST-3JZU4X.html?selectarea=SUPPORT&brand=root&x=0&y=4

	Thanks in advance,
	Milon
--
m.papezik@post.cz





To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 13:14:53 2000
Delivered-To: freebsd-current@freebsd.org
Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4])
	by hub.freebsd.org (Postfix) with ESMTP
	id A306E37BD0A; Tue, 21 Mar 2000 13:14:50 -0800 (PST)
	(envelope-from freebsd@gndrsh.dnsmgr.net)
Received: (from freebsd@localhost)
	by gndrsh.dnsmgr.net (8.9.3/8.9.3) id NAA49370;
	Tue, 21 Mar 2000 13:14:46 -0800 (PST)
	(envelope-from freebsd)
From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>
Message-Id: <200003212114.NAA49370@gndrsh.dnsmgr.net>
Subject: Re: patches for test / review
In-Reply-To: <20000321200438.F966@yedi.iaf.nl> from Wilko Bulte at "Mar 21, 2000 08:04:38 pm"
To: wilko@FreeBSD.ORG
Date: Tue, 21 Mar 2000 13:14:45 -0800 (PST)
Cc: dillon@apollo.backplane.com (Matthew Dillon),
	phk@critter.freebsd.dk (Poul-Henning Kamp),
	bright@wintelcom.net (Alfred Perlstein), current@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> On Tue, Mar 21, 2000 at 09:29:56AM -0800, Matthew Dillon wrote:
> > :> 
> > :> I would think that track-caches and intelligent drives would gain
> > :> much if not more of what clustering was designed to do gain.
> > :
> > :Hm. But I'd think that even with modern drives a smaller number of bigger
> > :I/Os is preferable over lots of very small I/Os. Or have I missed the point?
> 
> >     As long as you do not blow away the drive's cache with your big I/O's,
> >     and as long as you actually use all the returned data, it's definitely 
> >     more efficient to issue larger I/O's.
> 
> Prefetching data that is never used is obviously a waste. 256K might be a
> bit big, I was thinking of something like 64-128Kb 
> 
> Drive caches tend to be 0.5-1Mbyte (on SCSI disks) for modern drives. 

Your a bit behind the times with that set of numbers for modern SCSI
drives.  It is now 1 to 16 Mbyte of cache, with 2 and 4Mbyte being the
most common.


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)               rgrimes@gndrsh.dnsmgr.net


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 13:17:50 2000
Delivered-To: freebsd-current@freebsd.org
Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87])
	by hub.freebsd.org (Postfix) with ESMTP id AAC0137BD00
	for <freebsd-current@FreeBSD.ORG>; Tue, 21 Mar 2000 13:17:47 -0800 (PST)
	(envelope-from dcs@newsguy.com)
Received: from newsguy.com (dcs@p29-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.158])
	by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id GAA22544;
	Wed, 22 Mar 2000 06:17:42 +0900 (JST)
Message-ID: <38D7E69E.49695EE7@newsguy.com>
Date: Wed, 22 Mar 2000 06:16:14 +0900
From: "Daniel C. Sobral" <dcs@newsguy.com>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en,pt-BR,ja
MIME-Version: 1.0
To: Ollivier Robert <roberto@eurocontrol.fr>
Cc: "FreeBSD Current Users' list" <freebsd-current@FreeBSD.ORG>
Subject: Re: /boot/loader is making my VAIO reboot
References: <20000321171955.R93580@caerdonn.eurocontrol.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Ollivier Robert wrote:
> 
> Since after the Feb. 25th, /boot/loader is rebooting the machine during
> boot. I can't get to the prompt at all. The only version that works is the
> 25th one (I didn't upgrade between the Feb. 25th and March, 17th).
> 
> Nothing in the BIOS configuration changed during that period...
> 
> -r-xr-xr-x  1 root  wheel  143360 Mar 21 16:39 loader           REBOOTS
> -r-xr-xr-x  2 root  wheel  143360 Feb 25 20:03 loader.old       WORKS
> 
> This is on my VAIO laptop (Z505SX, PII/366, 128 MB).

This is not enough information. You might want to reverse src/sys/boot
to RELENG_4_BP, and test that version, though.

--
Daniel C. Sobral			(8-DCS)
dcs@newsguy.com
dcs@freebsd.org
dcs@zurichgnomes.bsdonspiracy.net

	One Unix to rule them all, One Resolver to find them,
        One IP to bring them all and in the zone bind them.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 13:23:26 2000
Delivered-To: freebsd-current@freebsd.org
Received: from ns.yogotech.com (ns.yogotech.com [206.127.79.126])
	by hub.freebsd.org (Postfix) with ESMTP id 675C237BD0A
	for <freebsd-current@FreeBSD.ORG>; Tue, 21 Mar 2000 13:23:17 -0800 (PST)
	(envelope-from nate@yogotech.com)
Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.79.115])
	by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id OAA00662;
	Tue, 21 Mar 2000 14:23:15 -0700 (MST)
	(envelope-from nate@nomad.yogotech.com)
Received: (from nate@localhost)
	by nomad.yogotech.com (8.8.8/8.8.8) id OAA00577;
	Tue, 21 Mar 2000 14:23:14 -0700 (MST)
	(envelope-from nate)
Date: Tue, 21 Mar 2000 14:23:14 -0700 (MST)
Message-Id: <200003212123.OAA00577@nomad.yogotech.com>
From: Nate Williams <nate@yogotech.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Guido van Rooij <guido@gvr.org>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: problem with reboot on 5.0-current with VAIO
In-Reply-To: <20000321211430.A65060@gvr.gvr.org>
References: <20000321211430.A65060@gvr.gvr.org>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
Reply-To: nate@yogotech.com (Nate Williams)
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> When I use reboot(8) to reboot my Vaio z505sx, it waits nicely for
> the bufdaeon and the syncer to stop. Then the screen goes blank
> and the system completely hangs. Unplugging the battery and power
> is the only way to gte it booting again. It used to work fine with a 
> 4.0-current of some 3 weeks ago but a 5.0-current from today gives the above
> result. 
> Does anyone have a clue?

Is this use VM86?  The Thinkpads have this problem when the amount of
memory that FreeBSD expects is larger than what actually exists, due to
memory sizing issues.  VM86 is supposed to fix this, although I've not
run 5.0 to check it...




Nate


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 13:25:55 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mass.cdrom.com (mg130-183.ricochet.net [204.179.130.183])
	by hub.freebsd.org (Postfix) with ESMTP id D34F937BBB3
	for <freebsd-current@freebsd.org>; Tue, 21 Mar 2000 13:25:44 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Received: from mass.cdrom.com (localhost [127.0.0.1])
	by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id NAA00822;
	Tue, 21 Mar 2000 13:28:30 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Message-Id: <200003212128.NAA00822@mass.cdrom.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To: thyerm@camtech.net.au
Cc: freebsd-current@freebsd.org
Subject: Re: Mylex Support 
In-reply-to: Your message of "Tue, 21 Mar 2000 22:07:01 +1030."
             <Pine.BSF.4.21.0003212200350.8769-100000@dx4.my-unregistered-domain.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 21 Mar 2000 13:28:29 -0800
From: Mike Smith <msmith@freebsd.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> Are there any particular preparation processes one should go through
> when setting up a Mylex DAC960 RAID array ?
> (if so give me a pointer to the docs)

Documentation typically ships with the adapter.

> Can I just purchase all the hardware, plug in the disks and boot the
> FreeBSD-4 install floppies ?  (for a system to be booting from the
> array with no internal ATA devices)

You'll need to configure the array first.

> or Should I have an internal ATA hard disk with some evil OS on it
> such as Lose 9X or NT so as to run any kind of Mylex DOS/Windows
> preparation utilities ?

Only for the very old adapters.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
\\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 13:27:28 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mass.cdrom.com (mg130-183.ricochet.net [204.179.130.183])
	by hub.freebsd.org (Postfix) with ESMTP id 0715237BD02
	for <freebsd-current@FreeBSD.ORG>; Tue, 21 Mar 2000 13:27:21 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Received: from mass.cdrom.com (localhost [127.0.0.1])
	by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id NAA00839;
	Tue, 21 Mar 2000 13:29:46 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Message-Id: <200003212129.NAA00839@mass.cdrom.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To: Brad Knowles <blk@skynet.be>
Cc: "John W. DeBoskey" <jwd@unx.sas.com>,
	freebsd-current@FreeBSD.ORG, Brad Chisholm <sasblc@unx.sas.com>
Subject: Re: AMI MegaRAID lockup? not accepting commands. 
In-reply-to: Your message of "Tue, 21 Mar 2000 10:25:53 +0100."
             <v04220801b4fcf066fdde@[195.238.1.121]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 21 Mar 2000 13:29:45 -0800
From: Mike Smith <msmith@freebsd.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> At 7:25 PM -0800 2000/3/20, Mike Smith wrote:
> 
> >  Not that I consider this particuarly optimal; busy-waiting for the
> >  controller is a terrible waste of the host CPU.  A better solution would
> >  probably defer the command and try again a short time later, but let's
> >  see if this works first.
> 
> 	Since this is a device driver, I guess you can't usleep() and 
> then check again?  Is there anything else useful you could be doing 
> during that period of time -- other than busy waiting?

Well, I call amr_done() to collect completed commands.  There's not much 
other housekeeping that's possible at that point.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
\\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 13:31:16 2000
Delivered-To: freebsd-current@freebsd.org
Received: from tantalum.btinternet.com (tantalum.btinternet.com [194.73.73.80])
	by hub.freebsd.org (Postfix) with ESMTP
	id 7C36037BE12; Tue, 21 Mar 2000 13:31:10 -0800 (PST)
	(envelope-from mark@ukug.uk.freebsd.org)
Received: from [213.1.178.231] (helo=parish.my.domain)
	by tantalum.btinternet.com with esmtp (Exim 2.05 #1)
	id 12XW7K-0005mI-00; Tue, 21 Mar 2000 21:23:10 +0000
Received: (from mark@localhost)
	by parish.my.domain (8.9.3/8.9.3) id VAA08180;
	Tue, 21 Mar 2000 21:31:02 GMT
	(envelope-from mark)
Date: Tue, 21 Mar 2000 21:31:02 +0000
From: Mark Ovens <mark@ukug.uk.freebsd.org>
To: "Kenneth D. Merry" <ken@kdm.org>
Cc: questions@freebsd.org, current@freebsd.org
Subject: Re: SCSI errors from xmcd
Message-ID: <20000321213102.D6493@parish>
References: <20000321201528.A6493@parish> <20000321135046.A41348@panzer.kdm.org> <20000321205717.C6493@parish> <20000321140257.A41481@panzer.kdm.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <20000321140257.A41481@panzer.kdm.org>; from ken@kdm.org on Tue, Mar 21, 2000 at 02:02:57PM -0700
Organization: Total lack of
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Tue, Mar 21, 2000 at 02:02:57PM -0700, Kenneth D. Merry wrote:
> On Tue, Mar 21, 2000 at 20:57:17 +0000, Mark Ovens wrote:
> > On Tue, Mar 21, 2000 at 01:50:46PM -0700, Kenneth D. Merry wrote:
> > > On Tue, Mar 21, 2000 at 20:15:29 +0000, Mark Ovens wrote:
> > > > Is this because xmcd needs updating to work with the new CAM system,
> > > > or something else?
> > > 
> > > You need to recompile xmcd.
> > > 
> > 
> > In that case I need to wait for the package to be updated. xmcd needs
> > Motif, which I don't have, so I use the binary package.
> 
> There's an xmcd package for 4.0 here:
> 
> ftp://ftp.FreeBSD.ORG/pub/FreeBSD/ports/i386/packages-4.0-release/audio/xmcd-2.6.tgz
> 
> What package are you waiting for?
> 

This one I guess :). Just d/l it and installed it; works a treat.
Thanks.

FWIW, I got the original from
ftp://ftp.FreeBSD.ORG/pub/FreeBSD/ports/packages/audio/



> Ken
> -- 
> Kenneth Merry
> ken@kdm.org
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-questions" in the body of the message

-- 
Seminars, n.:
       From "semi" and "arse", hence, any half-assed discussion.
________________________________________________________________
      FreeBSD - The Power To Serve http://www.freebsd.org
      My Webpage http://ukug.uk.freebsd.org/~mark/
mailto:mark@ukug.uk.freebsd.org             http://www.radan.com



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 13:33:37 2000
Delivered-To: freebsd-current@freebsd.org
Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3])
	by hub.freebsd.org (Postfix) with ESMTP
	id 00F1137BE58; Tue, 21 Mar 2000 13:33:32 -0800 (PST)
	(envelope-from eischen@vigrid.com)
Received: (from eischen@localhost)
	by pcnet1.pcnet.com (8.8.7/PCNet) id QAA02675;
	Tue, 21 Mar 2000 16:33:17 -0500 (EST)
Date: Tue, 21 Mar 2000 16:33:16 -0500 (EST)
From: Daniel Eischen <eischen@vigrid.com>
To: "Kenneth D. Merry" <ken@kdm.org>
Cc: Mark Ovens <mark@dogma.freebsd-uk.eu.org>, questions@FreeBSD.ORG,
	current@FreeBSD.ORG
Subject: Re: SCSI errors from xmcd
In-Reply-To: <20000321135046.A41348@panzer.kdm.org>
Message-ID: <Pine.SUN.3.91.1000321162923.1978A-100000@pcnet1.pcnet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Tue, 21 Mar 2000, Kenneth D. Merry wrote:
> On Tue, Mar 21, 2000 at 20:15:29 +0000, Mark Ovens wrote:
> > Since u/g to 4.0 I've had problems with audio CD players and my
> > Toshiba XM6201 SCSI CD drive, cdcontrol and xmcd. Re-MAKEDEV'ing all
> > the cd devices has got cdcontrol working but still xmcd (v2.6)
> > doesn't. It all worked fine under 3.4-STABLE
> > 
> > Starting it with ``-debug'' yields a constant (one every few seconds)
> > stream  of:
> > 
> > SCSI CDB bytes (dev=/dev/rcd0c rw=0 to=20):
> > 0000    00 00 00 00 00 00 -- --  -- -- -- -- -- -- -- --    ................
> > CD audio: SCSI command fault on /dev/rcd0c:
> > Status=0x16
> > 
> > Is this because xmcd needs updating to work with the new CAM system,
> > or something else?
> 
> You need to recompile xmcd.

Also be sure you have an imake that doesn't use cpp:

  strings /usr/X11R6/bin/imake | grep cpp
  /usr/libexec/cpp

That would be wrong, and if you rebuilt xmcd with that imake
it wouldn't work.  To get xmcd to build correctly, set
IMAKECPP=/usr/bin/cpp in your environment before building
xmcd.

Dan Eischen
eischen@vigrid.com



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 13:38:29 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mass.cdrom.com (mg130-183.ricochet.net [204.179.130.183])
	by hub.freebsd.org (Postfix) with ESMTP id 606FB37B881
	for <freebsd-current@FreeBSD.ORG>; Tue, 21 Mar 2000 13:38:24 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Received: from mass.cdrom.com (localhost [127.0.0.1])
	by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id NAA00925;
	Tue, 21 Mar 2000 13:40:20 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Message-Id: <200003212140.NAA00925@mass.cdrom.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: Brad Knowles <blk@skynet.be>,
	"John W. DeBoskey" <jwd@unx.sas.com>, freebsd-current@FreeBSD.ORG,
	Brad Chisholm <sasblc@unx.sas.com>
Subject: Re: AMI MegaRAID lockup? not accepting commands. 
In-reply-to: Your message of "Tue, 21 Mar 2000 09:14:14 PST."
             <200003211714.JAA81010@apollo.backplane.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 21 Mar 2000 13:40:20 -0800
From: Mike Smith <msmith@freebsd.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> :At 7:25 PM -0800 2000/3/20, Mike Smith wrote:
> :
> :>  Not that I consider this particuarly optimal; busy-waiting for the
> :>  controller is a terrible waste of the host CPU.  A better solution would
> :>  probably defer the command and try again a short time later, but let's
> :>  see if this works first.
> :
> :	Since this is a device driver, I guess you can't usleep() and 
> :then check again?  Is there anything else useful you could be doing 
> :during that period of time -- other than busy waiting?
> 
>     For situations that aren't in the critical path and don't happen often,
>     it may be beneficial to do a voluntary context switch inside the loop.

Is it possible/legal to do this inside a strategy() routine?

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
\\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 14:24:45 2000
Delivered-To: freebsd-current@freebsd.org
Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12])
	by hub.freebsd.org (Postfix) with ESMTP
	id B74EF37BD75; Tue, 21 Mar 2000 14:24:38 -0800 (PST)
	(envelope-from wilko@yedi.iaf.nl)
Received: from yedi.iaf.nl (uucp@localhost)
	  by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id XAA13668;
	  Tue, 21 Mar 2000 23:17:48 +0100 (MET)
Received: (from wilko@localhost)
	by yedi.iaf.nl (8.9.3/8.9.3) id WAA04083;
	Tue, 21 Mar 2000 22:45:59 +0100 (CET)
	(envelope-from wilko)
Date: Tue, 21 Mar 2000 22:45:58 +0100
From: Wilko Bulte <wilko@yedi.iaf.nl>
To: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>
Cc: wilko@freebsd.org, Matthew Dillon <dillon@apollo.backplane.com>,
	Poul-Henning Kamp <phk@critter.freebsd.dk>,
	Alfred Perlstein <bright@wintelcom.net>, current@freebsd.org
Subject: Re: patches for test / review
Message-ID: <20000321224558.B3899@yedi.iaf.nl>
Reply-To: wilko@freebsd.org
References: <20000321200438.F966@yedi.iaf.nl> <200003212114.NAA49370@gndrsh.dnsmgr.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200003212114.NAA49370@gndrsh.dnsmgr.net>; from freebsd@gndrsh.dnsmgr.net on Tue, Mar 21, 2000 at 01:14:45PM -0800
X-OS: FreeBSD 3.4-STABLE
X-PGP: finger wilko@freebsd.org
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Tue, Mar 21, 2000 at 01:14:45PM -0800, Rodney W. Grimes wrote:
> > On Tue, Mar 21, 2000 at 09:29:56AM -0800, Matthew Dillon wrote:
> > > :> 
> > > :> I would think that track-caches and intelligent drives would gain
> > > :> much if not more of what clustering was designed to do gain.
> > > :
> > > :Hm. But I'd think that even with modern drives a smaller number of bigger
> > > :I/Os is preferable over lots of very small I/Os. Or have I missed the point?
> > 
> > >     As long as you do not blow away the drive's cache with your big I/O's,
> > >     and as long as you actually use all the returned data, it's definitely 
> > >     more efficient to issue larger I/O's.
> > 
> > Prefetching data that is never used is obviously a waste. 256K might be a
> > bit big, I was thinking of something like 64-128Kb 
> > 
> > Drive caches tend to be 0.5-1Mbyte (on SCSI disks) for modern drives. 
> 
> Your a bit behind the times with that set of numbers for modern SCSI
> drives.  It is now 1 to 16 Mbyte of cache, with 2 and 4Mbyte being the
> most common.

Your drives are more modern than mine ;-) What drive has 16 Mb? Curious
here..

-- 
Wilko Bulte 			Arnhem, The Netherlands	  
http://www.tcja.nl  		The FreeBSD Project: http://www.freebsd.org


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 14:59:24 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP
	id D9F6C37BD2F; Tue, 21 Mar 2000 14:59:14 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id OAA83077;
	Tue, 21 Mar 2000 14:59:14 -0800 (PST)
	(envelope-from dillon)
Date: Tue, 21 Mar 2000 14:59:14 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003212259.OAA83077@apollo.backplane.com>
To: Mike Smith <msmith@FreeBSD.ORG>
Cc: Brad Knowles <blk@skynet.be>,
	"John W. DeBoskey" <jwd@unx.sas.com>, freebsd-current@FreeBSD.ORG,
	Brad Chisholm <sasblc@unx.sas.com>
Subject: Re: AMI MegaRAID lockup? not accepting commands. 
References:  <200003212140.NAA00925@mass.cdrom.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


:>     For situations that aren't in the critical path and don't happen often,
:>     it may be beneficial to do a voluntary context switch inside the loop.
:
:Is it possible/legal to do this inside a strategy() routine?

    Yes, though it isn't playing nice if the caller was trying to issue
    an asynchronous I/O.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 15: 0:57 2000
Delivered-To: freebsd-current@freebsd.org
Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
	by hub.freebsd.org (Postfix) with ESMTP id C168937BEE9
	for <freebsd-current@freebsd.org>; Tue, 21 Mar 2000 15:00:51 -0800 (PST)
	(envelope-from pechter@backup.ho.lucent.com)
Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1])
	by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id SAA14998
	for <freebsd-current@freebsd.org>; Tue, 21 Mar 2000 18:00:50 -0500 (EST)
Received: from backup.ho.lucent.com (h135-17-29-26.lucent.com [135.17.29.26])
	by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id SAA14992
	for <freebsd-current@freebsd.org>; Tue, 21 Mar 2000 18:00:50 -0500 (EST)
Received: (from pechter@localhost)
	by backup.ho.lucent.com (8.9.3/8.9.3) id SAA00375
	for freebsd-current@freebsd.org; Tue, 21 Mar 2000 18:00:47 -0500 (EST)
	(envelope-from pechter)
From: Bill Pechter <pechter@backup.ho.lucent.com>
Message-Id: <200003212300.SAA00375@backup.ho.lucent.com>
Subject: pstat -s error message
To: freebsd-current@freebsd.org
Date: Tue, 21 Mar 2000 18:00:46 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

I've done two make worlds and can't seem to get rid of the following
error... I had it on my home system, but didn't log what I did to 
correct it...

I just upgraded a 4.0-CURRENT (from around Jan 26) to the 4.0-STABLE
from yesterday.

when running pstat -s I get the following:
pstat: undefined symbol: _numvnodes

I rebuilt world and the kernel twice... I must be missing something.

Bill
+---------------------------------------------------------------------------+
| Bill Pechter | Lucent Technologies | Voice 732-949-1417 | Fax 732-949-5477|
| 101 Crawfords Corner Road, Holmdel, NJ 07733      | pechter@lucent.com    |
| This message brought to you by the letters PDP and the numbers 11 and 45  |
+---------------------------------------------------------------------------+


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 15: 6:32 2000
Delivered-To: freebsd-current@freebsd.org
Received: from veldy.net (veldy-host201.dsl.visi.com [208.42.48.201])
	by hub.freebsd.org (Postfix) with ESMTP
	id 91B3D37BDDA; Tue, 21 Mar 2000 15:03:42 -0800 (PST)
	(envelope-from veldy@veldy.net)
Received: from veldy.net (cascade.veldy.net [192.168.0.1])
	by veldy.net (Postfix) with ESMTP
	id 9B8661921; Tue, 21 Mar 2000 17:06:48 -0600 (CST)
Message-ID: <38D8001B.845180A5@veldy.net>
Date: Tue, 21 Mar 2000 17:04:59 -0600
From: "Thomas T. Veldhouse" <veldy@veldy.net>
X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 4.0-STABLE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: dan@freebsd.org, freebsd-current@freebsd.org
Subject: emu10k1 driver
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

I just tried it against 4.0-STABLE (03222000).  The patch
(http://www.freebsd.org/~cg/current.diff.gz) applied 100% successfully
(I assume sound has not yet diverged much in 5.0 except for Voxware).  I
don't get any sound when using KMP3.  I just get a pulse sound  in the
speaker when the app starts though and then a pulse again when I shut
the app down.

Here is the relavent dmesg output:

pcm0: <Creative EMU10K1> port 0x1400-0x141f irq 11 at device 3.0 on pci0

pcm0: ac97 codec reports dac not ready

Is there something that needs to enable the PCI card properly?  I do not
have the option to shut Plug-N-Play off on my system (nice Compaq-ism).

It looks like it is very close.

Thanks in advance,

Tom Veldhouse
veldy@veldy.net


> Subject:      Re: emu10k1 (SB Live!) support under FreeBSD?
> From:         Dan Moschuk
> Date:         2000/03/20
> Message-ID:   <20000320132433.B1790_spirit.jaded.net@ns.sol.net>
> Newsgroups:   sol.lists.freebsd.current
> [More Headers]
>
> | | I would love to help out, but I don't know where to start, and I have no
> | | kernel programming experience.  There are reference drivers available for
> | | linux via http://opensource.creative.com or http://www.alsa-project.org
> | | (my preference).
> |
> | One is on the way...
>
> Cam's boredom out-weighed my initiative. 8)
>
> http://www.freebsd.org/~cg/current.diff.gz contains a partial emu10k1
> driver (minus recording) which is need of debugging.  Give it a try!
>



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 15:14:58 2000
Delivered-To: freebsd-current@freebsd.org
Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4])
	by hub.freebsd.org (Postfix) with ESMTP
	id 9737837BD75; Tue, 21 Mar 2000 15:14:43 -0800 (PST)
	(envelope-from freebsd@gndrsh.dnsmgr.net)
Received: (from freebsd@localhost)
	by gndrsh.dnsmgr.net (8.9.3/8.9.3) id PAA49627;
	Tue, 21 Mar 2000 15:14:41 -0800 (PST)
	(envelope-from freebsd)
From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>
Message-Id: <200003212314.PAA49627@gndrsh.dnsmgr.net>
Subject: Re: patches for test / review
In-Reply-To: <20000321224558.B3899@yedi.iaf.nl> from Wilko Bulte at "Mar 21, 2000 10:45:58 pm"
To: wilko@freebsd.org
Date: Tue, 21 Mar 2000 15:14:41 -0800 (PST)
Cc: dillon@apollo.backplane.com (Matthew Dillon),
	phk@critter.freebsd.dk (Poul-Henning Kamp),
	bright@wintelcom.net (Alfred Perlstein), current@freebsd.org
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> On Tue, Mar 21, 2000 at 01:14:45PM -0800, Rodney W. Grimes wrote:
> > > On Tue, Mar 21, 2000 at 09:29:56AM -0800, Matthew Dillon wrote:
> > > > :> 
> > > > :> I would think that track-caches and intelligent drives would gain
> > > > :> much if not more of what clustering was designed to do gain.
> > > > :
> > > > :Hm. But I'd think that even with modern drives a smaller number of bigger
> > > > :I/Os is preferable over lots of very small I/Os. Or have I missed the point?
> > > 
> > > >     As long as you do not blow away the drive's cache with your big I/O's,
> > > >     and as long as you actually use all the returned data, it's definitely 
> > > >     more efficient to issue larger I/O's.
> > > 
> > > Prefetching data that is never used is obviously a waste. 256K might be a
> > > bit big, I was thinking of something like 64-128Kb 
> > > 
> > > Drive caches tend to be 0.5-1Mbyte (on SCSI disks) for modern drives. 
> > 
> > Your a bit behind the times with that set of numbers for modern SCSI
> > drives.  It is now 1 to 16 Mbyte of cache, with 2 and 4Mbyte being the
> > most common.
> 
> Your drives are more modern than mine ;-) What drive has 16 Mb? Curious
> here..

Seagates latest and greatest drives have a 4MB cache standard and an option
for 16MB.  These are 10K RPM chetta drives.  


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)               rgrimes@gndrsh.dnsmgr.net


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 15:18:48 2000
Delivered-To: freebsd-current@freebsd.org
Received: from rover.village.org (rover.village.org [204.144.255.49])
	by hub.freebsd.org (Postfix) with ESMTP id A1C5A37B84A
	for <current@FreeBSD.ORG>; Tue, 21 Mar 2000 15:18:33 -0800 (PST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (harmony.village.org [10.0.0.6])
	by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA24746;
	Tue, 21 Mar 2000 16:18:31 -0700 (MST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA26473; Tue, 21 Mar 2000 16:18:18 -0700 (MST)
Message-Id: <200003212318.QAA26473@harmony.village.org>
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Subject: Re: Reading from bad disk ? 
Cc: Luigi Rizzo <luigi@info.iet.unipi.it>,
	Soren Schmidt <sos@freebsd.dk>, current@FreeBSD.ORG
In-reply-to: Your message of "Tue, 21 Mar 2000 13:16:34 +0100."
		<25230.953640994@critter.freebsd.dk> 
References: <25230.953640994@critter.freebsd.dk>  
Date: Tue, 21 Mar 2000 16:18:18 -0700
From: Warner Losh <imp@village.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

: >A comment: this is a 18GB IBM 7200 RPM disk and i noticed it tends
: >to become very hot compared to other disks when mounted in the
: >same machine (on a removable frame). Do others have the same
: >experience ?

Yes.  They run very hot.  I had to steal an old powersupply fan and
mount it in front of the drive to get it to run at  a reasonable
temperature.  W/o the fan, it was running at 58C or so.  With the fan
it runs at 39C or so.  I've included the script that I use to find
this information out.  Ken Merry sent it to me.  It works on some IBM
drives.

Warner

#!/bin/sh

TEMPC=`camcontrol cmd -v -n da -u 0 -c "4D 0 76 0 0 0 0 0 20 0" -i 32 "s9 i1"`

TEMPF=`echo " 2 k $TEMPC 9 * 5 / 32 + p" | dc`

echo "The temperature is: $TEMPF F $TEMPC C"


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 15:25:11 2000
Delivered-To: freebsd-current@freebsd.org
Received: from rover.village.org (rover.village.org [204.144.255.49])
	by hub.freebsd.org (Postfix) with ESMTP id 1E35E37B518
	for <freebsd-current@FreeBSD.ORG>; Tue, 21 Mar 2000 15:24:13 -0800 (PST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (harmony.village.org [10.0.0.6])
	by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA24763;
	Tue, 21 Mar 2000 16:24:07 -0700 (MST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA26513; Tue, 21 Mar 2000 16:23:53 -0700 (MST)
Message-Id: <200003212323.QAA26513@harmony.village.org>
To: Nikolai Saoukh <nms@otdel-1.org>
Subject: Re: -current sudden panics :( 
Cc: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>, ilmar@ints.ru,
	freebsd-current@FreeBSD.ORG
In-reply-to: Your message of "Tue, 21 Mar 2000 19:57:37 +0300."
		<20000321195737.A8366@Draculina.otdel-1.org> 
References: <20000321195737.A8366@Draculina.otdel-1.org>  <Pine.BSF.4.21.0003210801280.223-300000@ws-ilmar.ints.ru> <20000322005136H.shin@nd.net.fujitsu.co.jp> <20000321192642.B8237@Draculina.otdel-1.org> <20000322015153F.shin@nd.net.fujitsu.co.jp> 
Date: Tue, 21 Mar 2000 16:23:52 -0700
From: Warner Losh <imp@village.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <20000321195737.A8366@Draculina.otdel-1.org> Nikolai Saoukh writes:
: > But shouldn't it be sys/pci/if_rl.c ?
: 
: Sorry,
: it is mea culpa. I mixed his case with my (token ring).

Do you have the patch to if_rl.c.  I looked at it for all of 10
seconds and it wasn't immediately obvious to me.

Warner


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 15:42: 1 2000
Delivered-To: freebsd-current@freebsd.org
Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161])
	by hub.freebsd.org (Postfix) with ESMTP
	id DA15A37C201; Tue, 21 Mar 2000 15:41:49 -0800 (PST)
	(envelope-from doconnor@gsoft.com.au)
Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97])
	by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id KAA12871;
	Wed, 22 Mar 2000 10:11:42 +1030 (CST)
	(envelope-from doconnor@gsoft.com.au)
Message-ID: <XFMail.000322101141.doconnor@gsoft.com.au>
X-Mailer: XFMail 1.4.0 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <004501bf9341$1aa63240$dd29680a@tgt.com>
Date: Wed, 22 Mar 2000 10:11:41 +1030 (CST)
From: "Daniel O'Connor" <doconnor@gsoft.com.au>
To: "Thomas T. Veldhouse" <veldy@veldy.net>
Subject: Re: emu10k1 (SB Live!) support under FreeBSD?
Cc: current@FreeBSD.ORG, Dan Moschuk <dan@FreeBSD.ORG>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


On 21-Mar-00 Thomas T. Veldhouse wrote:
>  What kind of drivers are these?  Are these ports of the ALSA drivers, or
>  are
>  they more OSS?

They're native BSD drivers.. I'd say Cameron read the code from Creative and
wrote a newpcm driver with it.

---
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 15:55:52 2000
Delivered-To: freebsd-current@freebsd.org
Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.144.32])
	by hub.freebsd.org (Postfix) with ESMTP id A062237BCEB
	for <freebsd-current@FreeBSD.ORG>; Tue, 21 Mar 2000 15:55:47 -0800 (PST)
	(envelope-from dwhite@resnet.uoregon.edu)
Received: from localhost (dwhite@localhost)
	by resnet.uoregon.edu (8.9.3/8.9.3) with ESMTP id PAA66438;
	Tue, 21 Mar 2000 15:55:36 -0800 (PST)
	(envelope-from dwhite@resnet.uoregon.edu)
Date: Tue, 21 Mar 2000 15:55:36 -0800 (PST)
From: Doug White <dwhite@resnet.uoregon.edu>
To: Pete <pmckenna@uswest.net>
Cc: Brian Dean <brdean@unx.sas.com>,
	"Daniel C. Sobral" <dcs@newsguy.com>,
	Forrest Aldrich <forrie@forrie.com>, freebsd-current@FreeBSD.ORG
Subject: Re: Streamlining FreeBSD Installations
In-Reply-To: <38D5B4C1.A170936A@uswest.net>
Message-ID: <Pine.BSF.4.21.0003211551180.50553-100000@resnet.uoregon.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Sun, 19 Mar 2000, Pete wrote:

> It does not have to be that hands on.

...

> I hacked PicoBSD to do this so it works from one floppy. You can
> either name the file install.cfg in which case it is run automatically
> or give it a ../stand/my_script.cfg to grab the build file you wish
> from stand which is where I put my scripts on the build floppy. I have
> about a dozen different scripts on the floppy and still seem to have
> lots of room. I haven't automated adding users. I did this under 3.2
> and am trying to find the time to move it to 3.4 although it should be
> able to build 3.4 servers with no problem.

I took this one step further --  The PicoBSD Install floppy just pulls
down a tarball of a running system, splats it on, and does anything else
you want to/can do from a shell script.  Works quite well and is easy to
update -- install, change the image, rebuild image.   You can even edit
the install script on the floppy without rebuilding the floppy.  

We also don't bother to stay -STABLE -- we're on 3.2-S with some kernel
hacks and it works fine, so we don't touch it :)

Doug White                    |  FreeBSD: The Power to Serve
dwhite@resnet.uoregon.edu     |  www.FreeBSD.org



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 16:24:19 2000
Delivered-To: freebsd-current@freebsd.org
Received: from ns0.netcraft.com (ns0.netcraft.com [195.188.192.4])
	by hub.freebsd.org (Postfix) with ESMTP
	id 2BC4A37BBEB; Tue, 21 Mar 2000 16:23:59 -0800 (PST)
	(envelope-from richard@netcraft.com)
Received: (from richard@localhost)
          by ns0.netcraft.com (8.8.8/8.8.8) id AAA28786;
          Wed, 22 Mar 2000 00:22:42 GMT
          (envelope-from richard)
From: Richard Wendland <richard@netcraft.com>
Message-Id: <200003220022.AAA28786@ns0.netcraft.com>
Subject: FreeBSD random I/O performance issues
In-Reply-To: <38D6BBD7.DA4B950B@originative.co.uk> from Paul Richards at "Mar
 21, 2000 00:01:27 am"
To: Paul Richards <paul@originative.co.uk>
Date: Wed, 22 Mar 2000 00:22:42 +0000 (GMT)
Cc: Alfred Perlstein <bright@wintelcom.net>,
	Poul-Henning Kamp <phk@critter.freebsd.dk>,
	Matthew Dillon <dillon@apollo.backplane.com>, current@FreeBSD.ORG,
	fs@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL61 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Paul Richards said in "Re: patches for test / review":

> Richard, do you want to post a summary of your tests?

Well I'd best post the working draft of my report on the issues
I've seen, as I'm not going to have time to work on it in the near
future, and it raises serious performance issues that are best
looked at soon.  Note none of these detailed results are from
current, but Paul Richards has checked that these issues are still
present in current.

There are still issues to be explored so this report isn't in a
complete state, and not polished.  It's grown in 3 stages:

- initial Berkeley DB (random I/O) performance problem analysis
- side-issue of ATA outperforming SCSI systems at my synthetic benchmark
- interesting dramatic performance changes from changing seek multiple
  and I/O block size one byte from 8192

Note I've cc'd freebsd-fs, as this raises issues in the filesystem
area.  I've also changed the subject since I think there are broader
issues here than the clustering algorithm, and this email is rather
large to drop into an ongoing discussion.

The benchmark program source code is available, and easy to run,
the bottom of the report has links.

I don't have an explanation for the behaviour I have been measuring,
but I hope these quite extensive results will enable someone to
explain and perhaps suggest improvements.

	Richard.


Folks,

I appear to have found a serious performance problem with random
access file I/O in FreeBSD, and have a simple C benchmark program
which reproducibly demonstrates it.  In that the benchmark demonstrates
very poor non-async performance, this touches on the age-old
sync/async filesystem argument, and FreeBSD vs Linux debates.

I originally observed this problem with perl DB_File (Berkeley DB),
and with the help of truss have synthesised this benchmark as a
much simplified model of heavy Berkeley DB update behaviour.  Quite
probably other database-like software will have similar performance
issues.

This issue appears to be related to the traditional BSD behaviour
of immediately scheduling full disc block writes.  I think this
benchmark must be showing up a related bug.  But it is conceivable
that this is intended noasync behaviour, in which case the implications
need to be thought through.

The program does simple random I/O within a 64KB file, which should
I hope be fully cached so hardly any real I/O would be done.  Other
than mtime, this program makes no file meta-data or directory
changes; and the file remains the same size.

The file is used as 8 8KB blocks, and for each block in the order
0,5,2,7,4,1,6,3,0,... 10,000 lseek/read/lseek/write block updates
are done, much like updating 10,000 non-localised Berkeley DB file
records.

Using a tiny 64KB file is just to simplify and make a point.  My
original perl performance problems were with multi-megabyte files,
but still small enough to be fully cached.

I ran this on a large range of lightly loaded or idle machines,
which gave reproducible results.  Results and a summary of the
machines, which unless otherwise noted use SCSI 7200 RPM discs and
Adaptec controllers, are given in descending performance order
below.


  OS						Elapse secs, system

  FreeBSD 3.2-RELEASE, async mount		<1  (cheap ATA C433, 5400 RPM)
  Linux 2.2.13					<1  (Dell 1300, PIII 450MHz)
  Linux 2.0.36					3   (old ATA P200, 5400 RPM)
  Linux 2.0.36, sync [meta-data] mount		3   (old ATA P200, 5400 RPM)
  SunOS 5.5.1 (Solaris 2.5.1)			7   (old SS4/110, 5400 RPM)
  FreeBSD 2.2.7-RELEASE+CAM, ccd stripe=5	15  (PII 450MHz, 512MB, 10k RPM)
  FreeBSD 2.2.7-RELEASE+CAM			21  (PII 400MHz, 512MB)
  FreeBSD 2.1.6.1-RELEASE			32  (old P100, 64MB)
  FreeBSD 2.2.7-RELEASE+CAM, ccd stripe=2	39  (PII 400MHz, 512MB)
  FreeBSD 3.4-STABLE, vinum stripe+mirr=4	41  (dual PIII 500MHz, 1GB)
  FreeBSD 3.4-STABLE				41  (dual PIII 500MHz, 1GB)
  FreeBSD 2.1.6.1-RELEASE, ccd stripe=2		52  (old P100, 64MB)
  FreeBSD 3.3-RELEASE, ccd stripe=2		53  (Dell 1300, PIII 450MHz)
  FreeBSD 3.2-RELEASE				55  (cheap ATA C433, 5400 RPM)
  FreeBSD 3.2-RELEASE, noatime mount		55  (cheap ATA C433, 5400 RPM)
  FreeBSD 3.2-RELEASE, noclusterr mount		55  (cheap ATA C433, 5400 RPM)
  FreeBSD 3.2-RELEASE, noclusterw mount		58  (cheap ATA C433, 5400 RPM)
  FreeBSD 3.3-RELEASE				63  (Dell 1300, PIII 450MHz)
  FreeBSD 3.3-RELEASE, softupdates		63  (Dell 1300, PIII 450MHz)
  FreeBSD 3.2-RELEASE, sync mount		105 (cheap ATA C433, 5400 RPM)


I also have a range of results from an ATA (IDE) cheap deskside
Dell system running FreeBSD 3.3-RELEASE, with a range of wd(4)
flags.  This system exhibits much better performance than the SCSI
systems above at this benchmark, perhaps related to better DMA
ability.

ATA being faster than SCSI on this benchmark is a bit of a side-issue
to the thrust of this report, but the performance numbers may give
hints diagnosing the problem.

    Dell Dimension XPS T450 440BX
    IBM-DPTA-372730 (Deskstar 34GXP, 7200RPM, 2MB buffer)
    default mount options

	wd(4) flags				Elapse secs

	0x0000					19
	0x00ff, multi-sector transfer mode	17
	0x8000, 32bit transfers			13
	0x2000, bus-mastering DMA		4
	0xa0ff, BM-DMA+32bit+multi-sector	4


Note that Linux performs about the same for [meta-data] sync &
async mounts, which is as I'd expect for this program.  But FreeBSD
performance is hugely affected by async, sync or default (meta-data
sync) filesystem mounts, with noclusterw unsurprisingly making it
somewhat worse.

One interesting observation is that for non sync, async or noclusterw
mounts ~8750 I/O operations are done, which is 7/8ths of the 10,000
writes.  If I change the program to use 16 blocks there are ~9375
I/O operations which is 15/16ths of the 10,000 writes.  Guessing,
this is as if writes are forced for all blocks but one.

With async filesystem mounts very little I/O occurs, and with
noclusterw there are ~10,000 operations matching the number of
writes.

With sync it's ~20,000 operations matching the total of reads &
writes.  This demonstrates another aspect of the bug, sync behaviour
should cause 10,000 operations; the reads aren't being cached.

A quick softupdates test suggests this makes no difference, as
would be expected.

Looking at mount output on FreeBSD 3 the substantial part of the
I/O is async in all cases other than sync mounts; as expected.


Another aspect of this issue is the effect of changing the seek
blocksize, and write blocksize, by 1 byte each way from 8192, thus
doing block unaligned I/O.  In some cases this changes the amount
of I/O recorded by getrusage to zero, and drops elapse time from
half a minute or so to less than 1 second.

Thanks to Paul Richard for noticing this.  I've not spent much time
researching this, so can only present my small set of measurements.
To do these tests you have to recompile my test program each time eg

	gcc -O4 -DBLOCKSIZE=8191 -DWRITESIZE=8193 seekreadwrite.c

Sorry it's that crude.  These results are from a FreeBSD
2.2.7-RELEASE+CAM, ccd stripe=2 (PII 400MHz, 512MB) system,
though exactly the same pattern is apparent with 3.4-STABLE.
"****" indicate sub-second "zero I/O" results.

BLOCKSIZE   WRITESIZE	csh 'time' output

8191	    8191	0.0u 1.5s 0:34.10 4.6% 5+186k 0+7500io 0pf+0w
8191	    8192	0.0u 1.3s 0:31.52 4.5% 5+178k 0+7500io 0pf+0w
8191	    8193	0.0u 1.4s 0:32.63 4.4% 5+189k 0+7500io 0pf+0w

8192	    8191	0.0u 0.7s 0:01.97 37.5% 8+178k 0+0io 0pf+0w    ****
8192	    8192	0.0u 1.3s 0:39.30 3.4% 7+196k 0+8750io 0pf+0w
8192	    8193	0.0u 1.3s 0:40.09 3.4% 5+187k 0+8750io 0pf+0w

8193	    8191	0.0u 1.4s 0:46.22 3.2% 5+192k 0+8750io 0pf+0w
8193	    8192	0.0u 1.6s 0:40.48 4.0% 5+182k 0+8750io 0pf+0w
8193	    8193	0.0u 1.5s 0:40.57 3.8% 5+175k 0+8750io 0pf+0w


8191	    4095	0.0u 1.2s 0:33.79 3.6% 5+193k 0+7500io 0pf+0w
8191	    4096	0.0u 1.2s 0:34.00 3.8% 5+190k 0+7500io 0pf+0w
8191	    4097	0.0u 1.1s 0:33.58 3.6% 4+165k 0+7500io 0pf+0w

8192	    4095	0.0u 0.5s 0:00.76 75.0% 5+189k 0+0io 0pf+0w    ****
8192	    4096	0.0u 0.5s 0:00.58 100.0% 5+183k 0+0io 0pf+0w   ****
8192	    4097	0.0u 0.5s 0:00.74 78.3% 5+181k 0+0io 0pf+0w    ****

8193	    4095	0.0u 0.6s 0:01.00 67.0% 5+177k 0+0io 0pf+0w    ****
8193	    4096	0.0u 0.6s 0:01.05 63.8% 5+179k 0+0io 0pf+0w    ****
8193	    4097	0.0u 0.6s 0:01.02 66.6% 5+183k 0+0io 0pf+0w    ****



Any views gratefully received.  A fix would be much better :-)

Test program source, including compile & run instructions, is
available at:

	http://www.netcraft.com/freebsd/random-IO/seekreadwrite.c

Detailed notes on the test system configurations are at:

	http://www.netcraft.com/freebsd/random-IO/results-notes.txt

Thanks,
	Richard
-
Richard Wendland				richard@netcraft.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 16:32:57 2000
Delivered-To: freebsd-current@freebsd.org
Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.144.32])
	by hub.freebsd.org (Postfix) with ESMTP id 4705337BCAA
	for <current@FreeBSD.ORG>; Tue, 21 Mar 2000 16:32:54 -0800 (PST)
	(envelope-from dwhite@resnet.uoregon.edu)
Received: from localhost (dwhite@localhost)
	by resnet.uoregon.edu (8.9.3/8.9.3) with ESMTP id QAA42795;
	Tue, 21 Mar 2000 16:32:35 -0800 (PST)
	(envelope-from dwhite@resnet.uoregon.edu)
Date: Tue, 21 Mar 2000 16:32:35 -0800 (PST)
From: Doug White <dwhite@resnet.uoregon.edu>
To: "Thierry.herbelot" <herbelot@cybercable.fr>
Cc: Joe Abley <jabley@patho.gen.nz>, current@FreeBSD.ORG
Subject: Re: 4.0-RELEASE boot.flp fails to boot on K6/2
In-Reply-To: <38D71C22.62A29CCE@cybercable.fr>
Message-ID: <Pine.BSF.4.21.0003211631260.50553-100000@resnet.uoregon.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Tue, 21 Mar 2000, Thierry.herbelot wrote:

> I had the exact same error message trying to boot from a floppy where I
> had tried to dd the full boot.flp (2,8 Megs is just too much for a
> normal floppy), instead of kern.flp (and dd does not give error messages
> ..)

I would be in favor of renaming the boot.flp to something obviously
different, like 288boot.flp, to untrain us 2.x heads that got used to the
single-floppy installer of yore. :)  I still reach for 'boot.flp' and have
to kick myself to grab kern/mfsroot instead.

Doug White                    |  FreeBSD: The Power to Serve
dwhite@resnet.uoregon.edu     |  www.FreeBSD.org



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 16:52:21 2000
Delivered-To: freebsd-current@freebsd.org
Received: from bilby.prth.tensor.pgs.com (bilby.prth.tensor.pgs.com [157.147.232.237])
	by hub.freebsd.org (Postfix) with ESMTP id 957AD37BF39
	for <current@freebsd.org>; Tue, 21 Mar 2000 16:52:05 -0800 (PST)
	(envelope-from shocking@bandicoot.prth.tensor.pgs.com)
Received: from bandicoot.prth.tensor.pgs.com (bandicoot.prth.tensor.pgs.com [157.147.224.1])
	by bilby.prth.tensor.pgs.com (8.9.3/8.8.8) with ESMTP id IAA18311
	for <current@freebsd.org>; Wed, 22 Mar 2000 08:49:44 +0800 (WST)
Received: (from shocking@localhost)
	by bandicoot.prth.tensor.pgs.com (8.9.3/8.8.8) id IAA23805
	for current@freebsd.org; Wed, 22 Mar 2000 08:51:53 +0800 (WST)
Date: Wed, 22 Mar 2000 08:51:53 +0800 (WST)
From: Stephen Hocking-Senior Programmer PGS SPS Perth <shocking@prth.pgs.com>
Message-Id: <200003220051.IAA23805@bandicoot.prth.tensor.pgs.com>
To: current@freebsd.org
Subject: Another current crash (cvs-cur.6183
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


cvs-cur.6183 appeared to fix the crash I reported under disk activity & NFS
but another one has reared its face, when using java with tya15 jit, running
the Together java IDE.

#0  boot (howto=256) at ../../kern/kern_shutdown.c:304
#1  0xc013d7e5 in panic (fmt=0xc0273534 "from debugger")
    at ../../kern/kern_shutdown.c:554
#2  0xc01265bd in db_panic (addr=-1071292639, have_addr=0, count=-1, 
    modif=0xc5988c64 "") at ../../ddb/db_command.c:433
#3  0xc012655d in db_command (last_cmdp=0xc02abc2c, cmd_table=0xc02aba8c, 
    aux_cmd_tablep=0xc02e4578) at ../../ddb/db_command.c:333
#4  0xc0126622 in db_command_loop () at ../../ddb/db_command.c:455
#5  0xc0128733 in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
#6  0xc0255cc1 in kdb_trap (type=3, code=0, regs=0xc5988d6c)
    at ../../i386/i386/db_interface.c:158
#7  0xc0262690 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 0, 
      tf_esi = -979913536, tf_ebp = -979857996, tf_isp = -979858024, 
      tf_ebx = -1044942540, tf_edx = 0, tf_ecx = -1070604512, tf_eax = 26, 
      tf_trapno = 3, tf_err = 0, tf_eip = -1071292639, tf_cs = 8, 
      tf_eflags = 12870, tf_esp = -1070994081, tf_ss = -1071140376})
    at ../../i386/i386/trap.c:549
#8  0xc0255f21 in Debugger (msg=0xc027b1e8 "d_iocmd botch")
    at machine/cpufunc.h:64
#9  0xc017385e in spec_strategy (ap=0xc5988df8)
    at ../../miscfs/specfs/spec_vnops.c:438
#10 0xc0173325 in spec_vnoperate (ap=0xc5988df8)
    at ../../miscfs/specfs/spec_vnops.c:117
#11 0xc020c3bd in ufs_vnoperatespec (ap=0xc5988df8)
    at ../../ufs/ufs/ufs_vnops.c:2301
#12 0xc0219167 in swapdev_strategy (ap=0xc5988e30) at vnode_if.h:923
#13 0xc020d80e in swap_pager_putpages (object=0xc02f9ea0, m=0xc5988ee0, 
    count=1, sync=0, rtvals=0xc5988e74) at vnode_if.h:923
#14 0xc020c427 in default_pager_putpages (object=0xc02f9ea0, m=0xc5988ee0, 
    c=1, sync=0, rtvals=0xc5988e74) at ../../vm/default_pager.c:133
#15 0xc02175ea in vm_pageout_flush (mc=0xc5988ee0, count=1, flags=0)
    at ../../vm/vm_pager.h:145
#16 0xc021754d in vm_pageout_clean (m=0xc0464ae0) at ../../vm/vm_pageout.c:338
#17 0xc0217e6e in vm_pageout_scan () at ../../vm/vm_pageout.c:914
#18 0xc0218764 in vm_pageout () at ../../vm/vm_pageout.c:1350
#19 0xc02565e0 in fork_trampoline ()
Cannot access memory at address 0xa000.




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 16:59:40 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP
	id E105B37BD80; Tue, 21 Mar 2000 16:59:29 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id QAA83848;
	Tue, 21 Mar 2000 16:59:25 -0800 (PST)
	(envelope-from dillon)
Date: Tue, 21 Mar 2000 16:59:25 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003220059.QAA83848@apollo.backplane.com>
To: Richard Wendland <richard@netcraft.com>
Cc: Paul Richards <paul@originative.co.uk>,
	Alfred Perlstein <bright@wintelcom.net>,
	Poul-Henning Kamp <phk@critter.freebsd.dk>, current@FreeBSD.ORG,
	fs@FreeBSD.ORG
Subject: Re: FreeBSD random I/O performance issues
References:  <200003220022.AAA28786@ns0.netcraft.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


:Paul Richards said in "Re: patches for test / review":
:
:> Richard, do you want to post a summary of your tests?
:
:Well I'd best post the working draft of my report on the issues
:I've seen, as I'm not going to have time to work on it in the near
:future, and it raises serious performance issues that are best
:looked at soon.  Note none of these detailed results are from
:current, but Paul Richards has checked that these issues are still
:present in current.
:
: (lots of good stuff)

    Interesting.  The behavior is probably related closely to the
    write-behind methodology that UFS uses.

    A while back while fixing an O(N^2) degenerate condition in the buffer
    cache queueing code, DG and I had a long discussion of the write_behind
    behavior.  I added a sysctl to 4.x that changes the write_behind
    behavior:

	sysctl vfs.write_behind

	0	Turned off
	1	Normal		(default)
	2	Backed off

    It would be interesting to see how the benchmark performs with 
    write_behind turned off (set to 0).  Note that a setting of 2
    is highly experimental and will probably suffer from the same problem(s)
    that normal mode suffers from.  (see below, I ran the benchmark)

    In general turning off write behind is *NOT* a good idea, because
    it saturates the buffer cache with dirty blocks and can lead to seriously
    degraded performance on a normal system due to write hogging.   On the
    flip side, this was all before I put in the new buffer cache flushing code
    so it is possible that 4.x will not degrade as seriously with write
    behind turned off.  I haven't run saturation tests recently with 
    write_behind turned off.

    A secondary issue -- actually the reason *why* performance is so bad, is
    that the buffer cache nominally locks the underlying VM pages when issuing
    a write and this is almost certainly the cause of the program stalls.
    When a program writes a piece of data (and I/O is started immediately),
    and then reads it back later on, the read operation may stall even though
    the data is in the cache due to the write not having yet completed.  The
    write operation might also stall if another nearby write is in progress
    (I'm not sure on that last point).

    Kirk has made significant improvements to stalls related to bitmap 
    operations.  I'm not sure if softupdates must be turned on or not to
    get these improvements.  The data blocks can still stall, though, but 
    part of the plan for later this year is to fix that too.

:The benchmark program source code is available, and easy to run,
:the bottom of the report has links.

    test3:/test/tmp# sysctl -w vfs.write_behind=0		(turned off)
    test3:/test/tmp# time ./seekreadwrite xxx 10000
    0.125u 0.807s 0:00.93 98.9%     5+181k 0+0io 0pf+0w

    test3:/test/tmp# sysctl -w vfs.write_behind=1		(normal)
    test3:/test/tmp# time ./seekreadwrite xxx 10000
    0.040u 1.709s 0:32.57 5.3%      4+174k 0+8750io 0pf+0w


:I also have a range of results from an ATA (IDE) cheap deskside
:Dell system running FreeBSD 3.3-RELEASE, with a range of wd(4)
:flags.  This system exhibits much better performance than the SCSI
:systems above at this benchmark, perhaps related to better DMA
:ability.
:
:ATA being faster than SCSI on this benchmark is a bit of a side-issue
:to the thrust of this report, but the performance numbers may give
:hints diagnosing the problem.

    IDE drives sometimes appear to be faster because they fake the 
    write-completion response (they return the response prior to the
    write actually completing).  It could also simply be that the 
    lack of any real mixed I/O (due to the file being so small) is
    a slightly faster operation on an IDE drive.  I wouldn't read much
    into it... where SCSI really shines is in more heavily loaded 
    environments.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>

:Thanks,
:	Richard
:-
:Richard Wendland				richard@netcraft.com



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 17:11:43 2000
Delivered-To: freebsd-current@freebsd.org
Received: from wopr.caltech.edu (wopr.caltech.edu [131.215.240.222])
	by hub.freebsd.org (Postfix) with ESMTP id 7F38F37BB6E
	for <current@FreeBSD.ORG>; Tue, 21 Mar 2000 17:11:39 -0800 (PST)
	(envelope-from mph@wopr.caltech.edu)
Received: (from mph@localhost)
	by wopr.caltech.edu (8.9.3/8.9.3) id RAA46225;
	Tue, 21 Mar 2000 17:11:30 -0800 (PST)
	(envelope-from mph)
Date: Tue, 21 Mar 2000 17:11:30 -0800
From: Matthew Hunt <mph@astro.caltech.edu>
To: Martin Cracauer <cracauer@cons.org>
Cc: David Malone <dwmalone@maths.tcd.ie>, current@FreeBSD.ORG
Subject: Re: Floating point exceptions.
Message-ID: <20000321171130.B45589@wopr.caltech.edu>
References: <20000321095024.A1011@cons.org> <200003210924.aa02305@salmon.maths.tcd.ie> <20000321102843.A1455@cons.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <20000321102843.A1455@cons.org>; from cracauer@cons.org on Tue, Mar 21, 2000 at 10:28:43AM +0100
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Tue, Mar 21, 2000 at 10:28:43AM +0100, Martin Cracauer wrote:

> FreeBSD's fpsetmask(3) stuff is simple inline assembler that I
> personally used in Linux, it should be relativly easy to carry it
> around with your application on i386 machines.

fpsetmask(3) also exists on Solaris.

-- 
Matthew Hunt <mph@astro.caltech.edu> * Stay close to the Vorlon.
http://www.pobox.com/~mph/           *


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 17:14:37 2000
Delivered-To: freebsd-current@freebsd.org
Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193])
	by hub.freebsd.org (Postfix) with ESMTP id 163DE37BE12
	for <current@FreeBSD.ORG>; Tue, 21 Mar 2000 17:14:34 -0800 (PST)
	(envelope-from wollman@khavrinen.lcs.mit.edu)
Received: (from wollman@localhost)
	by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id UAA19794;
	Tue, 21 Mar 2000 20:14:27 -0500 (EST)
	(envelope-from wollman)
Date: Tue, 21 Mar 2000 20:14:27 -0500 (EST)
From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Message-Id: <200003220114.UAA19794@khavrinen.lcs.mit.edu>
To: Matthew Hunt <mph@astro.caltech.edu>
Cc: current@FreeBSD.ORG
Subject: Re: Floating point exceptions.
In-Reply-To: <20000321171130.B45589@wopr.caltech.edu>
References: <20000321095024.A1011@cons.org>
	<200003210924.aa02305@salmon.maths.tcd.ie>
	<20000321102843.A1455@cons.org>
	<20000321171130.B45589@wopr.caltech.edu>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

<<On Tue, 21 Mar 2000 17:11:30 -0800, Matthew Hunt <mph@astro.caltech.edu> said:

> fpsetmask(3) also exists on Solaris.

fpsetmask(3) was copied from System V.

-GAWollman

--
Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
wollman@lcs.mit.edu  | O Siem / The fires of freedom 
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA|                     - Susan Aglukark and Chad Irschick


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 17:45: 5 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mailg.telia.com (mailg.telia.com [194.22.194.26])
	by hub.freebsd.org (Postfix) with ESMTP id 05B4237BF2F
	for <freebsd-current@FreeBSD.ORG>; Tue, 21 Mar 2000 17:44:58 -0800 (PST)
	(envelope-from girgen@partitur.se)
Received: from d1o90.telia.com (d1o90.telia.com [195.67.216.241])
	by mailg.telia.com (8.9.3/8.9.3) with ESMTP id CAA20728;
	Wed, 22 Mar 2000 02:44:55 +0100 (CET)
Received: from stordatan.telia.com (t5o90p103.telia.com [213.64.7.103])
	by d1o90.telia.com (8.8.8/8.8.8) with ESMTP id CAA19050;
	Wed, 22 Mar 2000 02:44:54 +0100 (CET)
Received: from partitur.se (localhost [127.0.0.1])
	by stordatan.telia.com (8.9.3/8.9.1) with ESMTP id CAA09412;
	Wed, 22 Mar 2000 02:44:34 +0100 (CET)
	(envelope-from girgen@partitur.se)
Message-ID: <38D82582.EBCA5B95@partitur.se>
Date: Wed, 22 Mar 2000 02:44:34 +0100
From: Palle Girgensohn <girgen@partitur.se>
Organization: Partitur
X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.0-CURRENT i386)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: freebsd-current@FreeBSD.ORG
Subject: Re: can't dump vinum volumes after upgrading
References: <38D77DC7.7F161FCB@partitur.se> <20000321110023.E1731@mojave.worldwide.lemis.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Greg Lehey wrote:
> 
> On Tuesday, 21 March 2000 at 14:48:55 +0100, Palle Girgensohn wrote:
> > Hi!
> >
> > I'm having a strange problem after upgrading: There are no raw
> > devices created for vinum volumes.
> 
> Indeed there are.  You list them below.  There are no longer any block
> devices.
> 
> 
> This was a block device.
> 
...
> 
> This is now a character device.

OK. Of course. Cool!

> You don't describe what dump has to say.  I know that they put in a
> fix recently, but you don't say how old your system is.

The system is 4.0-STABLE, which is more or less 4.0-RELEASE right
now.

dump fails at the point were it is trying to convert the block
device listed in fstab to a raw device, by inserting a 'r' after
the last '/' in the pathname. This part of dump wasn't changed
since the initial import :)

in sbin/dump/main.c:546:

char *
rawname(cp)
        char *cp;
{
        static char rawbuf[MAXPATHLEN];
        char *dp = strrchr(cp, '/');

        if (dp == NULL)
                return (NULL);
        *dp = '\0';
        (void)strncpy(rawbuf, cp, MAXPATHLEN - 1);
        rawbuf[MAXPATHLEN-1] = '\0';
        *dp = '/';
        (void)strncat(rawbuf, "/r", MAXPATHLEN - 1 -
strlen(rawbuf));
        (void)strncat(rawbuf, dp + 1, MAXPATHLEN - 1 -
strlen(rawbuf));
        return (rawbuf);
}

So, here what dump says:
trumpet:vinum# dump 0af /dev/null /cluster1
  DUMP: Date of this level 0 dump: Wed Mar 22 02:10:20 2000
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/vinum/rcluster1 (/cluster1) to /dev/null
  DUMP: Cannot open /dev/vinum/rcluster1

which is rather expected.

My fstab has the line:
/dev/vinum/cluster1  /cluster1  ufs  rw  2  2

Since you've enlighted me with the fact that there are only
character devices in vinum nowadays, my suggestion is putting a
symlink rfilesys->filesys in /dev/vinum for each filesystem, or
creating device nodes named rfilesys as well. This would make
dump(8) happy anyway.

Also, the manual pages (both vinum(4) vinum(8)) seem to be a bit
off here, since they mention both raw devices,
/dev/rvinum/rfilesys and /dev/vinum/rfilesys, none of which I
have (I do have /dev/rvinum/filesys, but they were probably made
under 3.4, right? Can I remove them?).

Oh, by the way, I love vinum. Thanks for all the hard work!

Cheers,
Palle


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 17:47:22 2000
Delivered-To: freebsd-current@freebsd.org
Received: from overcee.netplex.com.au (peter1.yahoo.com [208.48.107.4])
	by hub.freebsd.org (Postfix) with ESMTP
	id 832E237BE15; Tue, 21 Mar 2000 17:47:17 -0800 (PST)
	(envelope-from peter@netplex.com.au)
Received: from netplex.com.au (localhost [127.0.0.1])
	by overcee.netplex.com.au (Postfix) with ESMTP
	id A8C561CC9; Tue, 21 Mar 2000 17:47:16 -0800 (PST)
	(envelope-from peter@netplex.com.au)
X-Mailer: exmh version 2.1.1 10/15/1999
To: Stephen Hocking-Senior Programmer PGS SPS Perth <shocking@prth.pgs.com>
Cc: current@FreeBSD.ORG, phk@freebsd.org
Subject: Re: Another current crash (cvs-cur.6183 
In-Reply-To: Message from Stephen Hocking-Senior Programmer PGS SPS Perth <shocking@prth.pgs.com> 
   of "Wed, 22 Mar 2000 08:51:53 +0800." <200003220051.IAA23805@bandicoot.prth.tensor.pgs.com> 
Date: Tue, 21 Mar 2000 17:47:16 -0800
From: Peter Wemm <peter@netplex.com.au>
Message-Id: <20000322014716.A8C561CC9@overcee.netplex.com.au>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Stephen Hocking-Senior Programmer PGS SPS Perth wrote:

This one you need to tell phk about: this is one of his sanity checks
that trapped and found an insane value. (and then crashed since you didn't
have DDB)

> #8  0xc0255f21 in Debugger (msg=0xc027b1e8 "d_iocmd botch")
>     at machine/cpufunc.h:64
> #9  0xc017385e in spec_strategy (ap=0xc5988df8)
>     at ../../miscfs/specfs/spec_vnops.c:438
> #10 0xc0173325 in spec_vnoperate (ap=0xc5988df8)
>     at ../../miscfs/specfs/spec_vnops.c:117
> #11 0xc020c3bd in ufs_vnoperatespec (ap=0xc5988df8)
>     at ../../ufs/ufs/ufs_vnops.c:2301
> #12 0xc0219167 in swapdev_strategy (ap=0xc5988e30) at vnode_if.h:923
> #13 0xc020d80e in swap_pager_putpages (object=0xc02f9ea0, m=0xc5988ee0, 
>     count=1, sync=0, rtvals=0xc5988e74) at vnode_if.h:923
> #14 0xc020c427 in default_pager_putpages (object=0xc02f9ea0, m=0xc5988ee0, 
>     c=1, sync=0, rtvals=0xc5988e74) at ../../vm/default_pager.c:133
> #15 0xc02175ea in vm_pageout_flush (mc=0xc5988ee0, count=1, flags=0)
>     at ../../vm/vm_pager.h:145
> #16 0xc021754d in vm_pageout_clean (m=0xc0464ae0) at ../../vm/vm_pageout.c:33
    8
> #17 0xc0217e6e in vm_pageout_scan () at ../../vm/vm_pageout.c:914
> #18 0xc0218764 in vm_pageout () at ../../vm/vm_pageout.c:1350
> #19 0xc02565e0 in fork_trampoline ()


Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
"All of this is for nothing if we don't go to the stars" - JMS/B5



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 18:17:54 2000
Delivered-To: freebsd-current@freebsd.org
Received: from vinyl.sentex.ca (vinyl.sentex.ca [209.112.4.14])
	by hub.freebsd.org (Postfix) with ESMTP id 0AD8437BD6A
	for <current@freebsd.org>; Tue, 21 Mar 2000 18:17:39 -0800 (PST)
	(envelope-from mike@sentex.net)
Received: from granite.sentex.net (granite-atm.sentex.ca [209.112.4.1])
	by vinyl.sentex.ca (8.9.3/8.9.3) with ESMTP id VAA39832;
	Tue, 21 Mar 2000 21:17:32 -0500 (EST)
	(envelope-from mike@sentex.net)
Received: from chimp.simianscience.com (ospf-mdt.sentex.net [205.211.164.81]) by granite.sentex.net (8.8.8/8.6.9) with SMTP id VAA05671; Tue, 21 Mar 2000 21:17:30 -0500 (EST)
From: mike@sentex.net (Mike Tancsa)
To: me@camtech.net.au (Matthew Sean Thyer)
Cc: current@freebsd.org
Subject: Re: Mylex Support
Date: Wed, 22 Mar 2000 02:17:22 GMT
Message-ID: <38d82cda.2345545986@mail.sentex.net>
References: <200003102325.PAA01007@mass.cdrom.com> <MAILPine.BSF.4.21.0003212200350.8769-100000@dx4.my-unregistered-domain.com>
In-Reply-To: <MAILPine.BSF.4.21.0003212200350.8769-100000@dx4.my-unregistered-domain.com>
X-Mailer: Forte Agent .99e/32.227
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On 21 Mar 2000 06:37:33 -0500, in sentex.lists.freebsd.current you wrote:
>
>or Should I have an internal ATA hard disk with some evil OS on it
>such as Lose 9X or NT so as to run any kind of Mylex DOS/Windows
>preparation utilities ?

With the old adaptors that do not have the RAID config built into the BIOS,
a DOS boot disk is enough.  Make a couple to gaurd against bad floppies and
you should be fine.

	---Mike

Mike Tancsa  (mdtancsa@sentex.net)		
Sentex Communications Corp,   		
Waterloo, Ontario, Canada
"Given enough time, 100 monkeys on 100 routers 
could setup a national IP network." (KDW2)


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 18:45:30 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [194.217.50.228])
	by hub.freebsd.org (Postfix) with ESMTP
	id 799A437C048; Tue, 21 Mar 2000 18:45:18 -0800 (PST)
	(envelope-from paul@originative.co.uk)
Received: from originative.co.uk (lobster.originative.co.uk [194.217.50.241])
	by mailgate.originative.co.uk (Postfix) with ESMTP
	id 614EA1D131; Wed, 22 Mar 2000 02:45:16 +0000 (GMT)
Message-ID: <38D833BC.A082DF09@originative.co.uk>
Date: Wed, 22 Mar 2000 02:45:16 +0000
From: Paul Richards <paul@originative.co.uk>
Organization: Originative Solutions Ltd
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 4.0-CURRENT i386)
X-Accept-Language: en-GB, en
MIME-Version: 1.0
To: Richard Wendland <richard@netcraft.com>
Cc: Alfred Perlstein <bright@wintelcom.net>,
	Poul-Henning Kamp <phk@critter.freebsd.dk>,
	Matthew Dillon <dillon@apollo.backplane.com>, current@FreeBSD.ORG,
	fs@FreeBSD.ORG
Subject: Re: FreeBSD random I/O performance issues
References: <200003220022.AAA28786@ns0.netcraft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Richard Wendland wrote:
> 

I spent a bit of time analysing these results when I first saw them. I
don't think it has anything to do with the cache, it has to do with how
we write out blocks.

> One interesting observation is that for non sync, async or noclusterw
> mounts ~8750 I/O operations are done, which is 7/8ths of the 10,000
> writes.  If I change the program to use 16 blocks there are ~9375
> I/O operations which is 15/16ths of the 10,000 writes.  Guessing,
> this is as if writes are forced for all blocks but one.

This is due to a quirk of the clustering algorithm. See below or my
previous email.

> With async filesystem mounts very little I/O occurs, and with
> noclusterw there are ~10,000 operations matching the number of
> writes.
> 
> With sync it's ~20,000 operations matching the total of reads &
> writes.  This demonstrates another aspect of the bug, sync behaviour
> should cause 10,000 operations; the reads aren't being cached.

This isn't quite true. It's 20,000 *write* operations. I put this down
to the mtime update for each write doubling the number of actual write
operations. No read operations take place, the data *does* come out of
the cache. There's nothing wrong with reading as far as I can tell.
  
> Another aspect of this issue is the effect of changing the seek
> blocksize, and write blocksize, by 1 byte each way from 8192, thus
> doing block unaligned I/O.  In some cases this changes the amount
> of I/O recorded by getrusage to zero, and drops elapse time from
> half a minute or so to less than 1 second.
> 
> Thanks to Paul Richard for noticing this.  I've not spent much time
> researching this, so can only present my small set of measurements.
> To do these tests you have to recompile my test program each time eg
> 
>         gcc -O4 -DBLOCKSIZE=8191 -DWRITESIZE=8193 seekreadwrite.c

This is because of the fact that if the filesystem block is full it is
written immediately, or rather the clustering code is called
immediately. The rationale is that a full block isn't likely to be
written to again so it might as well be pushed out to disk. Richard's
program deliberately writes full blocks, which is apparently what db
does, so it always forces a write to take place. Given the behaviour of
db it might be more sensible to remove this feature and just mark full
blocks dirty the same as other blocks since it's likely that they will
be written to again shortly if the db record is written to frequently.

The clustering code has a bug in that an old cluster is not pushed out
if the block no is 0 because the code that would do so never gets
reached.

if (lbn == 0)
        vp->v_lasta = vp->v_clen = vp->v_cstart = vp->v_lastw = 0;


if (vp->v_clen == 0 || lbn != vp->v_lastw + 1 ||
        (bp->b_blkno != vp->v_lasta + btodb(lblocksize))) {
        maxclen = vp->v_mount->mnt_iosize_max / lblocksize - 1;
        if (vp->v_clen != 0) {
            /*
             * Next block is not sequential.
             *
             * If we are not writing at end of file, the process
             * seeked to another point in the file since its last
             * write, or we have reached our maximum cluster size,
             * then push the previous cluster. Otherwise try
             * reallocating to make it sequential.
             */

         ............

In Richard's program the next block is never sequential so the previous
cluster is always pushed *except* that when the program seeks back to
block zero the
"if (vp->v_clen != 0)" fails and a new cluster is started without
pushing out the previously started one. That dirty block in the previous
cluster then hangs around until it is flushed as dirty blocks normally
would be.

It is the combination of this clustering behaviour and the fact that the
program always writes full blocks that causes the 8750 writes below.
Since the blocks are full file system blocks rather than mark them dirty
they are immediately passed to the clustering code, because they are
never in sequence the clustering code always starts a new cluster and
flushes the previous one except for 1 in every 8 blocks that doesn't
happen because when block 0 is written the previous cluster is not
pushed out but hangs around.  The end result is that 7/8 blocks get
written immediately which is 8750/10000 writes.

When the write size drops below the filesystem block size then the
clustering code never gets called because the buffers are just marked
dirty and cached.

I think if we fixed the issue of writing out full blocks this behviour
would stop but I also think the clustering code could do with a fix. It
should at least check to see if there is a cluster being built when the
blockno is 0 and push it out. Possibly though it'd be better to not push
out clusters of only one block and just leave them in the cache.

> 
> Sorry it's that crude.  These results are from a FreeBSD
> 2.2.7-RELEASE+CAM, ccd stripe=2 (PII 400MHz, 512MB) system,
> though exactly the same pattern is apparent with 3.4-STABLE.
> "****" indicate sub-second "zero I/O" results.
> 
> BLOCKSIZE   WRITESIZE   csh 'time' output
> 
> 8191        8191        0.0u 1.5s 0:34.10 4.6% 5+186k 0+7500io 0pf+0w
> 8191        8192        0.0u 1.3s 0:31.52 4.5% 5+178k 0+7500io 0pf+0w
> 8191        8193        0.0u 1.4s 0:32.63 4.4% 5+189k 0+7500io 0pf+0w
> 
> 8192        8191        0.0u 0.7s 0:01.97 37.5% 8+178k 0+0io 0pf+0w    ****
> 8192        8192        0.0u 1.3s 0:39.30 3.4% 7+196k 0+8750io 0pf+0w
> 8192        8193        0.0u 1.3s 0:40.09 3.4% 5+187k 0+8750io 0pf+0w
> 
> 8193        8191        0.0u 1.4s 0:46.22 3.2% 5+192k 0+8750io 0pf+0w
> 8193        8192        0.0u 1.6s 0:40.48 4.0% 5+182k 0+8750io 0pf+0w
> 8193        8193        0.0u 1.5s 0:40.57 3.8% 5+175k 0+8750io 0pf+0w
> 
> 8191        4095        0.0u 1.2s 0:33.79 3.6% 5+193k 0+7500io 0pf+0w
> 8191        4096        0.0u 1.2s 0:34.00 3.8% 5+190k 0+7500io 0pf+0w
> 8191        4097        0.0u 1.1s 0:33.58 3.6% 4+165k 0+7500io 0pf+0w
> 
> 8192        4095        0.0u 0.5s 0:00.76 75.0% 5+189k 0+0io 0pf+0w    ****
> 8192        4096        0.0u 0.5s 0:00.58 100.0% 5+183k 0+0io 0pf+0w   ****
> 8192        4097        0.0u 0.5s 0:00.74 78.3% 5+181k 0+0io 0pf+0w    ****
> 
> 8193        4095        0.0u 0.6s 0:01.00 67.0% 5+177k 0+0io 0pf+0w    ****
> 8193        4096        0.0u 0.6s 0:01.05 63.8% 5+179k 0+0io 0pf+0w    ****
> 8193        4097        0.0u 0.6s 0:01.02 66.6% 5+183k 0+0io 0pf+0w    ****
> 
> Any views gratefully received.  A fix would be much better :-)
> 
> Test program source, including compile & run instructions, is
> available at:
> 
>         http://www.netcraft.com/freebsd/random-IO/seekreadwrite.c
> 
> Detailed notes on the test system configurations are at:
> 
>         http://www.netcraft.com/freebsd/random-IO/results-notes.txt
> 
> Thanks,
>         Richard
> -
> Richard Wendland                                richard@netcraft.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 19: 2:23 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [194.217.50.228])
	by hub.freebsd.org (Postfix) with ESMTP
	id AAB7E37C06D; Tue, 21 Mar 2000 19:02:03 -0800 (PST)
	(envelope-from paul@originative.co.uk)
Received: from originative.co.uk (lobster.originative.co.uk [194.217.50.241])
	by mailgate.originative.co.uk (Postfix) with ESMTP
	id 77E0E1D131; Wed, 22 Mar 2000 03:02:02 +0000 (GMT)
Message-ID: <38D837AA.A93FF73B@originative.co.uk>
Date: Wed, 22 Mar 2000 03:02:02 +0000
From: Paul Richards <paul@originative.co.uk>
Organization: Originative Solutions Ltd
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 4.0-CURRENT i386)
X-Accept-Language: en-GB, en
MIME-Version: 1.0
To: Stephen Hocking-Senior Programmer PGS SPS Perth <shocking@prth.pgs.com>
Cc: current@freebsd.org, poul@freebsd.org
Subject: Re: Another current crash (cvs-cur.6183
References: <200003220051.IAA23805@bandicoot.prth.tensor.pgs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Stephen Hocking-Senior Programmer PGS SPS Perth wrote:
> 
> cvs-cur.6183 appeared to fix the crash I reported under disk activity & NFS
> but another one has reared its face, when using java with tya15 jit, running
> the Together java IDE.
> 
> #0  boot (howto=256) at ../../kern/kern_shutdown.c:304
> #1  0xc013d7e5 in panic (fmt=0xc0273534 "from debugger")
>     at ../../kern/kern_shutdown.c:554
> #2  0xc01265bd in db_panic (addr=-1071292639, have_addr=0, count=-1,
>     modif=0xc5988c64 "") at ../../ddb/db_command.c:433
> #3  0xc012655d in db_command (last_cmdp=0xc02abc2c, cmd_table=0xc02aba8c,
>     aux_cmd_tablep=0xc02e4578) at ../../ddb/db_command.c:333
> #4  0xc0126622 in db_command_loop () at ../../ddb/db_command.c:455
> #5  0xc0128733 in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
> #6  0xc0255cc1 in kdb_trap (type=3, code=0, regs=0xc5988d6c)
>     at ../../i386/i386/db_interface.c:158
> #7  0xc0262690 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 0,
>       tf_esi = -979913536, tf_ebp = -979857996, tf_isp = -979858024,
>       tf_ebx = -1044942540, tf_edx = 0, tf_ecx = -1070604512, tf_eax = 26,
>       tf_trapno = 3, tf_err = 0, tf_eip = -1071292639, tf_cs = 8,
>       tf_eflags = 12870, tf_esp = -1070994081, tf_ss = -1071140376})
>     at ../../i386/i386/trap.c:549
> #8  0xc0255f21 in Debugger (msg=0xc027b1e8 "d_iocmd botch")


I've got a different but I think related panic.

#9  0xc0143280 in panic (fmt=0xc0250460 "vm_page_wakeup: page not
busy!!!")
    at ../../kern/kern_shutdown.c:552
#10 0xc01df583 in swp_pager_async_iodone (bp=0xc3236250)
    at ../../vm/vm_page.h:346
#11 0xc0167ae6 in biodone (bp=0xc3236250) at ../../kern/vfs_bio.c:2706
#12 0xc0126b8d in dadone (periph=0xc092e380, done_ccb=0xc093f400)
    at ../../cam/scsi/scsi_da.c:1230
#13 0xc0122acb in camisr (queue=0xc029def0) at ../../cam/cam_xpt.c:6298
#14 0xc01228dd in swi_cambio () at ../../cam/cam_xpt.c:6201
#15 0xc021188b in doreti_swi ()

A few more details

#11 0xc0167ae6 in biodone (bp=0xc3236250) at ../../kern/vfs_bio.c:2706
2706			(*b_iodone) (bp);

#10 0xc01df583 in swp_pager_async_iodone (bp=0xc3236250)
    at ../../vm/vm_page.h:346
346		KASSERT(m->flags & PG_BUSY, ("vm_page_wakeup: page not busy!!!"));


I've got the dump if you want more diagnostics. It's hitting the KASSERT
on the second of 16 pages in the buf but none of them have PG_BUSY set
and it's only not panicing on the first page because
bp->b_pager.pg_reqpage is 0 and the call to vm_page_wakeup is skipped.



Paul.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 19: 9: 5 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [194.217.50.228])
	by hub.freebsd.org (Postfix) with ESMTP
	id A326237BD4C; Tue, 21 Mar 2000 19:09:02 -0800 (PST)
	(envelope-from paul@originative.co.uk)
Received: from originative.co.uk (lobster.originative.co.uk [194.217.50.241])
	by mailgate.originative.co.uk (Postfix) with ESMTP
	id CA38B1D131; Wed, 22 Mar 2000 03:08:59 +0000 (GMT)
Message-ID: <38D8394B.7586B5A3@originative.co.uk>
Date: Wed, 22 Mar 2000 03:08:59 +0000
From: Paul Richards <paul@originative.co.uk>
Organization: Originative Solutions Ltd
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 4.0-CURRENT i386)
X-Accept-Language: en-GB, en
MIME-Version: 1.0
To: Stephen Hocking-Senior Programmer PGS SPS Perth <shocking@prth.pgs.com>,
	current@freebsd.org, poul@freebsd.org
Subject: Re: Another current crash (cvs-cur.6183
References: <200003220051.IAA23805@bandicoot.prth.tensor.pgs.com> <38D837AA.A93FF73B@originative.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Paul Richards wrote:
> 
> 
> A few more details
> 
> #11 0xc0167ae6 in biodone (bp=0xc3236250) at ../../kern/vfs_bio.c:2706
> 2706                    (*b_iodone) (bp);
> 
> #10 0xc01df583 in swp_pager_async_iodone (bp=0xc3236250)
>     at ../../vm/vm_page.h:346
> 346             KASSERT(m->flags & PG_BUSY, ("vm_page_wakeup: page not busy!!!"));
>

I meant to add, people developing current should have INVARIANTS set and
then they'd spot panics like these before I do :-)

Paul.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 19:40:31 2000
Delivered-To: freebsd-current@freebsd.org
Received: from wint.itfs.nsk.su (wint.itfs.nsk.su [212.20.32.43])
	by hub.freebsd.org (Postfix) with ESMTP id D4FCF37BB50
	for <current@freebsd.org>; Tue, 21 Mar 2000 19:40:26 -0800 (PST)
	(envelope-from nnd@wint.itfs.nsk.su)
Received: (from nnd@localhost)
	by wint.itfs.nsk.su (8.9.3/8.9.3) id JAA05869;
	Wed, 22 Mar 2000 09:40:23 +0600 (NOVT)
	(envelope-from nnd)
Date: Wed, 22 Mar 2000 09:40:23 +0600 (NOVT)
Message-Id: <200003220340.JAA05869@wint.itfs.nsk.su>
From: nnd@mail.nsk.ru
To: current@freebsd.org
Subject: Re: 'machine/param.h' required for 'sys/socket.h' 
In-Reply-To: <200003211853.e2LIrUg87051@nimitz.ca.sandia.gov>
User-Agent: tin/1.4.2-20000123 ("Polish") (UNIX) (FreeBSD/5.0-CURRENT (i386))
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In <200003211853.e2LIrUg87051@nimitz.ca.sandia.gov> Bruce A. Mah <bmah@ca.sandia.gov> wrote:
> --==_Exmh_789141986P
> Content-Type: text/plain; charset=us-ascii
> 
> If memory serves me right, Yoshinobu Inoue wrote:
>> > > I feel requesting inclusion of machine/param.h for any apps
>> > > which use socket is better. But if there are any other smarter
>> > > solution, please let me know and I'll appreciate it much.
>> > 
>> > <machine/param.h> should never be included by applications since
>> > it is an implementation detail.
>> > 
>> > Specify including <sys/param.h> in apps which use the CMSG*() macros.
>> > <sys/socket.h> doesn't depend on <*/param.h> unless these macros are used.
>> > Since these macros are undocumented, applications that use them should
>> > expect problems :-).
>> > 
>> > Bruce
>> 
>> After reading bmah's message, now I am inclined to including
>> machine/param.h from sys/socket.h for maximum portability, if
>> there is no spec for it, and if all other platforms doing it.
> 
> Arrgh.  Now it seems I might need to reverse my position.  I looked
> through some code fragments in UNIX Network Programming (Volume 1,
> Second Edition, pp. 362-365), and there's some precedent for needing
> <sys/param.h> with the CMSG*() macros.
> 
> On the other hand, RFC 2292 and draft-ietf-ipngwg-rfc2292bis (the
> references I was originally working from) don't mention this requirement
> at all; they just say that CMSG*() are defined with <sys/socket.h>.  I'm
> slightly confused by now.
> 
> I'm going to send off a note to the authors of 
> draft-ietf-ipngwg-rfc229bis asking for some clarification.  In the 
> meantime, maybe we should hold off on doing any changes.

	Can we (temporary) unbroke 'net/pchar' port in FreeBSD
with the next patch (until the Perfect Solution will be found :-) :

===================================================================
diff -ruN pchar.orig/patches/patch-aa pchar/patches/patch-aa
--- pchar.orig/patches/patch-aa	Thu Jan  1 07:00:00 1970
+++ pchar/patches/patch-aa	Wed Mar 22 09:36:04 2000
@@ -0,0 +1,10 @@
+--- PctestIpv6Udp.h.ORIG	Wed Jan 19 23:14:42 2000
++++ PctestIpv6Udp.h	Wed Mar 22 09:31:19 2000
+@@ -29,6 +29,7 @@
+ #endif /* STDC_HEADERS */
+ 
+ #include <sys/types.h>
++#include <sys/param.h>
+ #include <sys/socket.h>
+ #include <netinet/in.h>
+ 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 20:10:16 2000
Delivered-To: freebsd-current@freebsd.org
Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252])
	by hub.freebsd.org (Postfix) with ESMTP id 9807F37C0E3
	for <freebsd-current@FreeBSD.org>; Tue, 21 Mar 2000 20:09:55 -0800 (PST)
	(envelope-from roberto@keltia.freenix.fr)
Received: (from uucp@localhost)
	by frmug.org (8.9.3/frmug-2.5/nospam) with UUCP id FAA02185
	for freebsd-current@FreeBSD.org; Wed, 22 Mar 2000 05:09:53 +0100 (CET)
	(envelope-from roberto@keltia.freenix.fr)
Received: by keltia.freenix.fr (Postfix, from userid 101)
	id D82E88869; Wed, 22 Mar 2000 01:30:39 +0100 (CET)
Date: Wed, 22 Mar 2000 01:30:39 +0100
From: Ollivier Robert <roberto@keltia.freenix.fr>
To: "FreeBSD Current Users' list" <freebsd-current@FreeBSD.org>
Subject: Re: /boot/loader is making my VAIO reboot
Message-ID: <20000322013039.A5087@keltia.freenix.fr>
Mail-Followup-To: FreeBSD Current Users' list <freebsd-current@FreeBSD.org>
References: <20000321171955.R93580@caerdonn.eurocontrol.fr> <200003211832.NAA05075@server.baldwin.cx>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200003211832.NAA05075@server.baldwin.cx>; from jhb@FreeBSD.org on Tue, Mar 21, 2000 at 01:32:19PM -0500
X-Operating-System: FreeBSD 4.0-CURRENT/ELF AMD-K6/200 & 2x PPro/200 SMP
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

According to John Baldwin:
> The only changes in sys/boot in that time period are the loader bcache
> fixes.  Can you see how far into the loader it is getting?  Also, what

No. It happens too fast. A few lines are displayed then it reboots.

> is in your /boot/loader.rc.  Try booting with an empty loader.rc and see
> if you can get a prompt, please.

Will try tomorrow (GMT+1 time).
-- 
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr
FreeBSD keltia.freenix.fr 4.0-CURRENT #78: Sun Feb 27 15:32:39 CET 2000



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 20:32:35 2000
Delivered-To: freebsd-current@freebsd.org
Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38])
	by hub.freebsd.org (Postfix) with ESMTP id 96B8037BB7A
	for <freebsd-current@FreeBSD.ORG>; Tue, 21 Mar 2000 20:32:32 -0800 (PST)
	(envelope-from obrien@NUXI.ucdavis.edu)
Received: from dragon.nuxi.com (root@d60-024.leach.ucdavis.edu [169.237.60.24])
	by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id UAA77831;
	Tue, 21 Mar 2000 20:32:32 -0800 (PST)
	(envelope-from obrien@dragon.nuxi.com)
Received: (from obrien@localhost)
	by dragon.nuxi.com (8.9.3/8.9.1) id UAA57692;
	Tue, 21 Mar 2000 20:32:28 -0800 (PST)
	(envelope-from obrien)
Date: Tue, 21 Mar 2000 20:32:27 -0800
From: "David O'Brien" <obrien@FreeBSD.ORG>
To: "Jose M. Alcaide" <jose@we.lc.ehu.es>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: suggestion: a g77 -> f77 link
Message-ID: <20000321203227.A57384@dragon.nuxi.com>
Reply-To: obrien@FreeBSD.ORG
References: <38CD1091.94E73AC9@we.lc.ehu.es> <20000314143826.D9311@dragon.nuxi.com> <vqcog8h9f3q.fsf@silvia.hip.berkeley.edu> <38D601E2.268BEB2B@we.lc.ehu.es> <20000320070411.A91543@dragon.nuxi.com> <38D66364.9839CFF1@we.lc.ehu.es>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <38D66364.9839CFF1@we.lc.ehu.es>; from jose@we.lc.ehu.es on Mon, Mar 20, 2000 at 06:44:04PM +0100
X-Operating-System: FreeBSD 4.0-CURRENT
Organization: The NUXI BSD group
X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3  90 76 5D 69 58 D9 98 7A
X-Pgp-Keyid: 34F9F9D5
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Mon, Mar 20, 2000 at 06:44:04PM +0100, Jose M. Alcaide wrote:
> > What part about "NO" was unclear?
> 
> Hey, OK, don't get upset! :-) You are the maintainer, so you have the

Not upset.  I was just surprised by the request again.

-- 
-- David    (obrien@NUXI.com)


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 20:45:55 2000
Delivered-To: freebsd-current@freebsd.org
Received: from rhenium.btinternet.com (rhenium.btinternet.com [194.73.73.93])
	by hub.freebsd.org (Postfix) with ESMTP
	id C177337BE15; Tue, 21 Mar 2000 20:45:48 -0800 (PST)
	(envelope-from mark@ukug.uk.freebsd.org)
Received: from [213.1.141.242] (helo=parish.my.domain)
	by ruthenium.btinternet.com with esmtp (Exim 2.05 #1)
	id 12XVkg-0001VB-00; Tue, 21 Mar 2000 20:59:47 +0000
Received: (from mark@localhost)
	by parish.my.domain (8.9.3/8.9.3) id UAA06971;
	Tue, 21 Mar 2000 20:57:19 GMT
	(envelope-from mark)
Date: Tue, 21 Mar 2000 20:57:17 +0000
From: Mark Ovens <mark@ukug.uk.freebsd.org>
To: "Kenneth D. Merry" <ken@kdm.org>
Cc: questions@FreeBSD.ORG, current@FreeBSD.ORG
Subject: Re: SCSI errors from xmcd
Message-ID: <20000321205717.C6493@parish>
References: <20000321201528.A6493@parish> <20000321135046.A41348@panzer.kdm.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <20000321135046.A41348@panzer.kdm.org>; from ken@kdm.org on Tue, Mar 21, 2000 at 01:50:46PM -0700
Organization: Total lack of
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Tue, Mar 21, 2000 at 01:50:46PM -0700, Kenneth D. Merry wrote:
> On Tue, Mar 21, 2000 at 20:15:29 +0000, Mark Ovens wrote:
> > Since u/g to 4.0 I've had problems with audio CD players and my
> > Toshiba XM6201 SCSI CD drive, cdcontrol and xmcd. Re-MAKEDEV'ing all
> > the cd devices has got cdcontrol working but still xmcd (v2.6)
> > doesn't. It all worked fine under 3.4-STABLE
> > 
> > Starting it with ``-debug'' yields a constant (one every few seconds)
> > stream  of:
> > 
> > SCSI CDB bytes (dev=/dev/rcd0c rw=0 to=20):
> > 0000    00 00 00 00 00 00 -- --  -- -- -- -- -- -- -- --    ................
> > CD audio: SCSI command fault on /dev/rcd0c:
> > Status=0x16
> > 
> > Is this because xmcd needs updating to work with the new CAM system,
> > or something else?
> 
> You need to recompile xmcd.
> 

In that case I need to wait for the package to be updated. xmcd needs
Motif, which I don't have, so I use the binary package.

Thanks for the quick response.

> Ken
> -- 
> Kenneth Merry
> ken@kdm.org

-- 
Seminars, n.:
       From "semi" and "arse", hence, any half-assed discussion.
________________________________________________________________
      FreeBSD - The Power To Serve http://www.freebsd.org
      My Webpage http://ukug.uk.freebsd.org/~mark/
mailto:mark@ukug.uk.freebsd.org             http://www.radan.com



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 21: 2:18 2000
Delivered-To: freebsd-current@freebsd.org
Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38])
	by hub.freebsd.org (Postfix) with ESMTP id 7145737BB18
	for <current@FreeBSD.ORG>; Tue, 21 Mar 2000 21:02:05 -0800 (PST)
	(envelope-from obrien@NUXI.ucdavis.edu)
Received: from dragon.nuxi.com (root@d60-024.leach.ucdavis.edu [169.237.60.24])
	by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id VAA78261;
	Tue, 21 Mar 2000 21:02:02 -0800 (PST)
	(envelope-from obrien@dragon.nuxi.com)
Received: (from obrien@localhost)
	by dragon.nuxi.com (8.9.3/8.9.1) id VAA82870;
	Tue, 21 Mar 2000 21:02:02 -0800 (PST)
	(envelope-from obrien)
Date: Tue, 21 Mar 2000 21:02:01 -0800
From: "David O'Brien" <obrien@FreeBSD.ORG>
To: Doug White <dwhite@resnet.uoregon.edu>
Cc: current@FreeBSD.ORG
Subject: Re: 4.0-RELEASE boot.flp fails to boot on K6/2
Message-ID: <20000321210201.B81118@dragon.nuxi.com>
Reply-To: obrien@FreeBSD.ORG
References: <38D71C22.62A29CCE@cybercable.fr> <Pine.BSF.4.21.0003211631260.50553-100000@resnet.uoregon.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <Pine.BSF.4.21.0003211631260.50553-100000@resnet.uoregon.edu>; from dwhite@resnet.uoregon.edu on Tue, Mar 21, 2000 at 04:32:35PM -0800
X-Operating-System: FreeBSD 4.0-CURRENT
Organization: The NUXI BSD group
X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3  90 76 5D 69 58 D9 98 7A
X-Pgp-Keyid: 34F9F9D5
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Tue, Mar 21, 2000 at 04:32:35PM -0800, Doug White wrote:
> I would be in favor of renaming the boot.flp to something obviously
> different, like 288boot.flp, to untrain us 2.x heads that got used to the

Great idea.  Would you be able to make the changes locally and test a
`make release'?  Then all we need to do is pass the patch pass JKH.
(harder to say "NO" to working code)

-- 
-- David    (obrien@NUXI.com)


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 21:10:52 2000
Delivered-To: freebsd-current@freebsd.org
Received: from ws-ilmar.ints.ru (ws-ilmar.ints.ru [194.67.173.16])
	by hub.freebsd.org (Postfix) with ESMTP id 842A637C0A4
	for <freebsd-current@FreeBSD.ORG>; Tue, 21 Mar 2000 21:10:44 -0800 (PST)
	(envelope-from ilmar@ints.ru)
Received: from localhost (localhost [127.0.0.1])
	by ws-ilmar.ints.ru (8.9.3/8.9.3) with ESMTP id IAA00473;
	Wed, 22 Mar 2000 08:10:33 +0300 (MSK)
Date: Wed, 22 Mar 2000 08:10:33 +0300 (MSK)
From: "Ilmar S. Habibulin" <ilmar@ints.ru>
To: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: -current sudden panics :(
In-Reply-To: <20000322005136H.shin@nd.net.fujitsu.co.jp>
Message-ID: <Pine.BSF.4.21.0003220808170.220-100000@ws-ilmar.ints.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Wed, 22 Mar 2000, Yoshinobu Inoue wrote:

> Do you have any other hints for the problem?, because at least
> I couldn't reproduce it in my 4.0 and 5.0 machines.
>   -Any kernel crash dump?
Can you tell me ddb command to make a kernel dump?

>   -Is there any typical situation or condition where the
>    problem happens?
I don't know. uptime between panics is from 5 minutes to 10 hours. They
are sudden as i sayd. :(

>   -What is your LAN card?
Something on realtek chiset(rl8139), maybe acorp. I don't remember. The
card worked fine for about one year.



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 21:15:57 2000
Delivered-To: freebsd-current@freebsd.org
Received: from ws-ilmar.ints.ru (ws-ilmar.ints.ru [194.67.173.16])
	by hub.freebsd.org (Postfix) with ESMTP id 62BDA37C07B
	for <freebsd-current@FreeBSD.ORG>; Tue, 21 Mar 2000 21:15:52 -0800 (PST)
	(envelope-from ilmar@ints.ru)
Received: from localhost (localhost [127.0.0.1])
	by ws-ilmar.ints.ru (8.9.3/8.9.3) with ESMTP id IAA00492;
	Wed, 22 Mar 2000 08:15:39 +0300 (MSK)
Date: Wed, 22 Mar 2000 08:15:39 +0300 (MSK)
From: "Ilmar S. Habibulin" <ilmar@ints.ru>
To: Nikolai Saoukh <nms@otdel-1.org>
Cc: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>,
	freebsd-current@FreeBSD.ORG
Subject: Re: -current sudden panics :(
In-Reply-To: <20000321192642.B8237@Draculina.otdel-1.org>
Message-ID: <Pine.BSF.4.21.0003220813250.220-100000@ws-ilmar.ints.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Tue, 21 Mar 2000, Nikolai Saoukh wrote:

> The driver for his card does not set packet header pointer, thus
> arp stuff see NULL pointer. small patch will cure this problem
> (at least I hope so).
> 
> *** if_ed.c.old	Tue Mar 21 19:21:40 2000
> --- if_ed.c	Tue Mar 21 19:23:27 2000
> ***************
> *** 2728,2733 ****
> --- 2728,2734 ----
>   	 */
>   	m->m_pkthdr.len = m->m_len = len - sizeof(struct ether_header);
>   	m->m_data += sizeof(struct ether_header);
> + 	m->m_pkthdr.header = (void *)eh;
>   
>   	ether_input(&sc->arpcom.ac_if, eh, m);
>   	return;
This is driver for ed(ne2000) cards. I have realtek(rl driver). I took a
look at his source and didn't find such strings. There is comment there
about cutting off mbuf header before passing it to ether_input - what's
this?



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 21:18:45 2000
Delivered-To: freebsd-current@freebsd.org
Received: from cheddar.netmonger.net (cheddar.netmonger.net [209.54.21.140])
	by hub.freebsd.org (Postfix) with ESMTP
	id A50C837BB18; Tue, 21 Mar 2000 21:18:38 -0800 (PST)
	(envelope-from chris@cheddar.netmonger.net)
Received: (from chris@localhost)
	by cheddar.netmonger.net (8.8.8/8.8.8) id AAA26606;
	Wed, 22 Mar 2000 00:16:05 -0500 (EST)
Message-ID: <20000322001604.A26234@netmonger.net>
Date: Wed, 22 Mar 2000 00:16:04 -0500
From: Christopher Masto <chris@netmonger.net>
To: Paul Richards <paul@originative.co.uk>,
	Stephen Hocking-Senior Programmer PGS SPS Perth <shocking@prth.pgs.com>
Cc: current@FreeBSD.ORG, poul@FreeBSD.ORG
Subject: Re: Another current crash (cvs-cur.6183
References: <200003220051.IAA23805@bandicoot.prth.tensor.pgs.com> <38D837AA.A93FF73B@originative.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.91.1i
In-Reply-To: <38D837AA.A93FF73B@originative.co.uk>; from Paul Richards on Wed, Mar 22, 2000 at 03:02:02AM +0000
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Wed, Mar 22, 2000 at 03:02:02AM +0000, Paul Richards wrote:
> I've got a different but I think related panic.
> 
> #9  0xc0143280 in panic (fmt=0xc0250460 "vm_page_wakeup: page not
> busy!!!")
>     at ../../kern/kern_shutdown.c:552
> #10 0xc01df583 in swp_pager_async_iodone (bp=0xc3236250)
>     at ../../vm/vm_page.h:346

I've been playing around with one of those iopener things and got
myself into a state I thought I could get out of with the help of a
USB Zip drive.  Unfortunately, upon purchasing and connecting one,
I discovered that I can't access it without a panic, which I
point out here on the chance it's also related.

#7  0xc024ac2c in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, 
      tf_edi = -1018879976, tf_esi = 256, tf_ebp = -919618472, tf_isp = -919618500, 
      tf_ebx = -1071201278, tf_edx = 0, tf_ecx = -1070746656, tf_eax = 18, 
      tf_trapno = 3, tf_err = 0, tf_eip = -1071396739, tf_cs = 8, tf_eflags = 582, 
      tf_esp = -1071099905, tf_ss = -1071212893}) at ../../i386/i386/trap.c:549
#8  0xc023c87d in Debugger (msg=0xc02696a3 "panic") at machine/cpufunc.h:64
#9  0xc01549e8 in panic (fmt=0xc026c402 "allocbuf: buffer too small")
    at ../../kern/kern_shutdown.c:552
#10 0xc0178f5a in allocbuf (bp=0xc3452018, size=83886080) at ../../kern/vfs_bio.c:2346
#11 0xc0178f01 in geteblk (size=83886080) at ../../kern/vfs_bio.c:2315
#12 0xc025cb57 in dsinit (dev=0xc0be1e00, lp=0xc0c490f4, sspp=0xc0c490f0)
    at ../../kern/subr_diskmbr.c:186
#13 0xc015eec6 in dsopen (dev=0xc0be1e00, mode=8192, flags=0, sspp=0xc0c490f0, 
    lp=0xc0c490f4) at ../../kern/subr_diskslice.c:683
#14 0xc015dfbf in diskopen (dev=0xc0be1e00, oflags=1, devtype=8192, p=0xc88be860)
    at ../../kern/subr_disk.c:146
#15 0xc018ae65 in spec_open (ap=0xc92fbe10) at ../../miscfs/specfs/spec_vnops.c:191
#16 0xc018ad65 in spec_vnoperate (ap=0xc92fbe10)
    at ../../miscfs/specfs/spec_vnops.c:117
#17 0xc01ff2e9 in ufs_vnoperatespec (ap=0xc92fbe10) at ../../ufs/ufs/ufs_vnops.c:2301
#18 0xc018595f in vn_open (ndp=0xc92fbedc, fmode=1, cmode=0) at vnode_if.h:189
#19 0xc0181951 in open (p=0xc88be860, uap=0xc92fbf80) at ../../kern/vfs_syscalls.c:994
#20 0xc024b4ce in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, 
      tf_edi = -1077937212, tf_esi = 134894800, tf_ebp = -1077937132, 
      tf_isp = -919617580, tf_ebx = 0, tf_edx = 8, tf_ecx = 134894828, tf_eax = 5, 
      tf_trapno = 12, tf_err = 2, tf_eip = 672026540, tf_cs = 31, tf_eflags = 642, 
      tf_esp = -1077937316, tf_ss = 47}) at ../../i386/i386/trap.c:1073
#21 0xc023cf26 in Xint0x80_syscall ()

I'm not intimately familiar with the function involved, and I'm out of
time tonight, so I'm backing up a few days to see if it goes away.
-- 
Christopher Masto         Senior Network Monkey      NetMonger Communications
chris@netmonger.net        info@netmonger.net        http://www.netmonger.net

Free yourself, free your machine, free the daemon -- http://www.freebsd.org/


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 21:28:59 2000
Delivered-To: freebsd-current@freebsd.org
Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228])
	by hub.freebsd.org (Postfix) with ESMTP
	id 26BFA37BC0C; Tue, 21 Mar 2000 21:28:58 -0800 (PST)
	(envelope-from jkh@zippy.cdrom.com)
Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1])
	by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id VAA19624;
	Tue, 21 Mar 2000 21:29:15 -0800 (PST)
	(envelope-from jkh@zippy.cdrom.com)
To: obrien@FreeBSD.ORG
Cc: Doug White <dwhite@resnet.uoregon.edu>, current@FreeBSD.ORG
Subject: Re: 4.0-RELEASE boot.flp fails to boot on K6/2 
In-reply-to: Your message of "Tue, 21 Mar 2000 21:02:01 PST."
             <20000321210201.B81118@dragon.nuxi.com> 
Date: Tue, 21 Mar 2000 21:29:15 -0800
Message-ID: <19621.953702955@zippy.cdrom.com>
From: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Good idea, terrible name.  Can't you guys some up with something better? :)

> On Tue, Mar 21, 2000 at 04:32:35PM -0800, Doug White wrote:
> > I would be in favor of renaming the boot.flp to something obviously
> > different, like 288boot.flp, to untrain us 2.x heads that got used to the
> 
> Great idea.  Would you be able to make the changes locally and test a
> `make release'?  Then all we need to do is pass the patch pass JKH.
> (harder to say "NO" to working code)
> 
> -- 
> -- David    (obrien@NUXI.com)
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 22: 0: 4 2000
Delivered-To: freebsd-current@freebsd.org
Received: from ws-ilmar.ints.ru (ws-ilmar.ints.ru [194.67.173.16])
	by hub.freebsd.org (Postfix) with ESMTP id 5F98A37C08E
	for <freebsd-current@FreeBSD.ORG>; Tue, 21 Mar 2000 21:59:59 -0800 (PST)
	(envelope-from ilmar@ints.ru)
Received: from localhost (localhost [127.0.0.1])
	by ws-ilmar.ints.ru (8.9.3/8.9.3) with ESMTP id IAA01815;
	Wed, 22 Mar 2000 08:59:45 +0300 (MSK)
Date: Wed, 22 Mar 2000 08:59:45 +0300 (MSK)
From: "Ilmar S. Habibulin" <ilmar@ints.ru>
To: Warner Losh <imp@village.org>
Cc: Nikolai Saoukh <nms@otdel-1.org>,
	Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>,
	freebsd-current@FreeBSD.ORG
Subject: Re: -current sudden panics :( 
In-Reply-To: <200003212323.QAA26513@harmony.village.org>
Message-ID: <Pine.BSF.4.21.0003220858370.220-100000@ws-ilmar.ints.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Tue, 21 Mar 2000, Warner Losh wrote:

> In message <20000321195737.A8366@Draculina.otdel-1.org> Nikolai Saoukh writes:
> : > But shouldn't it be sys/pci/if_rl.c ?
> : 
> : Sorry,
> : it is mea culpa. I mixed his case with my (token ring).
> 
> Do you have the patch to if_rl.c.  I looked at it for all of 10
> seconds and it wasn't immediately obvious to me.

But why there is such a sudden change? Everything worked just fine a week
before 5-current.



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 22: 9:39 2000
Delivered-To: freebsd-current@freebsd.org
Received: from fgwmail7.fujitsu.co.jp (fgwmail7.fujitsu.co.jp [192.51.44.37])
	by hub.freebsd.org (Postfix) with ESMTP id ECFA737BBAB
	for <freebsd-current@FreeBSD.ORG>; Tue, 21 Mar 2000 22:09:35 -0800 (PST)
	(envelope-from shin@nd.net.fujitsu.co.jp)
Received: from m3.gw.fujitsu.co.jp by fgwmail7.fujitsu.co.jp (8.9.3/3.7W-MX0002-Fujitsu Gateway)
	id PAA11122; Wed, 22 Mar 2000 15:09:26 +0900 (JST)
	(envelope-from shin@nd.net.fujitsu.co.jp)
Received: from chisato.nd.net.fujitsu.co.jp by m3.gw.fujitsu.co.jp (8.9.3/3.7W-0002-Fujitsu Domain Master)
	id PAA25445; Wed, 22 Mar 2000 15:09:26 +0900 (JST)
Received: from localhost (dhcp7173.nd.net.fujitsu.co.jp [10.18.7.173]) by chisato.nd.net.fujitsu.co.jp (8.8.5+2.7Wbeta5/3.3W8chisato-970826) with ESMTP id PAA07937; Wed, 22 Mar 2000 15:09:24 +0900 (JST)
To: ilmar@ints.ru
Cc: nms@otdel-1.org, freebsd-current@FreeBSD.ORG
Subject: Re: -current sudden panics :(
In-Reply-To: <Pine.BSF.4.21.0003220813250.220-100000@ws-ilmar.ints.ru>
References: <20000321192642.B8237@Draculina.otdel-1.org>
	<Pine.BSF.4.21.0003220813250.220-100000@ws-ilmar.ints.ru>
X-Mailer: Mew version 1.94 on Emacs 20.4 / Mule 4.0 (HANANOEN)
X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000322151022G.shin@nd.net.fujitsu.co.jp>
Date: Wed, 22 Mar 2000 15:10:22 +0900
From: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 25
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> > The driver for his card does not set packet header pointer, thus
> > arp stuff see NULL pointer. small patch will cure this problem
> > (at least I hope so).
> > 
> > *** if_ed.c.old	Tue Mar 21 19:21:40 2000
> > --- if_ed.c	Tue Mar 21 19:23:27 2000
> > ***************
> > *** 2728,2733 ****
> > --- 2728,2734 ----
> >   	 */
> >   	m->m_pkthdr.len = m->m_len = len - sizeof(struct ether_header);
> >   	m->m_data += sizeof(struct ether_header);
> > + 	m->m_pkthdr.header = (void *)eh;
> >   
> >   	ether_input(&sc->arpcom.ac_if, eh, m);
> >   	return;
> This is driver for ed(ne2000) cards. I have realtek(rl driver). I took a
> look at his source and didn't find such strings. There is comment there
> about cutting off mbuf header before passing it to ether_input - what's
> this?

I think this fix is only necessary for token-ring case (as he
say in his following mail), and not related to ethernet.

Yoshinobu Inoue


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 22:18: 4 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP
	id 80A3637BB18; Tue, 21 Mar 2000 22:17:57 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id WAA86154;
	Tue, 21 Mar 2000 22:17:52 -0800 (PST)
	(envelope-from dillon)
Date: Tue, 21 Mar 2000 22:17:52 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003220617.WAA86154@apollo.backplane.com>
To: Paul Richards <paul@originative.co.uk>
Cc: Richard Wendland <richard@netcraft.com>,
	Alfred Perlstein <bright@wintelcom.net>,
	Poul-Henning Kamp <phk@critter.freebsd.dk>, current@FreeBSD.ORG,
	fs@FreeBSD.ORG
Subject: Re: FreeBSD random I/O performance issues
References: <200003220022.AAA28786@ns0.netcraft.com> <38D833BC.A082DF09@originative.co.uk>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

:written immediately which is 8750/10000 writes.
:
:When the write size drops below the filesystem block size then the
:clustering code never gets called because the buffers are just marked
:dirty and cached.
:
:I think if we fixed the issue of writing out full blocks this behviour
:would stop but I also think the clustering code could do with a fix. It
:should at least check to see if there is a cluster being built when the
:blockno is 0 and push it out. Possibly though it'd be better to not push
:out clusters of only one block and just leave them in the cache.

    Hmm.  Your analysis is correct but I don't think it's worth
    fixing the block-is-0 case.   It may be worth revisiting the
    write-behind code to try to give it the ability to better discern
    random I/O from sequential I/O (e.g. perhaps it should ignore unaligned
    full blocks).

    It is perfectly ok for dirty blocks to remain in the buffer cache.  In
    fact, it's *optimal* to leave them in the buffer cache as long as the
    buffer cache does not get saturated with them.  The buffer cache is
    perfectly capable of clustering delayed writes.  Also, the filesystem 
    syncer comes along every 30 seconds or so anyway and flushes everything
    out.

    What the write-behind code tries to do is to prevent the buffer cache 
    from being saturated with dirty buffers and to smooth out disk write
    I/O.  It makes the assumption that write-behind data is not typically
    accessed by the program immediately after being written -- an assumption
    that winds up being incorrect in the DBM case you tested and resulting
    in stalls due to the buffer / VM pages being locked during the write I/O.
    The stalls are *not* due to the I/O itself but instead are due to side
    effects of the I/O being in-progress.  If a user program doesn't access
    any of the information it recently wrote the whole mechanism winds up
    operating asynchronously in the background.  If a user program does, 
    then the write behind mechanism breaks down and you get a stall.

    The most common dirty-data case the filesystem has to deal with is 
    appending to a file -- that is, doing piecemeal sequential writes.  There
    are virtually no other cases which have the ability to saturate the
    buffer cache.  This is why the write-behind code only tries to handle
    the piecemeal-write-flush-full-blocks case.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 22:18:37 2000
Delivered-To: freebsd-current@freebsd.org
Received: from fgwmail5.fujitsu.co.jp (fgwmail5.fujitsu.co.jp [192.51.44.35])
	by hub.freebsd.org (Postfix) with ESMTP id C2B1837C081
	for <freebsd-current@FreeBSD.ORG>; Tue, 21 Mar 2000 22:18:33 -0800 (PST)
	(envelope-from shin@nd.net.fujitsu.co.jp)
Received: from m1.gw.fujitsu.co.jp by fgwmail5.fujitsu.co.jp (8.9.3/3.7W-MX0002-Fujitsu Gateway)
	id PAA18661; Wed, 22 Mar 2000 15:18:31 +0900 (JST)
	(envelope-from shin@nd.net.fujitsu.co.jp)
Received: from chisato.nd.net.fujitsu.co.jp by m1.gw.fujitsu.co.jp (8.9.3/3.7W-0002-Fujitsu Domain Master)
	id PAA09642; Wed, 22 Mar 2000 15:18:29 +0900 (JST)
Received: from localhost (dhcp7173.nd.net.fujitsu.co.jp [10.18.7.173]) by chisato.nd.net.fujitsu.co.jp (8.8.5+2.7Wbeta5/3.3W8chisato-970826) with ESMTP id PAA08198; Wed, 22 Mar 2000 15:18:29 +0900 (JST)
To: ilmar@ints.ru
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: -current sudden panics :(
In-Reply-To: <Pine.BSF.4.21.0003220808170.220-100000@ws-ilmar.ints.ru>
References: <20000322005136H.shin@nd.net.fujitsu.co.jp>
	<Pine.BSF.4.21.0003220808170.220-100000@ws-ilmar.ints.ru>
X-Mailer: Mew version 1.94 on Emacs 20.4 / Mule 4.0 (HANANOEN)
X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000322151927H.shin@nd.net.fujitsu.co.jp>
Date: Wed, 22 Mar 2000 15:19:27 +0900
From: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 22
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> >   -Any kernel crash dump?
> Can you tell me ddb command to make a kernel dump?

 -Please confirm that your /var/crash has enough size for your
  machine's memory.

 -Please check your swap device using "swapinfo" etc.
  In case of my machine,

   % swapinfo
   Device      1K-blocks     Used    Avail Capacity  Type
   /dev/wd0s2b    262144    75612   186404    29%    Interleaved

 -Please sepcify it as dumpdev in your /etc/rc.conf

   dumpdev="/dev/wd0s2b"

Then at the reboot of after a panic, crash dump will be
written to files under /var/crash/.

Cheers,
Yoshinobu Inoue


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 22:34: 2 2000
Delivered-To: freebsd-current@freebsd.org
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131])
	by hub.freebsd.org (Postfix) with ESMTP
	id C791337C0C5; Tue, 21 Mar 2000 22:33:55 -0800 (PST)
	(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1])
	by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id HAA29685;
	Wed, 22 Mar 2000 07:33:35 +0100 (CET)
	(envelope-from phk@critter.freebsd.dk)
To: Paul Richards <paul@originative.co.uk>
Cc: Stephen Hocking-Senior Programmer PGS SPS Perth <shocking@prth.pgs.com>,
	current@freebsd.org, poul@freebsd.org
Subject: Re: Another current crash (cvs-cur.6183 
In-reply-to: Your message of "Wed, 22 Mar 2000 03:08:59 GMT."
             <38D8394B.7586B5A3@originative.co.uk> 
Date: Wed, 22 Mar 2000 07:33:35 +0100
Message-ID: <29683.953706815@critter.freebsd.dk>
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <38D8394B.7586B5A3@originative.co.uk>, Paul Richards writes:
>Paul Richards wrote:
>> 
>> 
>> A few more details
>> 
>> #11 0xc0167ae6 in biodone (bp=0xc3236250) at ../../kern/vfs_bio.c:2706
>> 2706                    (*b_iodone) (bp);
>> 
>> #10 0xc01df583 in swp_pager_async_iodone (bp=0xc3236250)
>>     at ../../vm/vm_page.h:346
>> 346             KASSERT(m->flags & PG_BUSY, ("vm_page_wakeup: page not busy!!!"));
>>
>
>I meant to add, people developing current should have INVARIANTS set and
>then they'd spot panics like these before I do :-)

Paul, what on earth makes you think we don't run with INVARIANTS ?  :-)


But it might actually make a lot of sense to make INVARIANTS the
default this early in the -CURRENT cycle, protests ?

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 22:43: 6 2000
Delivered-To: freebsd-current@freebsd.org
Received: from iclub.nsu.ru (iclub.nsu.ru [193.124.222.66])
	by hub.freebsd.org (Postfix) with ESMTP id 7C3EA37C156
	for <current@freebsd.org>; Tue, 21 Mar 2000 22:40:25 -0800 (PST)
	(envelope-from fjoe@iclub.nsu.ru)
Received: from localhost (fjoe@localhost)
	by iclub.nsu.ru (8.9.3/8.9.3) with ESMTP id MAA03200
	for <current@freebsd.org>; Wed, 22 Mar 2000 12:39:47 +0600 (NS)
	(envelope-from fjoe@iclub.nsu.ru)
Date: Wed, 22 Mar 2000 12:39:47 +0600 (NS)
From: Max Khon <fjoe@iclub.nsu.ru>
To: current@freebsd.org
Subject: ARP issues (Arcnet)
Message-ID: <Pine.BSF.4.21.0003221233490.2948-100000@iclub.nsu.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

hi, there!

Once again I'm trying to port Arcnet driver from NetBSD/amiga to
FreeBSD/i386 (like I did more than a year ago for 3.x). The problem is in
ARP stuff -- should I port if_arp.c from NetBSD or should I make changes
in if_ether.c for arcnet stuff like Token Ring support did?
Any suggestions are appreciated.

/fjoe



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 22:53:17 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mta4.snfc21.pbi.net (mta4.snfc21.pbi.net [206.13.28.142])
	by hub.freebsd.org (Postfix) with ESMTP id 076DD37BD89
	for <current@FreeBSD.ORG>; Tue, 21 Mar 2000 22:53:16 -0800 (PST)
	(envelope-from jazepeda@pacbell.net)
Received: from zippy.dyn.ml.org ([207.214.149.200])
 by mta4.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9)
 with ESMTP id <0FRT007D09RMYD@mta4.snfc21.pbi.net> for current@FreeBSD.ORG;
 Tue, 21 Mar 2000 22:52:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by zippy.dyn.ml.org (Postfix)
 with ESMTP id E09457C00D; Tue, 21 Mar 2000 22:52:35 -0800 (PST)
Date: Tue, 21 Mar 2000 22:52:35 -0800 (PST)
From: Alex Zepeda <jazepeda@pacbell.net>
Subject: Re: 4.0-RELEASE boot.flp fails to boot on K6/2
In-reply-to: <19621.953702955@zippy.cdrom.com>
To: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>
Cc: current <current@FreeBSD.ORG>
Message-id: <Pine.BSF.4.21.0003212252080.316-100000@localhost>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Tue, 21 Mar 2000, Jordan K. Hubbard wrote:

> Good idea, terrible name.  Can't you guys some up with something better? :)

reallybigbootthing.flp?

- alex



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 22:56: 0 2000
Delivered-To: freebsd-current@freebsd.org
Received: from sharmas.dhs.org (c62443-a.frmt1.sfba.home.com [24.0.69.165])
	by hub.freebsd.org (Postfix) with ESMTP id F1F5837BCC9
	for <current@FreeBSD.ORG>; Tue, 21 Mar 2000 22:55:57 -0800 (PST)
	(envelope-from adsharma@sharmas.dhs.org)
Received: (from adsharma@localhost)
	by sharmas.dhs.org (8.9.3/8.9.3) id WAA04550;
	Tue, 21 Mar 2000 22:54:32 -0800 (PST)
	(envelope-from adsharma)
Date: Tue, 21 Mar 2000 22:54:32 -0800
From: Arun Sharma <adsharma@sharmas.dhs.org>
To: Marcel Moolenaar <marcel@scc.nl>
Cc: Peter Wemm <peter@netplex.com.au>, current@FreeBSD.ORG
Subject: ucontext
Message-ID: <20000321225432.A4533@sharmas.dhs.org>
References: <19990907103348.2801F1CA8@overcee.netplex.com.au> <37D4F557.F4F743E7@scc.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <37D4F557.F4F743E7@scc.nl>; from marcel@scc.nl on Tue, Sep 07, 1999 at 01:21:59PM +0200
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Tue, Sep 07, 1999 at 01:21:59PM +0200, Marcel Moolenaar wrote:
> Peter Wemm wrote:
> > 
> > Before getting too far here, can we consider some other standard interfaces?
> > 
> >      #include <ucontext.h>
> > 
> >      int getcontext(ucontext_t *ucp);
> >      int setcontext(const ucontext_t *ucp);
> >      void makecontext(ucontext_t *ucp, (void *func)(), int argc, ...);
> >      int swapcontext(ucontext_t *oucp, const ucontext_t *ucp);
> > 
> > http://www.opengroup.org/onlinepubs/007908799/xsh/ucontext.h.html
> > 
> > setjmp,longjmp,sigreturn,etc can all be done with this interface and it can
> > be used for libc_r and future kernel-assisted threading.
> 
> We're at a point where the discussion, altough meaningful and important,
> has no direct impact on the sigset_t change. I agree with Peter that we
> should as well consider the ucontext interface, but prefer to stay focussed
> on changing sigset_t. So, here's where I shut up and let you discuss the
> matter further :-)

Is anyone working on this ? Porting JDKs to FreeBSD would be a lot easier
if these routines are implemented.

	-Arun


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 22:59:14 2000
Delivered-To: freebsd-current@freebsd.org
Received: from rover.village.org (rover.village.org [204.144.255.49])
	by hub.freebsd.org (Postfix) with ESMTP id 82F3737C0E9
	for <freebsd-current@FreeBSD.ORG>; Tue, 21 Mar 2000 22:59:08 -0800 (PST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (harmony.village.org [10.0.0.6])
	by rover.village.org (8.9.3/8.9.3) with ESMTP id XAA26307;
	Tue, 21 Mar 2000 23:59:05 -0700 (MST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id XAA29305; Tue, 21 Mar 2000 23:58:49 -0700 (MST)
Message-Id: <200003220658.XAA29305@harmony.village.org>
To: "Ilmar S. Habibulin" <ilmar@ints.ru>
Subject: Re: -current sudden panics :( 
Cc: Nikolai Saoukh <nms@otdel-1.org>,
	Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>,
	freebsd-current@FreeBSD.ORG
In-reply-to: Your message of "Wed, 22 Mar 2000 08:59:45 +0300."
		<Pine.BSF.4.21.0003220858370.220-100000@ws-ilmar.ints.ru> 
References: <Pine.BSF.4.21.0003220858370.220-100000@ws-ilmar.ints.ru>  
Date: Tue, 21 Mar 2000 23:58:49 -0700
From: Warner Losh <imp@village.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <Pine.BSF.4.21.0003220858370.220-100000@ws-ilmar.ints.ru> "Ilmar S. Habibulin" writes:
: But why there is such a sudden change? Everything worked just fine a week
: before 5-current.

No it didn't.  I've been seeing panics like this for about two weeks,
but it hadn't been a priority until this week for me.  And I'm not
seeing it on lightly loaded networks, but am on heavily loaded ones.
Since our product's network port is just for debugging, it isn't a big
deal to me....

It is definitely a load related problem for me.  It usually works just
fine, but sometimes there's a packet that gets to arp that arp barfs
on.

Warner


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 23: 1:37 2000
Delivered-To: freebsd-current@freebsd.org
Received: from 001.co.jp (ej1.001.co.jp [210.146.252.72])
	by hub.freebsd.org (Postfix) with ESMTP
	id A712D37C0E9; Tue, 21 Mar 2000 23:01:16 -0800 (PST)
	(envelope-from mic@001.co.jp)
Received: from ej1.001.co.jp.001.co.jp ([192.168.100.33])
	by 001.co.jp (8.8.8/3.6W:Mon Mar 16 22:26:19 JST 1998) with SMTP id OAA13838;
	Wed, 22 Mar 2000 14:52:33 +0900 (JST)
Message-ID: <002601bf93c5$3abbf4a0$2164a8c0@ej1.001.co.jp.001.co.jp>
From: "=?iso-2022-jp?B?GyRCJTAlbCE8JUglOCVjITwlSyE8GyhC?=" <mic@001.co.jp>
To: <mic@001.co.jp>
Subject: =?iso-2022-jp?B?IBskQiUwJWwhPCVIJTglYyVLITwbKEIgTkVXUyAbJEIhShsoQnZvbC4x?=
	=?iso-2022-jp?B?ORskQiFLGyhCIDAzMjIxMDA5?=
Date: Wed, 22 Mar 2000 15:09:12 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

$B!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=(B
$BFMA3$N%a!<%k$9$k$3$H$r$*5v$72<$5$$!#(B
$B8fLBOG$N$+$+$C$F$7$^$C$?J}!"$3$N%a!<%k$,ITMW$JJ}$XFO$$$F(B
$B$7$^$C$F$$$^$7$?$i?<$/$*OM$S?=$7>e$2$^$9!#(B
$B8fMF<O2<$5$$$^$;!#(B
$B!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=!=(B

$B%0%l!<%H%8%c!<%K!<(BNEWS(vol $B#1#9(B)

$B#47n$+$i$N3$30N99T!'?7>&IJ$N$40FFb$G$9!#(B

$BEv<R?M5$#3%3!<%9$r%T%C%/%"%C%W$7$F$_$^$7$?!#(B
$B$*F@$J@_Dj$H$J$C$F$*$j$^$9!#@'Hs$4MxMQ$/$@$5$$!#(B

$B%0%l!<%H%8%c!<%K!<(BNEWS
---$B!~"!!~#47n$+$i$N?7>&IJ"!!~(B---

http://www.001.co.jp/mic/gj/beach/supuringkyanpen3.html

$B-!(B $BF|K\9R6uMxMQ!A%"%8%"$NN9!A!!(B
$B!J9a9A!&%7%s%,%]!<%k!&%^%l!<%7%"!&%?%$!&%U%#%j%T%s!&%;%V(B
$B!&%P%j!&%Y%H%J%`!&4Z(B
$B9q!K(B

$B-"(B $B%b%k%G%#%V%D%"!<(B
$B#37nCf$K$4M=Ls$rD:$$$?J}$K$O!"0lN'!o#5!"#0#0#0$N%G%#%9%+(B
$B%&%s%H!*!*(B

$B-#(B $B%S%s%?%sEg!u%7%s%,%]!<%k#5F|4V(B
$B!A:#$A$g$C$H$7$?%V!<%`$K$J$C$F$^$9!A(B


$B$*Ld$$9g$o$;$r?4$h$j$*BT$A?=$7>e$2$F$*$j$^$9!#(B

$B3t<02q<R%_%/%m%M%7%"(B
$B!J1?M"Bg?CEPO?N99T6HBh#6#3#29f!&F|K\N99T6H6(2q@52q0w!K(B
$B%0%l!<%H%8%c!<%K!<(B
$BC4Ev!':4F#(B
$BEEOC!'#0#3!=#3#7#9#7!=#5#7#1#1!!!!!!(B
   $B!!!!!!(B




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 23: 5:36 2000
Delivered-To: freebsd-current@freebsd.org
Received: from BSDpc.geek4food.org (adsl-216-103-105-71.dsl.snfc21.pacbell.net [216.103.105.71])
	by hub.freebsd.org (Postfix) with ESMTP
	id 480E137C0F9; Tue, 21 Mar 2000 23:05:32 -0800 (PST)
	(envelope-from andy@geek4food.org)
Received: from mega.geek4food.org (mega.geek4food.org [192.168.1.57])
	by BSDpc.geek4food.org (Postfix) with ESMTP
	id 2EDBB421; Wed, 22 Mar 2000 07:05:31 +0000 (GMT)
Received: from mega.geek4food.org (localhost.geek4food.org [127.0.0.1])
	by mega.geek4food.org (8.9.3/8.9.3) with ESMTP id XAA33131;
	Tue, 21 Mar 2000 23:05:30 -0800 (PST)
	(envelope-from andy@geek4food.org)
Message-Id: <200003220705.XAA33131@mega.geek4food.org>
To: Mark Ovens <mark@ukug.uk.freebsd.org>
Cc: "Kenneth D. Merry" <ken@kdm.org>, questions@FreeBSD.ORG,
	current@FreeBSD.ORG
Subject: Re: SCSI errors from xmcd 
In-reply-to: Your message of "Tue, 21 Mar 2000 20:57:17 GMT."
             <20000321205717.C6493@parish> 
Date: Tue, 21 Mar 2000 23:05:30 -0800
From: Andy Sparrow <andy@geek4food.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Your message dated: Tue, 21 Mar 2000 20:57:17 GMT

>> > Is this because xmcd needs updating to work with the new CAM system,
>> > or something else?
>> 
>> You need to recompile xmcd.
>> 
>
>In that case I need to wait for the package to be updated. xmcd needs
>Motif, which I don't have, so I use the binary package.

I find a lot of stuff which "needs" Motif (including 'xmcd') builds and 
works just great with Lesstif, and there's a port for that. You might like
to set 'HAVE_MOTIF=yes' manually in '/etc/make.conf' after installing. :-)


Something else that sometimes causes problems might be having old-as-dirt 
libraries kicking around from aeons ago - sometimes these seem to get used 
if they're present on the system, and not much cleans them out except
operator intervention...


Cheers,

AS



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 23:26:24 2000
Delivered-To: freebsd-current@freebsd.org
Received: from freebsd.dk (freebsd.dk [212.242.42.178])
	by hub.freebsd.org (Postfix) with ESMTP id 6921937C0A1
	for <current@FreeBSD.ORG>; Tue, 21 Mar 2000 23:26:20 -0800 (PST)
	(envelope-from sos@freebsd.dk)
Received: (from sos@localhost)
	by freebsd.dk (8.9.3/8.9.1) id IAA44014;
	Wed, 22 Mar 2000 08:26:07 +0100 (CET)
	(envelope-from sos)
From: Soren Schmidt <sos@freebsd.dk>
Message-Id: <200003220726.IAA44014@freebsd.dk>
Subject: Re: Reading from bad disk ?
In-Reply-To: <200003212318.QAA26473@harmony.village.org> from Warner Losh at "Mar 21, 2000 04:18:18 pm"
To: imp@village.org (Warner Losh)
Date: Wed, 22 Mar 2000 08:26:07 +0100 (CET)
Cc: phk@critter.freebsd.dk (Poul-Henning Kamp),
	luigi@info.iet.unipi.it (Luigi Rizzo), current@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

It seems Warner Losh wrote:
> : >A comment: this is a 18GB IBM 7200 RPM disk and i noticed it tends
> : >to become very hot compared to other disks when mounted in the
> : >same machine (on a removable frame). Do others have the same
> : >experience ?
> 
> Yes.  They run very hot.  I had to steal an old powersupply fan and
> mount it in front of the drive to get it to run at  a reasonable
> temperature.  W/o the fan, it was running at 58C or so.  With the fan
> it runs at 39C or so.  I've included the script that I use to find
> this information out.  Ken Merry sent it to me.  It works on some IBM
> drives.
> 
> Warner
> 
> #!/bin/sh
> 
> TEMPC=`camcontrol cmd -v -n da -u 0 -c "4D 0 76 0 0 0 0 0 20 0" -i 32 "s9 i1"`
> 
> TEMPF=`echo " 2 k $TEMPC 9 * 5 / 32 + p" | dc`
> 
> echo "The temperature is: $TEMPF F $TEMPC C"

Hmm, wonder if one can get that info from their ATA disks as well...

-Søren


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 23:35:45 2000
Delivered-To: freebsd-current@freebsd.org
Received: from rover.village.org (rover.village.org [204.144.255.49])
	by hub.freebsd.org (Postfix) with ESMTP id 2540937BB10
	for <current@FreeBSD.ORG>; Tue, 21 Mar 2000 23:35:37 -0800 (PST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (harmony.village.org [10.0.0.6])
	by rover.village.org (8.9.3/8.9.3) with ESMTP id AAA26411;
	Wed, 22 Mar 2000 00:35:34 -0700 (MST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id AAA29564; Wed, 22 Mar 2000 00:35:19 -0700 (MST)
Message-Id: <200003220735.AAA29564@harmony.village.org>
To: Soren Schmidt <sos@freebsd.dk>
Subject: Re: Reading from bad disk ? 
Cc: phk@critter.freebsd.dk (Poul-Henning Kamp),
	luigi@info.iet.unipi.it (Luigi Rizzo), current@FreeBSD.ORG
In-reply-to: Your message of "Wed, 22 Mar 2000 08:26:07 +0100."
		<200003220726.IAA44014@freebsd.dk> 
References: <200003220726.IAA44014@freebsd.dk>  
Date: Wed, 22 Mar 2000 00:35:19 -0700
From: Warner Losh <imp@village.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <200003220726.IAA44014@freebsd.dk> Soren Schmidt writes:
: > TEMPC=`camcontrol cmd -v -n da -u 0 -c "4D 0 76 0 0 0 0 0 20 0" -i 32 "s9 i1"`
....
: Hmm, wonder if one can get that info from their ATA disks as well...

Don't know.  You'd have to ask IBM.  All the above camcontrol is doing
is reading a special mode page (I'm sure ken will correct me if I'm
wrong)...  Do ata drives have this concept?

Warner



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 23:40:40 2000
Delivered-To: freebsd-current@freebsd.org
Received: from area51.v-wave.com (area51.v-wave.com [24.108.26.39])
	by hub.freebsd.org (Postfix) with SMTP id 6374537C0DE
	for <current@FreeBSD.ORG>; Tue, 21 Mar 2000 23:40:36 -0800 (PST)
	(envelope-from flatline@area51.v-wave.com)
Received: (qmail 82435 invoked by uid 1001); 22 Mar 2000 07:41:26 -0000
Date: Wed, 22 Mar 2000 00:41:26 -0700
From: Chris Wasser <cwasser@v-wave.com>
To: Richard Wendland <richard@netcraft.com>
Cc: current@FreeBSD.ORG
Subject: Re: FreeBSD random I/O performance issues
Message-ID: <20000322004126.A82200@area51.v-wave.com>
References: <38D6BBD7.DA4B950B@originative.co.uk> <200003220022.AAA28786@ns0.netcraft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200003220022.AAA28786@ns0.netcraft.com>; from richard@netcraft.com on Wed, Mar 22, 2000 at 12:22:42AM +0000
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Wed, Mar 22, 2000 at 12:22:42AM +0000, Richard Wendland wrote:
> Any views gratefully received.  A fix would be much better :-)

Not sure if my meager setup helps any, but in the interests in providing
results to help the cause so-to-speak, I ran the test on my own machine
(followed the instructions in the source file to the letter):

(/tmp)[13]# time ./seekreadwrite xxx 10000

real    0m4.462s
user    0m0.018s
sys     0m1.204s


Hardware information:

FreeBSD 4.0-STABLE #4: Thu Mar 16 15:15:07 MST 2000

CPU: Pentium II/Pentium II Xeon/Celeron (400.91-MHz 686-class CPU)

real memory  = 134217728 (131072K bytes)

atapci1: <HighPoint HPT366 ATA66 controller> port
0xe000-0xe0ff,0xdc00-0xdc03,0xd800-0xd807 irq 4 at device 19.0 on pci0
ata2: at 0xd800 on atapci1
atapci2: <HighPoint HPT366 ATA66 controller> port
0xec00-0xecff,0xe800-0xe803,0xe400-0xe407 irq 4 at device 19.1 on pci0
ata3: at 0xe400 on atapci2

ad4: 12416MB <QUANTUM FIREBALL CR13.0A> [25228/16/63] at ata2-master
using UDMA66

/dev/ad4s2f on /tmp (ufs, local, soft-updates, writes: sync 19 async
10197, reads: sync 169 async 0)

(/tmp)[19]# sysctl -a | grep -i vfs.write_behind
vfs.write_behind: 1

Mem: 58M Active, 29M Inact, 24M Wired, 4248K Cache, 11M Buf, 8860K Free
Swap: 257M Total, 257M Free

12:36AM  up 1 day,  9:54, 7 users, load averages: 0.10, 0.04, 0.01

The HDD is a 5400RPM ATA-66 drive (to state the obvious) this test was
conducted while I was in X (su'd to root) so there was some load on the
machine. Hope this helps in some way.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Tue Mar 21 23:49:29 2000
Delivered-To: freebsd-current@freebsd.org
Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184])
	by hub.freebsd.org (Postfix) with ESMTP id 3D47F37BBEA
	for <current@FreeBSD.ORG>; Tue, 21 Mar 2000 23:49:25 -0800 (PST)
	(envelope-from luigi@info.iet.unipi.it)
Received: (from luigi@localhost)
	by info.iet.unipi.it (8.9.3/8.9.3) id IAA32817;
	Wed, 22 Mar 2000 08:47:25 +0100 (CET)
	(envelope-from luigi)
From: Luigi Rizzo <luigi@info.iet.unipi.it>
Message-Id: <200003220747.IAA32817@info.iet.unipi.it>
Subject: Re: Reading from bad disk ?
In-Reply-To: <200003220735.AAA29564@harmony.village.org> from Warner Losh at
 "Mar 22, 2000 00:35:19 am"
To: Warner Losh <imp@village.org>
Date: Wed, 22 Mar 2000 08:47:25 +0100 (CET)
Cc: Soren Schmidt <sos@freebsd.dk>,
	Poul-Henning Kamp <phk@critter.freebsd.dk>, current@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL61 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> Don't know.  You'd have to ask IBM.  All the above camcontrol is doing
> is reading a special mode page (I'm sure ken will correct me if I'm
> wrong)...  Do ata drives have this concept?

i think they do.
	cheers
	luigi



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  0: 4:38 2000
Delivered-To: freebsd-current@freebsd.org
Received: from pr.infosec.ru (pr.infosec.ru [194.135.141.98])
	by hub.freebsd.org (Postfix) with ESMTP
	id 09F3C37BD2E; Wed, 22 Mar 2000 00:04:27 -0800 (PST)
	(envelope-from blaze@infosec.ru)
Received: from blaze (200.0.0.51 [200.0.0.51]) by pr.infosec.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id G0YN9P43; Wed, 22 Mar 2000 11:03:40 +0300
Date: Wed, 22 Mar 2000 11:07:31 +0300 (MSK)
From: Andrey Sverdlichenko <blaze@infosec.ru>
X-Sender: blaze@blaze
To: freebsd-current@freebsd.org
Cc: dan@freebsd.org
Subject: Re: emu10k1 driver
In-Reply-To: <38D8001B.845180A5@veldy.net>
Message-ID: <Pine.BSF.4.20.0003221102270.17456-100000@blaze>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> > | One is on the way...
> >
> > Cam's boredom out-weighed my initiative. 8)
> >
> > http://www.freebsd.org/~cg/current.diff.gz contains a partial emu10k1
> > driver (minus recording) which is need of debugging.  Give it a try!

I applied it to 4.0-CURRENT, but it works in mixer only mode.
Looks like pcm_addchan should be added in emu_pci_attach().



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  0:18:59 2000
Delivered-To: freebsd-current@freebsd.org
Received: from skaarup.org (skaarup.org [130.228.230.140])
	by hub.freebsd.org (Postfix) with ESMTP id A4E4A37BC70
	for <current@FreeBSD.ORG>; Wed, 22 Mar 2000 00:18:56 -0800 (PST)
	(envelope-from rasmus@gal.dk)
Received: from localhost (skaarup@localhost)
	by skaarup.org (8.9.3/8.9.3) with ESMTP id JAA04548;
	Wed, 22 Mar 2000 09:18:47 +0100 (CET)
	(envelope-from rasmus@gal.dk)
Date: Wed, 22 Mar 2000 09:18:47 +0100 (CET)
From: Rasmus Skaarup <rasmus@gal.dk>
X-Sender: skaarup@skaarup.org
To: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>
Cc: current@FreeBSD.ORG
Subject: Re: 4.0-RELEASE boot.flp fails to boot on K6/2 
In-Reply-To: <19621.953702955@zippy.cdrom.com>
Message-ID: <Pine.BSF.4.21.0003220913150.4434-100000@skaarup.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


Jordan K. Hubbard said:
> Good idea, terrible name.  Can't you guys some up with something better? :)

kern.flp    -> start.flp  
mfsroot.flp -> install.flp

boot.flp    -> bigstart.flp 
               bigdisk.flp ?

I thought we could rename kern.flp and mfsroot.flp aswell, since they
their names don't make much sense to anyone other than the one compiling
the darn disks :-)


Best regards
Rasmus Skaarup


> 
> > On Tue, Mar 21, 2000 at 04:32:35PM -0800, Doug White wrote:
> > > I would be in favor of renaming the boot.flp to something obviously
> > > different, like 288boot.flp, to untrain us 2.x heads that got used to the
> > 
> > Great idea.  Would you be able to make the changes locally and test a
> > `make release'?  Then all we need to do is pass the patch pass JKH.
> > (harder to say "NO" to working code)
> > 
> > -- 
> > -- David    (obrien@NUXI.com)




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  0:20:41 2000
Delivered-To: freebsd-current@freebsd.org
Received: from proxy.cbr.amur.ru (proxy.cbr.amur.ru [195.151.156.197])
	by hub.freebsd.org (Postfix) with ESMTP id DEE2737BD3C
	for <current@freebsd.org>; Wed, 22 Mar 2000 00:20:28 -0800 (PST)
	(envelope-from m.konovalov@amur.cbr.ru)
Received: (from uucp@localhost)
	by proxy.cbr.amur.ru (8.9.3/8.9.3) with UUCP id RAA29128;
	Wed, 22 Mar 2000 17:18:33 +0900 (YS)
Received: from stone.amur.cbr.ru (stone.amur.cbr.ru [10.82.64.20])
	by grizzly.amur.cbr.ru (Postfix) with ESMTP
	id D66C8BA07; Wed, 22 Mar 2000 17:17:39 +0900 (YAKT)
Received: from localhost (localhost [127.0.0.1])
	by stone.amur.cbr.ru (Postfix) with ESMTP
	id C4937217F; Wed, 22 Mar 2000 17:17:34 +0900 (YAKT)
Date: Wed, 22 Mar 2000 17:17:34 +0900 (YAKT)
From: Maxim Konovalov <m.konovalov@amur.cbr.ru>
To: current@freebsd.org
Cc: Bill Pechter <pechter@backup.ho.lucent.com>
Subject: Re: pstat -s error message
Message-ID: <Pine.BSF.4.21.0003221714030.87743-100000@stone.amur.cbr.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


> Date: Tue, 21 Mar 2000 18:00:46 -0500 (EST)
> From: Bill Pechter <pechter@backup.ho.lucent.com>
> Subject: pstat -s error message
>
> I've done two make worlds and can't seem to get rid of the following
> error... I had it on my home system, but didn't log what I did to 
> correct it...
>
> I just upgraded a 4.0-CURRENT (from around Jan 26) to the 4.0-STABLE
> from yesterday.
>
> when running pstat -s I get the following:
> pstat: undefined symbol: _numvnodes
>
> I rebuilt world and the kernel twice... I must be missing something.

You have to boot via loader(8). It was discussed for about a month ago.

Maxim Konovalov





To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  0:25:40 2000
Delivered-To: freebsd-current@freebsd.org
Received: from freebsd.dk (freebsd.dk [212.242.42.178])
	by hub.freebsd.org (Postfix) with ESMTP id 52CAB37C0CE
	for <current@FreeBSD.ORG>; Wed, 22 Mar 2000 00:25:37 -0800 (PST)
	(envelope-from sos@freebsd.dk)
Received: (from sos@localhost)
	by freebsd.dk (8.9.3/8.9.1) id JAA57801;
	Wed, 22 Mar 2000 09:25:07 +0100 (CET)
	(envelope-from sos)
From: Soren Schmidt <sos@freebsd.dk>
Message-Id: <200003220825.JAA57801@freebsd.dk>
Subject: Re: Reading from bad disk ?
In-Reply-To: <200003220735.AAA29564@harmony.village.org> from Warner Losh at "Mar 22, 2000 00:35:19 am"
To: imp@village.org (Warner Losh)
Date: Wed, 22 Mar 2000 09:25:07 +0100 (CET)
Cc: phk@critter.freebsd.dk (Poul-Henning Kamp),
	luigi@info.iet.unipi.it (Luigi Rizzo), current@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

It seems Warner Losh wrote:
> In message <200003220726.IAA44014@freebsd.dk> Soren Schmidt writes:
> : > TEMPC=`camcontrol cmd -v -n da -u 0 -c "4D 0 76 0 0 0 0 0 20 0" -i 32 "s9 i1"`
> ....
> : Hmm, wonder if one can get that info from their ATA disks as well...
> 
> Don't know.  You'd have to ask IBM.  All the above camcontrol is doing
> is reading a special mode page (I'm sure ken will correct me if I'm
> wrong)...  Do ata drives have this concept?

Yup, they have "SMART" for this, just brovsed my docs and found that 
the newer DPTA series has temperature as one of the things in there,
it doesn't seem that the older ones has it though...
Guess I have to finish that SMART handeling code I have lying here,
now that I got some motivation for it :)

-Søren


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  0:37:31 2000
Delivered-To: freebsd-current@freebsd.org
Received: from jason.argos.org (a1-3b058.neo.rr.com [24.93.181.58])
	by hub.freebsd.org (Postfix) with ESMTP id ED91337BCF5
	for <current@FreeBSD.ORG>; Wed, 22 Mar 2000 00:36:08 -0800 (PST)
	(envelope-from mike@argos.org)
Received: from localhost (mike@localhost)
	by jason.argos.org (8.9.1/8.9.1) with ESMTP id DAA26352;
	Wed, 22 Mar 2000 03:15:39 -0500
Date: Wed, 22 Mar 2000 03:15:39 -0500 (EST)
From: Mike Nowlin <mike@argos.org>
To: Max Khon <fjoe@iclub.nsu.ru>
Cc: current@FreeBSD.ORG
Subject: Re: ARP issues (Arcnet)
In-Reply-To: <Pine.BSF.4.21.0003221233490.2948-100000@iclub.nsu.ru>
Message-ID: <Pine.LNX.4.05.10003220313250.26341-100000@jason.argos.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


> Once again I'm trying to port Arcnet driver from NetBSD/amiga to
> FreeBSD/i386 (like I did more than a year ago for 3.x). The problem is in

Wow!  I might be able to make the Arcnet board in my Tandy 6000 XENIX
machine actually talk to someone someday!?!?!?!?  COOL!  :)

(Actually, that machine still works, and I fire it up every so often to
play around with...  68000, 1.5MB RAM, 35MB HD, 5 serial ports.  Runs UUCP
with the best of 'em...)

mike




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  0:39: 6 2000
Delivered-To: freebsd-current@freebsd.org
Received: from lola.heim10.tu-clausthal.de (lola.heim10.tu-clausthal.de [139.174.241.25])
	by hub.freebsd.org (Postfix) with ESMTP
	id 0EFDD37BD3C; Wed, 22 Mar 2000 00:38:56 -0800 (PST)
	(envelope-from norbert.irmer@heim9.tu-clausthal.de)
Received: from heim9.tu-clausthal.de (localhost.heim10.tu-clausthal.de [127.0.0.1])
	by lola.heim10.tu-clausthal.de (8.9.3/8.9.3) with ESMTP id JAA00347;
	Wed, 22 Mar 2000 09:38:50 +0100 (CET)
	(envelope-from norbert.irmer@heim9.tu-clausthal.de)
Message-ID: <38D8869A.A9D6E254@heim9.tu-clausthal.de>
Date: Wed, 22 Mar 2000 09:38:50 +0100
From: Norbert Irmer <norbert.irmer@heim9.tu-clausthal.de>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Andrey Sverdlichenko <blaze@infosec.ru>
Cc: freebsd-current@FreeBSD.ORG, dan@FreeBSD.ORG
Subject: Re: emu10k1 driver
References: <Pine.BSF.4.20.0003221102270.17456-100000@blaze>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Andrey Sverdlichenko wrote:
> 
> > > | One is on the way...
> > >
> > > Cam's boredom out-weighed my initiative. 8)
> > >
> > > http://www.freebsd.org/~cg/current.diff.gz contains a partial emu10k1
> > > driver (minus recording) which is need of debugging.  Give it a try!
> 
> I applied it to 4.0-CURRENT, but it works in mixer only mode.
> Looks like pcm_addchan should be added in emu_pci_attach().
> 

When you uncomment the pcm_addchan line in emu_pci_attach(),
the kernel crashes when booting.

It seems that there is still some work to be done,
but he is on the right way :)


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  0:40:14 2000
Delivered-To: freebsd-current@freebsd.org
Received: from wcn4.wcnet.net (mail.wcnet.net [216.88.248.234])
	by hub.freebsd.org (Postfix) with ESMTP id 9720837C0C5
	for <current@FreeBSD.ORG>; Wed, 22 Mar 2000 00:40:10 -0800 (PST)
	(envelope-from jestess@wcnet.net)
Received: from jestess [216.88.251.75] by wcn4.wcnet.net
  (SMTPD32-6.00) id A6E85BCF00E6; Wed, 22 Mar 2000 02:40:08 -0600
Message-ID: <002a01bf93a7$f2f92920$4bfb58d8@jestess>
From: "John Estess" <jestess@wcnet.net>
To: <current@FreeBSD.ORG>
Subject: Re: 4.0-RELEASE boot.flp fails to boot on K6/2 
Date: Wed, 22 Mar 2000 02:40:11 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


-----Original Message-----
From: Rasmus Skaarup <rasmus@gal.dk>
To: Jordan K. Hubbard <jkh@zippy.cdrom.com>
Cc: current@FreeBSD.ORG <current@FreeBSD.ORG>
Date: Wednesday, March 22, 2000 8:19 AM
Subject: Re: 4.0-RELEASE boot.flp fails to boot on K6/2


>
>Jordan K. Hubbard said:
>> Good idea, terrible name.  Can't you guys some up with something better?
:)
>
>kern.flp    -> start.flp        ====>>> boot.flp
>mfsroot.flp -> install.flp   ====>>> initsys.flp
>
>boot.flp    -> bigstart.flp  ====>>> bootinit.flp
>               bigdisk.flp ?
>

>> > Great idea.  Would you be able to make the changes locally and test a
>> > `make release'?  Then all we need to do is pass the patch pass JKH.

^^^^^^^^^^^^^^^^
                                                                    And I
thought this was the objectionable phrase




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  0:41:45 2000
Delivered-To: freebsd-current@freebsd.org
Received: from rccr1.rccr.cremona.it (rccr1.rccr.cremona.it [194.20.53.49])
	by hub.freebsd.org (Postfix) with ESMTP id 4C76437C0E3
	for <freebsd-current@FreeBSD.ORG>; Wed, 22 Mar 2000 00:41:39 -0800 (PST)
	(envelope-from mirko.viviani@rccr.cremona.it)
Received: from rccr.cremona.it (modem-1-2.rccr.cremona.it [192.168.2.12])
	by rccr1.rccr.cremona.it (8.9.3/8.9.3) with ESMTP id JAA12243
	for <freebsd-current@FreeBSD.ORG>; Wed, 22 Mar 2000 09:37:54 +0100
Received: (from mirko@localhost)
	by next.procom2.it (8.9.3/8.9.3) id JAA01602
	for freebsd-current@FreeBSD.ORG; Wed, 22 Mar 2000 09:14:03 +0100 (MET)
Message-Id: <200003220814.JAA01602@next.procom2.it>
Content-Type: text/plain
MIME-Version: 1.0 (NeXT Mail 3.3 v148.2.1)
X-Nextstep-Mailer: Mail 3.3 (Enhance 2.1)
Received: by NeXT.Mailer (1.148.2.1)
From: Mirko Viviani <mirko.viviani@rccr.cremona.it>
Date: Wed, 22 Mar 2000 09:03:47 +0100
To: freebsd-current@FreeBSD.ORG
Subject: libobjc and stack problems.
Reply-To: mirko.viviani@rccr.cremona.it
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Ciao.

Is it possible to apply the gnu/17433 patch before the 4.0-STABLE ?

Related to this I'm excepting some strange behaviour with prgs linked with libc_r
under 3.4 and I would like to know if they are also in 4.0.

1. In a prg linked with libc I can use a local buffer up to 65 MB, but if the same is
   linked with libc_r I can use up to 1 MB buffer else it fails with a seg fault.
   (char buf[60 * 1024])
   Why ?

2. The same thing apply to pthread, that apart from the ridicolously small (posix specs ?)
   initial default value of 65 kb the stack can't grown.
   Why ?

Thanks to libobjc and the first problem it's nearly impossible to run GNUstep prgs
with -pthread support. It there a way to fix ?

Thank you.

It's not possible to have contrib/gdb shipped with objective-c language patches ?

---
Bye,
     Mirko  <mirko.viviani@rccr.cremona.it>   (NeXTmail, MIME)
                    <mirko@yourbox.net>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  0:41:50 2000
Delivered-To: freebsd-current@freebsd.org
Received: from Draculina.otdel-1.org (Draculina.Otdel-1.ORG [195.230.65.30])
	by hub.freebsd.org (Postfix) with ESMTP id 14EBA37C0EF
	for <freebsd-current@freebsd.org>; Wed, 22 Mar 2000 00:41:40 -0800 (PST)
	(envelope-from nms@otdel-1.org)
Received: by Draculina.otdel-1.org (Postfix, from userid 1002)
	id 9629AE2; Wed, 22 Mar 2000 11:41:37 +0300 (MSK)
Date: Wed, 22 Mar 2000 11:41:37 +0300
From: Nikolai Saoukh <nms@otdel-1.org>
To: freebsd-current@freebsd.org
Subject: Debugger("b_iocmd botch") called.
Message-ID: <20000322114137.A10090@Draculina.otdel-1.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

I am the only one who see this? Brand new kernel
cvsuped few minutes ago. It barfs even on plain
compile. Verbose dmesg output below

Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
	The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #5: Wed Mar 22 11:16:13 MSK 2000
    nms@Playground:/usr/src/sys/compile/PLAYGROUND
Calibrating clock(s) ... TSC clock: 166183680 Hz, i8254 clock: 1193114 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter "i8254"  frequency 1193182 Hz
CLK_USE_TSC_CALIBRATION not specified - using old calibration method
Timecounter "TSC"  frequency 166193770 Hz
CPU: Pentium/P55C (166.19-MHz 586-class CPU)
  Origin = "GenuineIntel"  Id = 0x543  Stepping = 3
  Features=0x8001bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX>
real memory  = 16777216 (16384K bytes)
Physical memory chunk(s):
0x00001000 - 0x0009efff, 647168 bytes (158 pages)
0x0025c000 - 0x00ff7fff, 14270464 bytes (3484 pages)
avail memory = 14237696 (13904K bytes)
bios32: Found BIOS32 Service Directory header at 0xc00fd870
bios32: Entry = 0xfd881 (c00fd881)  Rev = 0  Len = 1
pcibios: PCI BIOS entry at 0xd8bc
pnpbios: Found PnP BIOS data at 0xc00fdef0
pnpbios: Entry = f0000:5863  Rev = 1.0
Other BIOS signatures found:
ACPI: 00000000
Preloaded elf kernel "kernel" at 0xc0243000.
Intel Pentium detected, installing workaround for F00F bug
pci_open(1):	mode 1 addr port (0x0cf8) is 0x8000005c
pci_open(1a):	mode1res=0x80000000 (0x80000000)
pci_cfgcheck:	device 0 [class=060000] [hdr=00] is there (id=70308086)
npx0: <math processor> on motherboard
npx0: INT 16 interface
i586_bzero() bandwidth = 174428745 bytes/sec
bzero() bandwidth = 87966220 bytes/sec
pci_open(1):	mode 1 addr port (0x0cf8) is 0x00000000
pci_open(1a):	mode1res=0x80000000 (0x80000000)
pci_cfgcheck:	device 0 [class=060000] [hdr=00] is there (id=70308086)
pcib0: <Host to PCI bridge> on motherboard
found->	vendor=0x8086, dev=0x7030, revid=0x02
	class=06-00-00, hdrtype=0x00, mfdev=0
	subordinatebus=0 	secondarybus=0
found->	vendor=0x8086, dev=0x7000, revid=0x01
	class=06-01-00, hdrtype=0x00, mfdev=1
	subordinatebus=0 	secondarybus=0
found->	vendor=0x8086, dev=0x7010, revid=0x00
	class=01-01-80, hdrtype=0x00, mfdev=0
	subordinatebus=0 	secondarybus=0
	map[20]: type 1, range 32, base 0000fff0, size  4, enabled
found->	vendor=0x8086, dev=0x7020, revid=0x01
	class=0c-03-00, hdrtype=0x00, mfdev=0
	subordinatebus=0 	secondarybus=0
	intpin=d, irq=11
	map[20]: type 1, range 32, base 00005000, size  5, enabled
found->	vendor=0x1013, dev=0x00b8, revid=0x00
	class=03-00-00, hdrtype=0x00, mfdev=0
	subordinatebus=0 	secondarybus=0
	map[10]: type 1, range 32, base 40000000, size 24, enabled
pci0: <PCI bus> on pcib0

	PCI Concurrency: enabled
	Cache: 256K pipelined-burst secondary; L1 enabled
	DRAM: no memory hole, 66 MHz refresh
	Read burst timing: x-2-2-2/x-3-3-3
	Write burst timing: x-2-2-2
	RAS-CAS delay: 3 clocks
isab0: <Intel 82371SB PCI to ISA bridge> at device 1.0 on pci0
	I/O Recovery Timing: 8-bit 1 clocks, 16-bit 1 clocks
	Extended BIOS: disabled
	Lower BIOS: enabled
	Coprocessor IRQ13: enabled
	Mouse IRQ12: enabled
	Interrupt Routing: A: disabled, B: IRQ10, C: disabled, D: IRQ11
		MB0: disabled, MB1: 
isa0: <ISA bus> on isab0
atapci0: <Intel PIIX3 ATA controller> port 0xfff0-0xffff at device 1.1 on pci0
ata0: iobase=0x01f0 altiobase=0x03f6 bmaddr=0xfff0
ata0: mask=03 status0=50 status1=00
ata0: mask=03 status0=50 status1=00
ata0: devices = 0x1
ata0: at 0x1f0 irq 14 on atapci0
ata1: iobase=0x0170 altiobase=0x0376 bmaddr=0xfff8
ata1: mask=00 status0=ff status1=ff
ata1: probe allocation failed
pci0: <Intel 82371SB (PIIX3) USB controller> (vendor=0x8086, dev=0x7020) at 1.2 irq 11
pci0: <Cirrus Logic GD5446 SVGA controller> (vendor=0x1013, dev=0x00b8) at 8.0
Trying Read_Port at 203
IBM0000: adding io range 0x300-0xeff, size=0x4, align=0x4
IBM0000: adding memory range 0xc8000-0xdffff, size=0x2000, align=0x2000
IBM0000: adding irq mask 0x9ec8
isa_probe_children: disabling PnP devices
isa_probe_children: probing non-PnP devices
fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
atkbd: the current kbd controller command byte 0045
atkbd: keyboard ID 0x41ab (2)
kbdc: RESET_KBD return code:00fa
kbdc: RESET_KBD status:00aa
kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000
psm0: current command byte:0045
kbdc: TEST_AUX_PORT status:0000
kbdc: RESET_AUX return code:00fa
kbdc: RESET_AUX status:00aa
kbdc: RESET_AUX ID:0000
psm: status 00 02 64
psm: status 00 00 64
psm: status 00 03 64
psm: status 00 03 64
psm: data 08 00 00
psm: status 10 00 64
psm: status 00 02 64
psm: data 08 00 00
psm: status 00 02 64
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons
psm0: config:00000000, flags:00000000, packet size:3
psm0: syncmask:c0, syncbits:00
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
fb0: vga0, vga, type:VGA (5), flags:0x7007f
fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000
fb0: init mode:24, bios mode:3, current mode:24
fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k
VGA parameters upon power-up
50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 
bf 1f 00 4f 0d 0e 00 00 04 60 9c 8e 8f 28 1f 96 
b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 
3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff 
VGA parameters in BIOS for mode 24
50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 
bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 
b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 
3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff 
EGA/VGA parameters to be used for mode 24
50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 
bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 
b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 
3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff 
sc0: <System console> on isa0
sc0: VGA <16 virtual consoles, flags=0x200>
sc0: fb0, kbd0, terminal emulator: sc (syscons terminal)
sio0: irq maps: 0x41 0x51 0x41 0x41
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1: irq maps: 0x41 0x49 0x41 0x41
sio1 at port 0x2f8-0x2ff irq 3 flags 0x10 on isa0
sio1: type 16550A
isa_probe_children: probing PnP devices
BIOS Geometries:
 0:026b3f3f 0..619=620 cylinders, 0..63=64 heads, 1..63=63 sectors
 0 accounted for
Device configuration finished.
bpf: lo0 attached
ata0-master: success setting up WDMA2 mode on PIIX3 chip
ad0: <WDC AC21200H/24.09P07> ATA-0 disk at ata0 as master
ad0: 1222MB (2503872 sectors), 2484 cyls, 16 heads, 63 S/T, 512 B/S
ad0: 16 secs/int, 1 depth queue, WDMA2
ad0: piomode=4 dmamode=2 udmamode=-1 cblid=0
Creating DISK ad0
Creating DISK wd0
Mounting root from ufs:/dev/ad0s1a
ad0s1: type 0xa5, start 0, end = 2503871, size 2503872 
ad0s1: C/H/S end 378/53/63 (1289357) != end 2503871: invalid
WARNING: / was not properly dismounted
start_init: trying /sbin/init
splash: image decoder found: green_saver
new masks: bio 40084040, tty 4003101a, net 4007101a
bpf: ng0 attached


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  0:44: 7 2000
Delivered-To: freebsd-current@freebsd.org
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131])
	by hub.freebsd.org (Postfix) with ESMTP id ED3F937C0EF
	for <current@FreeBSD.ORG>; Wed, 22 Mar 2000 00:43:57 -0800 (PST)
	(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1])
	by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id JAA30425;
	Wed, 22 Mar 2000 09:40:30 +0100 (CET)
	(envelope-from phk@critter.freebsd.dk)
To: Peter Wemm <peter@netplex.com.au>
Cc: Stephen Hocking-Senior Programmer PGS SPS Perth <shocking@prth.pgs.com>,
	current@FreeBSD.ORG
Subject: Re: Another current crash (cvs-cur.6183 
In-reply-to: Your message of "Tue, 21 Mar 2000 17:47:16 PST."
             <20000322014716.A8C561CC9@overcee.netplex.com.au> 
Date: Wed, 22 Mar 2000 09:40:30 +0100
Message-ID: <30423.953714430@critter.freebsd.dk>
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


Fixed.  The swap_pager "knew" that B_WRITE was zero.  Not nice.

In message <20000322014716.A8C561CC9@overcee.netplex.com.au>, Peter Wemm writes
:
>Stephen Hocking-Senior Programmer PGS SPS Perth wrote:
>
>This one you need to tell phk about: this is one of his sanity checks
>that trapped and found an insane value. (and then crashed since you didn't
>have DDB)
>
>> #8  0xc0255f21 in Debugger (msg=0xc027b1e8 "d_iocmd botch")
>>     at machine/cpufunc.h:64
>> #9  0xc017385e in spec_strategy (ap=0xc5988df8)
>>     at ../../miscfs/specfs/spec_vnops.c:438
>> #10 0xc0173325 in spec_vnoperate (ap=0xc5988df8)
>>     at ../../miscfs/specfs/spec_vnops.c:117
>> #11 0xc020c3bd in ufs_vnoperatespec (ap=0xc5988df8)
>>     at ../../ufs/ufs/ufs_vnops.c:2301
>> #12 0xc0219167 in swapdev_strategy (ap=0xc5988e30) at vnode_if.h:923
>> #13 0xc020d80e in swap_pager_putpages (object=0xc02f9ea0, m=0xc5988ee0, 
>>     count=1, sync=0, rtvals=0xc5988e74) at vnode_if.h:923
>> #14 0xc020c427 in default_pager_putpages (object=0xc02f9ea0, m=0xc5988ee0, 
>>     c=1, sync=0, rtvals=0xc5988e74) at ../../vm/default_pager.c:133
>> #15 0xc02175ea in vm_pageout_flush (mc=0xc5988ee0, count=1, flags=0)
>>     at ../../vm/vm_pager.h:145
>> #16 0xc021754d in vm_pageout_clean (m=0xc0464ae0) at ../../vm/vm_pageout.c:33
>    8
>> #17 0xc0217e6e in vm_pageout_scan () at ../../vm/vm_pageout.c:914
>> #18 0xc0218764 in vm_pageout () at ../../vm/vm_pageout.c:1350
>> #19 0xc02565e0 in fork_trampoline ()
>
>
>Cheers,
>-Peter
>--
>Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
>"All of this is for nothing if we don't go to the stars" - JMS/B5
>
>

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  1: 0:48 2000
Delivered-To: freebsd-current@freebsd.org
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131])
	by hub.freebsd.org (Postfix) with ESMTP id 0738437C134
	for <freebsd-current@FreeBSD.ORG>; Wed, 22 Mar 2000 01:00:45 -0800 (PST)
	(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1])
	by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id KAA30646;
	Wed, 22 Mar 2000 10:00:28 +0100 (CET)
	(envelope-from phk@critter.freebsd.dk)
To: Nikolai Saoukh <nms@otdel-1.org>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: Debugger("b_iocmd botch") called. 
In-reply-to: Your message of "Wed, 22 Mar 2000 11:41:37 +0300."
             <20000322114137.A10090@Draculina.otdel-1.org> 
Date: Wed, 22 Mar 2000 10:00:27 +0100
Message-ID: <30644.953715627@critter.freebsd.dk>
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


A traceback would have been nice.

I just committed a fix for one such bug, please try with that in place.

Poul-Henning

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  1: 4:21 2000
Delivered-To: freebsd-current@freebsd.org
Received: from skaarup.org (skaarup.org [130.228.230.140])
	by hub.freebsd.org (Postfix) with ESMTP id 560ED37C0CE
	for <current@FreeBSD.org>; Wed, 22 Mar 2000 01:04:13 -0800 (PST)
	(envelope-from rasmus@gal.dk)
Received: from localhost (skaarup@localhost)
	by skaarup.org (8.9.3/8.9.3) with ESMTP id KAA04679
	for <current@FreeBSD.org>; Wed, 22 Mar 2000 10:04:12 +0100 (CET)
	(envelope-from rasmus@gal.dk)
Date: Wed, 22 Mar 2000 10:04:12 +0100 (CET)
From: Rasmus Skaarup <rasmus@gal.dk>
X-Sender: skaarup@skaarup.org
To: current@FreeBSD.org
Subject: New names for installation floppies (Was: Re: 4.0-RELEASE boot.flp
 fails to boot on K6/2) 
Message-ID: <Pine.BSF.4.21.0003221003420.4640-100000@skaarup.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


> >Jordan K. Hubbard said:
> >> Good idea, terrible name.  Can't you guys some up with something better?

> >kern.flp    -> start.flp        ====>>> boot.flp
> >mfsroot.flp -> install.flp   ====>>> initsys.flp
> >
> >boot.flp    -> bigstart.flp  ====>>> bootinit.flp
> >               bigdisk.flp ?

I think it is a very bad idea to name kern.flp the same as the old 2.88
image. This would cause confusion. 

And I think the name of the 2.88 image should reflect the large size of
the image.

> >> > Great idea.  Would you be able to make the changes locally and test a
> >> > `make release'?  Then all we need to do is pass the patch pass JKH.
> 
> ^^^^^^^^^^^^^^^^
>                                                                     And I
> thought this was the objectionable phrase

It was. But then Jordan initiated a hunt-down-a-better-name-for-the-2.88-
installation-disk chase.


Best regards
Rasmus Skaarup




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  1: 5:40 2000
Delivered-To: freebsd-current@freebsd.org
Received: from pluton.ispras.ru (pluton.ispras.ru [194.186.94.6])
	by hub.freebsd.org (Postfix) with ESMTP
	id 3F48437C0E9; Wed, 22 Mar 2000 01:05:28 -0800 (PST)
	(envelope-from grn@ispras.ru)
Received: from gate.ispras.ru (gate [194.67.37.200])
	by pluton.ispras.ru (8.9.3/8.9.3) with ESMTP id MAA04794;
	Wed, 22 Mar 2000 12:04:14 +0300 (MSK)
Received: from ispgate (ispgate [194.67.37.200])
	by gate.ispras.ru (8.9.3/8.9.3) with ESMTP id MAA15300;
	Wed, 22 Mar 2000 12:04:56 +0300 (MSK)
Date: Wed, 22 Mar 2000 12:04:55 +0300 (MSK)
From: Grigory Kljuchnikov <grn@ispras.ru>
To: freebsd-questions@FreeBSD.ORG
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: errno (46) - for FreeBSD 4.0 NFS server
In-Reply-To: <C12568A9.005BA0F3.00@frmta003.netfr.alcatel.fr>
Message-ID: <Pine.GSO.4.20.0003221112530.14906-100000@gate.ispras.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Thierry, thank you for the information, 
but it's very bad that there isn't NFS locking in FreeBSD.
I'm afraid I need to move my FreeBSD NFS server to Solaris
for x86. 

I don't understand why NFS locking isn't in FreeBSD. 
Is it difficult in the implementation or are there another 
global problems in the kernel (or in the native filesystem)?

Who know when the NFS locking is planed to release in FreeBSD?


Grigory. 

On Tue, 21 Mar 2000 Thierry.Herbelot@alcatel.fr wrote:

> 
> 
> Hello,
> 
> There is presently *NO* NFS locking in FreeBSD (for all versions).
> There will be some NFS locking in the near future - stay tuned.
> 
>      TfH
> 
> Grigory Kljuchnikov <grn@ispras.ru> on 21/03/2000 17:16:08
>                                                               
> Hello!
> 
> I have a FreeBSD 4.0 NFS server and get an error message
> (No record locks available - errno (46)) when a HP-UX 10.20
> client run some compilation process (with make) on the NFS-mounted
> file system that is reside on that FreeBSD 4.0 NFS server.
> This error appear on the HP-UX 10.20 NFS-client host.
> If I use Solaris 2.6 NFS server in same circumstance I don't
> have that error.
> 
> What is wrong?
> or
> What are the kernel parameters I need to change on FreeBSD?
> 
> 

Grigory Kljuchnikov
------------------------------------------------------------
Institute for System Programming Russian Academy of Sciences,
109004, Moscow, Russia, B.Kommunistitcheskay, 25,
  phone(work):   +7-095-9125659
  fax:           +7-095-9121524
  e-mail:        <grn@ispras.ru>



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  1:45:38 2000
Delivered-To: freebsd-current@freebsd.org
Received: from Draculina.otdel-1.org (Draculina.Otdel-1.ORG [195.230.65.30])
	by hub.freebsd.org (Postfix) with ESMTP id D0B9137BD3A
	for <freebsd-current@FreeBSD.ORG>; Wed, 22 Mar 2000 01:45:35 -0800 (PST)
	(envelope-from nms@otdel-1.org)
Received: by Draculina.otdel-1.org (Postfix, from userid 1002)
	id 9B96E198; Wed, 22 Mar 2000 12:45:32 +0300 (MSK)
Date: Wed, 22 Mar 2000 12:45:32 +0300
From: Nikolai Saoukh <nms@otdel-1.org>
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: Debugger("b_iocmd botch") called.
Message-ID: <20000322124532.A10268@Draculina.otdel-1.org>
References: <20000322114137.A10090@Draculina.otdel-1.org> <30644.953715627@critter.freebsd.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <30644.953715627@critter.freebsd.dk>; from phk@critter.freebsd.dk on Wed, Mar 22, 2000 at 10:00:27AM +0100
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Wed, Mar 22, 2000 at 10:00:27AM +0100, Poul-Henning Kamp wrote:

> A traceback would have been nice.

Sorry, compiled kernel without it.

> I just committed a fix for one such bug, please try with that in place.

Yes, this fixed my problem.

Thanks


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  2: 3:38 2000
Delivered-To: freebsd-current@freebsd.org
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
	by hub.freebsd.org (Postfix) with ESMTP id B00A337C143
	for <freebsd-current@FreeBSD.ORG>; Wed, 22 Mar 2000 02:03:35 -0800 (PST)
	(envelope-from ertr1013@student.csd.uu.se)
Received: from regulus.student.UU.SE ([130.238.5.2]:64390 "HELO
        ertr1013.student.csd.uu.se") by merganser.its.uu.se with SMTP
	id <S460804AbQCVKD2>; Wed, 22 Mar 2000 11:03:28 +0100
Received: (qmail 2083 invoked by uid 1001); 22 Mar 2000 10:02:46 -0000
Date:   Wed, 22 Mar 2000 11:02:45 +0100
From: Erik Trulsson <ertr1013@student.csd.uu.se>
To: freebsd-questions@FreeBSD.ORG, freebsd-current@FreeBSD.ORG
Subject: Re: errno (46) - for FreeBSD 4.0 NFS server
Message-ID: <20000322110244.B1961@student.csd.uu.se>
References: <C12568A9.005BA0F3.00@frmta003.netfr.alcatel.fr> <Pine.GSO.4.20.0003221112530.14906-100000@gate.ispras.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <Pine.GSO.4.20.0003221112530.14906-100000@gate.ispras.ru>; from grn@ispras.ru on Wed, Mar 22, 2000 at 12:04:55PM +0300
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Wed, Mar 22, 2000 at 12:04:55PM +0300, Grigory Kljuchnikov wrote:
> Thierry, thank you for the information, 
> but it's very bad that there isn't NFS locking in FreeBSD.
> I'm afraid I need to move my FreeBSD NFS server to Solaris
> for x86. 
> 
> I don't understand why NFS locking isn't in FreeBSD. 
> Is it difficult in the implementation or are there another 
> global problems in the kernel (or in the native filesystem)?
> 
> Who know when the NFS locking is planed to release in FreeBSD?
> 
> 


Actually I think that server side locking *is* implemented but client side
locking isn't.
'man 8 rpc.lockd' for more information.
(And 'man 5 rc.conf' for information on how to start it at bootup.




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  2: 7:54 2000
Delivered-To: freebsd-current@freebsd.org
Received: from RedDust.BlueSky.net.au (reddust.bluesky.net.au [203.31.37.15])
	by hub.freebsd.org (Postfix) with ESMTP id A040E37BC70
	for <current@freebsd.org>; Wed, 22 Mar 2000 02:07:40 -0800 (PST)
	(envelope-from receiver@RedDust.BlueSky.net.au)
Received: from localhost (receiver@localhost)
	by RedDust.BlueSky.net.au (8.9.3/8.9.3) with ESMTP id UAA53321
	for <current@freebsd.org>; Wed, 22 Mar 2000 20:08:36 +1000 (EST)
	(envelope-from receiver@RedDust.BlueSky.net.au)
Date: Wed, 22 Mar 2000 20:08:36 +1000 (EST)
From: Idea Receiver <receiver@RedDust.BlueSky.net.au>
To: current@freebsd.org
Subject: -current crash while mouting cd..
Message-ID: <Pine.BSF.4.10.10003222001510.53311-100000@RedDust.BlueSky.net.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


cvsup to 6 hours ago.


Fatal trap 12: page fault while in kernel mode
mp_lock = 01000002; cpuid = 1; lapic.id = 01000000
fault virtual address	= 0x0
fault code		= supervisor read, page not present
instruction pointer	= 0x8:0xc021ad98
stack pointer		= 0x10:0xc87d0d88
frame pointer		= 0x10:0xc87d0d94
code segment		= base 0x0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, def32, gran 1
processor eflags	= interrupt enabled, resume, IOPL = 0
current process		= 238 (mount_cd9660)
interrupt mask		= none <- SMP: XXX
trap number		= 12
panic: page fault
mp_lock = 01000002; cpuid = 1; lapic.id = 01000000
boot() called on cpu#1



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  2:27:27 2000
Delivered-To: freebsd-current@freebsd.org
Received: from matrix.eurocontrol.fr (matrix.eurocontrol.fr [147.196.254.254])
	by hub.freebsd.org (Postfix) with ESMTP
	id C37E837C176; Wed, 22 Mar 2000 02:27:18 -0800 (PST)
	(envelope-from roberto@eurocontrol.fr)
Received: from caerdonn.eurocontrol.fr (caerdonn.eurocontrol.fr [147.196.5.62])
	by matrix.eurocontrol.fr (Postfix) with ESMTP
	id 60CD931F4; Wed, 22 Mar 2000 11:27:11 +0100 (CET)
	(envelope-from roberto@caerdonn.eurocontrol.fr)
Received: by caerdonn.eurocontrol.fr (Postfix, from userid 1193)
	id 4BED74E47; Wed, 22 Mar 2000 11:27:10 +0100 (CET)
Date: Wed, 22 Mar 2000 11:27:10 +0100
From: Ollivier Robert <roberto@eurocontrol.fr>
To: John Baldwin <jhb@FreeBSD.org>
Cc: dcs@FreeBSD.org,
	FreeBSD Current Users' list <freebsd-current@FreeBSD.org>
Subject: Re: /boot/loader is making my VAIO reboot
Message-ID: <20000322112710.C15904@caerdonn.eurocontrol.fr>
References: <20000321171955.R93580@caerdonn.eurocontrol.fr> <200003211832.NAA05075@server.baldwin.cx>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200003211832.NAA05075@server.baldwin.cx>; from jhb@FreeBSD.org on Tue, Mar 21, 2000 at 01:32:19PM -0500
X-Operating-System: FreeBSD 5.0-CURRENT
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

According to John Baldwin:
> fixes.  Can you see how far into the loader it is getting?  Also, what
> is in your /boot/loader.rc.  Try booting with an empty loader.rc and see
loader.rc

-=-=-
\ Loader.rc
\
\ Includes additional commands
include /boot/loader.4th

\ Reads and processes loader.rc
start

\ Unless set otherwise, autoboot is automatic at this point
-=-=-

> if you can get a prompt, please.

No prompt. It reboots just after displaying the 'Hit [Enter] blah' line.

An empty loader.rc doesn't help at all.
-- 
Ollivier ROBERT -=- Eurocontrol EEC/TEC -=- Ollivier.Robert@eurocontrol.fr
The Postman hits! The Postman hits! You have new mail.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  3:23:49 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131])
	by hub.freebsd.org (Postfix) with ESMTP id 9D19D37B625
	for <current@freebsd.org>; Wed, 22 Mar 2000 03:23:44 -0800 (PST)
	(envelope-from netchild@leidinger.net)
Received: from [62.104.201.2] (helo=mx1.freenet.de)
	by mout0.freenet.de with esmtp (Exim 3.13 #1)
	id 12XjEi-00080O-00
	for current@freebsd.org; Wed, 22 Mar 2000 12:23:40 +0100
Received: from [213.6.56.36] (helo=Magelan.Leidinger.net)
	by mx1.freenet.de with esmtp (Exim 3.13 #1)
	id 12XjEh-0001yh-00
	for current@freebsd.org; Wed, 22 Mar 2000 12:23:39 +0100
Received: from Leidinger.net (netchild@localhost [127.0.0.1])
	by Magelan.Leidinger.net (8.9.3/8.9.3) with ESMTP id KAA01303
	for <current@freebsd.org>; Wed, 22 Mar 2000 10:38:55 +0100 (CET)
	(envelope-from netchild@Leidinger.net)
Message-Id: <200003220938.KAA01303@Magelan.Leidinger.net>
Date: Wed, 22 Mar 2000 10:38:53 +0100 (CET)
From: Alexander Leidinger <Alexander@Leidinger.net>
Subject: backtrace: vm_object_terminate: freeing busy page
To: current@freebsd.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Hi,

5-current with last commit to sys/ at 2000/03/20 23:12:17 PST (date
taken from CVSROOT/commitlogs/sys), world and kernel are in sync:

(2) root@ttyp2# gdb -k /sys/compile/WORK/kernel.debug /var/crash/vmcore.1
[...]
IdlePTD 3747840
initial pcb at 2fcae0
panicstr: vm_object_terminate: freeing busy page 0xc049abf0

panic messages:
---
panic: vm_object_terminate: freeing busy page 0xc049abf0


syncing disks... 18 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 
giving up on 1 buffers
Uptime: 4h12m53s

dumping to dev #ad/0x30001, offset 282744
dump ata0: resetting devices .. done
[...]
(kgdb) bt
#0  boot (howto=256) at ../../kern/kern_shutdown.c:304
#1  0xc0176a65 in panic (
    fmt=0xc029cd00 "vm_object_terminate: freeing busy page %p\n")
    at ../../kern/kern_shutdown.c:554
#2  0xc0203beb in vm_object_terminate (object=0xc030a7a0)
    at ../../vm/vm_object.c:442
#3  0xc0203b14 in vm_object_deallocate (object=0xc030a7a0)
    at ../../vm/vm_object.c:377
#4  0xc0200d40 in vm_map_entry_delete (map=0xc7eaac40, entry=0xc0303ba0)
    at ../../vm/vm_map.c:1727
#5  0xc0200ee6 in vm_map_delete (map=0xc7eaac40, start=0, end=3217031168)
    at ../../vm/vm_map.c:1830
#6  0xc0200f79 in vm_map_remove (map=0xc7eaac40, start=0, end=3217031168)
    at ../../vm/vm_map.c:1855
#7  0xc016f265 in exit1 (p=0xc7ea7100, rv=15) at ../../kern/kern_exit.c:216
#8  0xc0178581 in sigexit (p=0xc7ea7100, sig=15) at ../../kern/kern_sig.c:1484
#9  0xc0178324 in postsig (sig=15) at ../../kern/kern_sig.c:1387
#10 0xc025b544 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, 
      tf_edi = 134660612, tf_esi = -1077937248, tf_ebp = -1077936824, 
      tf_isp = -930705452, tf_ebx = 0, tf_edx = 0, tf_ecx = -1077936720, 
      tf_eax = 0, tf_trapno = 12, tf_err = 2, tf_eip = 134539060, tf_cs = 31, 
      tf_eflags = 582, tf_esp = -1077938468, tf_ss = 47})
    at ../../i386/i386/trap.c:159
#11 0xc024dc66 in Xint0x80_syscall ()
Cannot access memory at address 0xbfbffd48.


At this time I was shutting down the machine (<ctrl>+<alt>+<del>).
Just drop me a note what variables you want to have printed.

Bye,
Alexander.

-- 
               I believe the technical term is "Oops!"

http://www.Leidinger.net                  Alexander+Home @ Leidinger.net
  Key fingerprint = 7423 F3E6 3A7E B334 A9CC  B10A 1F5F 130A A638 6E7E



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  3:49: 7 2000
Delivered-To: freebsd-current@freebsd.org
Received: from matrix.eurocontrol.fr (matrix.eurocontrol.fr [147.196.254.254])
	by hub.freebsd.org (Postfix) with ESMTP
	id 318C637BBCA; Wed, 22 Mar 2000 03:49:05 -0800 (PST)
	(envelope-from roberto@eurocontrol.fr)
Received: from caerdonn.eurocontrol.fr (caerdonn.eurocontrol.fr [147.196.5.62])
	by matrix.eurocontrol.fr (Postfix) with ESMTP
	id 0364931F8; Wed, 22 Mar 2000 12:49:04 +0100 (CET)
	(envelope-from roberto@caerdonn.eurocontrol.fr)
Received: by caerdonn.eurocontrol.fr (Postfix, from userid 1193)
	id 7CCCB4E00; Wed, 22 Mar 2000 12:49:03 +0100 (CET)
Date: Wed, 22 Mar 2000 12:49:03 +0100
From: Ollivier Robert <roberto@eurocontrol.fr>
To: John Baldwin <jhb@FreeBSD.org>
Cc: dcs@FreeBSD.org,
	FreeBSD Current Users' list <freebsd-current@FreeBSD.org>
Subject: Re: /boot/loader is making my VAIO reboot
Message-ID: <20000322124903.D15904@caerdonn.eurocontrol.fr>
References: <20000321171955.R93580@caerdonn.eurocontrol.fr> <200003211832.NAA05075@server.baldwin.cx>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200003211832.NAA05075@server.baldwin.cx>; from jhb@FreeBSD.org on Tue, Mar 21, 2000 at 01:32:19PM -0500
X-Operating-System: FreeBSD 5.0-CURRENT
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

According to John Baldwin:
> fixes.  Can you see how far into the loader it is getting?  Also, what
> is in your /boot/loader.rc.  Try booting with an empty loader.rc and see
> if you can get a prompt, please.

Reverting to the version in RELENG_4_0_0_RELEASE fixes the problem.
-- 
Ollivier ROBERT -=- Eurocontrol EEC/TEC -=- Ollivier.Robert@eurocontrol.fr
The Postman hits! The Postman hits! You have new mail.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  4:49:28 2000
Delivered-To: freebsd-current@freebsd.org
Received: from pluton.ispras.ru (pluton.ispras.ru [194.186.94.6])
	by hub.freebsd.org (Postfix) with ESMTP
	id 881E237B99A; Wed, 22 Mar 2000 04:48:42 -0800 (PST)
	(envelope-from grn@ispras.ru)
Received: from gate.ispras.ru (gate [194.67.37.200])
	by pluton.ispras.ru (8.9.3/8.9.3) with ESMTP id PAA05300;
	Wed, 22 Mar 2000 15:45:40 +0300 (MSK)
Received: from ispgate (ispgate [194.67.37.200])
	by gate.ispras.ru (8.9.3/8.9.3) with ESMTP id PAA17082;
	Wed, 22 Mar 2000 15:46:13 +0300 (MSK)
Date: Wed, 22 Mar 2000 15:46:12 +0300 (MSK)
From: Grigory Kljuchnikov <grn@ispras.ru>
To: Erik Trulsson <ertr1013@student.csd.uu.se>
Cc: freebsd-questions@FreeBSD.org, freebsd-current@FreeBSD.org
Subject: Re: errno (46) - for FreeBSD 4.0 NFS server
In-Reply-To: <20000322110244.B1961@student.csd.uu.se>
Message-ID: <Pine.GSO.4.20.0003221532580.14906-100000@gate.ispras.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Thank you, Erik!

I find rpc.lockd and start it manually. My test with NFS locking works right.
But it don't start on boot by default if I enable NFS server in
/stand/sysinstall and there is the comment in /etc/default/rc.conf
for rpc_lockd_enable:

rpc_lockd_enable="NO"          # Run NFS rpc.lockd (*broken!*) if nfs_server.

Does the comment "(*broken!*)" mean that rpc.lockd doesn't work properly? 

Grigory.

On Wed, 22 Mar 2000, Erik Trulsson wrote:

> On Wed, Mar 22, 2000 at 12:04:55PM +0300, Grigory Kljuchnikov wrote:
> > Thierry, thank you for the information, 
> > but it's very bad that there isn't NFS locking in FreeBSD.
> > I'm afraid I need to move my FreeBSD NFS server to Solaris
> > for x86. 
> > 
> > I don't understand why NFS locking isn't in FreeBSD. 
> > Is it difficult in the implementation or are there another 
> > global problems in the kernel (or in the native filesystem)?
> > 
> > Who know when the NFS locking is planed to release in FreeBSD?
> > 
> > 
> 
> 
> Actually I think that server side locking *is* implemented but client side
> locking isn't.
> 'man 8 rpc.lockd' for more information.
> (And 'man 5 rc.conf' for information on how to start it at bootup.
> 
> 

Grigory Kljuchnikov
------------------------------------------------------------
Institute for System Programming Russian Academy of Sciences,
109004, Moscow, Russia, B.Kommunistitcheskay, 25,
  phone(work):   +7-095-9125659
  fax:           +7-095-9121524
  e-mail:        <grn@ispras.ru>



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  5: 5:12 2000
Delivered-To: freebsd-current@freebsd.org
Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3])
	by hub.freebsd.org (Postfix) with ESMTP id 3959A37B5FC
	for <current@FreeBSD.ORG>; Wed, 22 Mar 2000 05:05:09 -0800 (PST)
	(envelope-from eischen@vigrid.com)
Received: (from eischen@localhost)
	by pcnet1.pcnet.com (8.8.7/PCNet) id IAA16055;
	Wed, 22 Mar 2000 08:04:37 -0500 (EST)
Date: Wed, 22 Mar 2000 08:04:37 -0500 (EST)
From: Daniel Eischen <eischen@vigrid.com>
To: Arun Sharma <adsharma@sharmas.dhs.org>
Cc: Marcel Moolenaar <marcel@scc.nl>,
	Peter Wemm <peter@netplex.com.au>, current@FreeBSD.ORG
Subject: Re: ucontext
In-Reply-To: <20000321225432.A4533@sharmas.dhs.org>
Message-ID: <Pine.SUN.3.91.1000322080258.15917A-100000@pcnet1.pcnet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Tue, 21 Mar 2000, Arun Sharma wrote:
> On Tue, Sep 07, 1999 at 01:21:59PM +0200, Marcel Moolenaar wrote:
> > Peter Wemm wrote:
> > > 
> > > Before getting too far here, can we consider some other standard interfaces?
> > > 
> > >      #include <ucontext.h>
> > > 
> > >      int getcontext(ucontext_t *ucp);
> > >      int setcontext(const ucontext_t *ucp);
> > >      void makecontext(ucontext_t *ucp, (void *func)(), int argc, ...);
> > >      int swapcontext(ucontext_t *oucp, const ucontext_t *ucp);
> > > 
> > > http://www.opengroup.org/onlinepubs/007908799/xsh/ucontext.h.html
> > > 
> > > setjmp,longjmp,sigreturn,etc can all be done with this interface and it can
> > > be used for libc_r and future kernel-assisted threading.
> > 
> > We're at a point where the discussion, altough meaningful and important,
> > has no direct impact on the sigset_t change. I agree with Peter that we
> > should as well consider the ucontext interface, but prefer to stay focussed
> > on changing sigset_t. So, here's where I shut up and let you discuss the
> > matter further :-)
> 
> Is anyone working on this ? Porting JDKs to FreeBSD would be a lot easier
> if these routines are implemented.

I had them implemented and working for i386, and even had a hacked up
libc_r that used them instead of setjmp/longjmp.  This was a few months
ago under 4.0-current.  At the time, I thought they'd be better off
implemented as syscalls, but now I'm leaning towards library routines
similar to setjmp/longjmp (which make a syscall to change the signal
mask).

Ucontext needs to change also.  We need a flags word to indicate whether
the register state and FP state are valid, and probably a revision word
to identify future changes within ucontext_t.

Dan Eischen
eischen@vigrid.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  6:39: 5 2000
Delivered-To: freebsd-current@freebsd.org
Received: from gizmo.internode.com.au (gizmo.internode.com.au [192.83.231.115])
	by hub.freebsd.org (Postfix) with ESMTP id 3A63A37BCA4
	for <current@FreeBSD.ORG>; Wed, 22 Mar 2000 06:38:59 -0800 (PST)
	(envelope-from newton@gizmo.internode.com.au)
Received: (from newton@localhost)
	by gizmo.internode.com.au (8.9.3/8.9.3) id BAA94006;
	Thu, 23 Mar 2000 01:08:25 +1030 (CST)
	(envelope-from newton)
Date: Thu, 23 Mar 2000 01:08:25 +1030
From: Mark Newton <newton@internode.com.au>
To: Arun Sharma <adsharma@sharmas.dhs.org>
Cc: Marcel Moolenaar <marcel@scc.nl>,
	Peter Wemm <peter@netplex.com.au>, current@FreeBSD.ORG
Subject: Re: ucontext
Message-ID: <20000323010825.A93949@internode.com.au>
References: <19990907103348.2801F1CA8@overcee.netplex.com.au> <37D4F557.F4F743E7@scc.nl> <20000321225432.A4533@sharmas.dhs.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3i
In-Reply-To: <20000321225432.A4533@sharmas.dhs.org>
X-PGP-Key: http://www.on.net/~newton/pgpkey.txt
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Tue, Mar 21, 2000 at 10:54:32PM -0800, Arun Sharma wrote:

 > > > Before getting too far here, can we consider some other
 > > > standard interfaces?
 > > >      #include <ucontext.h>
 > > >      int getcontext(ucontext_t *ucp);
 > > >      int setcontext(const ucontext_t *ucp);
 > > >      void makecontext(ucontext_t *ucp, (void *func)(), int argc, ...);
 > > >      int swapcontext(ucontext_t *oucp, const ucontext_t *ucp);
 > > > http://www.opengroup.org/onlinepubs/007908799/xsh/ucontext.h.html
   [ ... ]
 > Is anyone working on this ? Porting JDKs to FreeBSD would be a lot easier
 > if these routines are implemented.

If it helps at all, these are (approxmiately :-) implemented in the 
svr4 emulator.  

I'm not sure that svr4_setcontext() is doing entirely the right thing,
and there are some holes related to signal mask handling (which might 
be related to the "entirely the right thing" bit), but it's a start.

    - mark

-- 
Mark Newton                               Email:  newton@internode.com.au (W)
Network Engineer                          Email:  newton@atdot.dotat.org  (H)
Internode Systems Pty Ltd                 Desk:   +61-8-82232999
"Network Man" - Anagram of "Mark Newton"  Mobile: +61-416-202-223


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  7: 4:28 2000
Delivered-To: freebsd-current@freebsd.org
Received: from lunatic.oneinsane.net (lunatic.oneinsane.net [207.113.133.231])
	by hub.freebsd.org (Postfix) with ESMTP id 4B64837C047
	for <freebsd-current@freebsd.org>; Wed, 22 Mar 2000 07:04:26 -0800 (PST)
	(envelope-from insane@lunatic.oneinsane.net)
Received: by lunatic.oneinsane.net (Postfix, from userid 1000)
	id CB0F01A9; Wed, 22 Mar 2000 07:04:25 -0800 (PST)
Date: Wed, 22 Mar 2000 07:04:25 -0800
From: Ron 'The InSaNe One' Rosson <insane@lunatic.oneinsane.net>
To: freebsd-current@freebsd.org
Subject: Re: 4.0-RELEASE boot.flp fails to boot on K6/2
Message-ID: <20000322070425.B47986@lunatic.oneinsane.net>
Reply-To: Ron Rosson <insane@lunatic.oneinsane.net>
References: <19621.953702955@zippy.cdrom.com> <Pine.BSF.4.21.0003212252080.316-100000@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <Pine.BSF.4.21.0003212252080.316-100000@localhost>; from jazepeda@pacbell.net on Tue, Mar 21, 2000 at 10:52:35PM -0800
X-Operating-System: FreeBSD lunatic.oneinsane.net 3.4-STABLE
X-Moon: The Moon is Waning Gibbous (94% of Full)
X-Opinion: What you read here is my IMHO 
X-Disclaimer: I am a firm believer in RTFM 
X-WWW: http://www.oneinsane.net
X-PGP-KEY: http://www.oneinsane.net/~insane/insane2-pgp5i.txt
X-Uptime: 7:03AM  up 6 days, 21:04, 2 users, load averages: 0.08, 0.02, 0.01
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Tue, 21 Mar 2000, Alex Zepeda was heard blurting out:

> On Tue, 21 Mar 2000, Jordan K. Hubbard wrote:
> 
> > Good idea, terrible name.  Can't you guys some up with something better? :)
> 
> reallybigbootthing.flp?
> 

How about:
	
	isoboot.flp

Since it's use is for making bootable cdroms  ;-)

-- 
-------------------------------------------------------------------
Ron Rosson              	... and a UNIX user said ...
The InSaNe One                 		   rm -rf *
insane@oneinsane.net      	and all was /dev/null and *void()
-------------------------------------------------------------------
Tell me what you need, and I'll tell you how to get along without it.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  7:30:13 2000
Delivered-To: freebsd-current@freebsd.org
Received: from lunatic.oneinsane.net (lunatic.oneinsane.net [207.113.133.231])
	by hub.freebsd.org (Postfix) with ESMTP id 738B937BF64
	for <freebsd-current@freebsd.org>; Wed, 22 Mar 2000 07:30:11 -0800 (PST)
	(envelope-from insane@lunatic.oneinsane.net)
Received: by lunatic.oneinsane.net (Postfix, from userid 1000)
	id A6C6A1A9; Wed, 22 Mar 2000 07:30:10 -0800 (PST)
Date: Wed, 22 Mar 2000 07:30:10 -0800
From: Ron Rosson <insane@lunatic.oneinsane.net>
To: freebsd-current@freebsd.org
Subject: Re: XJEM3288
Message-ID: <20000322073010.G47986@lunatic.oneinsane.net>
Reply-To: Ron Rosson <insane@lunatic.oneinsane.net>
References: <20000322065811.A47986@lunatic.oneinsane.net> <QQihqa16243.200003221511@jmnoc28.ams.ops.eu.uu.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <QQihqa16243.200003221511@jmnoc28.ams.ops.eu.uu.net>; from marcel@eu.uu.net on Wed, Mar 22, 2000 at 04:11:30PM +0100
X-Operating-System: FreeBSD lunatic.oneinsane.net 3.4-STABLE
X-Moon: The Moon is Waning Gibbous (94% of Full)
X-Opinion: What you read here is my IMHO 
X-Disclaimer: I am a firm believer in RTFM 
X-WWW: http://www.oneinsane.net
X-PGP-KEY: http://www.oneinsane.net/~insane/insane2-pgp5i.txt
X-Uptime: 7:29AM  up 6 days, 21:30, 2 users, load averages: 0.00, 0.03, 0.05
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Wed, 22 Mar 2000, Anne Marcel Roorda was heard blurting out:

> Hi,
> 
>   It would probably help if you remove the '#' from the card
> definition :)
> 
> - marcel

That was a cut and paste error from VIM   ;-)

-- 
-------------------------------------------------------------------
Ron Rosson              	... and a UNIX user said ...
The InSaNe One                 		   rm -rf *
insane@oneinsane.net      	and all was /dev/null and *void()
-------------------------------------------------------------------
Science is the game we play with God to find out what His rules are.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  7:46: 3 2000
Delivered-To: freebsd-current@freebsd.org
Received: from ns0.netcraft.com (ns0.netcraft.com [195.188.192.4])
	by hub.freebsd.org (Postfix) with ESMTP
	id 2076B37BD9A; Wed, 22 Mar 2000 07:45:56 -0800 (PST)
	(envelope-from richard@netcraft.com)
Received: (from richard@localhost)
          by ns0.netcraft.com (8.8.8/8.8.8) id PAA08760;
          Wed, 22 Mar 2000 15:44:20 GMT
          (envelope-from richard)
From: Richard Wendland <richard@netcraft.com>
Message-Id: <200003221544.PAA08760@ns0.netcraft.com>
Subject: Re: FreeBSD random I/O performance issues
In-Reply-To: <38D833BC.A082DF09@originative.co.uk> from Paul Richards at "Mar
 22, 2000 02:45:16 am"
To: Paul Richards <paul@originative.co.uk>
Date: Wed, 22 Mar 2000 15:44:20 +0000 (GMT)
Cc: Richard Wendland <richard@netcraft.com>,
	Alfred Perlstein <bright@wintelcom.net>,
	Poul-Henning Kamp <phk@critter.freebsd.dk>,
	Matthew Dillon <dillon@apollo.backplane.com>, current@FreeBSD.ORG,
	fs@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL61 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> > With sync it's ~20,000 operations matching the total of reads &
> > writes.  This demonstrates another aspect of the bug, sync behaviour
> > should cause 10,000 operations; the reads aren't being cached.
> 
> This isn't quite true. It's 20,000 *write* operations. I put this down
> to the mtime update for each write doubling the number of actual write
> operations. No read operations take place, the data *does* come out of
> the cache. There's nothing wrong with reading as far as I can tell.

Yes, you're absolutely right, I should have looked at my own data
more closely.

If I change the test program to call fsync after write, and run on
a default mount filesystem I also see 20,000 I/O operations from
10,000 writes.  This probably impacts more real programs out there
than sync mounts.

If this is mtime updates being does synchronously, that seems a
separate issue to the clustering/VM issue, and seems to me it should
be fixed.  It'll normally double the number of all writes won't
it, possibly forcing seeks between otherwise localised access.

Can anyone offer an alternative hypothesis to mtime updates being
done synchronously?

Looking at my logs for the sync filesystem test, mount output before
and after shows all ~20,000 operations are writes::

	mount
	/dev/wd0s2e on /var (local, synchronous, writes: sync 182 async 10)

	time ./seekreadwrite xxx 10000
	0.1u 7.8s 1:47.61 7.4% 5+179k 0+20000io 0pf+0w

	mount
	/dev/wd0s2e on /var (local, synchronous, writes: sync 20190 async 15)

But when using fsync on a default mount filesystems, 10000 writes
are sync and 10000 async:

	mount
	/dev/wd0s2e on /var (local, writes: sync 682 async 2764)

	time ./seekreadwrite xxx 10000
	0.0u 1.7s 0:54.34 3.3% 4+171k 0+20000io 0pf+0w

	mount
	/dev/wd0s2e on /var (local, writes: sync 10682 async 12777)

This is on the ATA machine that could run the test in 4 seconds
without fsync, 54 seconds with fsync, suggesting some head movements
may be being forced, though not 20000 as that would imply 2.7ms
per seek.

	Richard
-- 
Richard Wendland				richard@netcraft.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  8:13:44 2000
Delivered-To: freebsd-current@freebsd.org
Received: from knight.cons.org (knight.cons.org [194.233.237.86])
	by hub.freebsd.org (Postfix) with ESMTP id D232337BB72
	for <freebsd-current@FreeBSD.ORG>; Wed, 22 Mar 2000 08:13:40 -0800 (PST)
	(envelope-from cracauer@knight.cons.org)
Received: (from cracauer@localhost)
	by knight.cons.org (8.9.3/8.9.3) id RAA18893;
	Wed, 22 Mar 2000 17:13:26 +0100 (CET)
Date: Wed, 22 Mar 2000 17:13:25 +0100
From: Martin Cracauer <cracauer@cons.org>
To: Mirko Viviani <mirko.viviani@rccr.cremona.it>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: libobjc and stack problems. (really libc_r and stack size)
Message-ID: <20000322171325.B18834@cons.org>
References: <200003220814.JAA01602@next.procom2.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200003220814.JAA01602@next.procom2.it>; from mirko.viviani@rccr.cremona.it on Wed, Mar 22, 2000 at 09:03:47AM +0100
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Hai,

In <200003220814.JAA01602@next.procom2.it>, Mirko Viviani wrote: 
> Ciao.
> 
> Is it possible to apply the gnu/17433 patch before the 4.0-STABLE ?
> 
> Related to this I'm excepting some strange behaviour with prgs linked with libc_r
> under 3.4 and I would like to know if they are also in 4.0.

[please break lines at < 80 chars, thanks]

> 1. In a prg linked with libc I can use a local buffer up to 65 MB, but if the same is
>    linked with libc_r I can use up to 1 MB buffer else it fails with a seg fault.
>    (char buf[60 * 1024])
>    Why ?

I assume this is function-local stack space? if not, please post a
compilable test program.

> 2. The same thing apply to pthread, that apart from the ridicolously small (posix specs ?)
>    initial default value of 65 kb the stack can't grown.
>    Why ?

I don't think anyone came up with a solution to provide growable
stacks in threads. 

Stacks in plain processes can grow, because the next allocated thing
is the heap on the other end of the address space.

You can't do this for threads, you have to choose a distance, you have
to device your address space. Large default stacks limit the heap
considerably on a 32 bit machine. They will also not solve, but shift
the problem.

So it's better to have a small limit so that application programmer
either use small stack amounts or when that fails think over their
choice. But we cannot make a good guess without hints from the
application. 

> Thanks to libobjc and the first problem it's nearly impossible to
> run GNUstep prgs with -pthread support. It there a way to fix ?

Use pthread_attr_setstacksize()

> It's not possible to have contrib/gdb shipped with objective-c
> language patches ?

Can you point me to the newest set of ObjC patches for gdb, please?

I don't think they will it into the base system, mainly because it
takes off files from the vendor branch. But we also have a gdb in
ports, where patches are more welcome.

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/
  Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  8:52:26 2000
Delivered-To: freebsd-current@freebsd.org
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
	by hub.freebsd.org (Postfix) with ESMTP id 7D76237BD69
	for <freebsd-current@FreeBSD.ORG>; Wed, 22 Mar 2000 08:52:18 -0800 (PST)
	(envelope-from ertr1013@student.csd.uu.se)
Received: from regulus.student.UU.SE ([130.238.5.2]:35181 "HELO
        ertr1013.student.csd.uu.se") by merganser.its.uu.se with SMTP
	id <S460805AbQCVQv5>; Wed, 22 Mar 2000 17:51:57 +0100
Received: (qmail 1043 invoked by uid 1001); 22 Mar 2000 16:51:18 -0000
Date:   Wed, 22 Mar 2000 17:51:18 +0100
From: Erik Trulsson <ertr1013@student.csd.uu.se>
To: Grigory Kljuchnikov <grn@ispras.ru>
Cc: freebsd-questions@FreeBSD.ORG, freebsd-current@FreeBSD.ORG
Subject: Re: errno (46) - for FreeBSD 4.0 NFS server
Message-ID: <20000322175118.A901@student.csd.uu.se>
References: <20000322110244.B1961@student.csd.uu.se> <Pine.GSO.4.20.0003221532580.14906-100000@gate.ispras.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <Pine.GSO.4.20.0003221532580.14906-100000@gate.ispras.ru>; from grn@ispras.ru on Wed, Mar 22, 2000 at 03:46:12PM +0300
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Wed, Mar 22, 2000 at 03:46:12PM +0300, Grigory Kljuchnikov wrote:
> Thank you, Erik!
> 
> I find rpc.lockd and start it manually. My test with NFS locking works right.
> But it don't start on boot by default if I enable NFS server in
> /stand/sysinstall and there is the comment in /etc/default/rc.conf
> for rpc_lockd_enable:
> 
> rpc_lockd_enable="NO"          # Run NFS rpc.lockd (*broken!*) if nfs_server.
> 
> Does the comment "(*broken!*)" mean that rpc.lockd doesn't work properly? 
> 

To be honest I don't know. I haven't used it myself but only read the
manpages. (Since I only use NFS between FreeBSD boxes and they don't support
client-side locking it seems pointless to have it on the server.)

That comment does seem to imply that something is broken but then the
manpage really should say something about that. (This might of course
indicate that the manpage isn't in sync with reality.)

Somebody who knows what is up with rpc.lockd is welcome to comment.


> 
> On Wed, 22 Mar 2000, Erik Trulsson wrote:
> 
> > On Wed, Mar 22, 2000 at 12:04:55PM +0300, Grigory Kljuchnikov wrote:
> > > Thierry, thank you for the information, 
> > > but it's very bad that there isn't NFS locking in FreeBSD.
> > > I'm afraid I need to move my FreeBSD NFS server to Solaris
> > > for x86. 
> > > 
> > > I don't understand why NFS locking isn't in FreeBSD. 
> > > Is it difficult in the implementation or are there another 
> > > global problems in the kernel (or in the native filesystem)?
> > > 
> > > Who know when the NFS locking is planed to release in FreeBSD?
> > > 
> > > 
> > 
> > 
> > Actually I think that server side locking *is* implemented but client side
> > locking isn't.
> > 'man 8 rpc.lockd' for more information.
> > (And 'man 5 rc.conf' for information on how to start it at bootup.
> > 
> > 
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  8:58:27 2000
Delivered-To: freebsd-current@freebsd.org
Received: from buffnet4.buffnet.net (buffnet4.buffnet.net [205.246.19.13])
	by hub.freebsd.org (Postfix) with ESMTP
	id 1984F37BD9B; Wed, 22 Mar 2000 08:58:22 -0800 (PST)
	(envelope-from shovey@buffnet.net)
Received: from buffnet11.buffnet.net (buffnet11.buffnet.net [205.246.19.55])
	by buffnet4.buffnet.net (8.9.3/8.8.7) with ESMTP id LAA27370;
	Wed, 22 Mar 2000 11:56:31 -0500 (EST)
	(envelope-from shovey@buffnet.net)
Date: Wed, 22 Mar 2000 11:56:24 -0500 (EST)
From: Steve Hovey <shovey@buffnet.net>
To: Erik Trulsson <ertr1013@student.csd.uu.se>
Cc: Grigory Kljuchnikov <grn@ispras.ru>,
	freebsd-questions@FreeBSD.ORG, freebsd-current@FreeBSD.ORG
Subject: Re: errno (46) - for FreeBSD 4.0 NFS server
In-Reply-To: <20000322175118.A901@student.csd.uu.se>
Message-ID: <Pine.BSF.4.05.10003221155240.5966-100000@buffnet11.buffnet.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


I believe the lockd daemon is used in environments where applications at
the client end will not work unless they can make a lock call and get a
positive result.. so in environments where you feel its fairly safe to
fake a lock to a client app, in order to get the app working at all, that
you would use this.  (At least I think that used to be the reason for it)

On Wed, 22 Mar 2000, Erik Trulsson wrote:

> On Wed, Mar 22, 2000 at 03:46:12PM +0300, Grigory Kljuchnikov wrote:
> > Thank you, Erik!
> > 
> > I find rpc.lockd and start it manually. My test with NFS locking works right.
> > But it don't start on boot by default if I enable NFS server in
> > /stand/sysinstall and there is the comment in /etc/default/rc.conf
> > for rpc_lockd_enable:
> > 
> > rpc_lockd_enable="NO"          # Run NFS rpc.lockd (*broken!*) if nfs_server.
> > 
> > Does the comment "(*broken!*)" mean that rpc.lockd doesn't work properly? 
> > 
> 
> To be honest I don't know. I haven't used it myself but only read the
> manpages. (Since I only use NFS between FreeBSD boxes and they don't support
> client-side locking it seems pointless to have it on the server.)
> 
> That comment does seem to imply that something is broken but then the
> manpage really should say something about that. (This might of course
> indicate that the manpage isn't in sync with reality.)
> 
> Somebody who knows what is up with rpc.lockd is welcome to comment.
> 
> 
> > 
> > On Wed, 22 Mar 2000, Erik Trulsson wrote:
> > 
> > > On Wed, Mar 22, 2000 at 12:04:55PM +0300, Grigory Kljuchnikov wrote:
> > > > Thierry, thank you for the information, 
> > > > but it's very bad that there isn't NFS locking in FreeBSD.
> > > > I'm afraid I need to move my FreeBSD NFS server to Solaris
> > > > for x86. 
> > > > 
> > > > I don't understand why NFS locking isn't in FreeBSD. 
> > > > Is it difficult in the implementation or are there another 
> > > > global problems in the kernel (or in the native filesystem)?
> > > > 
> > > > Who know when the NFS locking is planed to release in FreeBSD?
> > > > 
> > > > 
> > > 
> > > 
> > > Actually I think that server side locking *is* implemented but client side
> > > locking isn't.
> > > 'man 8 rpc.lockd' for more information.
> > > (And 'man 5 rc.conf' for information on how to start it at bootup.
> > > 
> > > 
> > 
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-questions" in the body of the message
> 



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  9: 2:36 2000
Delivered-To: freebsd-current@freebsd.org
Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169])
	by hub.freebsd.org (Postfix) with ESMTP id 0EE5C37BB72
	for <current@FreeBSD.ORG>; Wed, 22 Mar 2000 09:02:33 -0800 (PST)
	(envelope-from ken@panzer.kdm.org)
Received: (from ken@localhost)
	by panzer.kdm.org (8.9.3/8.9.1) id KAA48319;
	Wed, 22 Mar 2000 10:01:48 -0700 (MST)
	(envelope-from ken)
Date: Wed, 22 Mar 2000 10:01:48 -0700
From: "Kenneth D. Merry" <ken@kdm.org>
To: Warner Losh <imp@village.org>
Cc: Soren Schmidt <sos@freebsd.dk>,
	Poul-Henning Kamp <phk@critter.freebsd.dk>,
	Luigi Rizzo <luigi@info.iet.unipi.it>, current@FreeBSD.ORG
Subject: Re: Reading from bad disk ?
Message-ID: <20000322100147.A48281@panzer.kdm.org>
References: <200003220726.IAA44014@freebsd.dk> <200003220735.AAA29564@harmony.village.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200003220735.AAA29564@harmony.village.org>; from imp@village.org on Wed, Mar 22, 2000 at 12:35:19AM -0700
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Wed, Mar 22, 2000 at 00:35:19 -0700, Warner Losh wrote:
> In message <200003220726.IAA44014@freebsd.dk> Soren Schmidt writes:
> : > TEMPC=`camcontrol cmd -v -n da -u 0 -c "4D 0 76 0 0 0 0 0 20 0" -i 32 "s9 i1"`
> ....
> : Hmm, wonder if one can get that info from their ATA disks as well...
> 
> Don't know.  You'd have to ask IBM.  All the above camcontrol is doing
> is reading a special mode page (I'm sure ken will correct me if I'm
> wrong)...  Do ata drives have this concept?

It's actually a log page, which is very similar to a mode page.

Ken
-- 
Kenneth Merry
ken@kdm.org


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  9:13: 5 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id 3BD3B37B95D
	for <current@FreeBSD.ORG>; Wed, 22 Mar 2000 09:13:02 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id JAA91710;
	Wed, 22 Mar 2000 09:13:02 -0800 (PST)
	(envelope-from dillon)
Date: Wed, 22 Mar 2000 09:13:02 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003221713.JAA91710@apollo.backplane.com>
To: current@FreeBSD.ORG
Subject: Buf cache, swap spl, and NFS patches need review.
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

    Well, actually these have been partially reviewed over the last few
    months, but I'd like to commit them now so I need a final review on
    these babies.

    The three patches are available at:

	http://www.backplane.com/FreeBSD4/

    buffer cache cleanup:

	This is probably more for bde, dg, Julian, or Alfred.   bde has 
	already reviewed most of the patch.  This is the final version.

	This patch takes a step towards getting rid of the buffer cache's
	KVA management.  It chunks up the KVA allocations for the buffer
	cache to reduce fragmentation and also fixes geteblk()'s allocation
	size (previously geteblk() used MAXBSIZE, which can cause severe 
	fragmentation).

    swap-SPL:

	Required splvm()'s had to be added to two places in the swap subsystem
	(but I don't think the lack of these spl's is the cause of the
	recently reported crashes, though it is possible).

    NFS packet buffer:

	This patch increases the default buffer size from 2 to 4 packets
	for UDP NFS mounts and adds a sysctl that allows the buffer size
	to be adjusted prior to mounting.

	This patch apparently makes a big difference on clients on gigabit 
	networks, especially slower clients which can't pop the UDP packets 
	off the queue quickly enough.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  9:20:58 2000
Delivered-To: freebsd-current@freebsd.org
Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11])
	by hub.freebsd.org (Postfix) with SMTP
	id 5B25237BD9B; Wed, 22 Mar 2000 09:20:50 -0800 (PST)
	(envelope-from dwmalone@maths.tcd.ie)
Received: from bell.maths.tcd.ie by salmon.maths.tcd.ie with SMTP
          id <aa14415@salmon>; 22 Mar 2000 17:18:14 +0000 (GMT)
Date: Wed, 22 Mar 2000 17:18:13 +0000
From: David Malone <dwmalone@maths.tcd.ie>
To: Erik Trulsson <ertr1013@student.csd.uu.se>
Cc: Grigory Kljuchnikov <grn@ispras.ru>,
	freebsd-questions@FreeBSD.ORG, freebsd-current@FreeBSD.ORG
Subject: Re: errno (46) - for FreeBSD 4.0 NFS server
Message-ID: <20000322171813.A42613@bell.maths.tcd.ie>
References: <20000322110244.B1961@student.csd.uu.se> <Pine.GSO.4.20.0003221532580.14906-100000@gate.ispras.ru> <20000322175118.A901@student.csd.uu.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <20000322175118.A901@student.csd.uu.se>; from ertr1013@student.csd.uu.se on Wed, Mar 22, 2000 at 05:51:18PM +0100
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Wed, Mar 22, 2000 at 05:51:18PM +0100, Erik Trulsson wrote:

> Somebody who knows what is up with rpc.lockd is welcome to comment.

AFAIK the lockd code just says "Sure - have a lock" to any request.

I think David Cross and some other people have a half working
lockd now, they were looking for people to play with it on the
list only a couple of weeks ago.

	David.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  9:24:15 2000
Delivered-To: freebsd-current@freebsd.org
Received: from isds.duke.edu (davinci.isds.duke.edu [152.3.22.1])
	by hub.freebsd.org (Postfix) with ESMTP id E185D37C1C4
	for <freebsd-current@FreeBSD.ORG>; Wed, 22 Mar 2000 09:24:12 -0800 (PST)
	(envelope-from sto@stat.Duke.EDU)
Received: from cayenne.isds.duke.edu (cayenne.isds.duke.edu [152.3.22.11])
	by isds.duke.edu (8.8.8/8.8.8) with ESMTP id MAA19061
	for <freebsd-current@FreeBSD.ORG>; Wed, 22 Mar 2000 12:24:11 -0500 (EST)
Received: (from sto@localhost)
	by cayenne.isds.duke.edu (8.8.8/8.8.8) id MAA09823
	for freebsd-current@FreeBSD.ORG; Wed, 22 Mar 2000 12:24:11 -0500 (EST)
Date: Wed, 22 Mar 2000 12:24:10 -0500
From: "Sean O'Connell" <sean@stat.Duke.EDU>
To: freebsd-current@FreeBSD.ORG
Subject: Re: errno (46) - for FreeBSD 4.0 NFS server
Message-ID: <20000322122410.J9478@stat.Duke.EDU>
Reply-To: "Sean O'Connell" <sean@stat.Duke.EDU>
Mail-Followup-To: freebsd-current@FreeBSD.ORG
References: <20000322110244.B1961@student.csd.uu.se> <Pine.GSO.4.20.0003221532580.14906-100000@gate.ispras.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <Pine.GSO.4.20.0003221532580.14906-100000@gate.ispras.ru>; from grn@ispras.ru on Wed, Mar 22, 2000 at 03:46:12PM +0300
X-Organization: Institute of Statistics and Decision Sciences
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Grigory Kljuchnikov stated:
> Thank you, Erik!
> 
> I find rpc.lockd and start it manually. My test with NFS locking works right.
> But it don't start on boot by default if I enable NFS server in
> /stand/sysinstall and there is the comment in /etc/default/rc.conf
> for rpc_lockd_enable:
> 
> rpc_lockd_enable="NO"          # Run NFS rpc.lockd (*broken!*) if nfs_server.
> 
> Does the comment "(*broken!*)" mean that rpc.lockd doesn't work properly? 
> 
> Grigory.
> 
> On Wed, 22 Mar 2000, Erik Trulsson wrote:
> 
> > On Wed, Mar 22, 2000 at 12:04:55PM +0300, Grigory Kljuchnikov wrote:
> > > Thierry, thank you for the information, 
> > > but it's very bad that there isn't NFS locking in FreeBSD.
> > > I'm afraid I need to move my FreeBSD NFS server to Solaris
> > > for x86. 
> > > 
> > > I don't understand why NFS locking isn't in FreeBSD. 
> > > Is it difficult in the implementation or are there another 
> > > global problems in the kernel (or in the native filesystem)?
> > > 
> > > Who know when the NFS locking is planed to release in FreeBSD?
> > 
> > Actually I think that server side locking *is* implemented but client side
> > locking isn't.
> > 'man 8 rpc.lockd' for more information.
> > (And 'man 5 rc.conf' for information on how to start it at bootup.

Grigory-

My understanding of the current implementation of rpc.lockd is 
that it is a facade and simply tells the client requesting a
lock "sure kid, you have a lock" and then does nothing.

"David E. Cross" <crossd@cs.rpi.edu> has been working to
implement a real server-side rpc.lockd.  You may want to
contact him.  The first go 'round failed the nfs connectathon
tests, but the second version purportedly addresses these
issues with all but SGI boxen.   However, it was delayed
pending some system header changes...

<wild_speculation>
Since the merger with BSDi, FreeBSD hopefully will be getting
both client and server-side locking (of course, this will
appear first in 5.0-CURRENT at some point) along with some
nice SMP support (fingers firmly crossed).
</wild_speculation>

Hope this helps,
S

-----------------------------------------------------------------------
Sean O'Connell                                Email: sean@stat.Duke.EDU
Institute of Statistics and Decision Sciences Phone: (919) 684-5419
Duke University                               Fax:   (919) 684-8594


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22  9:56:37 2000
Delivered-To: freebsd-current@freebsd.org
Received: from sharmas.dhs.org (c62443-a.frmt1.sfba.home.com [24.0.69.165])
	by hub.freebsd.org (Postfix) with ESMTP id 47FB537B5C6
	for <current@FreeBSD.ORG>; Wed, 22 Mar 2000 09:56:18 -0800 (PST)
	(envelope-from adsharma@sharmas.dhs.org)
Received: (from adsharma@localhost)
	by sharmas.dhs.org (8.9.3/8.9.3) id JAA02329;
	Wed, 22 Mar 2000 09:56:20 -0800
Date: Wed, 22 Mar 2000 09:56:19 -0800
From: Arun Sharma <adsharma@sharmas.dhs.org>
To: Daniel Eischen <eischen@vigrid.com>
Cc: current@FreeBSD.ORG
Subject: Re: ucontext
Message-ID: <20000322095619.A30197@sharmas.dhs.org>
References: <20000321225432.A4533@sharmas.dhs.org> <Pine.SUN.3.91.1000322080258.15917A-100000@pcnet1.pcnet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.6i
In-Reply-To: <Pine.SUN.3.91.1000322080258.15917A-100000@pcnet1.pcnet.com>; from Daniel Eischen on Wed, Mar 22, 2000 at 08:04:37AM -0500
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Wed, Mar 22, 2000 at 08:04:37AM -0500, Daniel Eischen wrote:
> 
> I had them implemented and working for i386, and even had a hacked up
> libc_r that used them instead of setjmp/longjmp.  This was a few months
> ago under 4.0-current.  At the time, I thought they'd be better off
> implemented as syscalls, but now I'm leaning towards library routines
> similar to setjmp/longjmp (which make a syscall to change the signal
> mask).
> 

UNIX 98 specifies that setcontext should be callable from signal handlers.
http://www.opengroup.org/onlinepubs/007908799/xsh/getcontext.html

That pretty much means system calls. Doesn't it ?

I was wrong about this being necessary for the JDK. Linux doesn't implement
it either (it does have man pages and header files though!) and the JDK
runs fine on Linux. I was mislead by the some of these calls, which will
always fail on Linux.

	-Arun


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 10:29:41 2000
Delivered-To: freebsd-current@freebsd.org
Received: from unix.megared.net.mx (dns.megared.net.mx [200.52.207.52])
	by hub.freebsd.org (Postfix) with ESMTP id 9F25637C1FA
	for <freebsd-current@freebsd.org>; Wed, 22 Mar 2000 10:29:35 -0800 (PST)
	(envelope-from ales@megared.net.mx)
Received: from ales (ales.megared.net.mx [200.52.207.54])
	by unix.megared.net.mx (8.9.3/8.9.3) with SMTP id MAA03953
	for <freebsd-current@freebsd.org>; Wed, 22 Mar 2000 12:29:42 -0600 (CST)
	(envelope-from ales@megared.net.mx)
Message-ID: <051001bf942c$87e3fa40$020a0a0a@megared.net.mx>
From: "Alejandro Ramirez" <ales@megared.net.mx>
To: <freebsd-current@freebsd.org>
Subject: Chrooted telnet support in 4.x???
Date: Wed, 22 Mar 2000 12:29:12 -0600
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Hi,

Will FreeBSD 4.x will be able to chroot telnet sessions natively???, or are
there any plans to integrate this patches to the base system:

http://www.o-o.org/~licia/projects/login/

Thanks
Ales




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 10:41:10 2000
Delivered-To: freebsd-current@freebsd.org
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131])
	by hub.freebsd.org (Postfix) with ESMTP id A15CC37BF0B
	for <freebsd-current@FreeBSD.ORG>; Wed, 22 Mar 2000 10:41:07 -0800 (PST)
	(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1])
	by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id TAA33003;
	Wed, 22 Mar 2000 19:40:45 +0100 (CET)
	(envelope-from phk@critter.freebsd.dk)
To: "Alejandro Ramirez" <ales@megared.net.mx>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: Chrooted telnet support in 4.x??? 
In-reply-to: Your message of "Wed, 22 Mar 2000 12:29:12 CST."
             <051001bf942c$87e3fa40$020a0a0a@megared.net.mx> 
Date: Wed, 22 Mar 2000 19:40:45 +0100
Message-ID: <33001.953750445@critter.freebsd.dk>
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <051001bf942c$87e3fa40$020a0a0a@megared.net.mx>, "Alejandro Ramirez"
 writes:
>Hi,
>
>Will FreeBSD 4.x will be able to chroot telnet sessions natively???, or are
>there any plans to integrate this patches to the base system:

Investigate the jail(8) facility in 4.x, it is *far* stronger than
anything chroot(2) has to offer.

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 10:44:57 2000
Delivered-To: freebsd-current@freebsd.org
Received: from unix.megared.net.mx (dns.megared.net.mx [200.52.207.52])
	by hub.freebsd.org (Postfix) with ESMTP id 46BBF37BF37
	for <freebsd-current@FreeBSD.ORG>; Wed, 22 Mar 2000 10:44:49 -0800 (PST)
	(envelope-from ales@megared.net.mx)
Received: from ales (ales.megared.net.mx [200.52.207.54])
	by unix.megared.net.mx (8.9.3/8.9.3) with SMTP id MAA09215;
	Wed, 22 Mar 2000 12:44:54 -0600 (CST)
	(envelope-from ales@megared.net.mx)
Message-ID: <061301bf942e$a59253a0$020a0a0a@megared.net.mx>
From: "Alejandro Ramirez" <ales@megared.net.mx>
To: "Poul-Henning Kamp" <phk@critter.freebsd.dk>
Cc: <freebsd-current@FreeBSD.ORG>
References: <33001.953750445@critter.freebsd.dk>
Subject: RE: Chrooted telnet support in 4.x??? 
Date: Wed, 22 Mar 2000 12:44:25 -0600
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Thanks a lot for clarifying my mind,

    I will take a look at this.

Greetings...
Ales

----- Original Message -----
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
To: Alejandro Ramirez <ales@megared.net.mx>
Cc: <freebsd-current@FreeBSD.ORG>
Sent: Wednesday, March 22, 2000 12:40 PM
Subject: Re: Chrooted telnet support in 4.x???


> In message <051001bf942c$87e3fa40$020a0a0a@megared.net.mx>, "Alejandro
Ramirez"
>  writes:
> >Hi,
> >
> >Will FreeBSD 4.x will be able to chroot telnet sessions natively???, or
are
> >there any plans to integrate this patches to the base system:
>
> Investigate the jail(8) facility in 4.x, it is *far* stronger than
> anything chroot(2) has to offer.
>
> --
> Poul-Henning Kamp             FreeBSD coreteam member
> phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
> FreeBSD -- It will take a long time before progress goes too far!
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 10:56:10 2000
Delivered-To: freebsd-current@freebsd.org
Received: from inbox.org (inbox.org [216.22.145.8])
	by hub.freebsd.org (Postfix) with ESMTP id 3A64C37BF0B
	for <freebsd-current@FreeBSD.ORG>; Wed, 22 Mar 2000 10:56:04 -0800 (PST)
	(envelope-from bsd@inbox.org)
Received: from localhost (bsd@localhost)
	by inbox.org (8.9.3/8.9.3) with ESMTP id NAA06066;
	Wed, 22 Mar 2000 13:55:33 -0500 (EST)
Date: Wed, 22 Mar 2000 13:55:33 -0500 (EST)
From: "Mr. K." <bsd@inbox.org>
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc: Alejandro Ramirez <ales@megared.net.mx>,
	freebsd-current@FreeBSD.ORG
Subject: Re: Chrooted telnet support in 4.x??? 
In-Reply-To: <33001.953750445@critter.freebsd.dk>
Message-ID: <Pine.BSF.4.21.0003221353440.5894-100000@inbox.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

what would be even cooler is if we could jail() a user natively at
login.  I bet this patch could be easily modified to use jail() instead of
chroot().

On Wed, 22 Mar 2000, Poul-Henning Kamp wrote:

> In message <051001bf942c$87e3fa40$020a0a0a@megared.net.mx>, "Alejandro Ramirez"
>  writes:
> >Hi,
> >
> >Will FreeBSD 4.x will be able to chroot telnet sessions natively???, or are
> >there any plans to integrate this patches to the base system:
> 
> Investigate the jail(8) facility in 4.x, it is *far* stronger than
> anything chroot(2) has to offer.
> 
> --
> Poul-Henning Kamp             FreeBSD coreteam member
> phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
> FreeBSD -- It will take a long time before progress goes too far!
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message
> 



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 10:57:12 2000
Delivered-To: freebsd-current@freebsd.org
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131])
	by hub.freebsd.org (Postfix) with ESMTP id 6E25837BF3A
	for <freebsd-current@FreeBSD.ORG>; Wed, 22 Mar 2000 10:56:54 -0800 (PST)
	(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1])
	by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id TAA33115;
	Wed, 22 Mar 2000 19:56:25 +0100 (CET)
	(envelope-from phk@critter.freebsd.dk)
To: "Mr. K." <bsd@inbox.org>
Cc: Alejandro Ramirez <ales@megared.net.mx>,
	freebsd-current@FreeBSD.ORG
Subject: Re: Chrooted telnet support in 4.x??? 
In-reply-to: Your message of "Wed, 22 Mar 2000 13:55:33 EST."
             <Pine.BSF.4.21.0003221353440.5894-100000@inbox.org> 
Date: Wed, 22 Mar 2000 19:56:25 +0100
Message-ID: <33113.953751385@critter.freebsd.dk>
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


You could do that, rather easily.

In message <Pine.BSF.4.21.0003221353440.5894-100000@inbox.org>, "Mr. K." writes
:
>what would be even cooler is if we could jail() a user natively at
>login.  I bet this patch could be easily modified to use jail() instead of
>chroot().
>
>On Wed, 22 Mar 2000, Poul-Henning Kamp wrote:
>
>> In message <051001bf942c$87e3fa40$020a0a0a@megared.net.mx>, "Alejandro Ramirez"
>>  writes:
>> >Hi,
>> >
>> >Will FreeBSD 4.x will be able to chroot telnet sessions natively???, or are
>> >there any plans to integrate this patches to the base system:
>> 
>> Investigate the jail(8) facility in 4.x, it is *far* stronger than
>> anything chroot(2) has to offer.
>> 
>> --
>> Poul-Henning Kamp             FreeBSD coreteam member
>> phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
>> FreeBSD -- It will take a long time before progress goes too far!
>> 
>> 
>> To Unsubscribe: send mail to majordomo@FreeBSD.org
>> with "unsubscribe freebsd-current" in the body of the message
>> 
>
>

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 11:23:13 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mail4.aracnet.com (mail4.aracnet.com [216.99.193.36])
	by hub.freebsd.org (Postfix) with ESMTP id 4A02D37C207
	for <current@FreeBSD.ORG>; Wed, 22 Mar 2000 11:22:48 -0800 (PST)
	(envelope-from beattie@aracnet.com)
Received: from shell1.aracnet.com (shell1.aracnet.com [216.99.193.21])
	by mail4.aracnet.com (8.9.3/8.9.3) with ESMTP id LAA21590
	for <current@FreeBSD.ORG.>; Wed, 22 Mar 2000 11:22:52 -0800
Received: by shell1.aracnet.com (8.9.3)  id LAA09316; Wed, 22 Mar 2000 11:22:54 -0800
Date: Wed, 22 Mar 2000 11:22:54 -0800 (PST)
From: Brian Beattie <beattie@aracnet.com>
To: current@FreeBSD.ORG
Subject: Re: 4.0-RELEASE boot.flp fails to boot on K6/2 
In-Reply-To: <Pine.BSF.4.21.0003220913150.4434-100000@skaarup.org>
Message-ID: <Pine.LNX.4.21.0003221120100.31899-100000@shell1.aracnet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Wed, 22 Mar 2000, Rasmus Skaarup wrote:

> 
> Jordan K. Hubbard said:
> > Good idea, terrible name.  Can't you guys some up with something better? :)
> 
> kern.flp    -> start.flp  
> mfsroot.flp -> install.flp
> 
> boot.flp    -> bigstart.flp 
>                bigdisk.flp ?

Or Maybe:
kern.144
mfsroot.144
boot.288

or

kern-144.flp
root-144.flp
boot-288.flp


Brian Beattie            | This email was produced using professional quality,
beattie@aracnet.com      | standards based software.  Users of Microsoft
beattie@aracnet.com      | products or other substandard software should
www.aracnet.com/~beattie | contact the author about receiving a Free upgrade to
                         | FreeBSD or Linux.   "FreeBSD: The power to serve"



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 11:44:28 2000
Delivered-To: freebsd-current@freebsd.org
Received: from forrie.net (forrie.net [216.67.12.69])
	by hub.freebsd.org (Postfix) with ESMTP
	id 243D637C218; Wed, 22 Mar 2000 11:44:13 -0800 (PST)
	(envelope-from forrie@forrie.com)
Received: from forrie.forrie.com (boomer.navinet.net [216.67.12.90])
            by forrie.net with id e2MJiBC09788;
            Wed, 22 Mar 2000 14:44:11 -0500 (EST)
Message-Id: <4.3.1.2.20000322144026.00bb1c40@216.67.12.69>
X-Sender: forrie@216.67.12.69
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Wed, 22 Mar 2000 14:42:44 -0500
To: freebsd-questions@freebsd.org, freebsd-current@freebsd.org
From: Forrest Aldrich <forrie@forrie.com>
Subject: 4.0 sysinstall fails to recognize disks
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Since this is a fairly current issue, I'm posting this appropriately.

I have a DELL server that has hooked up to it a PowerVault, with 8 36gb 10krpm LVD drives.   The system has recognized these previously and dmesg shows them present; however, /stand/sysinstall says that I don't have ANY disks installed when using Label or Fdisk.   

Is this a known bug?   I've done a buildworld/installworld yesterday after a cvsup.  


TIA.



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 11:47:38 2000
Delivered-To: freebsd-current@freebsd.org
Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6])
	by hub.freebsd.org (Postfix) with ESMTP
	id 3228237C1A2; Wed, 22 Mar 2000 11:47:33 -0800 (PST)
	(envelope-from billf@jade.chc-chimes.com)
Received: by jade.chc-chimes.com (Postfix, from userid 1001)
	id B46B11C4A; Wed, 22 Mar 2000 14:47:31 -0500 (EST)
Date: Wed, 22 Mar 2000 14:47:31 -0500
From: Bill Fumerola <billf@chc-chimes.com>
To: Forrest Aldrich <forrie@forrie.com>
Cc: freebsd-questions@freebsd.org, freebsd-current@freebsd.org
Subject: Re: 4.0 sysinstall fails to recognize disks
Message-ID: <20000322144731.X25438@jade.chc-chimes.com>
References: <4.3.1.2.20000322144026.00bb1c40@216.67.12.69>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <4.3.1.2.20000322144026.00bb1c40@216.67.12.69>; from forrie@forrie.com on Wed, Mar 22, 2000 at 02:42:44PM -0500
X-Operating-System: FreeBSD 3.2-RELEASE i386
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Wed, Mar 22, 2000 at 02:42:44PM -0500, Forrest Aldrich wrote:

> Since this is a fairly current issue, I'm posting this appropriately.
> 
> I have a DELL server that has hooked up to it a PowerVault, with 8 36gb 
> 10krpm LVD drives.   The system has recognized these previously and dmesg 
> shows them present; however, /stand/sysinstall says that I don't have ANY 
> disks installed when using Label or Fdisk.   

The PowerVault is connected to a controller. Knowledge of which one would help.

-- 
Bill Fumerola - Network Architect
Computer Horizons Corp - CVM
e-mail: billf@chc-chimes.com / billf@FreeBSD.org
Office: 800-252-2421 x128 / Cell: 248-761-7272





To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 11:48:47 2000
Delivered-To: freebsd-current@freebsd.org
Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3])
	by hub.freebsd.org (Postfix) with ESMTP id 784BF37C277
	for <current@FreeBSD.ORG>; Wed, 22 Mar 2000 11:48:42 -0800 (PST)
	(envelope-from eischen@vigrid.com)
Received: (from eischen@localhost)
	by pcnet1.pcnet.com (8.8.7/PCNet) id OAA21854;
	Wed, 22 Mar 2000 14:48:24 -0500 (EST)
Date: Wed, 22 Mar 2000 14:48:24 -0500 (EST)
From: Daniel Eischen <eischen@vigrid.com>
To: Arun Sharma <adsharma@sharmas.dhs.org>
Cc: current@FreeBSD.ORG
Subject: Re: ucontext
In-Reply-To: <20000322095619.A30197@sharmas.dhs.org>
Message-ID: <Pine.SUN.3.91.1000322143136.19280A-100000@pcnet1.pcnet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Wed, 22 Mar 2000, Arun Sharma wrote:

> On Wed, Mar 22, 2000 at 08:04:37AM -0500, Daniel Eischen wrote:
> > 
> > I had them implemented and working for i386, and even had a hacked up
> > libc_r that used them instead of setjmp/longjmp.  This was a few months
> > ago under 4.0-current.  At the time, I thought they'd be better off
> > implemented as syscalls, but now I'm leaning towards library routines
> > similar to setjmp/longjmp (which make a syscall to change the signal
> > mask).
> > 
> 
> UNIX 98 specifies that setcontext should be callable from signal handlers.
> http://www.opengroup.org/onlinepubs/007908799/xsh/getcontext.html
> 
> That pretty much means system calls. Doesn't it ?

I don't know, does it?  The reason we don't want it to be a system
call is that if the threads library is going to use it to save and
restore thread state, we don't want the overhead of a system call.
The threads library doesn't _have_ to use ucontext, but both the
kernel and the threads library have to agree to some format (the
kernel has to pass register state out to the threads library when
threads once blocked in the kernel become unblocked).

> 
> I was wrong about this being necessary for the JDK. Linux doesn't implement
> it either (it does have man pages and header files though!) and the JDK
> runs fine on Linux. I was mislead by the some of these calls, which will
> always fail on Linux.

Dan Eischen
eischen@vigrid.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 11:52: 3 2000
Delivered-To: freebsd-current@freebsd.org
Received: from forrie.net (forrie.net [216.67.12.69])
	by hub.freebsd.org (Postfix) with ESMTP
	id BB80537B709; Wed, 22 Mar 2000 11:51:48 -0800 (PST)
	(envelope-from forrie@forrie.com)
Received: from forrie.forrie.com (boomer.navinet.net [216.67.12.90])
            by forrie.net with id e2MJpjC09874;
            Wed, 22 Mar 2000 14:51:46 -0500 (EST)
Message-Id: <4.3.1.2.20000322144918.00b8d6c0@216.67.12.69>
X-Sender: forrie@216.67.12.69
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Wed, 22 Mar 2000 14:50:19 -0500
To: Bill Fumerola <billf@chc-chimes.com>
From: Forrest Aldrich <forrie@forrie.com>
Subject: Re: 4.0 sysinstall fails to recognize disks
Cc: freebsd-questions@freebsd.org, freebsd-current@freebsd.org
In-Reply-To: <20000322144731.X25438@jade.chc-chimes.com>
References: <4.3.1.2.20000322144026.00bb1c40@216.67.12.69>
 <4.3.1.2.20000322144026.00bb1c40@216.67.12.69>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


Sorry:

da4 at ahc0 bus 0 target 1 lun 0
da4: <QUANTUM ATLAS 10K 36SCA UCHD> Fixed Direct Access SCSI-3 device 
da4: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled
da4: 34732MB (71132998 512 byte sectors: 255H 63S/T 4427C)


_F

At 02:47 PM 3/22/00 -0500, Bill Fumerola wrote:
>On Wed, Mar 22, 2000 at 02:42:44PM -0500, Forrest Aldrich wrote:
>
> > Since this is a fairly current issue, I'm posting this appropriately.
> > 
> > I have a DELL server that has hooked up to it a PowerVault, with 8 36gb 
> > 10krpm LVD drives.   The system has recognized these previously and dmesg 
> > shows them present; however, /stand/sysinstall says that I don't have ANY 
> > disks installed when using Label or Fdisk.   
>
>The PowerVault is connected to a controller. Knowledge of which one would help.
>
>-- 
>Bill Fumerola - Network Architect
>Computer Horizons Corp - CVM
>e-mail: billf@chc-chimes.com / billf@FreeBSD.org
>Office: 800-252-2421 x128 / Cell: 248-761-7272
>
>




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 12:20:32 2000
Delivered-To: freebsd-current@freebsd.org
Received: from sabre.velocet.net (sabre.velocet.net [198.96.118.66])
	by hub.freebsd.org (Postfix) with ESMTP id 0E65E37BAEC
	for <freebsd-current@freebsd.org>; Wed, 22 Mar 2000 12:20:23 -0800 (PST)
	(envelope-from dgilbert@office.tor.velocet.net)
Received: from office.tor.velocet.net (trooper.velocet.net [216.126.82.226])
	by sabre.velocet.net (Postfix) with ESMTP id CDD99137F75
	for <freebsd-current@freebsd.org>; Wed, 22 Mar 2000 15:20:16 -0500 (EST)
Received: (from dgilbert@localhost)
	by office.tor.velocet.net (8.9.3/8.9.3) id PAA46248;
	Wed, 22 Mar 2000 15:20:16 -0500 (EST)
	(envelope-from dgilbert)
From: David Gilbert <dgilbert@velocet.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14553.11008.223881.155942@trooper.velocet.net>
Date: Wed, 22 Mar 2000 15:20:16 -0500 (EST)
To: freebsd-current@freebsd.org
Subject: cd drivers and the 21143.
X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs  Lucid
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

I'm having some troubles with the dc driver and the 21143's.  I have
12 ports in a machine (3x 4 port cards).  Before I had more than 8 of
them connected, I never had any problems.  Now... I find that if I
unplug a cable and then reconnect it, that the driver will not
properly recognise the traffic on the interface.

It doesn't sound like the problem that if_dc.c version 1.4 was
addressing --- I can see traffic with tcpdump.

If I reboot the machine, the interfaces come up fine.

Dave.

-- 
============================================================================
|David Gilbert, Velocet Communications.       | Two things can only be     |
|Mail:       dgilbert@velocet.net             |  equal if and only if they |
|http://www.velocet.net/~dgilbert             |   are precisely opposite.  |
=========================================================GLO================


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 12:38:45 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mass.cdrom.com (mg134-217.ricochet.net [204.179.134.217])
	by hub.freebsd.org (Postfix) with ESMTP
	id 1EB4A37C24E; Wed, 22 Mar 2000 12:38:32 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Received: from mass.cdrom.com (localhost [127.0.0.1])
	by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id MAA00661;
	Wed, 22 Mar 2000 12:39:46 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Message-Id: <200003222039.MAA00661@mass.cdrom.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: Paul Richards <paul@originative.co.uk>,
	Richard Wendland <richard@netcraft.com>,
	Alfred Perlstein <bright@wintelcom.net>,
	Poul-Henning Kamp <phk@critter.freebsd.dk>, current@FreeBSD.ORG,
	fs@FreeBSD.ORG
Subject: Re: FreeBSD random I/O performance issues 
In-reply-to: Your message of "Tue, 21 Mar 2000 22:17:52 PST."
             <200003220617.WAA86154@apollo.backplane.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 22 Mar 2000 12:39:42 -0800
From: Mike Smith <msmith@freebsd.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

>     effects of the I/O being in-progress.  If a user program doesn't access
>     any of the information it recently wrote the whole mechanism winds up
>     operating asynchronously in the background.  If a user program does, 
>     then the write behind mechanism breaks down and you get a stall.

What makes no sense is that it should be perfectly ok to _read_ this 
information back.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
\\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 12:41:17 2000
Delivered-To: freebsd-current@freebsd.org
Received: from dt051n0b.san.rr.com (dt051n0b.san.rr.com [204.210.32.11])
	by hub.freebsd.org (Postfix) with ESMTP
	id 0FBF537C2DA; Wed, 22 Mar 2000 12:41:11 -0800 (PST)
	(envelope-from Doug@gorean.org)
Received: from slave (doug@slave [10.0.0.1])
	by dt051n0b.san.rr.com (8.9.3/8.9.3) with ESMTP id MAA80861;
	Wed, 22 Mar 2000 12:40:30 -0800 (PST)
	(envelope-from Doug@gorean.org)
Date: Wed, 22 Mar 2000 12:40:30 -0800 (PST)
From: Doug Barton <Doug@gorean.org>
X-Sender: doug@dt051n0b.san.rr.com
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc: Paul Richards <paul@originative.co.uk>,
	Stephen Hocking-Senior Programmer PGS SPS Perth <shocking@prth.pgs.com>,
	current@freebsd.org, poul@freebsd.org
Subject: Re: Another current crash (cvs-cur.6183 
In-Reply-To: <29683.953706815@critter.freebsd.dk>
Message-ID: <Pine.BSF.4.21.0003221239440.80766-100000@dt051n0b.san.rr.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Wed, 22 Mar 2000, Poul-Henning Kamp wrote:

> But it might actually make a lot of sense to make INVARIANTS the
> default this early in the -CURRENT cycle, protests ?

	What kind of overhead does it add? The warning messages in LINT
look rather dire to me, but I'm interested in knowing the facts..

Doug
-- 
"While the future's there for anyone to change, still you know it seems, 
 it would be easier sometimes to change the past"

     - Jackson Browne, "Fountain of Sorrow"



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 12:52:50 2000
Delivered-To: freebsd-current@freebsd.org
Received: from sharmas.dhs.org (c62443-a.frmt1.sfba.home.com [24.0.69.165])
	by hub.freebsd.org (Postfix) with ESMTP id 6147637B709
	for <current@FreeBSD.ORG>; Wed, 22 Mar 2000 12:52:47 -0800 (PST)
	(envelope-from adsharma@sharmas.dhs.org)
Received: (from adsharma@localhost)
	by sharmas.dhs.org (8.9.3/8.9.3) id MAA02716;
	Wed, 22 Mar 2000 12:52:39 -0800
Date: Wed, 22 Mar 2000 12:52:39 -0800
From: Arun Sharma <adsharma@sharmas.dhs.org>
To: Daniel Eischen <eischen@vigrid.com>
Cc: current@FreeBSD.ORG
Subject: Re: ucontext
Message-ID: <20000322125239.A2646@sharmas.dhs.org>
References: <20000322095619.A30197@sharmas.dhs.org> <Pine.SUN.3.91.1000322143136.19280A-100000@pcnet1.pcnet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.6i
In-Reply-To: <Pine.SUN.3.91.1000322143136.19280A-100000@pcnet1.pcnet.com>; from Daniel Eischen on Wed, Mar 22, 2000 at 02:48:24PM -0500
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Wed, Mar 22, 2000 at 02:48:24PM -0500, Daniel Eischen wrote:
> On Wed, 22 Mar 2000, Arun Sharma wrote:
> 
> > On Wed, Mar 22, 2000 at 08:04:37AM -0500, Daniel Eischen wrote:
> > > 
> > > I had them implemented and working for i386, and even had a hacked up
> > > libc_r that used them instead of setjmp/longjmp.  This was a few months
> > > ago under 4.0-current.  At the time, I thought they'd be better off
> > > implemented as syscalls, but now I'm leaning towards library routines
> > > similar to setjmp/longjmp (which make a syscall to change the signal
> > > mask).
> > > 
> > 
> > UNIX 98 specifies that setcontext should be callable from signal handlers.
> > http://www.opengroup.org/onlinepubs/007908799/xsh/getcontext.html
> > 
> > That pretty much means system calls. Doesn't it ?
> 
> I don't know, does it?  The reason we don't want it to be a system
> call is that if the threads library is going to use it to save and
> restore thread state, we don't want the overhead of a system call.

You're right. It doesn't have to be a system call, just to support 
longjmp'ing or doing setcontext from signal handlers.

However, I can think of two situations under which it might have to
be a system call:

(a) If the user is allowed to modify the system mode context of the processor
    i.e. things that can be done only in the privileged mode.
(b) If one needs to get the context of other blocked processes

Neither of the two sound like strong reasons to me.

	-Arun


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 12:57:50 2000
Delivered-To: freebsd-current@freebsd.org
Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193])
	by hub.freebsd.org (Postfix) with ESMTP id 692AF37B84D
	for <current@FreeBSD.ORG>; Wed, 22 Mar 2000 12:57:31 -0800 (PST)
	(envelope-from wollman@khavrinen.lcs.mit.edu)
Received: (from wollman@localhost)
	by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id PAA28256;
	Wed, 22 Mar 2000 15:57:23 -0500 (EST)
	(envelope-from wollman)
Date: Wed, 22 Mar 2000 15:57:23 -0500 (EST)
From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Message-Id: <200003222057.PAA28256@khavrinen.lcs.mit.edu>
To: Arun Sharma <adsharma@sharmas.dhs.org>
Cc: Daniel Eischen <eischen@vigrid.com>, current@FreeBSD.ORG
Subject: Re: ucontext
In-Reply-To: <20000322125239.A2646@sharmas.dhs.org>
References: <20000322095619.A30197@sharmas.dhs.org>
	<Pine.SUN.3.91.1000322143136.19280A-100000@pcnet1.pcnet.com>
	<20000322125239.A2646@sharmas.dhs.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

<<On Wed, 22 Mar 2000 12:52:39 -0800, Arun Sharma <adsharma@sharmas.dhs.org> said:

> However, I can think of two situations under which it might have to
> be a system call:

I'm fairly certain I found a circumstance which required that it be
available to a system call, but I can't remember quite what it was.
(It was some other system call which could accept a ucontext_t.)

-GAWollman

--
Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
wollman@lcs.mit.edu  | O Siem / The fires of freedom 
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA|                     - Susan Aglukark and Chad Irschick


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 13: 0:14 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mass.cdrom.com (mg134-217.ricochet.net [204.179.134.217])
	by hub.freebsd.org (Postfix) with ESMTP
	id 17DE037C29B; Wed, 22 Mar 2000 13:00:07 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Received: from mass.cdrom.com (localhost [127.0.0.1])
	by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id NAA01164;
	Wed, 22 Mar 2000 13:02:52 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Message-Id: <200003222102.NAA01164@mass.cdrom.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To: Ollivier Robert <roberto@eurocontrol.fr>
Cc: John Baldwin <jhb@FreeBSD.org>, dcs@FreeBSD.org,
	"FreeBSD Current Users' list" <freebsd-current@FreeBSD.org>
Subject: Re: /boot/loader is making my VAIO reboot 
In-reply-to: Your message of "Wed, 22 Mar 2000 11:27:10 +0100."
             <20000322112710.C15904@caerdonn.eurocontrol.fr> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 22 Mar 2000 13:02:52 -0800
From: Mike Smith <msmith@freebsd.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> > if you can get a prompt, please.
> 
> No prompt. It reboots just after displaying the 'Hit [Enter] blah' line.

Can you be more specific here - does it reboot _immediately_ after 
printing that message, or after the timeout finishes?

Try putting just "set autoboot_delay=0" in /boot/loader.rc and see if 
that gives you a prompt.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
\\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 13:42: 2 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mail.hellasnet.gr (mail.hellasnet.gr [212.54.192.3])
	by hub.freebsd.org (Postfix) with ESMTP id 7AB1537B5C4
	for <current@freebsd.org>; Wed, 22 Mar 2000 13:41:41 -0800 (PST)
	(envelope-from keramida@ceid.upatras.gr)
Received: from hades.hell.gr (ppp1.patr.hellasnet.gr [212.54.197.16])
	by mail.hellasnet.gr (8.9.1/8.9.1) with SMTP id XAA23561
	for <current@freebsd.org>; Wed, 22 Mar 2000 23:40:31 +0200 (GMT)
Received: (qmail 419 invoked by uid 1001); 22 Mar 2000 21:16:26 -0000
Date: Wed, 22 Mar 2000 23:16:26 +0200
From: Giorgos Keramidas <keramida@ceid.upatras.gr>
To: current@freebsd.org
Subject: crash in atkbd_isa_intr()
Message-ID: <20000322231626.A379@hades.hell.gr>
Reply-To: keramida@ceid.upatras.gr
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="vtzGhvizbBRQ85DL"
X-Mailer: Mutt 1.0i
X-PGP-Fingerprint: 62 45 D1 C9 26 F9 95 06  D6 21 2A C8 8C 16 C0 8E
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


--vtzGhvizbBRQ85DL
Content-Type: text/plain; charset=us-ascii

I CVSup'ed 5.0 sources yesterday, and built my kernel this afternoon.
The kernel built find, and I booted with the new kernel.  The uname
output is:

    FreeBSD hades.hell.gr 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Mar 22
    17:04:49 EET 2000 root@hades.hell.gr:/usr/src/sys/compile/HADES i386

When I tried to 'make buildworld' though, the kernel froze while
compiling openssl.  I thought it might be openssl triggering a bug in
gcc, for a while, and tried building world a couple of times, but the
system froze in different places; the kgdb information is shown below.

The kernel apparently stopped in atkbd_isa_intr().  I don't know if it
has any relation to the processing of interrupts, but after the system
freezes, and I boot, the hard disk seems to do some form of hard reset,
as if it was stopped for power-saving or something...

I'll try CVSup'ing once more today, and see if the new kernel stops
frozen too, but since this does not happen with the kernel I've kept as
my /kernel.safe (compiled from sources cvsup'ed on march 16), uhm,
I don't know.. is there something strange going on with atkbd?

I've seen commits on March 18th from Kazukata Yokota for the files:

    sys/isa              atkbd_isa.c atkbdc_isa.c
    sys/dev/kbd          atkbd.c atkbdc.c atkbdcreg.h atkbdreg.h
    sys/i386/isa/pcvt    pcvt_hdr.h

but has anyone else been having problems with these?

Attachments are:

    #0	dmesg output of first boot after crash
    #1	kgdb output for `where' and `list'

- Giorgos Keramidas

--vtzGhvizbBRQ85DL
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="dmesg.0"

Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
	The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #0: Wed Mar 22 17:04:49 EET 2000
    root@hades.hell.gr:/usr/src/sys/compile/HADES
Timecounter "i8254"  frequency 1193182 Hz
CPU: Pentium/P54C (132.63-MHz 586-class CPU)
  Origin = "GenuineIntel"  Id = 0x52c  Stepping = 12
  Features=0x1bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8>
real memory  = 33554432 (32768K bytes)
config> q
avail memory = 29831168 (29132K bytes)
Preloaded elf kernel "kernel" at 0xc02bf000.
Preloaded userconfig_script "/boot/kernel.conf" at 0xc02bf09c.
Intel Pentium detected, installing workaround for F00F bug
VESA: v1.2, 2048k memory, flags:0x0, mode table:0xc00c1bfa (c0001bfa)
VESA: S3 Incorporated. 86C325
npx0: <math processor> on motherboard
npx0: INT 16 interface
pcib0: <Host to PCI bridge> on motherboard
pci0: <PCI bus> on pcib0
isab0: <Intel 82371SB PCI to ISA bridge> at device 7.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel PIIX3 ATA controller> port 0xf000-0xf00f at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
pci0: <S3 ViRGE graphics accelerator> at 11.0 irq 11
fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
sc0: <System console> on isa0
sc0: VGA <16 virtual consoles, flags=0x200>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/16 bytes threshold
lpt0: <Printer> on ppbus0
lpt0: Interrupt-driven port
plip0: <PLIP network interface> on ppbus0
sbc0: <Creative SB16/SB32> at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0
sbc0: setting card to irq 5, drq 1, 5
pcm0: <SB DSP 4.13> on sbc0
unknown0: <Generic ESDI/IDE/ATA controller> at port 0x168-0x16f,0x36e-0x36f irq 10 on isa0
unknown1: <StereoEnhance> at port 0x100 on isa0
unknown2: <Game> at port 0x200-0x207 on isa0
IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to deny, logging limited to 100 packets/entry by default
DUMMYNET initialized (000106)
ad0: 6149MB <WDC AC26400B> [13328/15/63] at ata0-master using WDMA2
acd0: CDROM <FX4820T> at ata1-master using WDMA2
Mounting root from ufs:/dev/ad0s1a
WARNING: / was not properly dismounted

--vtzGhvizbBRQ85DL
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="kgdb.0"

hades# cd /sys/compile/HADES
/usr/src/sys/compile/HADES
hades# gdb -k kernel.debug /var/crash/vmcore.0
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
IdlePTD 2953216
initial pcb at 25ea80
panicstr: from debugger
panic messages:
---
panic: from debugger

syncing disks... 
done
Uptime: 57m27s

dumping to dev #ad/0x20001, offset 65536
dump ata0: resetting devices .. done
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:304
304			dumppcb.pcb_cr3 = rcr3();
(kgdb) where
#0  boot (howto=256) at ../../kern/kern_shutdown.c:304
#1  0xc0136195 in panic (fmt=0xc02004b4 "from debugger")
    at ../../kern/kern_shutdown.c:554
#2  0xc011b489 in db_panic (addr=-1071777419, have_addr=0, count=-1, 
    modif=0xc02262d4 "") at ../../ddb/db_command.c:433
#3  0xc011b429 in db_command (last_cmdp=0xc0227538, cmd_table=0xc0227398, 
    aux_cmd_tablep=0xc025b214) at ../../ddb/db_command.c:333
#4  0xc011b4ee in db_command_loop () at ../../ddb/db_command.c:455
#5  0xc011d5ff in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
#6  0xc01df715 in kdb_trap (type=3, code=0, regs=0xc02263dc)
    at ../../i386/i386/db_interface.c:158
#7  0xc01eb5d0 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, 
      tf_edi = -1071176096, tf_esi = -1071199872, tf_ebp = -1071487964, 
      tf_isp = -1071487992, tf_ebx = 134, tf_edx = 1073741824, 
      tf_ecx = -1071206912, tf_eax = 38, tf_trapno = 3, tf_err = 0, 
      tf_eip = -1071777419, tf_cs = 8, tf_eflags = 582, tf_esp = -1071528961, 
      tf_ss = -1071542615}) at ../../i386/i386/trap.c:549
#8  0xc01df975 in Debugger (msg=0xc0218ea9 "manual escape to debugger")
    at machine/cpufunc.h:64
#9  0xc01db626 in scgetc (sc=0xc0272660, flags=2)
    at ../../dev/syscons/syscons.c:3134
#10 0xc01d80a9 in sckbdevent (thiskbd=0xc026b140, event=0, arg=0xc0272660)
    at ../../dev/syscons/syscons.c:634
#11 0xc01cf166 in atkbd_intr (kbd=0xc026b140, arg=0x0)
    at ../../dev/kbd/atkbd.c:462
#12 0xc01f8024 in atkbd_isa_intr (arg=0xc026b140) at ../../isa/atkbd_isa.c:125
(kgdb) up 12
#12 0xc01f8024 in atkbd_isa_intr (arg=0xc026b140) at ../../isa/atkbd_isa.c:125
125		(*kbdsw[kbd->kb_index]->intr)(kbd, NULL);
(kgdb) list
120	atkbd_isa_intr(void *arg)
121	{
122		keyboard_t *kbd;
123	
124		kbd = (keyboard_t *)arg;
125		(*kbdsw[kbd->kb_index]->intr)(kbd, NULL);
126	}
127	
128	DRIVER_MODULE(atkbd, atkbdc, atkbd_driver, atkbd_devclass, 0, 0);
(kgdb) quit

--vtzGhvizbBRQ85DL--


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 13:48: 0 2000
Delivered-To: freebsd-current@freebsd.org
Received: from feral.com (feral.com [192.67.166.1])
	by hub.freebsd.org (Postfix) with ESMTP id 5332F37B692
	for <freebsd-current@freebsd.org>; Wed, 22 Mar 2000 13:47:57 -0800 (PST)
	(envelope-from mjacob@feral.com)
Received: from beppo.feral.com (beppo [192.67.166.79])
	by feral.com (8.9.3/8.9.3) with ESMTP id NAA07587
	for <freebsd-current@freebsd.org>; Wed, 22 Mar 2000 13:47:56 -0800
Date: Wed, 22 Mar 2000 13:47:56 -0800 (PST)
From: Matthew Jacob <mjacob@feral.com>
Reply-To: mjacob@feral.com
To: freebsd-current@freebsd.org
Subject: -current PCVT breakage?
Message-ID: <Pine.BSF.4.10.10003221347330.10867-100000@beppo.feral.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


Is someone planning on fixing this?


../../i386/isa/pcvt/pcvt_hdr.h:943: warning: `struct isa_device' declared inside parameter list
../../i386/isa/pcvt/pcvt_hdr.h:943: warning: its scope is only this definition or declaration, which is probably not what you want.
../../i386/isa/pcvt/pcvt_hdr.h:944: warning: `struct isa_device' declared inside parameter list
../../i386/isa/pcvt/pcvt_hdr.h:946: variable `vtdriver' has initializer but incomplete type
../../i386/isa/pcvt/pcvt_hdr.h:947: warning: excess elements in struct initializer
../../i386/isa/pcvt/pcvt_hdr.h:947: warning: (near initialization for `vtdriver')
../../i386/isa/pcvt/pcvt_hdr.h:947: warning: excess elements in struct initializer
../../i386/isa/pcvt/pcvt_hdr.h:947: warning: (near initialization for `vtdriver')
../../i386/isa/pcvt/pcvt_hdr.h:947: warning: excess elements in struct initializer
../../i386/isa/pcvt/pcvt_hdr.h:947: warning: (near initialization for `vtdriver')
../../i386/isa/pcvt/pcvt_hdr.h:947: warning: excess elements in struct initializer
../../i386/isa/pcvt/pcvt_hdr.h:947: warning: (near initialization for `vtdriver')
../../i386/isa/pcvt/pcvt_drv.c:130: warning: `struct isa_device' declared inside parameter list
../../i386/isa/pcvt/pcvt_drv.c:133: conflicting types for `pcprobe'
../../i386/isa/pcvt/pcvt_hdr.h:943: previous declaration of `pcprobe'
../../i386/isa/pcvt/pcvt_drv.c: In function `pcprobe':
../../i386/isa/pcvt/pcvt_drv.c:140: dereferencing pointer to incomplete type
../../i386/isa/pcvt/pcvt_drv.c: At top level:
../../i386/isa/pcvt/pcvt_drv.c:172: warning: `struct isa_device' declared inside parameter list
../../i386/isa/pcvt/pcvt_drv.c:173: conflicting types for `pcattach'
../../i386/isa/pcvt/pcvt_hdr.h:944: previous declaration of `pcattach'
../../i386/isa/pcvt/pcvt_drv.c: In function `pcattach':
../../i386/isa/pcvt/pcvt_drv.c:182: dereferencing pointer to incomplete type
../../i386/isa/pcvt/pcvt_drv.c:190: dereferencing pointer to incomplete type
../../i386/isa/pcvt/pcvt_drv.c:358: dereferencing pointer to incomplete type
*** Error code 1




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 13:50:25 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mass.cdrom.com (mg134-217.ricochet.net [204.179.134.217])
	by hub.freebsd.org (Postfix) with ESMTP id 73A9337C26B
	for <current@freebsd.org>; Wed, 22 Mar 2000 13:50:07 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Received: from mass.cdrom.com (localhost [127.0.0.1])
	by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id NAA01451;
	Wed, 22 Mar 2000 13:52:46 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Message-Id: <200003222152.NAA01451@mass.cdrom.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To: keramida@ceid.upatras.gr
Cc: current@freebsd.org
Subject: Not actually (Was Re: crash in atkbd_isa_intr() )
In-reply-to: Your message of "Wed, 22 Mar 2000 23:16:26 +0200."
             <20000322231626.A379@hades.hell.gr> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 22 Mar 2000 13:52:46 -0800
From: Mike Smith <msmith@freebsd.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> I CVSup'ed 5.0 sources yesterday, and built my kernel this afternoon.
> The kernel built find, and I booted with the new kernel.  The uname
> output is:
> 
>     FreeBSD hades.hell.gr 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Mar 22
>     17:04:49 EET 2000 root@hades.hell.gr:/usr/src/sys/compile/HADES i386
> 
> When I tried to 'make buildworld' though, the kernel froze while
> compiling openssl.  I thought it might be openssl triggering a bug in
> gcc, for a while, and tried building world a couple of times, but the
> system froze in different places; the kgdb information is shown below.
> 
> The kernel apparently stopped in atkbd_isa_intr().

No, that's where it went when you hit alt-ctrl-esc.
> #0  boot (howto=256) at ../../kern/kern_shutdown.c:304
> 304			dumppcb.pcb_cr3 = rcr3();
> (kgdb) where
> #0  boot (howto=256) at ../../kern/kern_shutdown.c:304
> #1  0xc0136195 in panic (fmt=0xc02004b4 "from debugger")
>     at ../../kern/kern_shutdown.c:554
> #2  0xc011b489 in db_panic (addr=-1071777419, have_addr=0, count=-1, 
>     modif=0xc02262d4 "") at ../../ddb/db_command.c:433
> #3  0xc011b429 in db_command (last_cmdp=0xc0227538, cmd_table=0xc0227398, 
>     aux_cmd_tablep=0xc025b214) at ../../ddb/db_command.c:333
> #4  0xc011b4ee in db_command_loop () at ../../ddb/db_command.c:455
> #5  0xc011d5ff in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
> #6  0xc01df715 in kdb_trap (type=3, code=0, regs=0xc02263dc)
>     at ../../i386/i386/db_interface.c:158
> #7  0xc01eb5d0 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, 
>       tf_edi = -1071176096, tf_esi = -1071199872, tf_ebp = -1071487964, 
>       tf_isp = -1071487992, tf_ebx = 134, tf_edx = 1073741824, 
>       tf_ecx = -1071206912, tf_eax = 38, tf_trapno = 3, tf_err = 0, 
>       tf_eip = -1071777419, tf_cs = 8, tf_eflags = 582, tf_esp = -1071528961, 
>       tf_ss = -1071542615}) at ../../i386/i386/trap.c:549
> #8  0xc01df975 in Debugger (msg=0xc0218ea9 "manual escape to debugger")
>     at machine/cpufunc.h:64
> #9  0xc01db626 in scgetc (sc=0xc0272660, flags=2)
>     at ../../dev/syscons/syscons.c:3134
> #10 0xc01d80a9 in sckbdevent (thiskbd=0xc026b140, event=0, arg=0xc0272660)
>     at ../../dev/syscons/syscons.c:634
> #11 0xc01cf166 in atkbd_intr (kbd=0xc026b140, arg=0x0)
>     at ../../dev/kbd/atkbd.c:462
> #12 0xc01f8024 in atkbd_isa_intr (arg=0xc026b140) at ../../isa/atkbd_isa.c:125

This is just you breaking into the debugger, followed by what looks like 
a 'panic' command.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
\\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 13:53:39 2000
Delivered-To: freebsd-current@freebsd.org
Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228])
	by hub.freebsd.org (Postfix) with ESMTP id 5931537C282
	for <current@FreeBSD.ORG>; Wed, 22 Mar 2000 13:53:37 -0800 (PST)
	(envelope-from jkh@zippy.cdrom.com)
Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1])
	by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id NAA22855;
	Wed, 22 Mar 2000 13:53:50 -0800 (PST)
	(envelope-from jkh@zippy.cdrom.com)
To: Brian Beattie <beattie@aracnet.com>
Cc: current@FreeBSD.ORG
Subject: Re: 4.0-RELEASE boot.flp fails to boot on K6/2 
In-reply-to: Your message of "Wed, 22 Mar 2000 11:22:54 PST."
             <Pine.LNX.4.21.0003221120100.31899-100000@shell1.aracnet.com> 
Date: Wed, 22 Mar 2000 13:53:50 -0800
Message-ID: <22852.953762030@zippy.cdrom.com>
From: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> kern-144.flp
> root-144.flp
> boot-288.flp

Winner!  Much better than my personal favorite of bigbooty.flp.  :-)

- Jordan


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 13:54: 1 2000
Delivered-To: freebsd-current@freebsd.org
Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87])
	by hub.freebsd.org (Postfix) with ESMTP
	id 74F0037C2F5; Wed, 22 Mar 2000 13:53:53 -0800 (PST)
	(envelope-from dcs@newsguy.com)
Received: from newsguy.com (dcs@p27-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.156])
	by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id GAA13906;
	Thu, 23 Mar 2000 06:53:51 +0900 (JST)
Message-ID: <38D94095.CCE928E9@newsguy.com>
Date: Thu, 23 Mar 2000 06:52:22 +0900
From: "Daniel C. Sobral" <dcs@newsguy.com>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en,pt-BR,ja
MIME-Version: 1.0
To: Mike Smith <msmith@FreeBSD.org>
Cc: Ollivier Robert <roberto@eurocontrol.fr>,
	John Baldwin <jhb@FreeBSD.org>, dcs@FreeBSD.org,
	"FreeBSD Current Users' list" <freebsd-current@FreeBSD.org>
Subject: Re: /boot/loader is making my VAIO reboot
References: <200003222102.NAA01164@mass.cdrom.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Mike Smith wrote:
> 
> > > if you can get a prompt, please.
> >
> > No prompt. It reboots just after displaying the 'Hit [Enter] blah' line.
> 
> Can you be more specific here - does it reboot _immediately_ after
> printing that message, or after the timeout finishes?
> 
> Try putting just "set autoboot_delay=0" in /boot/loader.rc and see if
> that gives you a prompt.

Or just pressing space when the countdown message first appears...

--
Daniel C. Sobral			(8-DCS)
dcs@newsguy.com
dcs@freebsd.org
capo@zurichgnomes.bsdconspiracy.net

	One Unix to rule them all, One Resolver to find them,
        One IP to bring them all and in the zone bind them.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 14: 0:21 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mail.hellasnet.gr (mail.hellasnet.gr [212.54.192.3])
	by hub.freebsd.org (Postfix) with ESMTP id DCC1A37C259
	for <current@freebsd.org>; Wed, 22 Mar 2000 13:59:12 -0800 (PST)
	(envelope-from keramida@ceid.upatras.gr)
Received: from hades.hell.gr (ppp1.patr.hellasnet.gr [212.54.197.16])
	by mail.hellasnet.gr (8.9.1/8.9.1) with SMTP id XAA24317
	for <current@freebsd.org>; Wed, 22 Mar 2000 23:58:05 +0200 (GMT)
Received: (qmail 2389 invoked by uid 1001); 22 Mar 2000 22:00:17 -0000
Date: Thu, 23 Mar 2000 00:00:17 +0200
From: Giorgos Keramidas <keramida@ceid.upatras.gr>
To: Mike Smith <msmith@freebsd.org>
Cc: current@freebsd.org
Subject: Re: Not actually (Was Re: crash in atkbd_isa_intr() )
Message-ID: <20000323000017.A2325@hades.hell.gr>
Reply-To: keramida@ceid.upatras.gr
References: <20000322231626.A379@hades.hell.gr> <200003222152.NAA01451@mass.cdrom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200003222152.NAA01451@mass.cdrom.com>; from msmith@freebsd.org on Wed, Mar 22, 2000 at 01:52:46PM -0800
X-PGP-Fingerprint: 62 45 D1 C9 26 F9 95 06  D6 21 2A C8 8C 16 C0 8E
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Wed, Mar 22, 2000 at 01:52:46PM -0800, Mike Smith wrote:
> > 
> > The kernel apparently stopped in atkbd_isa_intr().
> 
> No, that's where it went when you hit alt-ctrl-esc.

Yes, I did, to get into the debugger.  Now I wonder, if there is some
other bug that I need to chase around, how should I proceed?

Hitting alt-ctrl-esc makes the atkbd_* routines take over, and I don't
get a chance to see why the system freezes :/

> This is just you breaking into the debugger, followed by what looks
> like a 'panic' command.

It *is* a panic command, but it seems that apart from cvsup'ing my
sources tonight to their older revision (march 16) and rebuilding
kernel+world, I don't have much more information for the crash.

Be back to you with more info, after I roll back my sources to some
older date and see which is the first version that makes my system stop
coldly.

- Giorgos Keramidas


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 14: 1:57 2000
Delivered-To: freebsd-current@freebsd.org
Received: from rover.village.org (rover.village.org [204.144.255.49])
	by hub.freebsd.org (Postfix) with ESMTP id 4990037C2A1
	for <freebsd-current@FreeBSD.ORG>; Wed, 22 Mar 2000 14:01:49 -0800 (PST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (harmony.village.org [10.0.0.6])
	by rover.village.org (8.9.3/8.9.3) with ESMTP id PAA29964;
	Wed, 22 Mar 2000 15:01:47 -0700 (MST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id PAA33948; Wed, 22 Mar 2000 15:01:46 -0700 (MST)
Message-Id: <200003222201.PAA33948@harmony.village.org>
To: "Ilmar S. Habibulin" <ilmar@ints.ru>
Subject: Re: -current sudden panics :( 
Cc: Nikolai Saoukh <nms@otdel-1.org>,
	Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>,
	freebsd-current@FreeBSD.ORG
In-reply-to: Your message of "Wed, 22 Mar 2000 08:15:39 +0300."
		<Pine.BSF.4.21.0003220813250.220-100000@ws-ilmar.ints.ru> 
References: <Pine.BSF.4.21.0003220813250.220-100000@ws-ilmar.ints.ru>  
Date: Wed, 22 Mar 2000 15:01:46 -0700
From: Warner Losh <imp@village.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <Pine.BSF.4.21.0003220813250.220-100000@ws-ilmar.ints.ru> "Ilmar S. Habibulin" writes:
: This is driver for ed(ne2000) cards. I have realtek(rl driver). I took a
: look at his source and didn't find such strings. There is comment there
: about cutting off mbuf header before passing it to ether_input - what's
: this?

I applied a similar patch to the end of the rl packet handling
routine.  It didn't solve my arp crashes, however.   It is almost as
if sometimes the rl driver passes a packet to ether_input and then
does bad things to it behind the scenes...  I've not had a lot of time
to try to track down why this does what it does.

Warner


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 14: 3:18 2000
Delivered-To: freebsd-current@freebsd.org
Received: from rover.village.org (rover.village.org [204.144.255.49])
	by hub.freebsd.org (Postfix) with ESMTP id ACE0937C259
	for <current@FreeBSD.ORG>; Wed, 22 Mar 2000 14:03:08 -0800 (PST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (harmony.village.org [10.0.0.6])
	by rover.village.org (8.9.3/8.9.3) with ESMTP id PAA29984;
	Wed, 22 Mar 2000 15:03:07 -0700 (MST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id PAA33983; Wed, 22 Mar 2000 15:03:06 -0700 (MST)
Message-Id: <200003222203.PAA33983@harmony.village.org>
To: Alex Zepeda <jazepeda@pacbell.net>
Subject: Re: 4.0-RELEASE boot.flp fails to boot on K6/2 
Cc: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>,
	current <current@FreeBSD.ORG>
In-reply-to: Your message of "Tue, 21 Mar 2000 22:52:35 PST."
		<Pine.BSF.4.21.0003212252080.316-100000@localhost> 
References: <Pine.BSF.4.21.0003212252080.316-100000@localhost>  
Date: Wed, 22 Mar 2000 15:03:06 -0700
From: Warner Losh <imp@village.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

boot.flp288

Warner


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 14: 6:14 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mass.cdrom.com (mg134-217.ricochet.net [204.179.134.217])
	by hub.freebsd.org (Postfix) with ESMTP id 684AB37C2A1
	for <current@freebsd.org>; Wed, 22 Mar 2000 14:05:52 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Received: from mass.cdrom.com (localhost [127.0.0.1])
	by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id OAA03940;
	Wed, 22 Mar 2000 14:08:42 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Message-Id: <200003222208.OAA03940@mass.cdrom.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To: keramida@ceid.upatras.gr
Cc: current@freebsd.org
Subject: Re: Not actually (Was Re: crash in atkbd_isa_intr() ) 
In-reply-to: Your message of "Thu, 23 Mar 2000 00:00:17 +0200."
             <20000323000017.A2325@hades.hell.gr> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 22 Mar 2000 14:08:42 -0800
From: Mike Smith <msmith@freebsd.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> Yes, I did, to get into the debugger.  Now I wonder, if there is some
> other bug that I need to chase around, how should I proceed?

You can try looking at the stack further above the atkbd interrupt, since 
that's where it was running when it took the interrupt.  If there's 
nothing there, then it was running in userspace and you might want to try 
the 'ps' command.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
\\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 14:15: 0 2000
Delivered-To: freebsd-current@freebsd.org
Received: from elvis.mu.org (elvis.mu.org [207.154.226.10])
	by hub.freebsd.org (Postfix) with ESMTP id DAE4D37C251
	for <current@FreeBSD.ORG>; Wed, 22 Mar 2000 14:14:46 -0800 (PST)
	(envelope-from paul@elvis.mu.org)
Received: (from paul@localhost)
	by elvis.mu.org (8.9.1/8.9.1) id QAA19637;
	Wed, 22 Mar 2000 16:16:06 -0600 (CST)
	(envelope-from paul)
Date: Wed, 22 Mar 2000 16:16:06 -0600
From: Paul Saab <paul@mu.org>
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: current@FreeBSD.ORG
Subject: Re: Buf cache, swap spl, and NFS patches need review.
Message-ID: <20000322161606.A19237@elvis.mu.org>
References: <200003221713.JAA91710@apollo.backplane.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="yrj/dFKFPuw6o+aM"
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200003221713.JAA91710@apollo.backplane.com>; from dillon@apollo.backplane.com on Wed, Mar 22, 2000 at 09:13:02AM -0800
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


--yrj/dFKFPuw6o+aM
Content-Type: text/plain; charset=us-ascii

Matthew Dillon (dillon@apollo.backplane.com) wrote:
>     swap-SPL:
> 
> 	Required splvm()'s had to be added to two places in the swap subsystem
> 	(but I don't think the lack of these spl's is the cause of the
> 	recently reported crashes, though it is possible).

There are a few more that I still get if I dont add spl protection.
I need to commit the SPLASSERT stuff but I'm scared about how badly it
will break for people that run with INVARIANTS.

I'll attach the whole SPLASSERT to the VM here.

Also, I went through vfs_bio.c and added SPLASSERT there and it
goes kaboom really quick.  bdwrite calls everything with no spl
proctection when it really should.  My full SPLASSERT patch is at
http://people.freebsd.org/~ps/splassert.diff.  I should just go ahead and
submit this.  This patch doesn't have any of the vm patches we discussed
last month.

-- 
Paul Saab
Technical Yahoo
paul@mu.org - ps@yahoo-inc.com - ps@freebsd.org
Do You .. uhh .. Yahoo!?

--yrj/dFKFPuw6o+aM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=spl

Index: src/sys/vm/swap_pager.c
diff -u src/sys/vm/swap_pager.c:1.1.1.1 src/sys/vm/swap_pager.c:1.6
--- src/sys/vm/swap_pager.c:1.1.1.1	Tue Feb 29 02:15:04 2000
+++ src/sys/vm/swap_pager.c	Thu Mar 16 02:32:32 2000
@@ -65,6 +65,7 @@
  *	@(#)swap_pager.c	8.9 (Berkeley) 3/21/94
  *
  * $FreeBSD: src/sys/vm/swap_pager.c,v 1.130 1999/12/28 07:30:54 peter Exp $
+ * $PMS: src/sys/vm/swap_pager.c,v 1.6 2000/03/16 10:32:32 ps Exp $
  */
 
 #include <sys/param.h>
@@ -214,6 +215,8 @@
 static __inline void
 swp_sizecheck()
 {
+	SPLASSERT(vm, "swp_sizecheck");
+
 	if (vm_swap_size < nswap_lowat) {
 		if (swap_pager_almost_full == 0) {
 			printf("swap_pager: out of swap space\n");
@@ -462,6 +465,8 @@
 	int npages;
 {
 	daddr_t blk;
+	
+	SPLASSERT(vm, "swp_pager_getswapspace");
 
 	if ((blk = blist_alloc(swapblist, npages)) == SWAPBLK_NONE) {
 		if (swap_pager_full != 2) {
@@ -496,6 +501,8 @@
 	daddr_t blk;
 	int npages;
 {
+	SPLASSERT(vm, "swp_pager_freeswapspace");
+
 	blist_free(swapblist, blk, npages);
 	vm_swap_size += npages;
 	swp_sizecheck();
@@ -702,8 +709,6 @@
  *	distance.  We do not try to restrict it to the swap device stripe
  *	(that is handled in getpages/putpages).  It probably isn't worth
  *	doing here.
- *
- *	This routine must be called at splvm().
  */
 
 boolean_t
@@ -714,14 +719,17 @@
 	int *after;
 {
 	daddr_t blk0;
+	int s;
 
 	/*
 	 * do we have good backing store at the requested index ?
 	 */
 
+	s = splvm();
 	blk0 = swp_pager_meta_ctl(object, pindex, 0);
 
 	if (blk0 == SWAPBLK_NONE) {
+		splx(s);
 		if (before)
 			*before = 0;
 		if (after)
@@ -764,7 +772,7 @@
 		}
 		*after = (i - 1);
 	}
-
+	splx(s);
 	return (TRUE);
 }
 
@@ -784,14 +792,17 @@
  *	depends on it.
  *
  *	This routine may not block
- *	This routine must be called at splvm()
  */
 
 static void
 swap_pager_unswapped(m)
 	vm_page_t m;
 {
+	int s;
+
+	s = splvm();
 	swp_pager_meta_ctl(m->object, m->pindex, SWM_FREE);
+	splx(s);
 }
 
 /*
@@ -1230,8 +1241,13 @@
 	 * force sync if not pageout process
 	 */
 
-	if (object->type != OBJT_SWAP)
+	if (object->type != OBJT_SWAP) {
+		int s;
+		
+		s = splvm();
 		swp_pager_meta_build(object, 0, SWAPBLK_NONE);
+		splx(s);
+	}
 
 	if (curproc != pageproc)
 		sync = TRUE;
@@ -1682,6 +1698,8 @@
 	struct swblock **pswap;
 	struct swblock *swap;
 
+	SPLASSERT(vm, "swp_pager_hash");
+
 	index &= ~SWAP_META_MASK;
 	pswap = &swhash[(index ^ (int)(intptr_t)object) & swhash_mask];
 
@@ -1720,6 +1738,8 @@
 	struct swblock *swap;
 	struct swblock **pswap;
 
+	CONDSPLASSERT(object->type == OBJT_SWAP, vm, "swp_pager_meta_build");
+
 	/*
 	 * Convert default object to swap object if necessary
 	 */
@@ -1810,6 +1830,8 @@
 static void
 swp_pager_meta_free(vm_object_t object, vm_pindex_t index, daddr_t count)
 {
+	SPLASSERT(vm, "swp_pager_meta_free");
+
 	if (object->type != OBJT_SWAP)
 		return;
 
@@ -1856,6 +1878,8 @@
 {
 	daddr_t index = 0;
 
+	SPLASSERT(vm, "swp_pager_meta_free_all");
+
 	if (object->type != OBJT_SWAP)
 		return;
 
@@ -1924,6 +1948,8 @@
 	struct swblock **pswap;
 	struct swblock *swap;
 	daddr_t r1;
+
+	SPLASSERT(vm, "swp_pager_meta_ctl");
 
 	/*
 	 * The meta data only exists of the object is OBJT_SWAP 
Index: src/sys/vm/vm_page.c
diff -u src/sys/vm/vm_page.c:1.1.1.1 src/sys/vm/vm_page.c:1.2
--- src/sys/vm/vm_page.c:1.1.1.1	Tue Feb 29 02:15:04 2000
+++ src/sys/vm/vm_page.c	Tue Feb 29 02:28:01 2000
@@ -35,6 +35,7 @@
  *
  *	from: @(#)vm_page.c	7.4 (Berkeley) 5/7/91
  * $FreeBSD: src/sys/vm/vm_page.c,v 1.147 1999/12/12 03:19:30 dillon Exp $
+ * $PMS: src/sys/vm/vm_page.c,v 1.2 2000/02/29 10:28:01 ps Exp $
  */
 
 /*
@@ -342,7 +343,7 @@
  *	enter the page into the kernel's pmap.  We are not allowed to block
  *	here so we *can't* do this anyway.
  *
- *	The object and page must be locked, and must be splhigh.
+ *	The object and page must be locked, and must be splvm.
  *	This routine may not block.
  */
 
@@ -354,6 +355,8 @@
 {
 	register struct vm_page **bucket;
 
+	SPLASSERT(vm, "vm_page_insert");
+
 	if (m->object != NULL)
 		panic("vm_page_insert: already inserted");
 
@@ -402,7 +405,7 @@
  *	table and the object page list, but do not invalidate/terminate
  *	the backing store.
  *
- *	The object and page must be locked, and at splhigh.
+ *	The object and page must be locked, and at splvm.
  *	The underlying pmap entry (if any) is NOT removed here.
  *	This routine may not block.
  */
@@ -413,6 +416,8 @@
 {
 	vm_object_t object;
 
+	SPLASSERT(vm, "vm_page_remove");
+
 	if (m->object == NULL)
 		return;
 
@@ -560,7 +565,7 @@
  *
  * 	vm_page_unqueue() without any wakeup
  *
- *	This routine must be called at splhigh().
+ *	This routine must be called at splvm().
  *	This routine may not block.
  */
 
@@ -570,6 +575,9 @@
 {
 	int queue = m->queue;
 	struct vpgqueues *pq;
+	
+	SPLASSERT(vm, "vm_page_unqueue_nowakeup");
+
 	if (queue != PQ_NONE) {
 		pq = &vm_page_queues[queue];
 		m->queue = PQ_NONE;
@@ -584,7 +592,7 @@
  *
  *	Remove a page from its queue.
  *
- *	This routine must be called at splhigh().
+ *	This routine must be called at splvm().
  *	This routine may not block.
  */
 
@@ -594,6 +602,9 @@
 {
 	int queue = m->queue;
 	struct vpgqueues *pq;
+
+	SPLASSERT(vm, "vm_page_unqueue");
+
 	if (queue != PQ_NONE) {
 		m->queue = PQ_NONE;
 		pq = &vm_page_queues[queue];
@@ -634,6 +645,8 @@
 	vm_page_t m = NULL;
 	struct vpgqueues *pq;
 
+	SPLASSERT(vm, "_vm_page_list_find");
+
 	pq = &vm_page_queues[basequeue];
 
 	/*
@@ -671,6 +684,8 @@
 {
 	vm_page_t m;
 
+	SPLASSERT(vm, "vm_page_select_cache");
+
 	while (TRUE) {
 		m = vm_page_list_find(
 		    PQ_CACHE,
@@ -702,6 +717,8 @@
 {
 	vm_page_t m;
 
+	SPLASSERT(vm, "vm_page_select_free");
+
 	m = vm_page_list_find(
 		PQ_FREE,
 		(pindex + object->pg_color) & PQ_L2_MASK,
@@ -1019,6 +1036,9 @@
 	 * if pageout daemon needs pages, then tell it that there are
 	 * some free.
 	 */
+
+	SPLASSERT(vm, "vm_page_free_wakeup");
+
 	if (vm_pageout_pages_needed) {
 		wakeup(&vm_pageout_pages_needed);
 		vm_pageout_pages_needed = 0;
Index: src/sys/vm/vm_pager.h
diff -u src/sys/vm/vm_pager.h:1.1.1.1 src/sys/vm/vm_pager.h:1.3
--- src/sys/vm/vm_pager.h:1.1.1.1	Tue Feb 29 02:15:04 2000
+++ src/sys/vm/vm_pager.h	Tue Feb 29 02:32:34 2000
@@ -37,6 +37,7 @@
  *
  *	@(#)vm_pager.h	8.4 (Berkeley) 1/12/94
  * $FreeBSD: src/sys/vm/vm_pager.h,v 1.24 1999/12/29 04:55:11 peter Exp $
+ * $PMS: src/sys/vm/vm_pager.h,v 1.3 2000/02/29 10:32:34 ps Exp $
  */
 
 /*
@@ -145,6 +146,17 @@
 	(*pagertab[object->type]->pgo_putpages)
 	    (object, m, count, flags, rtvals);
 }
+
+/*
+ *	vm_pager_has_page
+ *
+ *	Check to see if an object's pager has the requested page.  The
+ *	object's pager will also set before and after to give the caller
+ *	some idea of the number of pages before and after the requested
+ *	page can be I/O'd efficiently.
+ *
+ *	This routine does not have to be called at any particular spl.
+ */
 
 static __inline boolean_t
 vm_pager_has_page(

--yrj/dFKFPuw6o+aM--


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 14:19:43 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mail2.aracnet.com (mail2.aracnet.com [216.99.193.35])
	by hub.freebsd.org (Postfix) with ESMTP id 3CF4137C251
	for <current@FreeBSD.ORG>; Wed, 22 Mar 2000 14:19:35 -0800 (PST)
	(envelope-from beattie@aracnet.com)
Received: from shell1.aracnet.com (shell1.aracnet.com [216.99.193.21])
	by mail2.aracnet.com (8.9.3/8.9.3) with ESMTP id OAA10467;
	Wed, 22 Mar 2000 14:20:07 -0800
Received: by shell1.aracnet.com (8.9.3)  id OAA00763; Wed, 22 Mar 2000 14:19:52 -0800
Date: Wed, 22 Mar 2000 14:19:52 -0800 (PST)
From: Brian Beattie <beattie@aracnet.com>
To: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>
Cc: current@FreeBSD.ORG
Subject: Re: 4.0-RELEASE boot.flp fails to boot on K6/2 
In-Reply-To: <22852.953762030@zippy.cdrom.com>
Message-ID: <Pine.LNX.4.21.0003221418550.31899-100000@shell1.aracnet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Wed, 22 Mar 2000, Jordan K. Hubbard wrote:

> > kern-144.flp
> > root-144.flp
> > boot-288.flp
> 
> Winner!  Much better than my personal favorite of bigbooty.flp.  :-)
> 
> - Jordan
>

Then that would make the CD LordWarfen.iso?
 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message
> 

Brian Beattie            | This email was produced using professional quality,
beattie@aracnet.com      | standards based software.  Users of Microsoft
beattie@aracnet.com      | products or other substandard software should
www.aracnet.com/~beattie | contact the author about receiving a Free upgrade to
                         | FreeBSD or Linux.   "FreeBSD: The power to serve"



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 14:34:54 2000
Delivered-To: freebsd-current@freebsd.org
Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38])
	by hub.freebsd.org (Postfix) with ESMTP id 566CA37C2BE
	for <freebsd-current@FreeBSD.ORG>; Wed, 22 Mar 2000 14:34:44 -0800 (PST)
	(envelope-from obrien@NUXI.ucdavis.edu)
Received: from dragon.nuxi.com (root@d60-024.leach.ucdavis.edu [169.237.60.24])
	by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id OAA41443;
	Wed, 22 Mar 2000 14:34:43 -0800 (PST)
	(envelope-from obrien@dragon.nuxi.com)
Received: (from obrien@localhost)
	by dragon.nuxi.com (8.9.3/8.9.1) id KAA67124;
	Wed, 22 Mar 2000 10:32:59 -0800 (PST)
	(envelope-from obrien)
Date: Wed, 22 Mar 2000 10:32:58 -0800
From: "David O'Brien" <obrien@FreeBSD.ORG>
To: Martin Cracauer <cracauer@cons.org>
Cc: Mirko Viviani <mirko.viviani@rccr.cremona.it>,
	freebsd-current@FreeBSD.ORG
Subject: Re: libobjc and stack problems. (really libc_r and stack size)
Message-ID: <20000322103258.F10584@dragon.nuxi.com>
Reply-To: obrien@FreeBSD.ORG
References: <200003220814.JAA01602@next.procom2.it> <20000322171325.B18834@cons.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <20000322171325.B18834@cons.org>; from cracauer@cons.org on Wed, Mar 22, 2000 at 05:13:25PM +0100
X-Operating-System: FreeBSD 4.0-CURRENT
Organization: The NUXI BSD group
X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3  90 76 5D 69 58 D9 98 7A
X-Pgp-Keyid: 34F9F9D5
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Wed, Mar 22, 2000 at 05:13:25PM +0100, Martin Cracauer wrote:
> Can you point me to the newest set of ObjC patches for gdb, please?
> 
> I don't think they will it into the base system, mainly because it
> takes off files from the vendor branch. But we also have a gdb in
> ports, where patches are more welcome.

Don't forget the patches can also be submitted to the GNU Bintuils
maintainers and then they will get in the base system.  :)
 
-- 
-- David    (obrien@NUXI.com)


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 15:11:43 2000
Delivered-To: freebsd-current@freebsd.org
Received: from germanium.xtalwind.net (germanium.xtalwind.net [205.160.242.5])
	by hub.freebsd.org (Postfix) with ESMTP id 2BD0837C2BE
	for <current@FreeBSD.ORG>; Wed, 22 Mar 2000 15:11:39 -0800 (PST)
	(envelope-from jack@germanium.xtalwind.net)
Received: from localhost (jack@localhost)
	by germanium.xtalwind.net (8.9.3/8.9.3) with ESMTP id SAA74480;
	Wed, 22 Mar 2000 18:11:27 -0500 (EST)
Date: Wed, 22 Mar 2000 18:11:27 -0500 (EST)
From: jack <jack@germanium.xtalwind.net>
To: Warner Losh <imp@village.org>
Cc: current <current@FreeBSD.ORG>
Subject: Re: 4.0-RELEASE boot.flp fails to boot on K6/2 
In-Reply-To: <200003222203.PAA33983@harmony.village.org>
Message-ID: <Pine.BSF.4.21.0003221808140.70181-100000@germanium.xtalwind.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Today Warner Losh wrote:

> boot.flp288

The M$ weenies would probably choke on that since they do
filenames other than 8.3 with smoke and mirrors.

--------------------------------------------------------------------------
Jack O'Neill                    Systems Administrator / Systems Analyst
jack@germanium.xtalwind.net     Crystal Wind Communications, Inc.
          Finger jack@germanium.xtalwind.net for my PGP key.
   PGP Key fingerprint = F6 C4 E6 D4 2F 15 A7 67   FD 09 E9 3C 5F CC EB CD
               enriched, vcard, HTML messages > /dev/null
--------------------------------------------------------------------------




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 15:15:48 2000
Delivered-To: freebsd-current@freebsd.org
Received: from rover.village.org (rover.village.org [204.144.255.49])
	by hub.freebsd.org (Postfix) with ESMTP id EDC6537C30E
	for <current@FreeBSD.ORG>; Wed, 22 Mar 2000 15:15:44 -0800 (PST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (harmony.village.org [10.0.0.6])
	by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA30340;
	Wed, 22 Mar 2000 16:15:40 -0700 (MST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA34624; Wed, 22 Mar 2000 16:15:39 -0700 (MST)
Message-Id: <200003222315.QAA34624@harmony.village.org>
To: jack <jack@germanium.xtalwind.net>
Subject: Re: 4.0-RELEASE boot.flp fails to boot on K6/2 
Cc: current <current@FreeBSD.ORG>
In-reply-to: Your message of "Wed, 22 Mar 2000 18:11:27 EST."
		<Pine.BSF.4.21.0003221808140.70181-100000@germanium.xtalwind.net> 
References: <Pine.BSF.4.21.0003221808140.70181-100000@germanium.xtalwind.net>  
Date: Wed, 22 Mar 2000 16:15:39 -0700
From: Warner Losh <imp@village.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <Pine.BSF.4.21.0003221808140.70181-100000@germanium.xtalwind.net> jack writes:
: Today Warner Losh wrote:
: 
: > boot.flp288
: 
: The M$ weenies would probably choke on that since they do
: filenames other than 8.3 with smoke and mirrors.

8.3 is so archaic these days we shouldn't be bothered with them.  It
hasn't been a real restriction since the 3.1 days.  Win95, released 5
years ago, fixed this.

Warner



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 15:32:10 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mail.hellasnet.gr (mail.hellasnet.gr [212.54.192.3])
	by hub.freebsd.org (Postfix) with ESMTP id 5D9FD37C2D0
	for <current@freebsd.org>; Wed, 22 Mar 2000 15:32:04 -0800 (PST)
	(envelope-from keramida@ceid.upatras.gr)
Received: from hades.hell.gr (ppp3.patr.hellasnet.gr [212.54.197.18])
	by mail.hellasnet.gr (8.9.1/8.9.1) with SMTP id BAA28911
	for <current@freebsd.org>; Thu, 23 Mar 2000 01:31:02 +0200 (GMT)
Received: (qmail 21072 invoked by uid 1001); 22 Mar 2000 23:33:12 -0000
Date: Thu, 23 Mar 2000 01:33:11 +0200
From: Giorgos Keramidas <keramida@ceid.upatras.gr>
To: Mike Smith <msmith@freebsd.org>
Cc: current@freebsd.org
Subject: Re: Not actually (Was Re: crash in atkbd_isa_intr() )
Message-ID: <20000323013311.A2468@hades.hell.gr>
Reply-To: keramida@ceid.upatras.gr
References: <20000323000017.A2325@hades.hell.gr> <200003222208.OAA03940@mass.cdrom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200003222208.OAA03940@mass.cdrom.com>; from msmith@freebsd.org on Wed, Mar 22, 2000 at 02:08:42PM -0800
X-PGP-Fingerprint: 62 45 D1 C9 26 F9 95 06  D6 21 2A C8 8C 16 C0 8E
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Wed, Mar 22, 2000 at 02:08:42PM -0800, Mike Smith wrote:
>
> > Yes, I did, to get into the debugger.  Now I wonder, if there is
> > some other bug that I need to chase around, how should I proceed?
>
> You can try looking at the stack further above the atkbd interrupt,
> since that's where it was running when it took the interrupt.  If
> there's nothing there, then it was running in userspace and you might
> want to try the 'ps' command.

There is no frame above #12, which means that the problem is probably
not in atkbd_isa_intr() after all, but I can not the system to respond
after it stops.  I'll try and run `ps' in ddd and see if I can get the
output written down somewhere.

In the mean time, I've recompiled a freshly cvsup'ed kernel, booted it,
and now I'm trying to build my world -- since it seems that compiling
the kernel and/or `world' triggers the funny condition I'm running into.

If that does not give me a working kernel/world, I might as well start
looking for hardware related problems, memory being the most likely
culprit for such kind of behavior.

- Giorgos Keramidas


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 15:44:16 2000
Delivered-To: freebsd-current@freebsd.org
Received: from trinity.skynet.be (trinity.skynet.be [195.238.2.38])
	by hub.freebsd.org (Postfix) with ESMTP
	id 5577237B719; Wed, 22 Mar 2000 15:44:10 -0800 (PST)
	(envelope-from blk@skynet.be)
Received: from [194.78.238.239] (dialup1071.brussels2.skynet.be [194.78.238.239])
	by trinity.skynet.be (Postfix) with ESMTP
	id 797351808D; Thu, 23 Mar 2000 00:44:03 +0100 (MET)
Mime-Version: 1.0
X-Sender: blk@pop.skynet.be
Message-Id: <v04220802b4ff029838ea@[194.78.238.239]>
In-Reply-To: <4.3.1.2.20000322144918.00b8d6c0@216.67.12.69>
References: <4.3.1.2.20000322144026.00bb1c40@216.67.12.69>
 <4.3.1.2.20000322144026.00bb1c40@216.67.12.69>
 <4.3.1.2.20000322144918.00b8d6c0@216.67.12.69>
Date: Thu, 23 Mar 2000 00:10:11 +0100
To: Forrest Aldrich <forrie@forrie.com>,
	Bill Fumerola <billf@chc-chimes.com>
From: Brad Knowles <blk@skynet.be>
Subject: Re: 4.0 sysinstall fails to recognize disks
Cc: freebsd-questions@FreeBSD.ORG, freebsd-current@FreeBSD.ORG
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

At 2:50 PM -0500 2000/3/22, Forrest Aldrich wrote:

>  da4 at ahc0 bus 0 target 1 lun 0
>  da4: <QUANTUM ATLAS 10K 36SCA UCHD> Fixed Direct Access SCSI-3 device
>  da4: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged 
>Queueing Enabled
>  da4: 34732MB (71132998 512 byte sectors: 255H 63S/T 4427C)

	This just says "ahc0", which doesn't tell us if it's the on-board 
AIC-7890 controller, or a Adaptec 2940U2W controller that has been 
added.  I suspect he wants more details about what ahc0 is.

	That said, I've got no problems with 4.0-STABLE (cvsup'ed within 
the last two or three days) on a Dell 1300/450 SMP with an on-board 
AIC-7890 and two additional Adaptec 2940U2W controllers, at least not 
with /stand/sysinstall claiming they don't exist.  I've got some 
weird SCSI errors under stress that I haven't yet been able to pin 
down, but the OS recognizes that the drives are there and I was able 
to disklabel them, etc....

--
   These are my opinions -- not to be taken as official Skynet policy
======================================================================
Brad Knowles, <blk@skynet.be>                || 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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 16:10:44 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP
	id 1803B37C259; Wed, 22 Mar 2000 16:10:40 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id QAA94351;
	Wed, 22 Mar 2000 16:10:39 -0800 (PST)
	(envelope-from dillon)
Date: Wed, 22 Mar 2000 16:10:39 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003230010.QAA94351@apollo.backplane.com>
To: Mike Smith <msmith@FreeBSD.ORG>
Cc: Paul Richards <paul@originative.co.uk>,
	Richard Wendland <richard@netcraft.com>,
	Alfred Perlstein <bright@wintelcom.net>,
	Poul-Henning Kamp <phk@critter.freebsd.dk>, current@FreeBSD.ORG,
	fs@FreeBSD.ORG
Subject: Re: FreeBSD random I/O performance issues 
References:  <200003222039.MAA00661@mass.cdrom.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


:
:>     effects of the I/O being in-progress.  If a user program doesn't access
:>     any of the information it recently wrote the whole mechanism winds up
:>     operating asynchronously in the background.  If a user program does, 
:>     then the write behind mechanism breaks down and you get a stall.
:
:What makes no sense is that it should be perfectly ok to _read_ this 
:information back.

    When we separate out the read vs write access in the buffer
    cache API we *will* be able to read the information back while a
    write is in progress.  At the moment the buffer cache has no clue
    how a buffer is going to be used, which means the buffer is locked
    exclusively.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 16:14:46 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP
	id AAAD837C379; Wed, 22 Mar 2000 16:14:42 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id QAA94423;
	Wed, 22 Mar 2000 16:14:40 -0800 (PST)
	(envelope-from dillon)
Date: Wed, 22 Mar 2000 16:14:40 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003230014.QAA94423@apollo.backplane.com>
To: Doug Barton <Doug@gorean.org>
Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>,
	Paul Richards <paul@originative.co.uk>,
	Stephen Hocking-Senior Programmer PGS SPS Perth <shocking@prth.pgs.com>,
	current@FreeBSD.ORG, poul@FreeBSD.ORG
Subject: Re: Another current crash (cvs-cur.6183 
References:  <Pine.BSF.4.21.0003221239440.80766-100000@dt051n0b.san.rr.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


:On Wed, 22 Mar 2000, Poul-Henning Kamp wrote:
:
:> But it might actually make a lot of sense to make INVARIANTS the
:> default this early in the -CURRENT cycle, protests ?
:
:	What kind of overhead does it add? The warning messages in LINT
:look rather dire to me, but I'm interested in knowing the facts..
:
:Doug

    The overhead is minimal.  INVARIANTS was originally put in because
    DIAGNOSTIC was being too nasty to the system.  So nasty, in fact,
    that it could crash the system all by itself in certain situations.  
    You can think of INVARIANTS as a light-weight non-intrusive version 
    of DIAGNOSTIC.

    Frankly, I have INVARIANTS (and INVARIANT_SUPPORT) turned on by default
    on all of my kernels.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 16:17:41 2000
Delivered-To: freebsd-current@freebsd.org
Received: from fLuFFy.iNt.tElE.dK (fw1.inet.tele.dk [193.163.158.4])
	by hub.freebsd.org (Postfix) with ESMTP
	id B20CC37C2B9; Wed, 22 Mar 2000 16:17:17 -0800 (PST)
	(envelope-from pedophile@INT.TELE.DK)
Received: from localhost (pedophile@localhost)
	by fLuFFy.iNt.tElE.dK (8.9.3/8.9.3) with SMTP id BAA86413;
	Thu, 23 Mar 2000 01:17:06 +0100 (CET)
	(envelope-from pedophile@INT.TELE.DK)
X-Authentication-Warning: fLuFFy.iNt.tElE.dK: pedophile owned process doing -bs
Date: Thu, 23 Mar 2000 01:17:06 +0100 (CET)
From: FREENIX IS OVERRATED <pedophile@INT.TELE.DK>
Reply-To: FreeBSD-abusers@netscum.dk
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: current@FreeBSD.ORG, fs@FreeBSD.ORG
Subject: Re: FreeBSD random I/O performance issues
In-Reply-To: <fa.kiqr0qv.1enaji3@ifi.uio.no>
Message-ID: <Pine.BSF.3.96.1000323001655.85607G-100000@fLuFFy.iNt.tElE.dK>
X-Pedophile: BARRY BOUWSMA IS AN OFFENSIVE USENET PEDOPHILE
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Wed, 2395 Sep 1993, Matthew Dillon wrote:

>     It is perfectly ok for dirty blocks to remain in the buffer cache.  In
>     fact, it's *optimal* to leave them in the buffer cache as long as the
>     buffer cache does not get saturated with them.  The buffer cache is
>     perfectly capable of clustering delayed writes.  Also, the filesystem 
>     syncer comes along every 30 seconds or so anyway and flushes everything
>     out.
> 
>     What the write-behind code tries to do is to prevent the buffer cache 
>     from being saturated with dirty buffers and to smooth out disk write
>     I/O.  It makes the assumption that write-behind data is not typically
>     accessed by the program immediately after being written -- an assumption
>     that winds up being incorrect in the DBM case you tested and resulting
>     in stalls due to the buffer / VM pages being locked during the write I/O.
>     The stalls are *not* due to the I/O itself but instead are due to side
>     effects of the I/O being in-progress.

And that sounds a heck of a lot like what those of us who have been
running INN news swervers with 1,1GB size text history files on 2.whazzit
(now dead, may it rest in pieces widely-scattered) and later have seen.

You should have forgotten that a couple months or so ago, I wrote to
one of these lists to ask why I was getting only about 50-70%
availability as my 1.5+MD5-based-dbz innd was stuck in ufslck2 during
these every-30-seconds syncs.  The .hash and .index files from this,
which are comparable to the dbm (dbz) files being typically 125MB and
85MB or so, this under 3.4-STABLE.

Well, I've meant to get around to trying 4.0 on it, and Real Soon Now
I will, but I wanted to relate my experiences in turning traitor, a
heretic who has left the fold, deserving to be ridden out of town on
a rail and stuff, which sounds like a lot of fun.  I tried NetBSD.

NetBSD (at least the development now 1.4V version) has trickle
syncing, which seems to work quite well when having to cope with
these rather large database files, keeping a full 14 days of message
IDs from a full news feed.

Without really tuning anything, after a bit of time, the time needed
to do history lookups drops to microseconds, and as long as a `sync'
isn't needed, innd doesn't get stuck.  Theoretically, a sync, where
you are in fact seeking rather wildly over the disk to update these
files, happens once a day at expiry.  Depending on the speed of the
drive (and I haven't optimized this at all, using a single drive for
OS, logs, history, and part of spool, with a second drive for the rest
of the spool, far from an ideal setup), this seems to mean only a
few minutes of downtime.  Actually building the new .index and .hash
files goes quite a bit faster, like by a factor of 3 to 4, so clearly
the update of these files during the `sync' could stand improved sorting.

I wouldn't complain a bit if you were to steal mercilessly from the
NetBSD k0deZ to incorporate trickle sync (if something comparable is
not already in place) since that seems to make a world of difference
for those of us using long-outdated INN code and who want to have
bigger history file sizes than our shriveling Freenix members.

(What kills me now is that I'm using a single drive to hold the news
spool apart from a small overflow, so while time spent accessing this
history database is way down, the time actually spent hopping around
the disk to write (and read, for our sluggish peers) articles has
skyrocketed.  The box I'll try 4.0 on has a separate disk pack that
is far faster under NetBSD.  Test boxen, eh?)


There.  I've confessed.  It feels really good.  Now have at me.


Naturally, since I haven't followed this discussion closely, you may
be talking about something completely different, but I did want to
mention generally improved (yet not totally perfect) performance
with huge INN database files and NetBSD's trickle syncing.  Now,
go out and steal some k0deZ, okay?


barry bouwsma, tele danMerika internet

-- 

     *** This was posted with the express permission of ***
     ******************************************************
     **  HIS HIGHNESS KAAZMANN LORD AND MASTER OF USENET **
     ******************************************************
     ********* We are simple servants of his will *********



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 16:18:35 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id E5AE137B7F4
	for <current@FreeBSD.ORG>; Wed, 22 Mar 2000 16:18:30 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id QAA94491;
	Wed, 22 Mar 2000 16:18:27 -0800 (PST)
	(envelope-from dillon)
Date: Wed, 22 Mar 2000 16:18:27 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003230018.QAA94491@apollo.backplane.com>
To: Paul Saab <paul@mu.org>
Cc: current@FreeBSD.ORG
Subject: Re: Buf cache, swap spl, and NFS patches need review.
References: <200003221713.JAA91710@apollo.backplane.com> <20000322161606.A19237@elvis.mu.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


:Content-Type: text/plain; charset=us-ascii
:
:Matthew Dillon (dillon@apollo.backplane.com) wrote:
:>     swap-SPL:
:> 
:> 	Required splvm()'s had to be added to two places in the swap subsystem
:> 	(but I don't think the lack of these spl's is the cause of the
:> 	recently reported crashes, though it is possible).
:
:There are a few more that I still get if I dont add spl protection.
:I need to commit the SPLASSERT stuff but I'm scared about how badly it
:will break for people that run with INVARIANTS.
:
:I'll attach the whole SPLASSERT to the VM here.
:
:Also, I went through vfs_bio.c and added SPLASSERT there and it
:goes kaboom really quick.  bdwrite calls everything with no spl
:proctection when it really should.  My full SPLASSERT patch is at
:http://people.freebsd.org/~ps/splassert.diff.  I should just go ahead and
:submit this.  This patch doesn't have any of the vm patches we discussed
:last month.

    Lets do this one step at a time.  Let me get in my (relatively minor)
    spl fixes, then I'll take a look at your vfs_bio.c stuff -- there's got
    to be some cockpit trouble there because for the most part vfs_bio.c
    does *NOT* need to run at splbio().  Only the buffer queue adds and drops
    and hash table ops need to run at splbio().  Once you have a buffer in
    hand and locked you own it.

						-Matt




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 16:36:14 2000
Delivered-To: freebsd-current@freebsd.org
Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1])
	by hub.freebsd.org (Postfix) with ESMTP id 1CD2C37B83B
	for <current@freebsd.org>; Wed, 22 Mar 2000 16:36:09 -0800 (PST)
	(envelope-from rb@gid.co.uk)
Received: (from uucp@localhost)
	by isbalham.ist.co.uk (8.9.2/8.8.7) with UUCP id AAA33060
	for current@freebsd.org; Thu, 23 Mar 2000 00:36:08 GMT
	(envelope-from rb@gid.co.uk)
Received: from [194.32.164.2] (eccles [194.32.164.2])
	by seagoon.gid.co.uk (8.9.3/8.9.3) with ESMTP id AAA36655
	for <current@freebsd.org>; Thu, 23 Mar 2000 00:18:28 GMT
	(envelope-from rb@gid.co.uk)
X-Sender: rb@194.32.164.1
Message-Id: <l03130309b4ff0e8f72d0@[194.32.164.2]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 23 Mar 2000 00:18:27 +0000
To: current@freebsd.org
From: Bob Bishop <rb@gid.co.uk>
Subject: Buildworld hung up with lots of cron processes
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Hi,

cvsup at Wed Mar 22 04:03:28 GMT 2000, this built without problems with -j8
on my SMP box, but on a uniprocessor (-j4, eveything else the same)
something appears to have deadlocked. The machine is generally OK but the
build has hung and there are 57 cron processes hanging around (ps ax
follows). Any ideas? I'll keep it hanging around for a bit, let me know if
you want more info.

atlas# ps ax
  PID  TT  STAT      TIME COMMAND
    0  ??  DLs    0:00.12  (swapper)
    1  ??  ILs    0:00.01 /sbin/init --
    2  ??  DL     0:00.83  (pagedaemon)
    3  ??  DL     0:00.00  (vmdaemon)
    4  ??  DL     0:01.17  (bufdaemon)
    5  ??  DL     0:07.85  (syncer)
  107  ??  Ss     0:00.54 syslogd
  114  ??  S<s    0:06.86 ntpd -p /var/run/ntpd.pid
  118  ??  Is     0:00.01 /usr/sbin/portmap
  129  ??  Is     0:00.01 mountd -r
  132  ??  Is     0:00.01 nfsd: master (nfsd)
  134  ??  I      3:48.71 nfsd: server (nfsd)
  135  ??  I      0:16.24 nfsd: server (nfsd)
  136  ??  I      0:05.48 nfsd: server (nfsd)
  137  ??  I      0:01.57 nfsd: server (nfsd)
  140  ??  Is     0:00.00 rpc.statd
  145  ??  I      0:00.00 nfsiod -n 4
  146  ??  I      0:00.00 nfsiod -n 4
  148  ??  I      0:00.00 nfsiod -n 4
  149  ??  I      0:00.00 nfsiod -n 4
  172  ??  Is     0:00.03 inetd
  175  ??  Ss     0:00.83 cron
  250  ??  RNs  1614:32.53 ./dnetc -quiet
  263  ??  Ss     0:00.21 telnetd
 2174  ??  D      0:00.00 cron
 2175  ??  DVL    0:00.00 cron
				[54 more cron processes here, state D or DVL]
 2277  ??  D      0:00.00 cron
 2278  ??  DVL    0:00.00 cron
  264  p0  Is     0:00.06 csh
  265  p0  S      0:00.09 _su (csh)
 1446  p0  I      0:00.01 sh -c (\nmake -j4 CFLAGS='-O2 -pipe' -DNOCRYPT -DNOPR
 1447  p0  I      0:00.00 sh -c (\nmake -j4 CFLAGS='-O2 -pipe' -DNOCRYPT -DNOPR
 1448  p0  S      0:03.08 make -j4 CFLAGS=-O2 -pipe -DNOCRYPT -DNOPROFILE world
 1455  p0  I      0:00.00 sh -ev
 1456  p0  S      0:03.04 make -m /source/cleansrc/share/mk -f Makefile.inc1 bu
 1459  p0  I      0:00.03 sh -ev
 1479  p0  S      0:02.79 make -f Makefile.inc1 -DNOMAN -DNOINFO -DNOHTML boots
 1482  p0  I      0:00.03 sh -ev
 1907  p0  S      0:02.79 make all
 1908  p0  I      0:00.01 sh -ev
 2172  p0  I      0:00.00 sh -ev
 2173  p0  DL     0:00.00 sh -ev
 2279  p0  R+     0:00.00 ps ax
  247  v0  Is+    0:00.01 /usr/libexec/getty Pc ttyv0
  248  v1  Is+    0:00.01 /usr/libexec/getty Pc ttyv1
  249  v2  Is+    0:00.01 /usr/libexec/getty Pc ttyv2
atlas#


--
Bob Bishop              (0118) 977 4017  international code +44 118
rb@gid.co.uk        fax (0118) 989 4254  between 0800 and 1800 UK




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 16:48:47 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP
	id 413E037B5BD; Wed, 22 Mar 2000 16:48:43 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id QAA94830;
	Wed, 22 Mar 2000 16:48:40 -0800 (PST)
	(envelope-from dillon)
Date: Wed, 22 Mar 2000 16:48:40 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003230048.QAA94830@apollo.backplane.com>
To: FREENIX IS OVERRATED <pedophile@INT.TELE.DK>
Cc: current@FreeBSD.ORG, fs@FreeBSD.ORG
Subject: Re: FreeBSD random I/O performance issues
References:  <Pine.BSF.3.96.1000323001655.85607G-100000@fLuFFy.iNt.tElE.dK>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


:>     out.
:> 
:>     What the write-behind code tries to do is to prevent the buffer cache 
:>     from being saturated with dirty buffers and to smooth out disk write
:>     I/O.  It makes the assumption that write-behind data is not typically
:>     accessed by the program immediately after being written -- an assumption
:>     that winds up being incorrect in the DBM case you tested and resulting
:>     in stalls due to the buffer / VM pages being locked during the write I/O.
:>     The stalls are *not* due to the I/O itself but instead are due to side
:>     effects of the I/O being in-progress.
:
:And that sounds a heck of a lot like what those of us who have been
:running INN news swervers with 1,1GB size text history files on 2.whazzit
:(now dead, may it rest in pieces widely-scattered) and later have seen.
:
:You should have forgotten that a couple months or so ago, I wrote to
:one of these lists to ask why I was getting only about 50-70%
:availability as my 1.5+MD5-based-dbz innd was stuck in ufslck2 during
:these every-30-seconds syncs.  The .hash and .index files from this,
:which are comparable to the dbm (dbz) files being typically 125MB and
:85MB or so, this under 3.4-STABLE.
:
:Well, I've meant to get around to trying 4.0 on it, and Real Soon Now
:I will, but I wanted to relate my experiences in turning traitor, a
:heretic who has left the fold, deserving to be ridden out of town on
:a rail and stuff, which sounds like a lot of fun.  I tried NetBSD.
:
:NetBSD (at least the development now 1.4V version) has trickle
:syncing, which seems to work quite well when having to cope with
:these rather large database files, keeping a full 14 days of message
:IDs from a full news feed.

    Personally speaking I agree with you in regards to the syncer code.
    I don't have time to fix it, though I suspect it would not be 
    difficult.  Trickle syncing is an inherently easy thing to do.

    Kirk and I have both had serious trouble with the syncer daemon not
    being able to smooth out write I/O's due to it fsync'ing whole files
    all in one go.  The buffer daemon does a much better job which is why
    the speedup_syncer stuff is being slowly depreciated in favor of 
    bd_speedup().

    For INN there are several things you can tune in 4.0.  First and
    foremost you can try turning off the write-behind code, 
    sysctl -w vfs.write_behind=0.  Secondly you can mess around with 
    the vfs.hidirtybuffers sysctl (generally lower it) in order to
    force out dirty pages earlier and thus reduce the number that 
    fsync has to deal with.  I believe that INN also messes around with
    shared/R+W mmap()'s - it may be possible to add MAP_NOSYNC to those
    maps to turn off the 30 second fsync on pages dirtied through the VM
    system (for those maps), though this may increase the amount of stale
    (unwritten) data after a crash.

:There.  I've confessed.  It feels really good.  Now have at me.
:
:Naturally, since I haven't followed this discussion closely, you may
:be talking about something completely different, but I did want to
:mention generally improved (yet not totally perfect) performance
:with huge INN database files and NetBSD's trickle syncing.  Now,
:go out and steal some k0deZ, okay?
:
:
:barry bouwsma, tele danMerika internet

							-Matt



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 17:10: 7 2000
Delivered-To: freebsd-current@freebsd.org
Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87])
	by hub.freebsd.org (Postfix) with ESMTP
	id D873537B5BD; Wed, 22 Mar 2000 17:09:59 -0800 (PST)
	(envelope-from dcs@newsguy.com)
Received: from newsguy.com (p30-dn01kiryunisiki.gunma.ocn.ne.jp [211.0.245.31])
	by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id KAA15108;
	Thu, 23 Mar 2000 10:09:49 +0900 (JST)
Message-ID: <38D96ACA.A6E8E7CD@newsguy.com>
Date: Thu, 23 Mar 2000 09:52:26 +0900
From: "Daniel C. Sobral" <dcs@newsguy.com>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en,pt-BR,ja
MIME-Version: 1.0
To: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>
Cc: obrien@FreeBSD.ORG, Doug White <dwhite@resnet.uoregon.edu>,
	current@FreeBSD.ORG
Subject: Re: 4.0-RELEASE boot.flp fails to boot on K6/2
References: <19621.953702955@zippy.cdrom.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

"Jordan K. Hubbard" wrote:
> 
> Good idea, terrible name.  Can't you guys some up with something better? :)

AFAIK, the idea is having the name keeping people away from that file.

--
Daniel C. Sobral			(8-DCS)
dcs@newsguy.com
dcs@freebsd.org
capo@zurichgnomes.bsdconspiracy.net

	One Unix to rule them all, One Resolver to find them,
        One IP to bring them all and in the zone bind them.




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 17:10:23 2000
Delivered-To: freebsd-current@freebsd.org
Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87])
	by hub.freebsd.org (Postfix) with ESMTP
	id 6055837B88B; Wed, 22 Mar 2000 17:10:20 -0800 (PST)
	(envelope-from dcs@newsguy.com)
Received: from newsguy.com (p30-dn01kiryunisiki.gunma.ocn.ne.jp [211.0.245.31])
	by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id KAA15091;
	Thu, 23 Mar 2000 10:09:43 +0900 (JST)
Message-ID: <38D96817.C24FABE3@newsguy.com>
Date: Thu, 23 Mar 2000 09:40:55 +0900
From: "Daniel C. Sobral" <dcs@newsguy.com>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en,pt-BR,ja
MIME-Version: 1.0
To: Doug Barton <Doug@gorean.org>
Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>,
	Paul Richards <paul@originative.co.uk>,
	Stephen Hocking-Senior Programmer PGS SPS Perth <shocking@prth.pgs.com>,
	current@FreeBSD.ORG, poul@FreeBSD.ORG
Subject: Re: Another current crash (cvs-cur.6183
References: <Pine.BSF.4.21.0003221239440.80766-100000@dt051n0b.san.rr.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Doug Barton wrote:
> 
>         What kind of overhead does it add? The warning messages in LINT
> look rather dire to me, but I'm interested in knowing the facts..

If you run current, by all means, use INVARIANTS. You'll find a few
selected persons, some even otherwise respectable, that will tell you
otherwise. Ignore them.

--
Daniel C. Sobral			(8-DCS)
dcs@newsguy.com
dcs@freebsd.org
capo@zurichgnomes.bsdconspiracy.net

	One Unix to rule them all, One Resolver to find them,
        One IP to bring them all and in the zone bind them.




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 17:16: 5 2000
Delivered-To: freebsd-current@freebsd.org
Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99])
	by hub.freebsd.org (Postfix) with ESMTP id 7052437B8D5
	for <current@FreeBSD.ORG>; Wed, 22 Mar 2000 17:16:03 -0800 (PST)
	(envelope-from winter@jurai.net)
Received: from localhost (winter@localhost)
	by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id UAA64772;
	Wed, 22 Mar 2000 20:15:52 -0500 (EST)
Date: Wed, 22 Mar 2000 20:15:51 -0500 (EST)
From: "Matthew N. Dodd" <winter@jurai.net>
To: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>
Cc: Brian Beattie <beattie@aracnet.com>, current@FreeBSD.ORG
Subject: Re: 4.0-RELEASE boot.flp fails to boot on K6/2 
In-Reply-To: <22852.953762030@zippy.cdrom.com>
Message-ID: <Pine.BSF.4.21.0003222015390.50194-100000@sasami.jurai.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Wed, 22 Mar 2000, Jordan K. Hubbard wrote:
> Winner!  Much better than my personal favorite of bigbooty.flp.  :-)

Bigboote.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| winter@jurai.net |       2 x '84 Volvo 245DL        | ix86,sparc,pmax |
| http://www.jurai.net/~winter | This Space For Rent  | ISO8802.5 4ever |



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 17:49:38 2000
Delivered-To: freebsd-current@freebsd.org
Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36])
	by hub.freebsd.org (Postfix) with ESMTP id 1D6AC37B719
	for <freebsd-current@FreeBSD.ORG>; Wed, 22 Mar 2000 17:49:36 -0800 (PST)
	(envelope-from shin@nd.net.fujitsu.co.jp)
Received: from m2.gw.fujitsu.co.jp by fgwmail6.fujitsu.co.jp (8.9.3/3.7W-MX0002-Fujitsu Gateway)
	id KAA08441; Thu, 23 Mar 2000 10:49:29 +0900 (JST)
	(envelope-from shin@nd.net.fujitsu.co.jp)
Received: from chisato.nd.net.fujitsu.co.jp by m2.gw.fujitsu.co.jp (8.9.3/3.7W-0003-Fujitsu Domain Master)
	id KAA00909; Thu, 23 Mar 2000 10:49:27 +0900 (JST)
Received: from localhost (dhcp7173.nd.net.fujitsu.co.jp [10.18.7.173]) by chisato.nd.net.fujitsu.co.jp (8.8.5+2.7Wbeta5/3.3W8chisato-970826) with ESMTP id KAA29865; Thu, 23 Mar 2000 10:49:26 +0900 (JST)
To: imp@village.org
Cc: ilmar@ints.ru, nms@otdel-1.org, freebsd-current@FreeBSD.ORG
Subject: Re: -current sudden panics :( 
In-Reply-To: <200003222201.PAA33948@harmony.village.org>
References: <Pine.BSF.4.21.0003220813250.220-100000@ws-ilmar.ints.ru>
	<200003222201.PAA33948@harmony.village.org>
X-Mailer: Mew version 1.94 on Emacs 20.4 / Mule 4.0 (HANANOEN)
X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000323105025W.shin@nd.net.fujitsu.co.jp>
Date: Thu, 23 Mar 2000 10:50:25 +0900
From: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 40
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Hi,

> : This is driver for ed(ne2000) cards. I have realtek(rl driver). I took a
> : look at his source and didn't find such strings. There is comment there
> : about cutting off mbuf header before passing it to ether_input - what's
> : this?
> 
> I applied a similar patch to the end of the rl packet handling
> routine.  It didn't solve my arp crashes, however.   It is almost as
> if sometimes the rl driver passes a packet to ether_input and then
> does bad things to it behind the scenes...  I've not had a lot of time
> to try to track down why this does what it does.
> 
> Warner

I would like to narrow down the problem more and could you
please try if this patch stop the problem or not?
(The m_pullup() is recently added to if_rl.c. It should not be
harmful, but I suspect that this might have invoked another
hidden bug.)

Yoshinobu Inoue

Index: if_rl.c
===================================================================
RCS file: /home/ncvs/src/sys/pci/if_rl.c,v
retrieving revision 1.38
diff -u -r1.38 if_rl.c
--- if_rl.c	1999/12/28 06:04:29	1.38
+++ if_rl.c	2000/03/23 01:35:02
@@ -1130,7 +1130,8 @@
				m_adj(m, RL_ETHER_ALIGN);
				m_copyback(m, wrap, total_len - wrap,
					sc->rl_cdata.rl_rx_buf);
-				m = m_pullup(m, sizeof(struct ether_header));
+				if (m->m_len < sizeof(struct ether_header))
+					m = m_pullup(m, sizeof(struct ether_header));
				if (m == NULL) {
					printf("rl%d: m_pullup failed",
					    sc->rl_unit);


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 17:59:30 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [194.217.50.228])
	by hub.freebsd.org (Postfix) with ESMTP id 23B8937B792
	for <current@FreeBSD.org>; Wed, 22 Mar 2000 17:59:28 -0800 (PST)
	(envelope-from paul@originative.co.uk)
Received: from originative.co.uk (lobster.originative.co.uk [194.217.50.241])
	by mailgate.originative.co.uk (Postfix) with ESMTP id D4B841D131
	for <current@FreeBSD.org>; Thu, 23 Mar 2000 01:59:26 +0000 (GMT)
Message-ID: <38D97A7E.F71FF332@originative.co.uk>
Date: Thu, 23 Mar 2000 01:59:26 +0000
From: Paul Richards <paul@originative.co.uk>
Organization: Originative Solutions Ltd
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 4.0-CURRENT i386)
X-Accept-Language: en-GB, en
MIME-Version: 1.0
To: current@FreeBSD.org
Subject: RSA library problems
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

I've posted this to current because it seems to be related to the
OpenSSL code.

Apache-modssl throws out the error below when you try to access a SSL
port. The only place I can find this message is in the
openssl/rsaref/rsaref_stubs.c where it tries to open librsaref.so

I'm picking up my secure code from internat so why is modssl trying to
use rsaref rather than the international rsa?

Is there a document that explains how all this is supposed to work, I've
lost track of how the crypto code is organised.


** RSAPrivateEncrypt: Unable to find an RSAREF shared library
(librsaref.so).
** Install the /usr/ports/security/rsaref port or package and run this
** program again. See Chapter 6.5 in the FreeBSD Handbook, located at
** http://www.freebsd.org/handbook/openssl.html, for more information.
[Thu Mar 23 01:53:19 2000] [error] mod_ssl: SSL handshake failed (server
lobster.originative.co.uk:443, client 194.217.50.243) (OpenSSL library
error follows)
[Thu Mar 23 01:53:19 2000] [error] OpenSSL: error:1409B004:SSL
routines:SSL3_SEND_SERVER_KEY_EXCHANGE:nested asn1 error


Paul.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 18:16:28 2000
Delivered-To: freebsd-current@freebsd.org
Received: from Kharma.Nextshift.Net (kharma.nextshift.net [216.200.15.16])
	by hub.freebsd.org (Postfix) with ESMTP
	id 205F337B582; Wed, 22 Mar 2000 18:16:25 -0800 (PST)
	(envelope-from eric@clickrebates.com)
Received: from clickrebates.com (adsl-63-197-30-140.dsl.snfc21.pacbell.net [63.197.30.140])
	by Kharma.Nextshift.Net (8.9.3/8.9.0) with ESMTP id SAA13033;
	Wed, 22 Mar 2000 18:16:22 -0800 (PST)
Message-ID: <38D97E76.BAD2FCF6@clickrebates.com>
Date: Wed, 22 Mar 2000 18:16:22 -0800
From: Eric Sabban <eric@clickrebates.com>
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Forrest Aldrich <forrie@forrie.com>
Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org
Subject: Re: 4.0 sysinstall fails to recognize disks
References: <4.3.1.2.20000322144026.00bb1c40@216.67.12.69>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Try low-levelling the drives. The behavior sounds similar to what I had a long time ago, low level formatting them fixed the problem.

-eric

Forrest Aldrich wrote:

> Since this is a fairly current issue, I'm posting this appropriately.
>
> I have a DELL server that has hooked up to it a PowerVault, with 8 36gb 10krpm LVD drives.   The system has recognized these previously and dmesg shows them present; however, /stand/sysinstall says that I don't have ANY disks installed when using Label or Fdisk.
>
> Is this a known bug?   I've done a buildworld/installworld yesterday after a cvsup.
>
> TIA.
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 18:21:22 2000
Delivered-To: freebsd-current@freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
	by hub.freebsd.org (Postfix) with ESMTP
	id 6FB7137B51D; Wed, 22 Mar 2000 18:21:20 -0800 (PST)
	(envelope-from kris@FreeBSD.org)
Received: from localhost (kris@localhost)
	by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id SAA99048;
	Wed, 22 Mar 2000 18:21:21 -0800 (PST)
	(envelope-from kris@FreeBSD.org)
X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs
Date: Wed, 22 Mar 2000 18:21:21 -0800 (PST)
From: Kris Kennaway <kris@FreeBSD.org>
To: Paul Richards <paul@originative.co.uk>
Cc: current@FreeBSD.org
Subject: Re: RSA library problems
In-Reply-To: <38D97A7E.F71FF332@originative.co.uk>
Message-ID: <Pine.BSF.4.21.0003221820410.98921-100000@freefall.freebsd.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Thu, 23 Mar 2000, Paul Richards wrote:

> I'm picking up my secure code from internat so why is modssl trying to
> use rsaref rather than the international rsa?

Because the dlopen() of librsaintl.so fails.

> Is there a document that explains how all this is supposed to work, I've
> lost track of how the crypto code is organised.

See the handbook. If thats not clear enough please tell me what you'd like
clarified..thanks

Kris

----
In God we Trust -- all others must submit an X.509 certificate.
    -- Charles Forsythe <forsythe@alum.mit.edu>



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 18:21:58 2000
Delivered-To: freebsd-current@freebsd.org
Received: from chmls05.mediaone.net (ne.mediaone.net [24.128.1.70])
	by hub.freebsd.org (Postfix) with ESMTP id BB5FE37B71F
	for <current@FreeBSD.ORG>; Wed, 22 Mar 2000 18:21:49 -0800 (PST)
	(envelope-from bloom@acm.org)
Received: from acm.org (reyim.ne.mediaone.net [24.218.251.241])
	by chmls05.mediaone.net (8.8.7/8.8.7) with ESMTP id VAA01014;
	Wed, 22 Mar 2000 21:21:40 -0500 (EST)
Message-ID: <38D97FAF.D1C051F@acm.org>
Date: Wed, 22 Mar 2000 21:21:35 -0500
From: Jim Bloom <bloom@acm.org>
X-Mailer: Mozilla 4.72 [en]C-MOENE  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Bishop <rb@gid.co.uk>
Cc: current@FreeBSD.ORG
Subject: Re: Buildworld hung up with lots of cron processes
References: <l03130309b4ff0e8f72d0@[194.32.164.2]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

cvsup again.  You want to get version 1.134 of sys/vm/swap_pager.c.  The fix for
your problem was committed 4.5 hours later.

Good luck trying to compile the kernel.  I had hangs while linking the kernel as
well as while trying to install a fixed one.  Make sure you have a good backup
of the kernel, I ended up with a zero byte kernel while trying to install the
fixed one.

Jim Bloom
bloom@acm.org

Bob Bishop wrote:
> 
> Hi,
> 
> cvsup at Wed Mar 22 04:03:28 GMT 2000, this built without problems with -j8
> on my SMP box, but on a uniprocessor (-j4, eveything else the same)
> something appears to have deadlocked. The machine is generally OK but the
> build has hung and there are 57 cron processes hanging around (ps ax
> follows). Any ideas? I'll keep it hanging around for a bit, let me know if
> you want more info.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 18:26:32 2000
Delivered-To: freebsd-current@freebsd.org
Received: from forrie.net (forrie.net [216.67.12.69])
	by hub.freebsd.org (Postfix) with ESMTP
	id 57F3B37B8DC; Wed, 22 Mar 2000 18:26:28 -0800 (PST)
	(envelope-from forrie@forrie.com)
Received: from Forrest (getbent@forrie.ne.mediaone.net [24.147.129.124])
            by forrie.net with id e2N2QAC12747;
            Wed, 22 Mar 2000 21:26:10 -0500 (EST)
Message-Id: <4.3.1.2.20000322212337.00b647c0@216.67.12.69>
X-Sender: forrie@216.67.12.69
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Wed, 22 Mar 2000 21:24:13 -0500
To: Eric Sabban <eric@clickrebates.com>
From: Forrest Aldrich <forrie@forrie.com>
Subject: Re: 4.0 sysinstall fails to recognize disks
Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org
In-Reply-To: <38D97E76.BAD2FCF6@clickrebates.com>
References: <4.3.1.2.20000322144026.00bb1c40@216.67.12.69>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Interesting point... these ARE new drives that were put in today.

I presume you mean to use the BIOS scsi utility?

_F


At 06:16 PM 3/22/00 -0800, Eric Sabban wrote:
>Try low-levelling the drives. The behavior sounds similar to what I had a 
>long time ago, low level formatting them fixed the problem.
>
>-eric
>
>Forrest Aldrich wrote:
>
> > Since this is a fairly current issue, I'm posting this appropriately.
> >
> > I have a DELL server that has hooked up to it a PowerVault, with 8 36gb 
> 10krpm LVD drives.   The system has recognized these previously and dmesg 
> shows them present; however, /stand/sysinstall says that I don't have ANY 
> disks installed when using Label or Fdisk.
> >
> > Is this a known bug?   I've done a buildworld/installworld yesterday 
> after a cvsup.
> >
> > TIA.
> >
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-current" in the body of the message



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 18:30:11 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [194.217.50.228])
	by hub.freebsd.org (Postfix) with ESMTP
	id 47DDC37B825; Wed, 22 Mar 2000 18:30:05 -0800 (PST)
	(envelope-from paul@originative.co.uk)
Received: from originative.co.uk (lobster.originative.co.uk [194.217.50.241])
	by mailgate.originative.co.uk (Postfix) with ESMTP
	id AF5391D131; Thu, 23 Mar 2000 02:30:04 +0000 (GMT)
Message-ID: <38D981AC.52EFAD57@originative.co.uk>
Date: Thu, 23 Mar 2000 02:30:04 +0000
From: Paul Richards <paul@originative.co.uk>
Organization: Originative Solutions Ltd
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 4.0-CURRENT i386)
X-Accept-Language: en-GB, en
MIME-Version: 1.0
To: Kris Kennaway <kris@FreeBSD.org>
Cc: current@FreeBSD.org
Subject: Re: RSA library problems
References: <Pine.BSF.4.21.0003221820410.98921-100000@freefall.freebsd.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Kris Kennaway wrote:
> 
> On Thu, 23 Mar 2000, Paul Richards wrote:
> 
> > I'm picking up my secure code from internat so why is modssl trying to
> > use rsaref rather than the international rsa?
> 
> Because the dlopen() of librsaintl.so fails.

Ok, I give up :-) Why would that happen then ?

I can't see anything wrong with librsaINTL.* that would prevent it from
being loaded.

I'm not the only person seeing this, it's been reported on the ports
list by someone else as well.

> 
> > Is there a document that explains how all this is supposed to work, I've
> > lost track of how the crypto code is organised.
> 
> See the handbook. If thats not clear enough please tell me what you'd like
> clarified..thanks

Do you mean section 8.5? I was looking for implementation details not a
general overview.

e.g. what goes on in libcrypto that determines which of the librsa*
libraries to load. Yes, I know I could read the code but I'm just
looking for some general pointers as to what's supposed to be going on.



Paul.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 18:34:27 2000
Delivered-To: freebsd-current@freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
	by hub.freebsd.org (Postfix) with ESMTP
	id 1FAAF37B97C; Wed, 22 Mar 2000 18:34:25 -0800 (PST)
	(envelope-from kris@FreeBSD.org)
Received: from localhost (kris@localhost)
	by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id SAA00615;
	Wed, 22 Mar 2000 18:34:25 -0800 (PST)
	(envelope-from kris@FreeBSD.org)
X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs
Date: Wed, 22 Mar 2000 18:34:25 -0800 (PST)
From: Kris Kennaway <kris@FreeBSD.org>
To: Paul Richards <paul@originative.co.uk>
Cc: current@FreeBSD.org
Subject: Re: RSA library problems
In-Reply-To: <38D981AC.52EFAD57@originative.co.uk>
Message-ID: <Pine.BSF.4.21.0003221830310.259-100000@freefall.freebsd.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Thu, 23 Mar 2000, Paul Richards wrote:

> > Because the dlopen() of librsaintl.so fails.
> 
> Ok, I give up :-) Why would that happen then ?

I don't know :-)

> I'm not the only person seeing this, it's been reported on the ports
> list by someone else as well.

Hmm, I think I missed this mail.

> Do you mean section 8.5? I was looking for implementation details not a
> general overview.
> 
> e.g. what goes on in libcrypto that determines which of the librsa*
> libraries to load. Yes, I know I could read the code but I'm just
> looking for some general pointers as to what's supposed to be going on.

libcrypto tries to dlopen() librsaintl, or failing that, librsausa when a
RSA function is called.

librsaintl contains the OpenSSL RSA code.

librsausa contains wrappers which interface to the RSAREF API, and calls
librsaref via dlopen().

If you need more than that, perhaps either read the code or the mailing
list archives for the last month. I've explained it all N>>1 times :-)

Kris

----
In God we Trust -- all others must submit an X.509 certificate.
    -- Charles Forsythe <forsythe@alum.mit.edu>



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 19:16:20 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [194.217.50.228])
	by hub.freebsd.org (Postfix) with ESMTP
	id 65FDE37BA23; Wed, 22 Mar 2000 19:16:11 -0800 (PST)
	(envelope-from paul@originative.co.uk)
Received: from originative.co.uk (lobster.originative.co.uk [194.217.50.241])
	by mailgate.originative.co.uk (Postfix) with ESMTP
	id 53A321D131; Thu, 23 Mar 2000 03:16:10 +0000 (GMT)
Message-ID: <38D98C7A.D6705F48@originative.co.uk>
Date: Thu, 23 Mar 2000 03:16:10 +0000
From: Paul Richards <paul@originative.co.uk>
Organization: Originative Solutions Ltd
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 4.0-CURRENT i386)
X-Accept-Language: en-GB, en
MIME-Version: 1.0
To: Kris Kennaway <kris@FreeBSD.org>
Cc: current@FreeBSD.org
Subject: Re: RSA library problems
References: <Pine.BSF.4.21.0003221830310.259-100000@freefall.freebsd.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Kris Kennaway wrote:
> 
> On Thu, 23 Mar 2000, Paul Richards wrote:
> 
> > > Because the dlopen() of librsaintl.so fails.
> >
> > Ok, I give up :-) Why would that happen then ?
> 
> I don't know :-)
> 
> > I'm not the only person seeing this, it's been reported on the ports
> > list by someone else as well.
> 
> Hmm, I think I missed this mail.

Actually I had this one in mind

Subject:         Problems with apache+php+mod_ssl-1.3.12+3.0.15+2.6.2
   Date:         Thu, 16 Mar 2000 17:28:00 +0200 (SAST)
   From:         Khetan Gajjar <khetan@uunet.co.za>

but it's about a different problem.

> > Do you mean section 8.5? I was looking for implementation details not a
> > general overview.
> >
> > e.g. what goes on in libcrypto that determines which of the librsa*
> > libraries to load. Yes, I know I could read the code but I'm just
> > looking for some general pointers as to what's supposed to be going on.
> 
> libcrypto tries to dlopen() librsaintl, or failing that, librsausa when a
> RSA function is called.
> 
> librsaintl contains the OpenSSL RSA code.
> 
> librsausa contains wrappers which interface to the RSAREF API, and calls
> librsaref via dlopen().

Ok, I looked at the code. It looks like the rsaref_stubs.c getsym() is
being called, which doesn't even try to open the INTL lib.

As far as I can see libcrypto is being built with rsa_stubs.c so how
come the other getsym() is being called! 

I haven't managed to work out how that's happening, 
> If you need more than that, perhaps either read the code or the mailing
> list archives for the last month. I've explained it all N>>1 times :-)

The mail archive isn't returning any results at all for 2000, I'd
already tried looking there :-)

Paul.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 19:49:57 2000
Delivered-To: freebsd-current@freebsd.org
Received: from dt051n0b.san.rr.com (dt051n0b.san.rr.com [204.210.32.11])
	by hub.freebsd.org (Postfix) with ESMTP id 1F0FF37BA18
	for <current@FreeBSD.ORG>; Wed, 22 Mar 2000 19:49:55 -0800 (PST)
	(envelope-from Doug@gorean.org)
Received: from gorean.org (doug@master [10.0.0.2])
	by dt051n0b.san.rr.com (8.9.3/8.9.3) with ESMTP id TAA85766;
	Wed, 22 Mar 2000 19:46:51 -0800 (PST)
	(envelope-from Doug@gorean.org)
Message-ID: <38D993AB.7B7051DC@gorean.org>
Date: Wed, 22 Mar 2000 19:46:51 -0800
From: Doug Barton <Doug@gorean.org>
Organization: Triborough Bridge & Tunnel Authority
X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 4.0-HEAD-0320 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Warner Losh <imp@village.org>
Cc: jack <jack@germanium.xtalwind.net>, current <current@FreeBSD.ORG>
Subject: Re: 4.0-RELEASE boot.flp fails to boot on K6/2
References: <Pine.BSF.4.21.0003221808140.70181-100000@germanium.xtalwind.net> <200003222315.QAA34624@harmony.village.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Warner Losh wrote:
> 
> In message <Pine.BSF.4.21.0003221808140.70181-100000@germanium.xtalwind.net> jack writes:
> : Today Warner Losh wrote:
> :
> : > boot.flp288
> :
> : The M$ weenies would probably choke on that since they do
> : filenames other than 8.3 with smoke and mirrors.
> 
> 8.3 is so archaic these days we shouldn't be bothered with them.  It
> hasn't been a real restriction since the 3.1 days.  Win95, released 5
> years ago, fixed this.

	But win95 didn't really fix it, it just covered it up. Filenames in
Win9x are still 8.3, but the "OS" provides a translation layer that maps
those 8.3 filenames to long ones. Also, are we sure that fdimage,
running under DOS can handle longer names? 

Doug
-- 
    "So, the cows were part of a dream that dreamed itself into
existence,
is that possible?"
    The master simply replied, "Mu."


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 19:51: 5 2000
Delivered-To: freebsd-current@freebsd.org
Received: from rover.village.org (rover.village.org [204.144.255.49])
	by hub.freebsd.org (Postfix) with ESMTP id F090737B825
	for <current@FreeBSD.ORG>; Wed, 22 Mar 2000 19:50:58 -0800 (PST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (harmony.village.org [10.0.0.6])
	by rover.village.org (8.9.3/8.9.3) with ESMTP id UAA31338;
	Wed, 22 Mar 2000 20:50:56 -0700 (MST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id UAA36275; Wed, 22 Mar 2000 20:50:55 -0700 (MST)
Message-Id: <200003230350.UAA36275@harmony.village.org>
To: Doug Barton <Doug@gorean.org>
Subject: Re: 4.0-RELEASE boot.flp fails to boot on K6/2 
Cc: jack <jack@germanium.xtalwind.net>, current <current@FreeBSD.ORG>
In-reply-to: Your message of "Wed, 22 Mar 2000 19:46:51 PST."
		<38D993AB.7B7051DC@gorean.org> 
References: <38D993AB.7B7051DC@gorean.org>  <Pine.BSF.4.21.0003221808140.70181-100000@germanium.xtalwind.net> <200003222315.QAA34624@harmony.village.org> 
Date: Wed, 22 Mar 2000 20:50:55 -0700
From: Warner Losh <imp@village.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <38D993AB.7B7051DC@gorean.org> Doug Barton writes:
: 	But win95 didn't really fix it, it just covered it up. Filenames in
: Win9x are still 8.3, but the "OS" provides a translation layer that maps
: those 8.3 filenames to long ones. Also, are we sure that fdimage,
: running under DOS can handle longer names? 

But DOS will truncate it.  By that point the name has served its
purpose and it doesn't matter if it is truncated :-).

Warner


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 20: 9:50 2000
Delivered-To: freebsd-current@freebsd.org
Received: from rtp.tfd.com (rtp.tfd.com [198.79.53.206])
	by hub.freebsd.org (Postfix) with ESMTP id 77D5337C2EA
	for <current@freebsd.org>; Wed, 22 Mar 2000 20:09:45 -0800 (PST)
	(envelope-from kent@lab1.tfd.com)
Received: from lab1.tfd.com (lab1.tfd.com [10.9.200.31])
	by rtp.tfd.com (8.9.3/8.9.3) with SMTP id XAA23052
	for <current@freebsd.org>; Wed, 22 Mar 2000 23:10:14 -0500 (EST)
Received: by lab1.tfd.com id AA14888
  (5.67b/IDA-1.5 for current@freebsd.org); Wed, 22 Mar 2000 23:07:49 -0500
Date: Wed, 22 Mar 2000 23:07:49 -0500
From: Kent Hauser <kent@lab1.tfd.com>
Message-Id: <200003230407.AA14888@lab1.tfd.com>
To: current@freebsd.org
Subject: src install/upgrade
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


As it just happened to me (*again*), I thought I'd complain
to the powers-that-be.

I'm upgrading my laptop to current. (And on a different subject
"cd /usr/src/release;make release" doesn't build because of 
some ports problems...but no big deal.)

I mount the cd (or nfs or whatever), cd to the "src" distribution and
do "sh install.sh all". Then "cd /usr/src; make world >& world.log"
and immediately the build fails -- no "tools". So I then have to
go back to the distribution & "sh install.sh tools". Then of course,
I remember I didn't install the crypto stuff so I have to 
"cd crypto;sh ../src/install.sh `basename *.aa .aa|sed s/s//`"

Then I can build world.

Why can't the src/install.sh do the right thing the first time?

Just curious,

Kent


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 22:18:37 2000
Delivered-To: freebsd-current@freebsd.org
Received: from ws-ilmar.ints.ru (ws-ilmar.ints.ru [194.67.173.16])
	by hub.freebsd.org (Postfix) with ESMTP id 4E7B837BA06
	for <freebsd-current@FreeBSD.ORG>; Wed, 22 Mar 2000 22:18:30 -0800 (PST)
	(envelope-from ilmar@ints.ru)
Received: from localhost (localhost [127.0.0.1])
	by ws-ilmar.ints.ru (8.9.3/8.9.3) with ESMTP id JAA02272;
	Thu, 23 Mar 2000 09:18:06 +0300 (MSK)
Date: Thu, 23 Mar 2000 09:18:06 +0300 (MSK)
From: "Ilmar S. Habibulin" <ilmar@ints.ru>
To: Warner Losh <imp@village.org>
Cc: Nikolai Saoukh <nms@otdel-1.org>,
	Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>,
	freebsd-current@FreeBSD.ORG
Subject: Re: -current sudden panics :( 
In-Reply-To: <200003220658.XAA29305@harmony.village.org>
Message-ID: <Pine.BSF.4.21.0003230913310.733-100000@ws-ilmar.ints.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Tue, 21 Mar 2000, Warner Losh wrote:

> : But why there is such a sudden change? Everything worked just fine a week
> : before 5-current.
> No it didn't.  I've been seeing panics like this for about two weeks,
Ok, it worked for me.

> but it hadn't been a priority until this week for me.  And I'm not
> seeing it on lightly loaded networks, but am on heavily loaded ones.
My pc is not on lightly loaded network. This networks' load is moving
towards(?) zero. ;-)

> Since our product's network port is just for debugging, it isn't a big
> deal to me....
And i'm using freebsd as my desktop OS. So this became a VERY BIG problem
for me. :(

> It is definitely a load related problem for me.  It usually works just
> fine, but sometimes there's a packet that gets to arp that arp barfs
> on.
I can't track this situation. Everything seems to be fine, then 
- BBBOOOMMM - page fault. :( 



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 23:35:57 2000
Delivered-To: freebsd-current@freebsd.org
Received: from muzak.iinet.net.au (muzak.iinet.net.au [203.59.24.237])
	by hub.freebsd.org (Postfix) with ESMTP
	id 7822237B574; Wed, 22 Mar 2000 23:35:39 -0800 (PST)
	(envelope-from julian@elischer.org)
Received: from jules.elischer.org (reggae-09-79.nv.iinet.net.au [203.59.67.79])
	by muzak.iinet.net.au (8.8.5/8.8.5) with SMTP id PAA30777;
	Thu, 23 Mar 2000 15:35:26 +0800
Message-ID: <38D9B306.2781E494@elischer.org>
Date: Wed, 22 Mar 2000 23:34:11 -0800
From: Julian Elischer <julian@elischer.org>
X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386)
MIME-Version: 1.0
To: Mike Smith <msmith@freebsd.org>
Cc: Matthew Dillon <dillon@apollo.backplane.com>,
	Paul Richards <paul@originative.co.uk>,
	Richard Wendland <richard@netcraft.com>,
	Alfred Perlstein <bright@wintelcom.net>,
	Poul-Henning Kamp <phk@critter.freebsd.dk>, current@freebsd.org,
	fs@freebsd.org
Subject: Re: FreeBSD random I/O performance issues
References: <200003222039.MAA00661@mass.cdrom.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

This is one of the things that made us do so badly
in the benchmarks against NT/Linux last year.
OBVIOUSLY one should be able to re-read this infoirmation
without affecting a pending write.

Mike Smith wrote:
> 
> >     effects of the I/O being in-progress.  If a user program doesn't access
> >     any of the information it recently wrote the whole mechanism winds up
> >     operating asynchronously in the background.  If a user program does,
> >     then the write behind mechanism breaks down and you get a stall.
> 
> What makes no sense is that it should be perfectly ok to _read_ this
> information back.
> 


-- 
      __--_|\  Julian Elischer
     /       \ julian@elischer.org
    (   OZ    ) World tour 2000
---> X_.---._/  presently in:  Perth
            v


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 23:41:31 2000
Delivered-To: freebsd-current@freebsd.org
Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252])
	by hub.freebsd.org (Postfix) with ESMTP id 7CFF037B574
	for <freebsd-current@FreeBSD.org>; Wed, 22 Mar 2000 23:41:24 -0800 (PST)
	(envelope-from roberto@keltia.freenix.fr)
Received: (from uucp@localhost)
	by frmug.org (8.9.3/frmug-2.5/nospam) with UUCP id IAA20909
	for freebsd-current@FreeBSD.org; Thu, 23 Mar 2000 08:41:23 +0100 (CET)
	(envelope-from roberto@keltia.freenix.fr)
Received: by keltia.freenix.fr (Postfix, from userid 101)
	id 7D0708869; Thu, 23 Mar 2000 07:59:16 +0100 (CET)
Date: Thu, 23 Mar 2000 07:59:16 +0100
From: Ollivier Robert <roberto@keltia.freenix.fr>
To: "FreeBSD Current Users' list" <freebsd-current@FreeBSD.org>
Subject: Re: /boot/loader is making my VAIO reboot
Message-ID: <20000323075916.A18056@keltia.freenix.fr>
Mail-Followup-To: FreeBSD Current Users' list <freebsd-current@FreeBSD.org>
References: <20000322112710.C15904@caerdonn.eurocontrol.fr> <200003222102.NAA01164@mass.cdrom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200003222102.NAA01164@mass.cdrom.com>; from msmith@freebsd.org on Wed, Mar 22, 2000 at 01:02:52PM -0800
X-Operating-System: FreeBSD 4.0-CURRENT/ELF AMD-K6/200 & 2x PPro/200 SMP
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

According to Mike Smith:
> Can you be more specific here - does it reboot _immediately_ after 
> printing that message, or after the timeout finishes?

Immediately after printing the message. No timeout whatsoever.
 
> Try putting just "set autoboot_delay=0" in /boot/loader.rc and see if 
> that gives you a prompt.

OK, will try.
-- 
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr
FreeBSD keltia.freenix.fr 4.0-CURRENT #78: Sun Feb 27 15:32:39 CET 2000



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 23:41:39 2000
Delivered-To: freebsd-current@freebsd.org
Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252])
	by hub.freebsd.org (Postfix) with ESMTP id B182137C397
	for <freebsd-current@FreeBSD.org>; Wed, 22 Mar 2000 23:41:27 -0800 (PST)
	(envelope-from roberto@keltia.freenix.fr)
Received: (from uucp@localhost)
	by frmug.org (8.9.3/frmug-2.5/nospam) with UUCP id IAA20910
	for freebsd-current@FreeBSD.org; Thu, 23 Mar 2000 08:41:26 +0100 (CET)
	(envelope-from roberto@keltia.freenix.fr)
Received: by keltia.freenix.fr (Postfix, from userid 101)
	id E454D886B; Thu, 23 Mar 2000 07:59:44 +0100 (CET)
Date: Thu, 23 Mar 2000 07:59:44 +0100
From: Ollivier Robert <roberto@keltia.freenix.fr>
To: "FreeBSD Current Users' list" <freebsd-current@FreeBSD.org>
Subject: Re: /boot/loader is making my VAIO reboot
Message-ID: <20000323075944.B18056@keltia.freenix.fr>
Mail-Followup-To: FreeBSD Current Users' list <freebsd-current@FreeBSD.org>
References: <200003222102.NAA01164@mass.cdrom.com> <38D94095.CCE928E9@newsguy.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <38D94095.CCE928E9@newsguy.com>; from dcs@newsguy.com on Thu, Mar 23, 2000 at 06:52:22AM +0900
X-Operating-System: FreeBSD 4.0-CURRENT/ELF AMD-K6/200 & 2x PPro/200 SMP
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

According to Daniel C. Sobral:
> Or just pressing space when the countdown message first appears...

No time for that.
-- 
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr
FreeBSD keltia.freenix.fr 4.0-CURRENT #78: Sun Feb 27 15:32:39 CET 2000



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 23:45:22 2000
Delivered-To: freebsd-current@freebsd.org
Received: from dt051n0b.san.rr.com (dt051n0b.san.rr.com [204.210.32.11])
	by hub.freebsd.org (Postfix) with ESMTP id D6D0937C3A3
	for <freebsd-current@freebsd.org>; Wed, 22 Mar 2000 23:45:19 -0800 (PST)
	(envelope-from Doug@gorean.org)
Received: from gorean.org (doug@master [10.0.0.2])
	by dt051n0b.san.rr.com (8.9.3/8.9.3) with ESMTP id XAA87676
	for <freebsd-current@freebsd.org>; Wed, 22 Mar 2000 23:45:19 -0800 (PST)
	(envelope-from Doug@gorean.org)
Message-ID: <38D9CB8F.F8BE36CC@gorean.org>
Date: Wed, 22 Mar 2000 23:45:19 -0800
From: Doug Barton <Doug@gorean.org>
Organization: Triborough Bridge & Tunnel Authority
X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 5.0-CURRENT-0322 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: freebsd-current@freebsd.org
Subject: Can't build sysinstall
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

	I have a prehistoric version of sysinstall on my otherwise up to date
5.0-Current, and when I used it my system rebooted, so I thought I'd
recompile. Unfortunately 'cd /usr/src/release/sysinstall ; make clean ;
make all' bombed out in kget. More details available on request, but I
thought someone might want to know.

Doug
-- 
    "So, the cows were part of a dream that dreamed itself into
existence? Is that possible?" asked the student incredulously.
    The master simply replied, "Mu."


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 23:50:42 2000
Delivered-To: freebsd-current@freebsd.org
Received: from Kharma.Nextshift.Net (kharma.nextshift.net [216.200.15.16])
	by hub.freebsd.org (Postfix) with ESMTP
	id B12DF37BDF0; Wed, 22 Mar 2000 23:50:38 -0800 (PST)
	(envelope-from eric@clickrebates.com)
Received: from clickrebates.com (adsl-63-197-30-140.dsl.snfc21.pacbell.net [63.197.30.140])
	by Kharma.Nextshift.Net (8.9.3/8.9.0) with ESMTP id XAA17250;
	Wed, 22 Mar 2000 23:50:36 -0800 (PST)
Message-ID: <38D9CCCB.DC970B95@clickrebates.com>
Date: Wed, 22 Mar 2000 23:50:35 -0800
From: Eric Sabban <eric@clickrebates.com>
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Forrest Aldrich <forrie@forrie.com>
Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org
Subject: Re: 4.0 sysinstall fails to recognize disks
References: <4.3.1.2.20000322144026.00bb1c40@216.67.12.69> <4.3.1.2.20000322212337.00b647c0@216.67.12.69>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Yep.

-eric

Forrest Aldrich wrote:

> Interesting point... these ARE new drives that were put in today.
>
> I presume you mean to use the BIOS scsi utility?
>
> _F
>
> At 06:16 PM 3/22/00 -0800, Eric Sabban wrote:
> >Try low-levelling the drives. The behavior sounds similar to what I had a
> >long time ago, low level formatting them fixed the problem.
> >
> >-eric
> >
> >Forrest Aldrich wrote:
> >
> > > Since this is a fairly current issue, I'm posting this appropriately.
> > >
> > > I have a DELL server that has hooked up to it a PowerVault, with 8 36gb
> > 10krpm LVD drives.   The system has recognized these previously and dmesg
> > shows them present; however, /stand/sysinstall says that I don't have ANY
> > disks installed when using Label or Fdisk.
> > >
> > > Is this a known bug?   I've done a buildworld/installworld yesterday
> > after a cvsup.
> > >
> > > TIA.
> > >
> > > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > > with "unsubscribe freebsd-current" in the body of the message



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Wed Mar 22 23:55:41 2000
Delivered-To: freebsd-current@freebsd.org
Received: from ws-ilmar.ints.ru (ws-ilmar.ints.ru [194.67.173.16])
	by hub.freebsd.org (Postfix) with ESMTP id E757E37B934
	for <freebsd-current@FreeBSD.ORG>; Wed, 22 Mar 2000 23:55:34 -0800 (PST)
	(envelope-from ilmar@ints.ru)
Received: from localhost (localhost [127.0.0.1])
	by ws-ilmar.ints.ru (8.9.3/8.9.3) with ESMTP id KAA01647
	for <freebsd-current@FreeBSD.ORG>; Thu, 23 Mar 2000 10:55:32 +0300 (MSK)
Date: Thu, 23 Mar 2000 10:55:32 +0300 (MSK)
From: "Ilmar S. Habibulin" <ilmar@ints.ru>
To: freebsd-current@FreeBSD.ORG
Subject: Next thought: -current sudden panics :(
In-Reply-To: <Pine.BSF.4.21.0003210801280.223-300000@ws-ilmar.ints.ru>
Message-ID: <Pine.BSF.4.21.0003231050410.1636-100000@ws-ilmar.ints.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


We have dhcp server in our net, which configures windows clients. Maybe 
dhcp requests somehow involved in my panics?



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23  0:15:38 2000
Delivered-To: freebsd-current@freebsd.org
Received: from hcshh.hcs.de (hcshh.hcs.de [194.123.40.1])
	by hub.freebsd.org (Postfix) with SMTP id A8F0237BABF
	for <freebsd-current@FreeBSD.ORG>; Thu, 23 Mar 2000 00:15:25 -0800 (PST)
	(envelope-from hm@hcs.de)
Received: from hcswork.hcs.de([192.76.124.5]) (1259 bytes) by hcshh.hcs.de
	via sendmail with P:smtp/R:inet_hosts/T:smtp
	(sender: <hm@hcs.de>) 
	id <m12Y2lW-00024fC@hcshh.hcs.de>
	for <freebsd-current@FreeBSD.ORG>; Thu, 23 Mar 2000 09:14:50 +0100 (CET)
	(Smail-3.2.0.104 1998-Nov-20 #1 built 1998-Dec-11)
Received: by hcswork.hcs.de (Postfix, from userid 200)
	id 2688B482C; Thu, 23 Mar 2000 09:14:45 +0100 (MET)
Subject: Re: -current PCVT breakage?
In-Reply-To: <Pine.BSF.4.10.10003221347330.10867-100000@beppo.feral.com> from Matthew Jacob at "Mar 22, 0 01:47:56 pm"
To: mjacob@feral.com
Date: Thu, 23 Mar 2000 09:14:44 +0100 (MET)
Cc: freebsd-current@FreeBSD.ORG
Reply-To: hm@hcs.de
Organization: HCS Hanseatischer Computerservice GmbH
X-Mailer: ELM [version 2.4ME+ PL39 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 406       
Message-Id: <20000323081445.2688B482C@hcswork.hcs.de>
From: hm@hcs.de (Hellmuth Michaelis)
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

From the keyboard of Matthew Jacob:

> Is someone planning on fixing this?

Yes!

hellmuth
-- 
Hellmuth Michaelis                                    Tel   +49 40 55 97 47-70
HCS Hanseatischer Computerservice GmbH                Fax   +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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23  0:21:57 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mass.cdrom.com (c487804-a.frmt1.sfba.home.com [24.1.51.48])
	by hub.freebsd.org (Postfix) with ESMTP
	id C8B8F37BDE4; Thu, 23 Mar 2000 00:21:52 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Received: from mass.cdrom.com (localhost [127.0.0.1])
	by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id AAA01040;
	Thu, 23 Mar 2000 00:25:01 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Message-Id: <200003230825.AAA01040@mass.cdrom.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To: Eric Sabban <eric@clickrebates.com>
Cc: Forrest Aldrich <forrie@forrie.com>, freebsd-current@freebsd.org,
	freebsd-questions@freebsd.org
Subject: Re: 4.0 sysinstall fails to recognize disks 
In-reply-to: Your message of "Wed, 22 Mar 2000 18:16:22 PST."
             <38D97E76.BAD2FCF6@clickrebates.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 23 Mar 2000 00:25:01 -0800
From: Mike Smith <msmith@freebsd.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> Try low-levelling the drives. The behavior sounds similar to what I had a long time ago, low level formatting them fixed the problem.

Not a good idea.  Sounds more like sysinstall is massively out of sync 
with the rest of the system; it's not updated with the rest of the world.

> 
> -eric
> 
> Forrest Aldrich wrote:
> 
> > Since this is a fairly current issue, I'm posting this appropriately.
> >
> > I have a DELL server that has hooked up to it a PowerVault, with 8 36gb 10krpm LVD drives.   The system has recognized these previously and dmesg shows them present; however, /stand/sysinstall says that I don't have ANY disks installed when using Label or Fdisk.
> >
> > Is this a known bug?   I've done a buildworld/installworld yesterday after a cvsup.
> >
> > TIA.
> >
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-current" in the body of the message
> 
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message
> 

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
\\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23  0:58:22 2000
Delivered-To: freebsd-current@freebsd.org
Received: from matrix.eurocontrol.fr (matrix.eurocontrol.fr [147.196.254.254])
	by hub.freebsd.org (Postfix) with ESMTP
	id CEC9837C3CF; Thu, 23 Mar 2000 00:58:09 -0800 (PST)
	(envelope-from roberto@eurocontrol.fr)
Received: from caerdonn.eurocontrol.fr (caerdonn.eurocontrol.fr [147.196.5.62])
	by matrix.eurocontrol.fr (Postfix) with ESMTP
	id D81CF58DC; Thu, 23 Mar 2000 09:58:08 +0100 (CET)
	(envelope-from roberto@caerdonn.eurocontrol.fr)
Received: by caerdonn.eurocontrol.fr (Postfix, from userid 1193)
	id 7AB284E01; Thu, 23 Mar 2000 09:58:08 +0100 (CET)
Date: Thu, 23 Mar 2000 09:58:08 +0100
From: Ollivier Robert <roberto@eurocontrol.fr>
To: Mike Smith <msmith@freebsd.org>
Cc: John Baldwin <jhb@FreeBSD.org>, dcs@FreeBSD.org,
	FreeBSD Current Users' list <freebsd-current@FreeBSD.org>
Subject: Re: /boot/loader is making my VAIO reboot
Message-ID: <20000323095808.C24148@caerdonn.eurocontrol.fr>
References: <20000322112710.C15904@caerdonn.eurocontrol.fr> <200003222102.NAA01164@mass.cdrom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200003222102.NAA01164@mass.cdrom.com>; from msmith@freebsd.org on Wed, Mar 22, 2000 at 01:02:52PM -0800
X-Operating-System: FreeBSD 5.0-CURRENT
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

According to Mike Smith:
> Try putting just "set autoboot_delay=0" in /boot/loader.rc and see if 
> that gives you a prompt.

In loader.conf you mean ? loader.rc is supposed to contain Forth...
-- 
Ollivier ROBERT -=- Eurocontrol EEC/TEC -=- Ollivier.Robert@eurocontrol.fr
The Postman hits! The Postman hits! You have new mail.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23  1:13:32 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mass.cdrom.com (c487804-a.frmt1.sfba.home.com [24.1.51.48])
	by hub.freebsd.org (Postfix) with ESMTP
	id 47C2C37BF6C; Thu, 23 Mar 2000 01:13:28 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Received: from mass.cdrom.com (localhost [127.0.0.1])
	by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id BAA01328;
	Thu, 23 Mar 2000 01:16:35 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Message-Id: <200003230916.BAA01328@mass.cdrom.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To: Ollivier Robert <roberto@eurocontrol.fr>
Cc: Mike Smith <msmith@freebsd.org>, John Baldwin <jhb@freebsd.org>,
	dcs@freebsd.org,
	"FreeBSD Current Users' list" <freebsd-current@freebsd.org>
Subject: Re: /boot/loader is making my VAIO reboot 
In-reply-to: Your message of "Thu, 23 Mar 2000 09:58:08 +0100."
             <20000323095808.C24148@caerdonn.eurocontrol.fr> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 23 Mar 2000 01:16:35 -0800
From: Mike Smith <msmith@freebsd.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> According to Mike Smith:
> > Try putting just "set autoboot_delay=0" in /boot/loader.rc and see if 
> > that gives you a prompt.
> 
> In loader.conf you mean ? loader.rc is supposed to contain Forth...

I wrote the damn thing.  I meant loader.rc.  You're welcome to make the 
appropriate changes in loader.conf, I was simply trying to reduce the 
number of variables in the equation.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
\\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23  1:46:55 2000
Delivered-To: freebsd-current@freebsd.org
Received: from Kharma.Nextshift.Net (kharma.nextshift.net [216.200.15.16])
	by hub.freebsd.org (Postfix) with ESMTP
	id C3EA137BB5D; Thu, 23 Mar 2000 01:46:51 -0800 (PST)
	(envelope-from eric@clickrebates.com)
Received: from clickrebates.com (adsl-63-197-30-140.dsl.snfc21.pacbell.net [63.197.30.140])
	by Kharma.Nextshift.Net (8.9.3/8.9.0) with ESMTP id BAA18580;
	Thu, 23 Mar 2000 01:46:49 -0800 (PST)
Message-ID: <38D9E80A.E11E0F11@clickrebates.com>
Date: Thu, 23 Mar 2000 01:46:50 -0800
From: Eric Sabban <eric@clickrebates.com>
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Mike Smith <msmith@FreeBSD.ORG>
Cc: Forrest Aldrich <forrie@forrie.com>, freebsd-current@FreeBSD.ORG,
	freebsd-questions@FreeBSD.ORG
Subject: Re: 4.0 sysinstall fails to recognize disks
References: <200003230825.AAA01040@mass.cdrom.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Why not? The drives are empty LVD Drives, nothing bad'll happen.

I mean, it may very well be sysinstall being massively out of sync, but it shouldn't hurt to LL the drives.

-eric

Mike Smith wrote:

> > Try low-levelling the drives. The behavior sounds similar to what I had a long time ago, low level formatting them fixed the problem.
>
> Not a good idea.  Sounds more like sysinstall is massively out of sync
> with the rest of the system; it's not updated with the rest of the world.
>
> >
> > -eric
> >
> > Forrest Aldrich wrote:
> >
> > > Since this is a fairly current issue, I'm posting this appropriately.
> > >
> > > I have a DELL server that has hooked up to it a PowerVault, with 8 36gb 10krpm LVD drives.   The system has recognized these previously and dmesg shows them present; however, /stand/sysinstall says that I don't have ANY disks installed when using Label or Fdisk.
> > >
> > > Is this a known bug?   I've done a buildworld/installworld yesterday after a cvsup.
> > >
> > > TIA.
> > >
> > > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > > with "unsubscribe freebsd-current" in the body of the message
> >
> >
> >
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-current" in the body of the message
> >
>
> --
> \\ Give a man a fish, and you feed him for a day. \\  Mike Smith
> \\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
> \\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23  1:51: 5 2000
Delivered-To: freebsd-current@freebsd.org
Received: from trinity.skynet.be (trinity.skynet.be [195.238.2.38])
	by hub.freebsd.org (Postfix) with ESMTP
	id A8A2A37C3E6; Thu, 23 Mar 2000 01:50:59 -0800 (PST)
	(envelope-from blk@skynet.be)
Received: from [195.238.1.121] (brad.techos.skynet.be [195.238.1.121])
	by trinity.skynet.be (Postfix) with ESMTP
	id 6DBEC1814B; Thu, 23 Mar 2000 10:50:34 +0100 (MET)
Mime-Version: 1.0
X-Sender: blk@pop.skynet.be
Message-Id: <v04220805b4ff94c7c0ec@[195.238.1.121]>
In-Reply-To:
 <Pine.BSF.3.96.1000323001655.85607G-100000@fLuFFy.iNt.tElE.dK>
References:
 <Pine.BSF.3.96.1000323001655.85607G-100000@fLuFFy.iNt.tElE.dK>
Date: Thu, 23 Mar 2000 10:34:42 +0100
To: FreeBSD-abusers@netscum.dk,
	Matthew Dillon <dillon@apollo.backplane.com>
From: Brad Knowles <blk@skynet.be>
Subject: Re: FreeBSD random I/O performance issues
Cc: current@FreeBSD.ORG, fs@FreeBSD.ORG
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

At 1:17 AM +0100 2000/3/23, FREENIX IS OVERRATED wrote:

>  Without really tuning anything, after a bit of time, the time needed
>  to do history lookups drops to microseconds, and as long as a `sync'
>  isn't needed, innd doesn't get stuck.  Theoretically, a sync, where
>  you are in fact seeking rather wildly over the disk to update these
>  files, happens once a day at expiry.  Depending on the speed of the
>  drive (and I haven't optimized this at all, using a single drive for
>  OS, logs, history, and part of spool, with a second drive for the rest
>  of the spool, far from an ideal setup), this seems to mean only a
>  few minutes of downtime.  Actually building the new .index and .hash
>  files goes quite a bit faster, like by a factor of 3 to 4, so clearly
>  the update of these files during the `sync' could stand improved sorting.

	There are those of us running Diablo that solve this sort of 
problem on our main news peering servers by having the entire history 
file stored on a memory-based filesystem, so that we can sustain 
1000-2000 history lookups per second.

	Obviously, this solution is not scalable to news spool servers, 
because you can't afford to lose the history file for a months worth 
of news, but the current mmap() based solution for the indexes of the 
history database seems to cause much more disk accesses than I would 
like to see.


	Perhaps this would be a good application for md?

--
   These are my opinions -- not to be taken as official Skynet policy
======================================================================
Brad Knowles, <blk@skynet.be>                || 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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23  1:51:15 2000
Delivered-To: freebsd-current@freebsd.org
Received: from trinity.skynet.be (trinity.skynet.be [195.238.2.38])
	by hub.freebsd.org (Postfix) with ESMTP
	id 136A337C476; Thu, 23 Mar 2000 01:51:12 -0800 (PST)
	(envelope-from blk@skynet.be)
Received: from [195.238.1.121] (brad.techos.skynet.be [195.238.1.121])
	by trinity.skynet.be (Postfix) with ESMTP
	id C60351834C; Thu, 23 Mar 2000 10:50:26 +0100 (MET)
Mime-Version: 1.0
X-Sender: blk@pop.skynet.be
Message-Id: <v04220804b4ff93f99067@[195.238.1.121]>
In-Reply-To: <200003230014.QAA94423@apollo.backplane.com>
References:
 <Pine.BSF.4.21.0003221239440.80766-100000@dt051n0b.san.rr.com>
 <200003230014.QAA94423@apollo.backplane.com>
Date: Thu, 23 Mar 2000 10:29:01 +0100
To: Matthew Dillon <dillon@apollo.backplane.com>,
	Doug Barton <Doug@gorean.org>
From: Brad Knowles <blk@skynet.be>
Subject: Re: Another current crash (cvs-cur.6183
Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>,
	Paul Richards <paul@originative.co.uk>,
	Stephen Hocking-Senior Programmer PGS SPS Perth <shocking@prth.pgs.com>,
	current@FreeBSD.ORG, poul@FreeBSD.ORG
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

At 4:14 PM -0800 2000/3/22, Matthew Dillon wrote:

>      Frankly, I have INVARIANTS (and INVARIANT_SUPPORT) turned on by default
>      on all of my kernels.

	If it's this useful and this lightweight, may I suggest that we 
change the descriptive text around it in the LINT kernel, and copy 
that over to the GENERIC kernel (although we can turn it off by 
default)?

	I likewise made sure I turned it off when I built my new kernel, 
because of the descriptive text that warned me away.

--
   These are my opinions -- not to be taken as official Skynet policy
======================================================================
Brad Knowles, <blk@skynet.be>                || 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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23  2:43:12 2000
Delivered-To: freebsd-current@freebsd.org
Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38])
	by hub.freebsd.org (Postfix) with ESMTP id D4AD737BE87
	for <current@freebsd.org>; Thu, 23 Mar 2000 02:43:10 -0800 (PST)
	(envelope-from obrien@NUXI.ucdavis.edu)
Received: from dragon.nuxi.com (root@d60-024.leach.ucdavis.edu [169.237.60.24])
	by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id CAA49718
	for <current@freebsd.org>; Thu, 23 Mar 2000 02:43:10 -0800 (PST)
	(envelope-from obrien@dragon.nuxi.com)
Received: (from obrien@localhost)
	by dragon.nuxi.com (8.9.3/8.9.1) id CAA25996
	for current@freebsd.org; Thu, 23 Mar 2000 02:43:09 -0800 (PST)
	(envelope-from obrien)
Date: Thu, 23 Mar 2000 02:43:09 -0800
From: "David O'Brien" <obrien@freebsd.org>
To: current@freebsd.org
Subject: ** HEADS UP **  cvs commit: src/gnu/usr.bin/cc/cc_tools Makefile src/gnu/lib/libgcc Makefile src/contrib/gcc/config freebsd.h src/contrib/gcc/config/i386 freebsd.h src/contrib/gcc/config/alpha freebsd.h
Message-ID: <20000323024309.A25967@dragon.nuxi.com>
Reply-To: obrien@freebsd.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
X-Operating-System: FreeBSD 4.0-CURRENT
Organization: The NUXI BSD group
X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3  90 76 5D 69 58 D9 98 7A
X-Pgp-Keyid: 34F9F9D5
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

This commit -- changing much of the configuration of GCC on a FreeBSD
host, has the potential to wreck havoc.  One typo in these files can
render your compiler dead.  I have tested these changes on both i386 and
DEC Alpha.  However your environment may tickle an area of the
configuration mine didn't.

So if you are some what cautious, you might want to hold off a day or two
before your next buildworld.


----- Forwarded message from "David E. O'Brien" <obrien@FreeBSD.org> -----
  Modified files:
    gnu/usr.bin/cc/cc_tools Makefile 
    gnu/lib/libgcc       Makefile 
    contrib/gcc/config   freebsd.h 
    contrib/gcc/config/i386 freebsd.h 
    contrib/gcc/config/alpha freebsd.h 
  Log:
  Clean up the FreeBSD configuration files -- includes removing the usage
  of svr4.h on the i386, and moving all the shared arch neutral bits into
  the FreeBSD general config header.
----- End forwarded message -----


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23  2:51:43 2000
Delivered-To: freebsd-current@freebsd.org
Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87])
	by hub.freebsd.org (Postfix) with ESMTP
	id 5780837B840; Thu, 23 Mar 2000 02:51:30 -0800 (PST)
	(envelope-from dcs@newsguy.com)
Received: from newsguy.com (p44-dn01kiryunisiki.gunma.ocn.ne.jp [211.0.245.45])
	by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id TAA01485;
	Thu, 23 Mar 2000 19:51:23 +0900 (JST)
Message-ID: <38D9F6D2.ED2241F1@newsguy.com>
Date: Thu, 23 Mar 2000 19:49:54 +0900
From: "Daniel C. Sobral" <dcs@newsguy.com>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en,pt-BR,ja
MIME-Version: 1.0
To: Ollivier Robert <roberto@eurocontrol.fr>
Cc: Mike Smith <msmith@freebsd.org>, John Baldwin <jhb@freebsd.org>,
	"FreeBSD Current Users' list" <freebsd-current@freebsd.org>
Subject: Re: /boot/loader is making my VAIO reboot
References: <20000322112710.C15904@caerdonn.eurocontrol.fr> <200003222102.NAA01164@mass.cdrom.com> <20000323095808.C24148@caerdonn.eurocontrol.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Ollivier Robert wrote:
> 
> According to Mike Smith:
> > Try putting just "set autoboot_delay=0" in /boot/loader.rc and see if
> > that gives you a prompt.
> 
> In loader.conf you mean ? loader.rc is supposed to contain Forth...

Forth + "user friendly" loader commands, which the above is supposed to
be. :-)

That's in loader.rc. The loader.conf equivalent is 'autoboot_delay="0"'.

--
Daniel C. Sobral			(8-DCS)
dcs@newsguy.com
dcs@freebsd.org
capo@zurichgnomes.bsdconspiracy.net

	One Unix to rule them all, One Resolver to find them,
        One IP to bring them all and in the zone bind them.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23  3: 2:57 2000
Delivered-To: freebsd-current@freebsd.org
Received: from bluebottle.calcaphon.com (calcaphon.demon.co.uk [193.237.19.5])
	by hub.freebsd.org (Postfix) with ESMTP id 3FDC137BA5B
	for <current@freebsd.org>; Thu, 23 Mar 2000 03:02:50 -0800 (PST)
	(envelope-from n_hibma@calcaphon.com)
Received: from henny.calcaphon.com (henny.calcaphon.com [10.0.0.36])
	by bluebottle.calcaphon.com (8.9.3/8.9.1) with ESMTP id LAA45832;
	Thu, 23 Mar 2000 11:06:24 GMT
	(envelope-from n_hibma@calcaphon.com)
Date: Thu, 23 Mar 2000 11:00:17 +0000 (GMT)
From: Nick Hibma <n_hibma@calcaphon.com>
X-Sender: n_hibma@localhost
Reply-To: Nick Hibma <n_hibma@calcaphon.com>
To: USB BSD list <usb-bsd@egroups.com>
Cc: FreeBSD CURRENT Mailing List <current@freebsd.org>
Subject: Re: [usb-bsd] USB to Serial Port , anyone working on it?
In-Reply-To: <v0421011cb4fe2d721ccd@[137.134.1.102]>
Message-ID: <Pine.BSF.4.20.0003231058120.1118-100000@localhost>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: QUOTED-PRINTABLE
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


Yes. Doug Ambrisko (Whistle Communications) has written the beginnings
of a driver (but it works!). I've meant to check out the work he has
done and see for which devices this works. I will do that sometime this
week (weekend probably, maybe tomorrow evening)

His code is very generic, so I've got good hopes that the code will work
for many different devices (read: Entrega 25 pin, 9 pin, Keyspan
adapter and more).

Nick


> Just like to check if anyone is working on a USB to Serial Port driver?
> Thanks
> Richard
>=20
> ------------------------------------------------------------------------
> eLerts!
> It=92s easy. It=92s fun. Best of all, it=92s free.
> http://click.egroups.com/1/2073/6/_/85983/_/953776994/
>=20
> -- Create a poll/survey for your group!
> -- http://www.egroups.com/vote?listname=3Dusb-bsd&m=3D1
>=20
>=20

--
n_hibma@webweaving.org
n_hibma@freebsd.org                                          USB project
http://www.etla.net/~n_hibma/



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23  3:17:29 2000
Delivered-To: freebsd-current@freebsd.org
Received: from bluebottle.calcaphon.com (calcaphon.demon.co.uk [193.237.19.5])
	by hub.freebsd.org (Postfix) with ESMTP id 8830F37C405
	for <freebsd-current@freebsd.org>; Thu, 23 Mar 2000 03:17:21 -0800 (PST)
	(envelope-from n_hibma@calcaphon.com)
Received: from henny.calcaphon.com (henny.calcaphon.com [10.0.0.36])
	by bluebottle.calcaphon.com (8.9.3/8.9.1) with ESMTP id LAA46076;
	Thu, 23 Mar 2000 11:20:39 GMT
	(envelope-from n_hibma@calcaphon.com)
Date: Thu, 23 Mar 2000 11:14:32 +0000 (GMT)
From: Nick Hibma <n_hibma@calcaphon.com>
X-Sender: n_hibma@localhost
Reply-To: Nick Hibma <n_hibma@calcaphon.com>
To: Aaron Hughes <aaronh@bind.com>
Cc: freebsd-current@freebsd.org
Subject: Re: Found problem with pcm
In-Reply-To: <Pine.BSF.4.21.0003211259330.598-100000@user1.bind.com>
Message-ID: <Pine.BSF.4.20.0003231111440.1118-100000@localhost>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


Have you overclocked your system? If you are using an Athlon box, do you
have an extra fan on the bridge chip?

MP3's are heavy on the processor and will get you this behaviour if
the system is prone to glitches.


My system had similar problem (Fine until you run a make world) and
Windows _never_ crashed because of it, until I played 3 MP3's at the
same time. :)

Nick


On Tue, 21 Mar 2000, Aaron Hughes wrote:

> 
> pcm0: <AudioPCI ES1371> port 0xef00-0xef3f irq 7 at device 16.0 on pci0
> 
> When running esd, works for 10-15 minutes, and then system complely
> freezes, no errors, no core.
> 
> I can reproduce this if more info is needed.
> 
> 
> - Aaron Hughes 
> - aaronh@bind.com
> - For public PGP key: finger aaronh@bind.com 
> - Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C C6 B8
> 
> 
> 
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message
> 

--
n_hibma@webweaving.org
n_hibma@freebsd.org                                          USB project
http://www.etla.net/~n_hibma/



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23  3:29:35 2000
Delivered-To: freebsd-current@freebsd.org
Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97])
	by hub.freebsd.org (Postfix) with ESMTP id E88C637B522
	for <current@freebsd.org>; Thu, 23 Mar 2000 03:29:32 -0800 (PST)
	(envelope-from ncbp@bank-pedersen.dk)
Received: by freesbee.wheel.dk (Postfix, from userid 1002)
	id 99E613E40; Thu, 23 Mar 2000 12:29:28 +0100 (CET)
Date: Thu, 23 Mar 2000 12:29:28 +0100
From: "Niels Chr. Bank-Pedersen" <ncbp@bank-pedersen.dk>
To: current@freebsd.org
Subject: current panics
Message-ID: <20000323122928.E4987@bank-pedersen.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Hi,

I know it isn't much (no debugger compiled in (yet)), but is
anybody else seeing panics like this:

  mode = 0100644, inum = 214354, fs = /data0
  panic: ffs_valloc: dup alloc
  
  syncing disks... 23 13 4 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 
  giving up on 2 buffers
  Uptime: 3m24s
  Automatic reboot in 15 seconds - press a key on the console to abort

and

  dev = #vinum/1, block = 9757, fs = /data10
  panic: ffs_blkfree: freeing free frag
  
  syncing disks... 63 13 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 
  giving up on 1 buffers
  Uptime: 3m34s
  Automatic reboot in 15 seconds - press a key on the console to abort
  Rebooting...

Happening within a couple of minutes on -current kernels from 22/3 and
23/3 but not on a kernel from around the 18/3.
Running SU and vinum (both panics on a vinum fs), but otherwise
its just a plain nfs-server.


/Niels Chr.

-- 
 Niels Christian Bank-Pedersen, NCB1-RIPE.
 Network Manager, Tele Danmark NET, IP-section.

 "Hey, are any of you guys out there actually *using* RFC 2549?"


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23  3:35:29 2000
Delivered-To: freebsd-current@freebsd.org
Received: from PacHell.TelcoSucks.org (pachell.telcosucks.org [207.90.181.5])
	by hub.freebsd.org (Postfix) with ESMTP id AC2D937C3DA
	for <current@FreeBSD.ORG>; Thu, 23 Mar 2000 03:35:24 -0800 (PST)
	(envelope-from ulf@PacHell.TelcoSucks.org)
Received: (from ulf@localhost)
	by PacHell.TelcoSucks.org (8.9.3/8.9.1) id DAA01757;
	Thu, 23 Mar 2000 03:35:11 -0800 (PST)
	(envelope-from ulf)
Date: Thu, 23 Mar 2000 03:35:10 -0800
From: Ulf Zimmermann <ulf@Alameda.net>
To: Nick Hibma <n_hibma@calcaphon.com>
Cc: USB BSD list <usb-bsd@egroups.com>,
	FreeBSD CURRENT Mailing List <current@FreeBSD.ORG>
Subject: Re: [usb-bsd] USB to Serial Port , anyone working on it?
Message-ID: <20000323033510.F95709@PacHell.TelcoSucks.org>
Reply-To: ulf@Alameda.net
References: <v0421011cb4fe2d721ccd@[137.134.1.102]> <Pine.BSF.4.20.0003231058120.1118-100000@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 1.0i
In-Reply-To: <Pine.BSF.4.20.0003231058120.1118-100000@localhost>; from n_hibma@calcaphon.com on Thu, Mar 23, 2000 at 11:00:17AM +0000
Organization: Alameda Networks, Inc.
X-Operating-System: FreeBSD 3.2-STABLE
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Thu, Mar 23, 2000 at 11:00:17AM +0000, Nick Hibma wrote:
> 
> Yes. Doug Ambrisko (Whistle Communications) has written the beginnings
> of a driver (but it works!). I've meant to check out the work he has
> done and see for which devices this works. I will do that sometime this
> week (weekend probably, maybe tomorrow evening)
> 
> His code is very generic, so I've got good hopes that the code will work
> for many different devices (read: Entrega 25 pin, 9 pin, Keyspan
> adapter and more).

Any pointer to this driver ? I have a USB to 8 port serial from Digi
and would love to try if the driver works with it.

> 
> Nick
> 
> 
> > Just like to check if anyone is working on a USB to Serial Port driver?
> > Thanks
> > Richard
> > 
> > ------------------------------------------------------------------------
> > eLerts!
> > It’s easy. It’s fun. Best of all, it’s free.
> > http://click.egroups.com/1/2073/6/_/85983/_/953776994/
> > 
> > -- Create a poll/survey for your group!
> > -- http://www.egroups.com/vote?listname=usb-bsd&m=1
> > 
> > 
> 
> --
> n_hibma@webweaving.org
> n_hibma@freebsd.org                                          USB project
> http://www.etla.net/~n_hibma/
> 
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message

-- 
Regards, Ulf.

---------------------------------------------------------------------
Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936
Alameda Networks, Inc. | http://www.Alameda.net  | Fax#: 510-521-5073


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23  3:45: 5 2000
Delivered-To: freebsd-current@freebsd.org
Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87])
	by hub.freebsd.org (Postfix) with ESMTP id 6FAD137C412
	for <freebsd-current@FreeBSD.ORG>; Thu, 23 Mar 2000 03:44:59 -0800 (PST)
	(envelope-from dcs@newsguy.com)
Received: from newsguy.com (p34-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.99])
	by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id UAA14512;
	Thu, 23 Mar 2000 20:44:53 +0900 (JST)
Message-ID: <38DA0045.95DC8B25@newsguy.com>
Date: Thu, 23 Mar 2000 20:30:13 +0900
From: "Daniel C. Sobral" <dcs@newsguy.com>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en,pt-BR,ja
MIME-Version: 1.0
To: Ollivier Robert <roberto@keltia.freenix.fr>
Cc: "FreeBSD Current Users' list" <freebsd-current@FreeBSD.ORG>
Subject: Re: /boot/loader is making my VAIO reboot
References: <200003222102.NAA01164@mass.cdrom.com> <38D94095.CCE928E9@newsguy.com> <20000323075944.B18056@keltia.freenix.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Ollivier Robert wrote:
> 
> According to Daniel C. Sobral:
> > Or just pressing space when the countdown message first appears...
> 
> No time for that.

MMmmmm... the countdown message is 10 seconds long. It crashes before
going through the countdown???

Damn, I wish I could see the log of this boot.

IIRC, you only have "include /boot/loader.4th" and "start" in your
loader.rc, right? The lines starting with "\ " are comment lines.
Well... I'd like you to sprinkle some stuff in there so I can better
pinpoint _when_ the crash happens. Put the follow around the include and
start lines (before include, between them and after start):

.( Here ) cr

--
Daniel C. Sobral			(8-DCS)
dcs@newsguy.com
dcs@freebsd.org
capo@zurichgnomes.bsdconspiracy.net

	One Unix to rule them all, One Resolver to find them,
        One IP to bring them all and in the zone bind them.



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23  3:45:55 2000
Delivered-To: freebsd-current@freebsd.org
Received: from bluebottle.calcaphon.com (calcaphon.demon.co.uk [193.237.19.5])
	by hub.freebsd.org (Postfix) with ESMTP id 90B3737C42B
	for <current@FreeBSD.ORG>; Thu, 23 Mar 2000 03:45:48 -0800 (PST)
	(envelope-from n_hibma@calcaphon.com)
Received: from henny.calcaphon.com (henny.calcaphon.com [10.0.0.36])
	by bluebottle.calcaphon.com (8.9.3/8.9.1) with ESMTP id LAA46868;
	Thu, 23 Mar 2000 11:49:10 GMT
	(envelope-from n_hibma@calcaphon.com)
Date: Thu, 23 Mar 2000 11:43:03 +0000 (GMT)
From: Nick Hibma <n_hibma@calcaphon.com>
X-Sender: n_hibma@localhost
Reply-To: Nick Hibma <n_hibma@calcaphon.com>
To: Ulf Zimmermann <ulf@Alameda.net>
Cc: USB BSD list <usb-bsd@egroups.com>,
	FreeBSD CURRENT Mailing List <current@FreeBSD.ORG>
Subject: Re: [usb-bsd] USB to Serial Port , anyone working on it?
In-Reply-To: <20000323033510.F95709@PacHell.TelcoSucks.org>
Message-ID: <Pine.BSF.4.20.0003231140530.1118-100000@localhost>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> > His code is very generic, so I've got good hopes that the code will work
> > for many different devices (read: Entrega 25 pin, 9 pin, Keyspan
> > adapter and more).
> 
> Any pointer to this driver ? I have a USB to 8 port serial from Digi
> and would love to try if the driver works with it.

Ah, it won't. Those devices are different from the 16550 ones I've
mentioned above.

The pointer to the source I can't give, because it has escaped me
whether I sorted out the licensing issue with Doug Ambrisko. I'd rather
would like to sort that out first.

I've spoken to the guys from Digi. We got as far as NDA's but then they
stopped dead in their tracks. Their lawyers never got back to me. Maybe
I should have another attempt at convincing them.

Nick
--
n_hibma@webweaving.org
n_hibma@freebsd.org                                          USB project
http://www.etla.net/~n_hibma/



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23  3:59:58 2000
Delivered-To: freebsd-current@freebsd.org
Received: from ada.eu.org (marvin.enst.fr [137.194.161.2])
	by hub.freebsd.org (Postfix) with ESMTP id CCC9A37C426
	for <current@FreeBSD.ORG>; Thu, 23 Mar 2000 03:59:47 -0800 (PST)
	(envelope-from sam@inf.enst.fr)
Received: from antinea.enst.fr (antinea.enst.fr [137.194.160.145])
	by ada.eu.org (Postfix) with ESMTP
	id 42B8719076; Thu, 23 Mar 2000 12:59:36 +0100 (CET)
Received: by antinea.enst.fr (Postfix, from userid 1000)
	id A8468402; Thu, 23 Mar 2000 12:59:34 +0100 (CET)
Date: Thu, 23 Mar 2000 12:59:34 +0100
To: Jim Bloom <bloom@acm.org>
Cc: Bob Bishop <rb@gid.co.uk>, current@FreeBSD.ORG
Subject: Re: Buildworld hung up with lots of cron processes
References: <l03130309b4ff0e8f72d0@[194.32.164.2]> <38D97FAF.D1C051F@acm.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <38D97FAF.D1C051F@acm.org>; from bloom@acm.org on Wed, Mar 22, 2000 at 09:21:35PM -0500
From: Samuel Tardieu <sam@inf.enst.fr>
Organization: Ecole Nationale Superieure des Telecommunications
Reply-To: Samuel Tardieu <sam@inf.enst.fr>
Content-Transfer-Encoding: 8bit
X-WWW: http://www.inf.enst.fr/~tardieu/
X-Mail-Processing: Sam's procmail tools
X-ICQ: 21547599
Message-Id: <2000-03-23-12-59-34+trackit+sam@inf.enst.fr>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On 22/03, Jim Bloom wrote:

| I had hangs while linking the kernel as
| well as while trying to install a fixed one.  Make sure you have a good backup
| of the kernel, I ended up with a zero byte kernel while trying to install the
| fixed one.

Well, running without swap is likely to suppress those hangs, and let you
compile the new kernel.



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23  4: 7:14 2000
Delivered-To: freebsd-current@freebsd.org
Received: from matrix.eurocontrol.fr (matrix.eurocontrol.fr [147.196.254.254])
	by hub.freebsd.org (Postfix) with ESMTP id D451F37C436
	for <freebsd-current@FreeBSD.ORG>; Thu, 23 Mar 2000 04:07:11 -0800 (PST)
	(envelope-from roberto@eurocontrol.fr)
Received: from caerdonn.eurocontrol.fr (caerdonn.eurocontrol.fr [147.196.5.62])
	by matrix.eurocontrol.fr (Postfix) with ESMTP
	id D57FE56A9; Thu, 23 Mar 2000 13:07:10 +0100 (CET)
	(envelope-from roberto@caerdonn.eurocontrol.fr)
Received: by caerdonn.eurocontrol.fr (Postfix, from userid 1193)
	id 506B94E00; Thu, 23 Mar 2000 13:07:10 +0100 (CET)
Date: Thu, 23 Mar 2000 13:07:10 +0100
From: Ollivier Robert <roberto@eurocontrol.fr>
To: "Daniel C. Sobral" <dcs@newsguy.com>
Cc: FreeBSD Current Users' list <freebsd-current@FreeBSD.ORG>
Subject: Re: /boot/loader is making my VAIO reboot
Message-ID: <20000323130710.H24148@caerdonn.eurocontrol.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
X-Operating-System: FreeBSD 5.0-CURRENT
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> MMmmmm... the countdown message is 10 seconds long. It crashes before
> going through the countdown???

Yes.

> Damn, I wish I could see the log of this boot.

I can't record it and it goes way too fast to tell.

> IIRC, you only have "include /boot/loader.4th" and "start" in your
> loader.rc, right? The lines starting with "\ " are comment lines.
> Well... I'd like you to sprinkle some stuff in there so I can better
> pinpoint _when_ the crash happens. Put the follow around the include and
> start lines (before include, between them and after start):

.( Here ) cr

Will try, hope I'll be able to see them :)

Is there a way to do a "sleep 5" ?
-- 
Ollivier ROBERT -=- Eurocontrol EEC/TEC -=- Ollivier.Robert@eurocontrol.fr
The Postman hits! The Postman hits! You have new mail.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23  4:32:16 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mail.af.airnet.ne.jp (mail.af.airnet.ne.jp [210.159.66.49])
	by hub.freebsd.org (Postfix) with ESMTP
	id 6617E37B789; Thu, 23 Mar 2000 04:32:11 -0800 (PST)
	(envelope-from imura@cs.titech.ac.jp)
Received: from imura.af.airnet.ne.jp (tok209.airnet.ne.jp [210.159.88.209])
	by mail.af.airnet.ne.jp (8.8.8/3.6W/06/13/98-AF.AIRNET.NE.JP) with ESMTP id VAA16680;
	Thu, 23 Mar 2000 21:32:06 +0900
Posted-Date: Thu, 23 Mar 2000 21:31:06 +0900 (JST)
To: nsayer@freebsd.org, asami@freebsd.org, will@freebsd.org
Cc: freebsd-ports@freebsd.org, freebsd-current@freebsd.org
Subject: Re: KDE kdm problem with packaged version (make release
 issue?)
From: "R. Imura" <imura@af.airnet.ne.jp>
In-Reply-To: <38C9823F.5FCDCF40@sftw.com>
References: <38C9823F.5FCDCF40@sftw.com>
X-Mailer: Mew version 1.94b20 on Emacs 19.34 / Mule 2.3
 =?iso-2022-jp?B?KBskQkt2RSYyVhsoQik=?=
X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000323213103K.imura@cs.titech.ac.jp>
Date: Thu, 23 Mar 2000 21:31:03 +0900
X-Dispatcher: imput version 990401(IM113)
Lines: 23
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> For a long time I have noticed that when I build kdm from the kdebase
> port, it works.
> But if I used packages off either the CDs or ftp sites, it doesn't work.
> Specifically if I
> do a 'strings' on the binary and grep for /, some of the paths I see
> have XBINDIR
> rather than explicit references to /usr/X11R6/bin. I am not enough a
> ports guru to
> grok what is to be done, but before the freeze maybe someone could look
> into it?

It's because, there are no /usr/X11R6/bin/X in Asami-san's chroot
environment, I bet.
(I think Asami-san prepares a small XFree86 package with port building)

To solve this, we can simply prepare a patch against kdebase's configure,
but I think the best way is put X to chroot environment.

If I was wrong, sorry. :)

-- R. Imura
// my private mail address has changed.
// imura@cs.titech.ac.jp ====> imura@af.airnet.ne.jp /(-.-)y-~~


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23  4:33:53 2000
Delivered-To: freebsd-current@freebsd.org
Received: from hcshh.hcs.de (hcshh.hcs.de [194.123.40.1])
	by hub.freebsd.org (Postfix) with SMTP id 4DAC237B789
	for <freebsd-current@FreeBSD.ORG>; Thu, 23 Mar 2000 04:33:49 -0800 (PST)
	(envelope-from hm@hcs.de)
Received: from hcswork.hcs.de([192.76.124.5]) (1894 bytes) by hcshh.hcs.de
	via sendmail with P:smtp/R:inet_hosts/T:smtp
	(sender: <hm@hcs.de>) 
	id <m12Y6nY-00024fC@hcshh.hcs.de>
	for <freebsd-current@FreeBSD.ORG>; Thu, 23 Mar 2000 13:33:12 +0100 (CET)
	(Smail-3.2.0.104 1998-Nov-20 #1 built 1998-Dec-11)
Received: by hcswork.hcs.de (Postfix, from userid 200)
	id D3E1D3FEB; Thu, 23 Mar 2000 13:33:11 +0100 (MET)
Subject: Re: -current PCVT breakage?
In-Reply-To: <Pine.BSF.4.10.10003221347330.10867-100000@beppo.feral.com> from Matthew Jacob at "Mar 22, 0 01:47:56 pm"
To: mjacob@feral.com
Date: Thu, 23 Mar 2000 13:33:11 +0100 (MET)
Cc: freebsd-current@FreeBSD.ORG
Reply-To: hm@hcs.de
Organization: HCS Hanseatischer Computerservice GmbH
X-Mailer: ELM [version 2.4ME+ PL39 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1041      
Message-Id: <20000323123311.D3E1D3FEB@hcswork.hcs.de>
From: hm@hcs.de (Hellmuth Michaelis)
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

From the keyboard of Matthew Jacob:

> Is someone planning on fixing this?
>
> ../../i386/isa/pcvt/pcvt_hdr.h:943: warning: `struct isa_device' declared inside parameter list
> ../../i386/isa/pcvt/pcvt_hdr.h:943: warning: its scope is only this definition or declaration, which is probably not what you want.
> ../../i386/isa/pcvt/pcvt_hdr.h:944: warning: `struct isa_device' declared inside parameter list
> ../../i386/isa/pcvt/pcvt_hdr.h:946: variable `vtdriver' has initializer but incomplete type
[...]

I had to add 

	options         COMPAT_OLDISA
	options         COMPAT_OLDPCI

to my some-days-old kernel config file to make things compile and work
again.

The time seems to have come to new-busify pcvt ...

hellmuth
-- 
Hellmuth Michaelis                                    Tel   +49 40 55 97 47-70
HCS Hanseatischer Computerservice GmbH                Fax   +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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23  7:51: 9 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mass.cdrom.com (c487804-a.frmt1.sfba.home.com [24.1.51.48])
	by hub.freebsd.org (Postfix) with ESMTP
	id 2CA3B37BD0E; Thu, 23 Mar 2000 07:51:03 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Received: from mass.cdrom.com (localhost [127.0.0.1])
	by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id HAA01743;
	Thu, 23 Mar 2000 07:54:10 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Message-Id: <200003231554.HAA01743@mass.cdrom.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To: Eric Sabban <eric@clickrebates.com>
Cc: Forrest Aldrich <forrie@forrie.com>, freebsd-current@FreeBSD.ORG,
	freebsd-questions@FreeBSD.ORG
Subject: Re: 4.0 sysinstall fails to recognize disks 
In-reply-to: Your message of "Thu, 23 Mar 2000 01:46:50 PST."
             <38D9E80A.E11E0F11@clickrebates.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 23 Mar 2000 07:54:10 -0800
From: Mike Smith <msmith@freebsd.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> Why not? The drives are empty LVD Drives, nothing bad'll happen.

Apart from screwing up the factory format.

> I mean, it may very well be sysinstall being massively out of sync, but it shouldn't hurt to LL the drives.

It should, and will.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
\\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23  8:34: 1 2000
Delivered-To: freebsd-current@freebsd.org
Received: from serenity.mcc.ac.uk (serenity.mcc.ac.uk [130.88.200.93])
	by hub.freebsd.org (Postfix) with ESMTP id 5C1B637B590
	for <freebsd-current@freebsd.org>; Thu, 23 Mar 2000 08:33:55 -0800 (PST)
	(envelope-from jcm@dogma.freebsd-uk.eu.org)
Received: from dogma.freebsd-uk.eu.org ([130.88.200.97])
	by serenity.mcc.ac.uk with esmtp (Exim 1.92 #3)
	for freebsd-current@freebsd.org
	id 12YAYT-0004Qp-00; Thu, 23 Mar 2000 16:33:53 +0000
Received: (from jcm@localhost)
	by dogma.freebsd-uk.eu.org (8.9.3/8.9.3) id QAA80321
	for freebsd-current@freebsd.org; Thu, 23 Mar 2000 16:33:53 GMT
	(envelope-from jcm)
Date: Thu, 23 Mar 2000 16:33:53 +0000
From: J McKitrick <jcm@freebsd-uk.eu.org>
To: freebsd-current@freebsd.org
Subject: parallel zip driver problem
Message-ID: <20000323163353.A80279@dogma.freebsd-uk.eu.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

I'm not sure if this belongs on -stable or -current.  Has anyone taken
a look at the timeout problem in the parallel port zip driver?

jm
-- 
--------------------------------------------
Jonathon McKitrick -- jcm@freebsd-uk.eu.org 
Pure... unrefined... spice....
--------------------------------------------


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23  8:53: 8 2000
Delivered-To: freebsd-current@freebsd.org
Received: from probity.mcc.ac.uk (probity.mcc.ac.uk [130.88.200.94])
	by hub.freebsd.org (Postfix) with ESMTP id 4C33037B9E5
	for <freebsd-current@freebsd.org>; Thu, 23 Mar 2000 08:53:00 -0800 (PST)
	(envelope-from jcm@dogma.freebsd-uk.eu.org)
Received: from dogma.freebsd-uk.eu.org ([130.88.200.97])
	by probity.mcc.ac.uk with esmtp (Exim 1.92 #3)
	id 12YAqt-000APZ-00; Thu, 23 Mar 2000 16:52:55 +0000
Received: (from jcm@localhost)
	by dogma.freebsd-uk.eu.org (8.9.3/8.9.3) id QAA80417;
	Thu, 23 Mar 2000 16:52:55 GMT
	(envelope-from jcm)
Date: Thu, 23 Mar 2000 16:52:55 +0000
From: J McKitrick <jcm@freebsd-uk.eu.org>
To: "Sean O'Connell" <sean@stat.duke.edu>
Cc: freebsd-current@freebsd.org
Subject: Re: parallel zip driver problem
Message-ID: <20000323165255.D80279@dogma.freebsd-uk.eu.org>
References: <20000323163353.A80279@dogma.freebsd-uk.eu.org> <20000323114657.F9905@stat.Duke.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <20000323114657.F9905@stat.Duke.EDU>; from sean@stat.duke.edu on Thu, Mar 23, 2000 at 11:46:57AM -0500
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Thu, Mar 23, 2000 at 11:46:57AM -0500, Sean O'Connell wrote:
> J McKitrick stated:
> > I'm not sure if this belongs on -stable or -current.  Has anyone taken
> > a look at the timeout problem in the parallel port zip driver?
> 
> Have you tried backing vpo.c down to 1.19 (1.20 was committed
> on 23 Jan).  There was also a fairly large commit on 14 Jan.
> Have you emailed the author (nsouch)?

No, and no.  I'm not quite sure about how to 'back out' changes.  But
the real reason i didn't take a similar approach is because someone
else i am corresponding with about this said the vpo code doesn't seem
to be the culprit.  He thinks it's the da code, possibly.  And once he
started wading around in that, he said it's been gutted, so he felt a
quick fix would be unlikely. 

I should email the author, however.

jm
-- 
--------------------------------------------
Jonathon McKitrick -- jcm@freebsd-uk.eu.org 
Pure... unrefined... spice....
--------------------------------------------


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23  9: 1:44 2000
Delivered-To: freebsd-current@freebsd.org
Received: from feral.com (feral.com [192.67.166.1])
	by hub.freebsd.org (Postfix) with ESMTP id 73B7137B81F
	for <freebsd-current@FreeBSD.ORG>; Thu, 23 Mar 2000 09:01:38 -0800 (PST)
	(envelope-from mjacob@feral.com)
Received: from beppo.feral.com (beppo [192.67.166.79])
	by feral.com (8.9.3/8.9.3) with ESMTP id JAA10803;
	Thu, 23 Mar 2000 09:01:18 -0800
Date: Thu, 23 Mar 2000 09:01:18 -0800 (PST)
From: Matthew Jacob <mjacob@feral.com>
Reply-To: mjacob@feral.com
To: Hellmuth Michaelis <hm@hcs.de>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: -current PCVT breakage?
In-Reply-To: <20000323123311.D3E1D3FEB@hcswork.hcs.de>
Message-ID: <Pine.BSF.4.10.10003230900480.11902-100000@beppo.feral.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


> 	options         COMPAT_OLDISA
> 	options         COMPAT_OLDPCI

I'm an idiot - I should have paid closer attention to some other commits.
Thanks!

> 
> to my some-days-old kernel config file to make things compile and work
> again.
> 
> The time seems to have come to new-busify pcvt ...
> 
> hellmuth
> -- 
> Hellmuth Michaelis                                    Tel   +49 40 55 97 47-70
> HCS Hanseatischer Computerservice GmbH                Fax   +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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23  9: 2:10 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [194.217.50.228])
	by hub.freebsd.org (Postfix) with ESMTP
	id DEA4B37C174; Thu, 23 Mar 2000 09:02:05 -0800 (PST)
	(envelope-from paul@originative.co.uk)
Received: from originative.co.uk (lobster.originative.co.uk [194.217.50.241])
	by mailgate.originative.co.uk (Postfix) with ESMTP
	id 93F221D131; Thu, 23 Mar 2000 17:01:55 +0000 (GMT)
Message-ID: <38DA4E03.CB2E84A8@originative.co.uk>
Date: Thu, 23 Mar 2000 17:01:55 +0000
From: Paul Richards <paul@originative.co.uk>
Organization: Originative Solutions Ltd
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 4.0-CURRENT i386)
X-Accept-Language: en-GB, en
MIME-Version: 1.0
To: Kris Kennaway <kris@FreeBSD.org>
Cc: current@FreeBSD.org
Subject: Re: RSA library problems
References: <Pine.BSF.4.21.0003221830310.259-100000@freefall.freebsd.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Kris Kennaway wrote:
> 
> On Thu, 23 Mar 2000, Paul Richards wrote:
> 
> > > Because the dlopen() of librsaintl.so fails.
> >
> > Ok, I give up :-) Why would that happen then ?
> 
> I don't know :-)

I stuck a dlerror() in there and the problem is

usr/lib/librsaINTL.so: Undefined symbol "BN_mod_exp_mont"


Paul.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23  9:21:20 2000
Delivered-To: freebsd-current@freebsd.org
Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38])
	by hub.freebsd.org (Postfix) with ESMTP id 7F14837BCE2
	for <current@FreeBSD.ORG>; Thu, 23 Mar 2000 09:21:17 -0800 (PST)
	(envelope-from ambrisko@whistle.com)
Received: from whistle.com (crab.whistle.com [207.76.205.112])
	by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id JAA52099;
	Thu, 23 Mar 2000 09:21:12 -0800 (PST)
Received: (from ambrisko@localhost)
	by whistle.com (8.9.3/8.9.1) id JAA58245;
	Thu, 23 Mar 2000 09:20:40 -0800 (PST)
	(envelope-from ambrisko)
From: Doug Ambrisko <ambrisko@whistle.com>
Message-Id: <200003231720.JAA58245@whistle.com>
Subject: Re: [usb-bsd] USB to Serial Port , anyone working on it?
In-Reply-To: <Pine.BSF.4.20.0003231140530.1118-100000@localhost> from Nick Hibma
 at "Mar 23, 2000 11:43:03 am"
To: Nick Hibma <n_hibma@calcaphon.com>
Date: Thu, 23 Mar 2000 09:20:40 -0800 (PST)
Cc: Ulf Zimmermann <ulf@Alameda.net>,
	USB BSD list <usb-bsd@egroups.com>,
	FreeBSD CURRENT Mailing List <current@FreeBSD.ORG>
X-Mailer: ELM [version 2.4ME+ PL61 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Nick Hibma writes:
| The pointer to the source I can't give, because it has escaped me
| whether I sorted out the licensing issue with Doug Ambrisko. I'd rather
| would like to sort that out first.

This shouldn't be an issue since it is the same license as the netgraph
license from Whistle.  I have to revisit this issue for Linux USB though.

Doug A.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23  9:36: 8 2000
Delivered-To: freebsd-current@freebsd.org
Received: from trinity.skynet.be (trinity.skynet.be [195.238.2.38])
	by hub.freebsd.org (Postfix) with ESMTP id 867BC37B914
	for <freebsd-current@freebsd.org>; Thu, 23 Mar 2000 09:36:05 -0800 (PST)
	(envelope-from blk@skynet.be)
Received: from [195.238.1.121] (brad.techos.skynet.be [195.238.1.121])
	by trinity.skynet.be (Postfix) with ESMTP id 5711918497
	for <freebsd-current@freebsd.org>; Thu, 23 Mar 2000 18:35:18 +0100 (MET)
Mime-Version: 1.0
X-Sender: blk@pop.skynet.be
Message-Id: <v04220808b5000473e2bd@[195.238.1.121]>
Date: Thu, 23 Mar 2000 18:34:42 +0100
To: FreeBSD-CURRENT Mailing List <freebsd-current@freebsd.org>
From: Brad Knowles <blk@skynet.be>
Subject: INVARIANTS doesn't work?
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Folks,

	It looks to me like setting INVARIANTS in your kernel doesn't 
work in 4.0-STABLE.


	This one drove me batty for most of the day, until I remembered 
that I had also enabled this stuff as well as a couple other changes 
I had wanted to make to my kernel config.

	In the meanwhile, I can assure you that I am pretty current -- I 
automatically assumed I was at fault and that I should cvsup to make 
sure I've got the latest and greatest.  ;-)


	The "make" ends with:

cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline 
-Wcast-qual  -fformat-extensions -ansi -g -nostdinc -I- -I. -I../.. 
-I../../../include  -D_KERNEL -include opt_global.h -elf 
-mpreferred-stack-boundary=2  vers.c
linking kernel.debug
vm_zone.o: In function `zalloci':
/usr/src/sys/compile/AUDREY/../../vm/vm_zone.h:81: undefined 
reference to `zerror'
/usr/src/sys/compile/AUDREY/../../vm/vm_zone.h:91: undefined 
reference to `zerror'
vm_zone.o: In function `zfreei':
/usr/src/sys/compile/AUDREY/../../vm/vm_zone.h:106: undefined 
reference to `zerror'
vm_zone.o: In function `_zget':
/usr/src/sys/compile/AUDREY/../../vm/vm_zone.c:373: undefined 
reference to `zerror'
*** Error code 1

	The kernel config is a bit large, so I will transmit it on 
request to interested parties, but I won't post it to the list unless 
specifically asked to do so.  The one thing I'll note is that this 
might be an interaction between INVARIANTS and "makeoptions 
DEBUG=-g".  I'll try turning off DEBUG and see if I can make a kernel 
that way....

--
   These are my opinions -- not to be taken as official Skynet policy
======================================================================
Brad Knowles, <blk@skynet.be>                || 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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23  9:40:36 2000
Delivered-To: freebsd-current@freebsd.org
Received: from postfix2.free.fr (postfix2.free.fr [212.27.32.74])
	by hub.freebsd.org (Postfix) with ESMTP id ED25C37B5FE
	for <current@freebsd.org>; Thu, 23 Mar 2000 09:40:30 -0800 (PST)
	(envelope-from jaco@titine.fr.eu.org)
Received: from alex.titine.fr.eu.org (toulouse-50-124.dial.proxad.net [212.27.50.124])
	by postfix2.free.fr (Postfix) with ESMTP id 9E0697409B
	for <current@freebsd.org>; Thu, 23 Mar 2000 18:40:28 +0100 (MET)
Received: by alex.titine.fr.eu.org (Postfix, from userid 1000)
	id D0FFD5D2B2; Thu, 23 Mar 2000 18:40:17 +0100 (CET)
To: current@freebsd.org
Subject: Fatal trap 12 in 5.0-C
From: Eric Jacoboni <jaco@titine.fr.eu.org>
Date: 23 Mar 2000 18:40:16 +0100
Message-ID: <877letzitb.fsf@alex.titine.fr.eu.org>
Lines: 33
User-Agent: Gnus/5.0803 (Gnus v5.8.3) XEmacs/21.1 (Canyonlands)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Hi,

From yesterday and today cvsup + make world + kernel build : each time
i try to mount a cd (this is not related to a particular cd as the
same pb arises when the drive is empty...), my system reboot :

/kernel: Fatal trap 12: page fault while in kernel mode
/kernel: fault virtual address     = 0x0
/kernel: fault code                = supervisor read, page not present
/kernel: instruction pointer       = 0x8:0xc01fd360
/kernel: stack pointer             = 0x10:0xc673fd8c
/kernel: frame pointer             = 0x10:0xc673fd98
/kernel: code segment              = base 0x0, limit 0xfffff, type 0x1b
/kernel: = DPL 0, pres 1, def32 1, gran 1
/kernel: processor eflags  = interrupt enabled, resume, IOPL = 0
/kernel: current process           = 1477 (mount_cd9660)
/kernel: interrupt mask            = none
/kernel: trap number               = 12
/kernel: panic: page fault
/kernel:
/kernel: syncing disks... 10 9
/kernel: done
/kernel: Uptime: 2m28s
/kernel:
/kernel: dumping to dev #ad/0x30001, offset 55280
/kernel: dump ata0: resetting devices .. done

This is a Dell i3500 Laptop, which uses to run ok with previous world
(4.0-C and the first of 5.0-C, was ok).

-- 
Eric Jacoboni       
               Ta mère, son mot de passe c'est « toto » ! 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23  9:45:42 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id D450A37C49F
	for <freebsd-current@FreeBSD.ORG>; Thu, 23 Mar 2000 09:45:38 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id JAA02103;
	Thu, 23 Mar 2000 09:45:31 -0800 (PST)
	(envelope-from dillon)
Date: Thu, 23 Mar 2000 09:45:31 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003231745.JAA02103@apollo.backplane.com>
To: Brad Knowles <blk@skynet.be>
Cc: FreeBSD-CURRENT Mailing List <freebsd-current@FreeBSD.ORG>
Subject: Re: INVARIANTS doesn't work?
References:  <v04220808b5000473e2bd@[195.238.1.121]>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

    I just did a full buildworld/installworld and complete recompile
    of RELENG_4 last night with INVARIANTS turned on, and I use makeoptions
    DEBUG=-g.  It worked fine.

    Make sure you also specify the INVARIANT_SUPPORT options (note: this
    one is not plural).

						-Matt

:(Brad Knowles <blk@skynet.be>)
:Folks,
:
:	It looks to me like setting INVARIANTS in your kernel doesn't 
:work in 4.0-STABLE.
:
:...
:reference to `zerror'
:/usr/src/sys/compile/AUDREY/../../vm/vm_zone.h:91: undefined 
:reference to `zerror'
:vm_zone.o: In function `zfreei':
:/usr/src/sys/compile/AUDREY/../../vm/vm_zone.h:106: undefined 
:reference to `zerror'
:vm_zone.o: In function `_zget':
:/usr/src/sys/compile/AUDREY/../../vm/vm_zone.c:373: undefined 
:reference to `zerror'
:*** Error code 1
:
:	The kernel config is a bit large, so I will transmit it on 
:request to interested parties, but I won't post it to the list unless 
:specifically asked to do so.  The one thing I'll note is that this 
:might be an interaction between INVARIANTS and "makeoptions 
:DEBUG=-g".  I'll try turning off DEBUG and see if I can make a kernel 
:that way....



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23  9:51: 0 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP
	id 06A0D37BD13; Thu, 23 Mar 2000 09:50:57 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id JAA02133;
	Thu, 23 Mar 2000 09:50:56 -0800 (PST)
	(envelope-from dillon)
Date: Thu, 23 Mar 2000 09:50:56 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003231750.JAA02133@apollo.backplane.com>
To: Mike Smith <msmith@FreeBSD.ORG>
Cc: Eric Sabban <eric@clickrebates.com>,
	Forrest Aldrich <forrie@forrie.com>, freebsd-current@FreeBSD.ORG,
	freebsd-questions@FreeBSD.ORG
Subject: Re: 4.0 sysinstall fails to recognize disks 
References:  <200003231554.HAA01743@mass.cdrom.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

:
:> Why not? The drives are empty LVD Drives, nothing bad'll happen.
:
:Apart from screwing up the factory format.
:
:> I mean, it may very well be sysinstall being massively out of sync, but it shouldn't hurt to LL the drives.
:
:It should, and will.
:
:-- 
:\\ Give a man a fish, and you feed him for a day. \\  Mike Smith

    I get scared when lay-prorammers talk about Low-Leveling a disk :-).  
    There are virtually no programmers outside of RAID-land (and those are
    usually considered insane anyway :-)) who should ever have to LL a disk.
    I think I've LL'd maybe one SCSI disk in the last fifteen years.

    That said, today's disks are far less likely to blow up if you LL them
    then older (over 7 years) disks since there isn't a clock track any more.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23  9:57: 4 2000
Delivered-To: freebsd-current@freebsd.org
Received: from Kharma.Nextshift.Net (kharma.nextshift.net [216.200.15.16])
	by hub.freebsd.org (Postfix) with ESMTP
	id 1787737BD60; Thu, 23 Mar 2000 09:57:00 -0800 (PST)
	(envelope-from eric@clickrebates.com)
Received: from clickrebates.com (adsl-63-197-30-140.dsl.snfc21.pacbell.net [63.197.30.140])
	by Kharma.Nextshift.Net (8.9.3/8.9.0) with ESMTP id JAA26889;
	Thu, 23 Mar 2000 09:56:46 -0800 (PST)
Message-ID: <38DA5ADE.27FD7481@clickrebates.com>
Date: Thu, 23 Mar 2000 09:56:46 -0800
From: Eric Sabban <eric@clickrebates.com>
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: Mike Smith <msmith@FreeBSD.ORG>,
	Forrest Aldrich <forrie@forrie.com>, freebsd-current@FreeBSD.ORG,
	freebsd-questions@FreeBSD.ORG
Subject: Re: 4.0 sysinstall fails to recognize disks
References: <200003231554.HAA01743@mass.cdrom.com> <200003231750.JAA02133@apollo.backplane.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

I normally wouldn't recommend it. But the same situation with a different (not to be mentioned) OS happened to me.
After hours of being frustrated, I decided the scsi controller went south. A cow-orker told me to LL the drive,
and voila, magic. These were IBM LVD 10kRPM drives, brand spankin new. I'd recommend updating sysinstall first, if
that doesn't work, LL the drives.

-eric

Matthew Dillon wrote:

> :
> :> Why not? The drives are empty LVD Drives, nothing bad'll happen.
> :
> :Apart from screwing up the factory format.
> :
> :> I mean, it may very well be sysinstall being massively out of sync, but it shouldn't hurt to LL the drives.
> :
> :It should, and will.
> :
> :--
> :\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
>
>     I get scared when lay-prorammers talk about Low-Leveling a disk :-).
>     There are virtually no programmers outside of RAID-land (and those are
>     usually considered insane anyway :-)) who should ever have to LL a disk.
>     I think I've LL'd maybe one SCSI disk in the last fifteen years.
>
>     That said, today's disks are far less likely to blow up if you LL them
>     then older (over 7 years) disks since there isn't a clock track any more.
>
>                                         -Matt
>                                         Matthew Dillon
>                                         <dillon@backplane.com>



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 10: 0:15 2000
Delivered-To: freebsd-current@freebsd.org
Received: from forrie.net (forrie.net [216.67.12.69])
	by hub.freebsd.org (Postfix) with ESMTP
	id E663937C2F7; Thu, 23 Mar 2000 09:59:59 -0800 (PST)
	(envelope-from forrie@forrie.com)
Received: from Forrest (getbent@forrie.ne.mediaone.net [24.147.129.124])
            by forrie.net with id e2NHxqC19166;
            Thu, 23 Mar 2000 12:59:52 -0500 (EST)
Message-Id: <4.3.1.2.20000323125731.00b68100@216.67.12.69>
X-Sender: forrie@216.67.12.69
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 23 Mar 2000 12:59:06 -0500
To: Eric Sabban <eric@clickrebates.com>,
	Matthew Dillon <dillon@apollo.backplane.com>
From: Forrest Aldrich <forrie@forrie.com>
Subject: Re: 4.0 sysinstall fails to recognize disks
Cc: Mike Smith <msmith@FreeBSD.ORG>, freebsd-current@FreeBSD.ORG,
	freebsd-questions@FreeBSD.ORG
In-Reply-To: <38DA5ADE.27FD7481@clickrebates.com>
References: <200003231554.HAA01743@mass.cdrom.com>
 <200003231750.JAA02133@apollo.backplane.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

I tend to think there is something wrong with sysinstall... obviously, the 
OS works as the internal drives (also LVD 10KRPM drives) work.   Sysinstall 
just tells me there aren't any disks in the system.

So,  hope whomever maintains sysinstall is monitoring this conversation.

I will attempt another rebuild of the system.   I've not had a chance to 
check the cvs logs to see if someone committed any changes/fixes with 
serendipity.


_F


At 09:56 AM 3/23/00 -0800, Eric Sabban wrote:
>I normally wouldn't recommend it. But the same situation with a different 
>(not to be mentioned) OS happened to me.
>After hours of being frustrated, I decided the scsi controller went south. 
>A cow-orker told me to LL the drive,
>and voila, magic. These were IBM LVD 10kRPM drives, brand spankin new. I'd 
>recommend updating sysinstall first, if
>that doesn't work, LL the drives.
>
>-eric
>
>Matthew Dillon wrote:
>
> > :
> > :> Why not? The drives are empty LVD Drives, nothing bad'll happen.
> > :
> > :Apart from screwing up the factory format.
> > :
> > :> I mean, it may very well be sysinstall being massively out of sync, 
> but it shouldn't hurt to LL the drives.
> > :
> > :It should, and will.
> > :
> > :--
> > :\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
> >
> >     I get scared when lay-prorammers talk about Low-Leveling a disk :-).
> >     There are virtually no programmers outside of RAID-land (and those are
> >     usually considered insane anyway :-)) who should ever have to LL a 
> disk.
> >     I think I've LL'd maybe one SCSI disk in the last fifteen years.
> >
> >     That said, today's disks are far less likely to blow up if you LL them
> >     then older (over 7 years) disks since there isn't a clock track any 
> more.
> >
> >                                         -Matt
> >                                         Matthew Dillon
> >                                         <dillon@backplane.com>



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 10: 2: 7 2000
Delivered-To: freebsd-current@freebsd.org
Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1])
	by hub.freebsd.org (Postfix) with ESMTP id 3866737C5D4
	for <freebsd-current@FreeBSD.ORG>; Thu, 23 Mar 2000 10:01:56 -0800 (PST)
	(envelope-from bmilekic@dsuper.net)
Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1])
	by oracle.dsuper.net (8.9.3/8.9.3) with ESMTP id NAA15949;
	Thu, 23 Mar 2000 13:01:46 -0500 (EST)
Date: Thu, 23 Mar 2000 13:01:43 -0500 (EST)
From: Bosko Milekic <bmilekic@dsuper.net>
To: Brad Knowles <blk@skynet.be>
Cc: FreeBSD-CURRENT Mailing List <freebsd-current@FreeBSD.ORG>
Subject: Re: INVARIANTS doesn't work?
In-Reply-To: <v04220808b5000473e2bd@[195.238.1.121]>
Message-ID: <Pine.OSF.4.05.10003231242210.5283-100000@oracle.dsuper.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG



On Thu, 23 Mar 2000, Brad Knowles wrote:

>Folks,
>
>	It looks to me like setting INVARIANTS in your kernel doesn't 
>work in 4.0-STABLE.
>
[...]
>reference to `zerror'
>vm_zone.o: In function `zfreei':
>
>	The kernel config is a bit large, so I will transmit it on 
>request to interested parties, but I won't post it to the list unless 
>specifically asked to do so.  The one thing I'll note is that this 
>might be an interaction between INVARIANTS and "makeoptions 
>DEBUG=-g".  I'll try turning off DEBUG and see if I can make a kernel 
>that way....
>

	Hopefully, you've done this and the following will come out
  as a pretty useless question for you, but I have not seen it
  mentionned in your Email:

	Do you have `options INVARIANT_SUPPORT' ?

 ..........................................................................
  Bosko Milekic * bmilekic@dsuper.net * http://pages.infinit.net/bmilekic/
  Montreal, Quebec, Canada. *  Technokratis:  http://www.technokratis.com/




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 10: 2:48 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mass.cdrom.com (mg-20425418-10.ricochet.net [204.254.18.10])
	by hub.freebsd.org (Postfix) with ESMTP
	id 29BD137B60C; Thu, 23 Mar 2000 10:02:23 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Received: from mass.cdrom.com (localhost [127.0.0.1])
	by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id KAA01112;
	Thu, 23 Mar 2000 10:04:50 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Message-Id: <200003231804.KAA01112@mass.cdrom.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To: Eric Sabban <eric@clickrebates.com>
Cc: Matthew Dillon <dillon@apollo.backplane.com>,
	Mike Smith <msmith@FreeBSD.ORG>, Forrest Aldrich <forrie@forrie.com>,
	freebsd-current@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG
Subject: Re: 4.0 sysinstall fails to recognize disks 
In-reply-to: Your message of "Thu, 23 Mar 2000 09:56:46 PST."
             <38DA5ADE.27FD7481@clickrebates.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 23 Mar 2000 10:04:49 -0800
From: Mike Smith <msmith@freebsd.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


I say again, DO NOT low-level format the drive.  The _only_ situation 
where it's worth taking this risk is when you're seeing errors from the 
drive itself specifically referring to formatting issues; eg. 'address 
mark not found'.  There are no other circumstances which justify this 
action, and a great deal of harm can come from it.

> I normally wouldn't recommend it. But the same situation with a different (not to be mentioned) OS happened to me.
> After hours of being frustrated, I decided the scsi controller went south. A cow-orker told me to LL the drive,
> and voila, magic. These were IBM LVD 10kRPM drives, brand spankin new. I'd recommend updating sysinstall first, if
> that doesn't work, LL the drives.

Wrong solution.


-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
\\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 10: 6:30 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mass.cdrom.com (mg-20425418-10.ricochet.net [204.254.18.10])
	by hub.freebsd.org (Postfix) with ESMTP
	id 6765C37BD71; Thu, 23 Mar 2000 10:06:22 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Received: from mass.cdrom.com (localhost [127.0.0.1])
	by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id KAA01160;
	Thu, 23 Mar 2000 10:08:36 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Message-Id: <200003231808.KAA01160@mass.cdrom.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To: Forrest Aldrich <forrie@forrie.com>
Cc: Eric Sabban <eric@clickrebates.com>,
	Matthew Dillon <dillon@apollo.backplane.com>,
	Mike Smith <msmith@FreeBSD.ORG>, freebsd-current@FreeBSD.ORG,
	freebsd-questions@FreeBSD.ORG
Subject: Re: 4.0 sysinstall fails to recognize disks 
In-reply-to: Your message of "Thu, 23 Mar 2000 12:59:06 EST."
             <4.3.1.2.20000323125731.00b68100@216.67.12.69> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 23 Mar 2000 10:08:36 -0800
From: Mike Smith <msmith@freebsd.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> I tend to think there is something wrong with sysinstall... obviously, the 
> OS works as the internal drives (also LVD 10KRPM drives) work.   Sysinstall 
> just tells me there aren't any disks in the system.
> 
> So,  hope whomever maintains sysinstall is monitoring this conversation.

Sysinstall works fine _IF_IT_IS_IN_SYNCH_WITH_THE_REST_OF_YOUR_SYSTEM_.

> I will attempt another rebuild of the system.   I've not had a chance to 
> check the cvs logs to see if someone committed any changes/fixes with 
> serendipity.

Just rebuild sysinstall, like I told you to start with.  Or just bring 
the disks up by hand, which is much faster.  Or even try Warner's 
'diskprep' tool.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
\\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 10: 7: 9 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP
	id 7B04637C52A; Thu, 23 Mar 2000 10:06:59 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id KAA02333;
	Thu, 23 Mar 2000 10:06:57 -0800 (PST)
	(envelope-from dillon)
Date: Thu, 23 Mar 2000 10:06:57 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003231806.KAA02333@apollo.backplane.com>
To: Eric Sabban <eric@clickrebates.com>
Cc: Mike Smith <msmith@FreeBSD.ORG>,
	Forrest Aldrich <forrie@forrie.com>, freebsd-current@FreeBSD.ORG,
	freebsd-questions@FreeBSD.ORG
Subject: Re: 4.0 sysinstall fails to recognize disks
References: <200003231554.HAA01743@mass.cdrom.com> <200003231750.JAA02133@apollo.backplane.com> <38DA5ADE.27FD7481@clickrebates.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


:I normally wouldn't recommend it. But the same situation with a different (not to be mentioned) OS happened to me.
:After hours of being frustrated, I decided the scsi controller went south. A cow-orker told me to LL the drive,
:and voila, magic. These were IBM LVD 10kRPM drives, brand spankin new. I'd recommend updating sysinstall first, if
:that doesn't work, LL the drives.
:
:-eric

    I really doubt that LLing the drive fixed your problem.  You probably
    did something else while messing around that wound up fixing it.

    The simple answer when someone approaches you on the street and suggests
    that you can fix the world by LLing your hard drive, is "NO" :-).

    The worst I've ever had to do to a drive to make the system recognize
    it is zero-out the first few sectors with dd.  That way the system 
    believes that the drive does not have a valid label and lets you install
    a new one trivially.

						-Matt




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 10:16:25 2000
Delivered-To: freebsd-current@freebsd.org
Received: from forrie.net (forrie.net [216.67.12.69])
	by hub.freebsd.org (Postfix) with ESMTP
	id D56B237C4EB; Thu, 23 Mar 2000 10:16:14 -0800 (PST)
	(envelope-from forrie@forrie.com)
Received: from Forrest (getbent@forrie.ne.mediaone.net [24.147.129.124])
            by forrie.net with id e2NIFsC19314;
            Thu, 23 Mar 2000 13:15:55 -0500 (EST)
Message-Id: <4.3.1.2.20000323131429.00b69410@216.67.12.69>
X-Sender: forrie@216.67.12.69
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 23 Mar 2000 13:15:08 -0500
To: Mike Smith <msmith@FreeBSD.ORG>
From: Forrest Aldrich <forrie@forrie.com>
Subject: Re: 4.0 sysinstall fails to recognize disks 
Cc: Eric Sabban <eric@clickrebates.com>,
	Matthew Dillon <dillon@apollo.backplane.com>,
	Mike Smith <msmith@FreeBSD.ORG>, freebsd-current@FreeBSD.ORG,
	freebsd-questions@FreeBSD.ORG
In-Reply-To: <200003231808.KAA01160@mass.cdrom.com>
References: <Your message of "Thu, 23 Mar 2000 12:59:06 EST." <4.3.1.2.20000323125731.00b68100@216.67.12.69>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Is not sysinstall built and installed with a typical make 
buildworld/installworld?

Anyways, I rebuilt it and it works now.   Sysinstall was the culprit.


_F

At 10:08 AM 3/23/00 -0800, Mike Smith wrote:
> > I tend to think there is something wrong with sysinstall... obviously, the
> > OS works as the internal drives (also LVD 10KRPM drives) 
> work.   Sysinstall
> > just tells me there aren't any disks in the system.
> >
> > So,  hope whomever maintains sysinstall is monitoring this conversation.
>
>Sysinstall works fine _IF_IT_IS_IN_SYNCH_WITH_THE_REST_OF_YOUR_SYSTEM_.
>
> > I will attempt another rebuild of the system.   I've not had a chance to
> > check the cvs logs to see if someone committed any changes/fixes with
> > serendipity.
>
>Just rebuild sysinstall, like I told you to start with.  Or just bring
>the disks up by hand, which is much faster.  Or even try Warner's
>'diskprep' tool.
>
>--
>\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
>\\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
>\\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com
>



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 10:22: 5 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mass.cdrom.com (mg-20425418-10.ricochet.net [204.254.18.10])
	by hub.freebsd.org (Postfix) with ESMTP
	id 9115037C507; Thu, 23 Mar 2000 10:21:46 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Received: from mass.cdrom.com (localhost [127.0.0.1])
	by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id KAA01235;
	Thu, 23 Mar 2000 10:24:40 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Message-Id: <200003231824.KAA01235@mass.cdrom.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To: Forrest Aldrich <forrie@forrie.com>
Cc: freebsd-current@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG
Subject: Re: 4.0 sysinstall fails to recognize disks 
In-reply-to: Your message of "Thu, 23 Mar 2000 13:15:08 EST."
             <4.3.1.2.20000323131429.00b69410@216.67.12.69> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 23 Mar 2000 10:24:40 -0800
From: Mike Smith <msmith@freebsd.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> Is not sysinstall built and installed with a typical make 
> buildworld/installworld?

As I told you in my original reply, _NO_.

> Anyways, I rebuilt it and it works now.   Sysinstall was the culprit.

"I told you so".

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
\\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 10:24:24 2000
Delivered-To: freebsd-current@freebsd.org
Received: from trinity.skynet.be (trinity.skynet.be [195.238.2.38])
	by hub.freebsd.org (Postfix) with ESMTP id 634D737BD8B
	for <freebsd-current@FreeBSD.ORG>; Thu, 23 Mar 2000 10:24:19 -0800 (PST)
	(envelope-from blk@skynet.be)
Received: from [195.238.1.121] (brad.techos.skynet.be [195.238.1.121])
	by trinity.skynet.be (Postfix) with ESMTP
	id 7FE6918116; Thu, 23 Mar 2000 19:23:14 +0100 (MET)
Mime-Version: 1.0
X-Sender: blk@pop.skynet.be
Message-Id: <v0422080ab500108fbdce@[195.238.1.121]>
In-Reply-To: <200003231745.JAA02103@apollo.backplane.com>
References: <v04220808b5000473e2bd@[195.238.1.121]>
 <200003231745.JAA02103@apollo.backplane.com>
Date: Thu, 23 Mar 2000 19:20:15 +0100
To: Matthew Dillon <dillon@apollo.backplane.com>,
	Bosko Milekic <bmilekic@dsuper.net>
From: Brad Knowles <blk@skynet.be>
Subject: Re: INVARIANTS doesn't work?
Cc: FreeBSD-CURRENT Mailing List <freebsd-current@FreeBSD.ORG>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

At 9:45 AM -0800 2000/3/23, Matthew Dillon wrote:

>      Make sure you also specify the INVARIANT_SUPPORT options (note: this
>      one is not plural).

	DOH!!!

	<open mouth><insert>foot</insert></open>


	Rebooting now.  We'll see if it works.  Sigh....  ;-)


	Thanks guys!

--
   These are my opinions -- not to be taken as official Skynet policy
======================================================================
Brad Knowles, <blk@skynet.be>                || 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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 11:15:44 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id 33C4937C575
	for <freebsd-current@FreeBSD.ORG>; Thu, 23 Mar 2000 11:15:36 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id LAA03210;
	Thu, 23 Mar 2000 11:15:27 -0800 (PST)
	(envelope-from dillon)
Date: Thu, 23 Mar 2000 11:15:27 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003231915.LAA03210@apollo.backplane.com>
To: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>
Cc: imp@village.org, ilmar@ints.ru, nms@otdel-1.org,
	freebsd-current@FreeBSD.ORG
Subject: Re: -current sudden panics :( 
References: <Pine.BSF.4.21.0003220813250.220-100000@ws-ilmar.ints.ru>
	<200003222201.PAA33948@harmony.village.org> <20000323105025W.shin@nd.net.fujitsu.co.jp>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

    This problem should now be fixed, it's probably the problem I just fixed
    a moment ago in netinet/if_ether.c based on a thread in -hackers.  The
    m_pullup() NULL check in arpintr() was broken, resulting in a NULL
    pointer dereference.  

						-Matt



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 11:21:18 2000
Delivered-To: freebsd-current@freebsd.org
Received: from rover.village.org (rover.village.org [204.144.255.49])
	by hub.freebsd.org (Postfix) with ESMTP id 19C8A37BA3E
	for <freebsd-current@FreeBSD.ORG>; Thu, 23 Mar 2000 11:21:16 -0800 (PST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (harmony.village.org [10.0.0.6])
	by rover.village.org (8.9.3/8.9.3) with ESMTP id MAA34922;
	Thu, 23 Mar 2000 12:21:05 -0700 (MST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id MAA42799; Thu, 23 Mar 2000 12:21:02 -0700 (MST)
Message-Id: <200003231921.MAA42799@harmony.village.org>
To: Matthew Dillon <dillon@apollo.backplane.com>
Subject: Re: -current sudden panics :( 
Cc: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>, ilmar@ints.ru,
	nms@otdel-1.org, freebsd-current@FreeBSD.ORG
In-reply-to: Your message of "Thu, 23 Mar 2000 11:15:27 PST."
		<200003231915.LAA03210@apollo.backplane.com> 
References: <200003231915.LAA03210@apollo.backplane.com>  <Pine.BSF.4.21.0003220813250.220-100000@ws-ilmar.ints.ru> <200003222201.PAA33948@harmony.village.org> <20000323105025W.shin@nd.net.fujitsu.co.jp> 
Date: Thu, 23 Mar 2000 12:21:02 -0700
From: Warner Losh <imp@village.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <200003231915.LAA03210@apollo.backplane.com> Matthew Dillon writes:
:     This problem should now be fixed, it's probably the problem I just fixed
:     a moment ago in netinet/if_ether.c based on a thread in -hackers.  The
:     m_pullup() NULL check in arpintr() was broken, resulting in a NULL
:     pointer dereference.  

inoue-san's patch survived the night.  I'll check into your patch and
give it a try instead.

Warner


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 11:41:28 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mail.kpnqwest.ch (mail.eunet.ch [146.228.10.7])
	by hub.freebsd.org (Postfix) with ESMTP id 432CD37B7CF
	for <freebsd-current@freebsd.org>; Thu, 23 Mar 2000 11:40:34 -0800 (PST)
	(envelope-from mw@kpnqwest.ch)
Received: (from mw@localhost) by mail.kpnqwest.ch (8.9.3/1.34) id TAA24686
	for freebsd-current@freebsd.org; Thu, 23 Mar 2000 19:40:27 GMT
	env-from (mw@kpnqwest.ch)
From: mw@kpnqwest.ch
Message-Id: <200003231940.TAA24686@mail.kpnqwest.ch>
Subject: Re: AMI MegaRAID lockup? not accepting commands.
To: freebsd-current@freebsd.org
Date: Thu, 23 Mar 2000 20:40:27 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL72 (25)]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=ELM953840427-11422-2_
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


--ELM953840427-11422-2_
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I've played around changing the spinloop to using DELAY (like the Linux model),
but this didn't prevent the controller from either "just" locking up or 
crashing the whole machine with it. Changing various other places in a similar
manner (like replacing the bcopy() in amr_quartz_get_work() with similar
code as in the linux driver to wait for 0xFF to clear) didn't do the trick
either. 

However, when I forced the driver to not use the full number of
concurrent commands as returned by the firmware, I seem to finally have 
found the one change that made the difference. Looking at the linux
code, it sets a hard limit of AMR_MAXCMD (MAX_COMMANDS in the linux code) of
127 (my controller, a 466, returned 254), and it says the value can be tweaked
between 0 and 253, not 254...). So, forcing sc->amr_maxio to AMR_MAXCMD if
that one's smaller, in amr_query_controller(), might cause some performance
loss, but it made the code *significantly* stabler than before. I did two
make world on the raid now, and not one hickup. Before I wasn't even able to
copy over the system to the raid without sending the system to reboot. 

Possible explanation: people that introduced debugging statements slowed down
the feeding of new commands to the controller, so the controller didn't ever
use up the full set of concurrent commands. The lockup happens when too many
concurrent commands are open (now, I haven't tried setting things to 253, I
am glad things finally work:-)).

Hope this helps,
Markus
-- 
KPNQwest Switzerland Ltd
P.O. Box 9470, Zweierstrasse 35, CH-8036 Zuerich
Tel: +41-1-298-6030, Fax: +41-1-291-4642
Markus Wild, Manager Engineering, e-mail: markus.wild@kpnqwest.ch

--ELM953840427-11422-2_
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: attachment; filename=mydiff.short
Content-Description: mydiff.short
Content-Transfer-Encoding: 7bit

Index: amr.c
===================================================================
RCS file: /home/ncvs/src/sys/dev/amr/amr.c,v
retrieving revision 1.8
diff -c -r1.8 amr.c
*** amr.c	2000/03/20 10:44:03	1.8
--- amr.c	2000/03/23 19:20:03
***************
*** 699,704 ****
--- 702,712 ----
  	}
  	sc->amr_maxdrives = 8;
  	sc->amr_maxio = ae->ae_adapter.aa_maxio;
+ 	if (sc->amr_maxio > AMR_MAXCMD) {
+ 	  device_printf(sc->amr_dev, "reducing maxio from %d to %d\n", 
+ 			sc->amr_maxio, AMR_MAXCMD);
+ 	  sc->amr_maxio = AMR_MAXCMD;
+ 	}
  	for (i = 0; i < ae->ae_ldrv.al_numdrives; i++) {
  	    sc->amr_drive[i].al_size = ae->ae_ldrv.al_size[i];
  	    sc->amr_drive[i].al_state = ae->ae_ldrv.al_state[i];
***************
*** 853,859 ****
  	ac->ac_private = bp;
  	ac->ac_data = bp->b_data;
  	ac->ac_length = bp->b_bcount;
! 	if (bp->b_iocmd == BIO_READ) {
  	    ac->ac_flags |= AMR_CMD_DATAIN;
  	    cmd = AMR_CMD_LREAD;
  	} else {
--- 861,868 ----
  	ac->ac_private = bp;
  	ac->ac_data = bp->b_data;
  	ac->ac_length = bp->b_bcount;
! /*	if (bp->b_iocmd == BIO_READ) { */
! 	if (bp->b_flags & B_READ) {
  	    ac->ac_flags |= AMR_CMD_DATAIN;
  	    cmd = AMR_CMD_LREAD;
  	} else {
Index: amrvar.h
===================================================================
RCS file: /home/ncvs/src/sys/dev/amr/amrvar.h,v
retrieving revision 1.2
diff -c -r1.2 amrvar.h
*** amrvar.h	1999/10/26 23:18:57	1.2
--- amrvar.h	2000/03/23 19:20:04
***************
*** 37,43 ****
  #define AMR_CFG_SIG	0xa0
  #define AMR_SIGNATURE	0x3344
  
! #define AMR_MAXCMD	255		/* ident = 0 not allowed */
  #define AMR_MAXLD      	40
  
  #define AMR_BLKSIZE	512
--- 37,44 ----
  #define AMR_CFG_SIG	0xa0
  #define AMR_SIGNATURE	0x3344
  
! /*#define AMR_MAXCMD	255*/		/* ident = 0 not allowed */
! #define AMR_MAXCMD	127		/* ident = 0 not allowed */
  #define AMR_MAXLD      	40
  
  #define AMR_BLKSIZE	512

--ELM953840427-11422-2_--


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 11:57:40 2000
Delivered-To: freebsd-current@freebsd.org
Received: from spirit.jaded.net (spirit.jaded.net [216.94.113.12])
	by hub.freebsd.org (Postfix) with ESMTP id 7660B37C508
	for <current@freebsd.org>; Thu, 23 Mar 2000 11:57:28 -0800 (PST)
	(envelope-from dan@spirit.jaded.net)
Received: (from dan@localhost)
	by spirit.jaded.net (8.9.3/8.9.3) id OAA00485
	for current@freebsd.org; Thu, 23 Mar 2000 14:57:40 -0500 (EST)
Date: Thu, 23 Mar 2000 14:57:40 -0500
From: Dan Moschuk <dan@freebsd.org>
To: current@freebsd.org
Subject: -current, ep and fragment problems.
Message-ID: <20000323145740.A299@spirit.jaded.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


Is anyone else seeing odd behaviour with a fairly recent -current, an ep
driver nic card and fragmented packets?

-- 
Dan Moschuk (TFreak!dan@freebsd.org)
"Waste not fresh tears on old griefs."


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 12: 1:56 2000
Delivered-To: freebsd-current@freebsd.org
Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87])
	by hub.freebsd.org (Postfix) with ESMTP id 75CFB37BE11
	for <freebsd-current@FreeBSD.ORG>; Thu, 23 Mar 2000 12:01:47 -0800 (PST)
	(envelope-from dcs@newsguy.com)
Received: from newsguy.com (dcs@p21-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.150])
	by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id FAA12994;
	Fri, 24 Mar 2000 05:01:40 +0900 (JST)
Message-ID: <38DA77C8.CB78CD33@newsguy.com>
Date: Fri, 24 Mar 2000 05:00:08 +0900
From: "Daniel C. Sobral" <dcs@newsguy.com>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en,pt-BR,ja
MIME-Version: 1.0
To: Ollivier Robert <roberto@eurocontrol.fr>
Cc: "FreeBSD Current Users' list" <freebsd-current@FreeBSD.ORG>
Subject: Re: /boot/loader is making my VAIO reboot
References: <20000323130710.H24148@caerdonn.eurocontrol.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Ollivier Robert wrote:
> 
> .( Here ) cr
> 
> Will try, hope I'll be able to see them :)
> 
> Is there a way to do a "sleep 5" ?

5000 ms

Or, to wait for a keypress:

key

--
Daniel C. Sobral			(8-DCS)
dcs@newsguy.com
dcs@freebsd.org
capo@zurichgnomes.bsdconspiracy.net

	One Unix to rule them all, One Resolver to find them,
        One IP to bring them all and in the zone bind them.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 12:33: 1 2000
Delivered-To: freebsd-current@freebsd.org
Received: from milquetoast.cs.mcgill.ca (milquetoast.CS.McGill.CA [132.206.2.5])
	by hub.freebsd.org (Postfix) with ESMTP id 1AA6737BA0B
	for <freebsd-current@FreeBSD.ORG>; Thu, 23 Mar 2000 12:32:54 -0800 (PST)
	(envelope-from mat@milquetoast.cs.mcgill.ca)
Received: (from mat@localhost)
	by milquetoast.cs.mcgill.ca (8.9.3/8.9.3) id PAA03996;
	Thu, 23 Mar 2000 15:30:16 -0500 (EST)
Date: Thu, 23 Mar 2000 15:30:16 -0500
From: Mathew Kanner <mat@cs.mcgill.ca>
To: Greg Lehey <grog@lemis.com>
Cc: Soren Schmidt <sos@freebsd.dk>, freebsd-current@FreeBSD.ORG
Subject: Re: ata + vinum problems
Message-ID: <20000323153016.A29708@cs.mcgill.ca>
References: <20000314182259.I17156@cs.mcgill.ca> <200003150829.JAA22516@freebsd.dk> <20000315095930.A7309@cs.mcgill.ca> <20000315162903.A10174@cs.mcgill.ca> <20000315165410.A3663@mojave.worldwide.lemis.com> <20000315201301.A20777@cs.mcgill.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mutt 0.94.15i
In-Reply-To: Mathew Kanner's message [Re: ata + vinum problems] as of Wed, Mar 15, 2000 at 08:13:01PM -0500
Organization: SOCS, McGill University, Montreal, CANADA
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Mar 15, Mathew Kanner wrote:
> On Mar 15, Greg Lehey wrote:
> > attention yet, but I do see that your problem relates to soft
> > updates.  It's not clear that the soft updates themselves are a cause
> > of the problem, or just a facilitator, but it would be interesting to
> 	I did try it couple of days back with and without softupdates.
> Softupdates only made the problems appear more quickly but
> I've lost track of all the combinations that's I've tried so I=20
> should try one more time without.

	After some more time spent with the system.  It turns out it
is softupdates.  I can complete the script (which copies /usr/ports to
a newfs'ed system) without softupdates but with, it will stall and
then crash.  An interesting note, with softupdates, during a stall I
did a sysctl vfs.hidirtbuffers=3D500 and it completed, howver, if I do
this before running the script, it crashes as well (but doesn't take
nearly as long to do so).
	Included is a traceback of when it crashed witht he hibuffers
at 500.

	--Mat


Script started on Thu Mar 23 15:23:03 2000
bash-2.03# gdb -k
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain condition=
s.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd".
(kgdb) core=1B[Kexec-file kernel2.
kernel2.: No such file or directory.
(kgdb) ecx=08=08xec-file kernel.2
(kgdb) core=08=08=08=08su=08ymbol-file /usr/src/sys/compile/KZ=08AZE/kernel=
.debug
Reading symbols from /usr/src/sys/compile/KAZE/kernel.debug...done.
(kgdb) core-file vmcore.2
IdlePTD 4165632
initial pcb at 364ea0
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address	=3D 0x0
fault code		=3D supervisor read, page not present
instruction pointer	=3D 0x8:0xc026745a
stack pointer	        =3D 0x10:0xc03218e4
frame pointer	        =3D 0x10:0xc03218f0
code segment		=3D base 0x0, limit 0xfffff, type 0x1b
			=3D DPL 0, pres 1, def32 1, gran 1
processor eflags	=3D interrupt enabled, resume, IOPL =3D 0
current process		=3D Idle
interrupt mask		=3D bio=20
trap number		=3D 12
panic: page fault

syncing disks...=20

Fatal trap 12: page fault while in kernel mode
fault virtual address	=3D 0x30
fault code		=3D supervisor read, page not present
instruction pointer	=3D 0x8:0xc025e10c
stack pointer	        =3D 0x10:0xc032171c
frame pointer	        =3D 0x10:0xc0321720
code segment		=3D base 0x0, limit 0xfffff, type 0x1b
			=3D DPL 0, pres 1, def32 1, gran 1
processor eflags	=3D interrupt enabled, resume, IOPL =3D 0
current process		=3D Idle
interrupt mask		=3D bio=20
trap number		=3D 12
panic: page fault
Uptime: 6m53s

dumping to dev #ad/0x20001, offset 3047552
dump ata0: resetting devices .. done
511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495
494 493 492 491 490 489 488 487 486 485 484 483 482 481 480 479 478
477 476 475 474 473 472 471 470 469 468 467 466 465 464 463 462 461
460 459 458 457 456 455 454 453 452 451 450 449 448 447 446 445 444
443 442 441 440 439 438 437 436 435 434 433 432 431 430 429 428 427
426 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410
409 408 407 406 405 404 403 402 401 400 399 398 397 396 395 394 393
392 391 390 389 388 387 386 385 384 383 382 381 380 379 378 377 376
375 374 373 372 371 370 369 368 367 366 365 364 363 362 361 360 359
358 357 356 355 354 353 352 351 350 349 348 347 346 345 344 343 342
341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325
324 323 322 321 320 319 318 317 316 315 314 313 312 311 310 309 308
307 306 305 304 303 302 301 300 299 298 297 296 295 294 293 292 291
290 289 288 287 286 285 284 283 282 281 280 279 278 277 276 275 274
273 272 271 270 269 268 267 266 265 264 263 262 261 260 259 258 257
256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240
239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223
222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206
205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189
188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172
171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155
154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138
137 136 135 134 133 132 131 130 129 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=20
---
#0  0xc017f688 in boot ()
(kgdb) where
#0  0xc017f688 in boot ()
#1  0xc017fa0c in poweroff_wait ()
#2  0xc02ba969 in trap_fatal ()
#3  0xc02ba641 in trap_pfault ()
#4  0xc02ba237 in trap ()
#5  0xc025e10c in acquire_lock ()
#6  0xc026327c in softdep_count_dependencies ()
#7  0xc02663b0 in ffs_fsync ()
#8  0xc0264f5f in ffs_sync ()
#9  0xc01aac93 in sync ()
#10 0xc017f45b in boot ()
#11 0xc017fa0c in poweroff_wait ()
#12 0xc02ba969 in trap_fatal ()
#13 0xc02ba641 in trap_pfault ()
#14 0xc02ba237 in trap ()
#15 0xc026745a in bufqdisksort ()
#16 0xc0290c21 in adstrategy ()
#17 0xc0188779 in diskstrategy ()
#18 0xc274da58 in ?? ()
#19 0xc274d3ba in ?? ()
#20 0xc01a329f in biodone ()
#21 0xc02913f2 in ad_interrupt ()
#22 0xc028ddea in ata_intr ()
#23 0xc02ccfe1 in intr_mux ()
(kgdb) bash-2.03# exit

Script done on Thu Mar 23 15:23:36 2000


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 13: 4: 1 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id 2F8E037C5BA
	for <freebsd-current@FreeBSD.ORG>; Thu, 23 Mar 2000 13:03:57 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id NAA04161;
	Thu, 23 Mar 2000 13:03:44 -0800 (PST)
	(envelope-from dillon)
Date: Thu, 23 Mar 2000 13:03:44 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003232103.NAA04161@apollo.backplane.com>
To: Greg Lehey <grog@lemis.com>
Cc: Mathew Kanner <mat@cs.mcgill.ca>, Soren Schmidt <sos@freebsd.dk>,
	freebsd-current@FreeBSD.ORG
Subject: Re: ata + vinum problems
References: <20000314182259.I17156@cs.mcgill.ca> <200003150829.JAA22516@freebsd.dk> <20000315095930.A7309@cs.mcgill.ca> <20000315162903.A10174@cs.mcgill.ca> <20000315165410.A3663@mojave.worldwide.lemis.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

    Ok, this is NOT a softupdates *or* a vinum problem.

    This is a buffer cache problem.

    The problem is due to the large block size you are using when newfs'ing
    the filesystem coupled with problems in geteblk() which causes severe
    buffer cache KVM fragmentation.  Softupdates exasperates the geteblk()
    problem.

    I thought I had fixed this problem but apparently not.

    Try applying my buf-cleanup-3.diff patch from:

	http://www.backplane.com/FreeBSD4/

    Then go back to the configuration that was producing the problem before
    and see if it still occurs.

    Even with the above patch there is still a significant KVM fragmentation
    issue with large-block filesystems.  You can guarentee 100% success by
    hacking the BKVASIZE define in sys/sys/param.h (AFTER applying the patch)
    from 16384 to 32768, but I wouldn't raise it much beyond that.  This 
    patch is only a partial fix to the problem.

						-Matt


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 13:11:50 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id 23B1D37C6DE
	for <freebsd-current@FreeBSD.ORG>; Thu, 23 Mar 2000 13:10:25 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id NAA04208;
	Thu, 23 Mar 2000 13:10:21 -0800 (PST)
	(envelope-from dillon)
Date: Thu, 23 Mar 2000 13:10:21 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003232110.NAA04208@apollo.backplane.com>
To: Mathew Kanner <mat@cs.mcgill.ca>
Cc: Greg Lehey <grog@lemis.com>, Soren Schmidt <sos@freebsd.dk>,
	freebsd-current@FreeBSD.ORG
Subject: Re: ata + vinum problems
References: <20000314182259.I17156@cs.mcgill.ca> <200003150829.JAA22516@freebsd.dk> <20000315095930.A7309@cs.mcgill.ca> <20000315162903.A10174@cs.mcgill.ca> <20000315165410.A3663@mojave.worldwide.lemis.com> <20000315201301.A20777@cs.mcgill.ca> <20000323153016.A29708@cs.mcgill.ca>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

    Oh, addendum... I didn't see this email regarding an actual panic.

    There are two problems here, one of which (the nbufkv lockup) should
    be solved by my previous email.

    The second problem is this panic you are reporting, and I have no idea
    what is causing it so this issue remains open.  It could be softupdates,
    it could be vinum, or it could be the ATA driver.

    What you need to do to help solve the panic is to gdb a debug version
    of the kernel image rather then the non debug version so the stack
    backtrace contains source line numbers and such.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>

:	After some more time spent with the system.  It turns out it
:is softupdates.  I can complete the script (which copies /usr/ports to
:a newfs'ed system) without softupdates but with, it will stall and
:then crash.  An interesting note, with softupdates, during a stall I
:did a sysctl vfs.hidirtbuffers=500 and it completed, howver, if I do
:this before running the script, it crashes as well (but doesn't take
:nearly as long to do so).
:	Included is a traceback of when it crashed witht he hibuffers
:at 500.
:
:	--Mat
:
:Script started on Thu Mar 23 15:23:03 2000
:bash-2.03# gdb -k
:GNU gdb 4.18
:Copyright 1998 Free Software Foundation, Inc.
:GDB is free software, covered by the GNU General Public License, and you are
:welcome to change it and/or distribute copies of it under certain conditions.
:Type "show copying" to see the conditions.
:There is absolutely no warranty for GDB.  Type "show warranty" for details.
:This GDB was configured as "i386-unknown-freebsd".
:(kgdb) coreexec-file kernel2.
:kernel2.: No such file or directory.
:(kgdb) ecxxec-file kernel.2
:(kgdb) coresuymbol-file /usr/src/sys/compile/KZAZE/kernel.debug
:Reading symbols from /usr/src/sys/compile/KAZE/kernel.debug...done.
:(kgdb) core-file vmcore.2
:IdlePTD 4165632
:initial pcb at 364ea0
:panicstr: page fault
:panic messages:
:---
:Fatal trap 12: page fault while in kernel mode
:fault virtual address	= 0x0
:fault code		= supervisor read, page not present
:instruction pointer	= 0x8:0xc026745a
:stack pointer	        = 0x10:0xc03218e4
:frame pointer	        = 0x10:0xc03218f0
:code segment		= base 0x0, limit 0xfffff, type 0x1b
:			= DPL 0, pres 1, def32 1, gran 1
:processor eflags	= interrupt enabled, resume, IOPL = 0
:current process		= Idle
:interrupt mask		= bio 
:trap number		= 12
:panic: page fault
:
:syncing disks... 
:
:Fatal trap 12: page fault while in kernel mode
:fault virtual address	= 0x30
:fault code		= supervisor read, page not present
:instruction pointer	= 0x8:0xc025e10c
:stack pointer	        = 0x10:0xc032171c
:frame pointer	        = 0x10:0xc0321720
:code segment		= base 0x0, limit 0xfffff, type 0x1b
:			= DPL 0, pres 1, def32 1, gran 1
:processor eflags	= interrupt enabled, resume, IOPL = 0
:current process		= Idle
:interrupt mask		= bio 
:trap number		= 12
:panic: page fault
:Uptime: 6m53s
:
:dumping to dev #ad/0x20001, offset 3047552
:dump ata0: resetting devices .. done
:511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495
:494 493 492 491 490 489 488 487 486 485 484 483 482 481 480 479 478
:477 476 475 474 473 472 471 470 469 468 467 466 465 464 463 462 461
:460 459 458 457 456 455 454 453 452 451 450 449 448 447 446 445 444
:443 442 441 440 439 438 437 436 435 434 433 432 431 430 429 428 427
:426 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410
:409 408 407 406 405 404 403 402 401 400 399 398 397 396 395 394 393
:392 391 390 389 388 387 386 385 384 383 382 381 380 379 378 377 376
:375 374 373 372 371 370 369 368 367 366 365 364 363 362 361 360 359
:358 357 356 355 354 353 352 351 350 349 348 347 346 345 344 343 342
:341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325
:324 323 322 321 320 319 318 317 316 315 314 313 312 311 310 309 308
:307 306 305 304 303 302 301 300 299 298 297 296 295 294 293 292 291
:290 289 288 287 286 285 284 283 282 281 280 279 278 277 276 275 274
:273 272 271 270 269 268 267 266 265 264 263 262 261 260 259 258 257
:256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240
:239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223
:222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206
:205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189
:188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172
:171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155
:154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138
:137 136 135 134 133 132 131 130 129 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 
:---
:#0  0xc017f688 in boot ()
:(kgdb) where
:#0  0xc017f688 in boot ()
:#1  0xc017fa0c in poweroff_wait ()
:#2  0xc02ba969 in trap_fatal ()
:#3  0xc02ba641 in trap_pfault ()
:#4  0xc02ba237 in trap ()
:#5  0xc025e10c in acquire_lock ()
:#6  0xc026327c in softdep_count_dependencies ()
:#7  0xc02663b0 in ffs_fsync ()
:#8  0xc0264f5f in ffs_sync ()
:#9  0xc01aac93 in sync ()
:#10 0xc017f45b in boot ()
:#11 0xc017fa0c in poweroff_wait ()
:#12 0xc02ba969 in trap_fatal ()
:#13 0xc02ba641 in trap_pfault ()
:#14 0xc02ba237 in trap ()
:#15 0xc026745a in bufqdisksort ()
:#16 0xc0290c21 in adstrategy ()
:#17 0xc0188779 in diskstrategy ()
:#18 0xc274da58 in ?? ()
:#19 0xc274d3ba in ?? ()
:#20 0xc01a329f in biodone ()
:#21 0xc02913f2 in ad_interrupt ()
:#22 0xc028ddea in ata_intr ()
:#23 0xc02ccfe1 in intr_mux ()
:(kgdb) bash-2.03# exit
:
:Script done on Thu Mar 23 15:23:36 2000


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 13:30:46 2000
Delivered-To: freebsd-current@freebsd.org
Received: from roam.psg.com (roam.psg.com [147.28.4.2])
	by hub.freebsd.org (Postfix) with ESMTP id 9F40637B50E
	for <freebsd-current@freebsd.org>; Thu, 23 Mar 2000 13:30:37 -0800 (PST)
	(envelope-from randy@psg.com)
Received: from randy by roam.psg.com with local (Exim 3.12 #1)
	id 12YF7H-00009F-00
	for freebsd-current@freebsd.org; Fri, 24 Mar 2000 06:26:07 +0900
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: FreeBSD Current <freebsd-current@freebsd.org>
Subject: ppp oddity
Message-Id: <E12YF7H-00009F-00@roam.psg.com>
Date: Fri, 24 Mar 2000 06:26:07 +0900
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

usually ppp from laptop (3.4+pao) to home (4.0-stable) works fine.  and then
sometimes it will get stuck in the following mode three N in a row.

ppp[547]: tun0: Chat: Send: AT^M 
ppp[547]: tun0: Chat: Expect(5): OK 
ppp[547]: tun0: Chat: Received: AT^M^M 
ppp[547]: tun0: Chat: Received: OK^M 
ppp[547]: tun0: Chat: Send: ATE1Q0x1s7=90s11=180^M 
ppp[547]: tun0: Chat: Expect(5): OK 
ppp[547]: tun0: Chat: Received: ATE1Q0x1s7=90s11=180^M^M 
ppp[547]: tun0: Chat: Received: OK^M 
ppp[547]: tun0: Chat: Send: ATDT666-555-1212^M 
ppp[547]: tun0: Chat: Expect(120): CONNECT 
ppp[547]: tun0: Chat: Received: ATDT666-555-1212^M^M 
ppp[547]: tun0: Chat: Received: CONNECT 57600^M 
ppp[547]: tun0: Phase: deflink: dial -> carrier 
ppp[547]: tun0: Phase: deflink: /dev/cuaa1: CD detected 
ppp[547]: tun0: Phase: deflink: carrier -> login 
ppp[547]: tun0: Chat: Expect(5): ogin: 
ppp[547]: tun0: Chat: Received: ^M^M 
ppp[547]: tun0: Chat: Received: FreeBSD/i386 (doo.com) (ttyd1)^M^M 
ppp[547]: tun0: Chat: Received: ^M^M 
ppp[547]: tun0: Chat: Received: login: 
ppp[547]: tun0: Chat: Send: roamP^M 
ppp[547]: tun0: Chat: Expect(5): word: 
ppp[547]: tun0: Chat: Received:  ~upyour^M 
ppp[547]: tun0: Chat: Received: Password: 
ppp[547]: tun0: Chat: Send: wazoo^M 
ppp[547]: tun0: Phase: deflink: login -> lcp 
ppp[547]: tun0: LCP: FSM: Using "deflink" as a transport 
ppp[547]: tun0: LCP: deflink: State change Initial --> Closed 
ppp[547]: tun0: LCP: deflink: State change Closed --> Stopped 
ppp[547]: tun0: LCP: deflink: LayerStart 
ppp[547]: tun0: LCP: deflink: SendConfigReq(1) state = Stopped 
ppp[547]: tun0: LCP:  ACFCOMP[2] 
ppp[547]: tun0: LCP:  PROTOCOMP[2] 
ppp[547]: tun0: LCP:  ACCMAP[6] 0x00000000 
ppp[547]: tun0: LCP:  MRU[4] 1500 
ppp[547]: tun0: LCP:  MAGICNUM[6] 0x2c18b501 
ppp[547]: tun0: LCP: deflink: State change Stopped --> Req-Sent 
ppp[547]: tun0: LCP: deflink: RecvConfigReq(1) state = Req-Sent 
ppp[547]: tun0: LCP:  ACFCOMP[2] 
ppp[547]: tun0: LCP:  PROTOCOMP[2] 
ppp[547]: tun0: LCP:  ACCMAP[6] 0x00000000 
ppp[547]: tun0: LCP:  MRU[4] 1500 
ppp[547]: tun0: LCP:  MAGICNUM[6] 0x2c18b501 
ppp[547]: tun0: LCP: Magic is same (2c18b501) - 1 times 
ppp[547]: tun0: LCP: deflink: SendConfigNak(1) state = Req-Sent 
ppp[547]: tun0: LCP:  MAGICNUM[6] 0x2c18b501 
ppp[547]: tun0: LCP: deflink: RecvConfigNak(1) state = Req-Sent 
ppp[547]: tun0: LCP:  MAGICNUM[6] 0x2c18b501 
ppp[547]: tun0: LCP:  Magic 0x2c18b501 is NAKed! 
ppp[547]: tun0: LCP: deflink: SendConfigReq(2) state = Req-Sent 
ppp[547]: tun0: LCP:  ACFCOMP[2] 
ppp[547]: tun0: LCP:  PROTOCOMP[2] 
ppp[547]: tun0: LCP:  ACCMAP[6] 0x00000000 
ppp[547]: tun0: LCP:  MRU[4] 1500 
ppp[547]: tun0: LCP:  MAGICNUM[6] 0x42093812 
ppp[547]: tun0: LCP: deflink: RecvConfigReq(2) state = Req-Sent 
ppp[547]: tun0: LCP:  ACFCOMP[2] 
ppp[547]: tun0: LCP:  PROTOCOMP[2] 
ppp[547]: tun0: LCP:  ACCMAP[6] 0x00000000 
ppp[547]: tun0: LCP:  MRU[4] 1500 
ppp[547]: tun0: LCP:  MAGICNUM[6] 0x42093812 
ppp[547]: tun0: LCP: Magic is same (42093812) - 2 times 
ppp[547]: tun0: LCP: deflink: SendConfigNak(2) state = Req-Sent 
ppp[547]: tun0: LCP:  MAGICNUM[6] 0x42093812 
ppp[547]: tun0: LCP: deflink: RecvConfigNak(2) state = Req-Sent 
ppp[547]: tun0: LCP:  MAGICNUM[6] 0x42093812 
ppp[547]: tun0: LCP:  Magic 0x42093812 is NAKed! 
ppp[547]: tun0: LCP: deflink: SendConfigReq(3) state = Req-Sent 
ppp[547]: tun0: LCP:  ACFCOMP[2] 
ppp[547]: tun0: LCP:  PROTOCOMP[2] 
ppp[547]: tun0: LCP:  ACCMAP[6] 0x00000000 
ppp[547]: tun0: LCP:  MRU[4] 1500 
ppp[547]: tun0: LCP:  MAGICNUM[6] 0x30625651 

clues?

randy


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 13:32:50 2000
Delivered-To: freebsd-current@freebsd.org
Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20])
	by hub.freebsd.org (Postfix) with ESMTP id 60D8F37C55D
	for <freebsd-current@FreeBSD.ORG>; Thu, 23 Mar 2000 13:32:34 -0800 (PST)
	(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
	by fw.wintelcom.net (8.10.0/8.10.0) id e2NLu3024299;
	Thu, 23 Mar 2000 13:56:03 -0800 (PST)
Date: Thu, 23 Mar 2000 13:56:03 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: mw@kpnqwest.ch
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: AMI MegaRAID lockup? not accepting commands.
Message-ID: <20000323135603.D21029@fw.wintelcom.net>
References: <200003231940.TAA24686@mail.kpnqwest.ch>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200003231940.TAA24686@mail.kpnqwest.ch>; from mw@kpnqwest.ch on Thu, Mar 23, 2000 at 08:40:27PM +0100
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

* mw@kpnqwest.ch <mw@kpnqwest.ch> [000323 12:47] wrote:
> I've played around changing the spinloop to using DELAY (like the Linux model),
> but this didn't prevent the controller from either "just" locking up or 
> crashing the whole machine with it. Changing various other places in a similar
> manner (like replacing the bcopy() in amr_quartz_get_work() with similar
> code as in the linux driver to wait for 0xFF to clear) didn't do the trick
> either. 
> 
> However, when I forced the driver to not use the full number of
> concurrent commands as returned by the firmware, I seem to finally have 
> found the one change that made the difference. Looking at the linux
> code, it sets a hard limit of AMR_MAXCMD (MAX_COMMANDS in the linux code) of
> 127 (my controller, a 466, returned 254), and it says the value can be tweaked
> between 0 and 253, not 254...). So, forcing sc->amr_maxio to AMR_MAXCMD if
> that one's smaller, in amr_query_controller(), might cause some performance
> loss, but it made the code *significantly* stabler than before. I did two
> make world on the raid now, and not one hickup. Before I wasn't even able to
> copy over the system to the raid without sending the system to reboot. 
> 
> Possible explanation: people that introduced debugging statements slowed down
> the feeding of new commands to the controller, so the controller didn't ever
> use up the full set of concurrent commands. The lockup happens when too many
> concurrent commands are open (now, I haven't tried setting things to 253, I
> am glad things finally work:-)).

dude, you rule!  I'm glad this looks like it's finally resolved, can
you let me know if it survives further stress testing?

I've found the easiest way to wedge the box is to perform a 'cvs up'
(not cvsup) from a local repository over /usr/src or /usr/ports, this
would always lockup my box with amr, if you have the time and disk
space that would be a much better stressor than just make world.

thanks,
-Alfred

> 
> Hope this helps,
> Markus
> -- 
> KPNQwest Switzerland Ltd
> P.O. Box 9470, Zweierstrasse 35, CH-8036 Zuerich
> Tel: +41-1-298-6030, Fax: +41-1-291-4642
> Markus Wild, Manager Engineering, e-mail: markus.wild@kpnqwest.ch

Content-Description: mydiff.short
> Index: amr.c
> ===================================================================
> RCS file: /home/ncvs/src/sys/dev/amr/amr.c,v
> retrieving revision 1.8
> diff -c -r1.8 amr.c
> *** amr.c	2000/03/20 10:44:03	1.8
> --- amr.c	2000/03/23 19:20:03
> ***************
> *** 699,704 ****
> --- 702,712 ----
>   	}
>   	sc->amr_maxdrives = 8;
>   	sc->amr_maxio = ae->ae_adapter.aa_maxio;
> + 	if (sc->amr_maxio > AMR_MAXCMD) {
> + 	  device_printf(sc->amr_dev, "reducing maxio from %d to %d\n", 
> + 			sc->amr_maxio, AMR_MAXCMD);
> + 	  sc->amr_maxio = AMR_MAXCMD;
> + 	}
>   	for (i = 0; i < ae->ae_ldrv.al_numdrives; i++) {
>   	    sc->amr_drive[i].al_size = ae->ae_ldrv.al_size[i];
>   	    sc->amr_drive[i].al_state = ae->ae_ldrv.al_state[i];
> ***************
> *** 853,859 ****
>   	ac->ac_private = bp;
>   	ac->ac_data = bp->b_data;
>   	ac->ac_length = bp->b_bcount;
> ! 	if (bp->b_iocmd == BIO_READ) {
>   	    ac->ac_flags |= AMR_CMD_DATAIN;
>   	    cmd = AMR_CMD_LREAD;
>   	} else {
> --- 861,868 ----
>   	ac->ac_private = bp;
>   	ac->ac_data = bp->b_data;
>   	ac->ac_length = bp->b_bcount;
> ! /*	if (bp->b_iocmd == BIO_READ) { */
> ! 	if (bp->b_flags & B_READ) {
>   	    ac->ac_flags |= AMR_CMD_DATAIN;
>   	    cmd = AMR_CMD_LREAD;
>   	} else {
> Index: amrvar.h
> ===================================================================
> RCS file: /home/ncvs/src/sys/dev/amr/amrvar.h,v
> retrieving revision 1.2
> diff -c -r1.2 amrvar.h
> *** amrvar.h	1999/10/26 23:18:57	1.2
> --- amrvar.h	2000/03/23 19:20:04
> ***************
> *** 37,43 ****
>   #define AMR_CFG_SIG	0xa0
>   #define AMR_SIGNATURE	0x3344
>   
> ! #define AMR_MAXCMD	255		/* ident = 0 not allowed */
>   #define AMR_MAXLD      	40
>   
>   #define AMR_BLKSIZE	512
> --- 37,44 ----
>   #define AMR_CFG_SIG	0xa0
>   #define AMR_SIGNATURE	0x3344
>   
> ! /*#define AMR_MAXCMD	255*/		/* ident = 0 not allowed */
> ! #define AMR_MAXCMD	127		/* ident = 0 not allowed */
>   #define AMR_MAXLD      	40
>   
>   #define AMR_BLKSIZE	512


-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 13:48:12 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mass.cdrom.com (mg-20425418-10.ricochet.net [204.254.18.10])
	by hub.freebsd.org (Postfix) with ESMTP id C305F37BB2B
	for <freebsd-current@freebsd.org>; Thu, 23 Mar 2000 13:47:56 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Received: from mass.cdrom.com (localhost [127.0.0.1])
	by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id NAA02123;
	Thu, 23 Mar 2000 13:50:29 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Message-Id: <200003232150.NAA02123@mass.cdrom.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To: mw@kpnqwest.ch
Cc: freebsd-current@freebsd.org
Subject: Re: AMI MegaRAID lockup? not accepting commands. 
In-reply-to: Your message of "Thu, 23 Mar 2000 20:40:27 +0100."
             <200003231940.TAA24686@mail.kpnqwest.ch> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 23 Mar 2000 13:50:28 -0800
From: Mike Smith <msmith@freebsd.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> I've played around changing the spinloop to using DELAY (like the Linux model),
> but this didn't prevent the controller from either "just" locking up or 
> crashing the whole machine with it. Changing various other places in a similar
> manner (like replacing the bcopy() in amr_quartz_get_work() with similar
> code as in the linux driver to wait for 0xFF to clear) didn't do the trick
> either. 

Can you try instead the changes that I just committed to -current?  I 
think that the problem shows up when the controller is heavily loaded; 
your patch will keep the load on the controller down, which may mask the 
'real' bug.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
\\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 13:57:26 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mail.kpnqwest.ch (mail.eunet.ch [146.228.10.7])
	by hub.freebsd.org (Postfix) with ESMTP id 2457137C771
	for <freebsd-current@FreeBSD.ORG>; Thu, 23 Mar 2000 13:57:14 -0800 (PST)
	(envelope-from mw@kpnqwest.ch)
Received: (from mw@localhost) by mail.kpnqwest.ch (8.9.3/1.34) id VAA20551; Thu, 23 Mar 2000 21:57:02 GMT
	env-from (mw@kpnqwest.ch)
From: mw@kpnqwest.ch
Message-Id: <200003232157.VAA20551@mail.kpnqwest.ch>
Subject: Re: AMI MegaRAID lockup? not accepting commands.
In-Reply-To: <20000323135603.D21029@fw.wintelcom.net> from Alfred Perlstein at
 "Mar 23, 2000 01:56:03 pm"
To: Alfred Perlstein <bright@wintelcom.net>
Date: Thu, 23 Mar 2000 22:57:02 +0100 (CET)
Cc: mw@kpnqwest.ch, freebsd-current@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL72 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> I've found the easiest way to wedge the box is to perform a 'cvs up'
> (not cvsup) from a local repository over /usr/src or /usr/ports, this
> would always lockup my box with amr, if you have the time and disk
> space that would be a much better stressor than just make world.

I have done a cvs update on the whole root tree, well, the repository was 
the default (certainly not local, but I'd say I have fairly decent 
connectivity, and there was quite some stress on the drive).

I had also done something that should be comparable. I had the initial system
on a disk on my Adaptec controller, and as the first stress test I copied over
the whole system (~13GB) with dump | restore to the raid (so, /usr/src and
/usr/ports were included there). And, I just unpacked X11R6.4 sources, which
also caused quite a bit of stress. Still running :)

Might have to add I've enabled softdeps on all partitions, this could change
the usage pattern slightly (don't know whether to the better or worse regarding
crash likelyhood).

About my source tree: I tried some other changes before, and some of them are 
still in my sources (and were not in the included diff). Since those changes 
by themselves didn't make a difference, I didn't include them. However, if 
someone should still get crashes with just the minimal diffs, I can include 
the complete diffs to fully reproduce my sources.

Markus
-- 
KPNQwest Switzerland Ltd
P.O. Box 9470, Zweierstrasse 35, CH-8036 Zuerich
Tel: +41-1-298-6030, Fax: +41-1-291-4642
Markus Wild, Manager Engineering, e-mail: markus.wild@kpnqwest.ch


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 14: 7: 1 2000
Delivered-To: freebsd-current@freebsd.org
Received: from rover.village.org (rover.village.org [204.144.255.49])
	by hub.freebsd.org (Postfix) with ESMTP id A537837C6DD
	for <current@FreeBSD.ORG>; Thu, 23 Mar 2000 14:06:54 -0800 (PST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (harmony.village.org [10.0.0.6])
	by rover.village.org (8.9.3/8.9.3) with ESMTP id PAA36021;
	Thu, 23 Mar 2000 15:06:50 -0700 (MST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id PAA44154; Thu, 23 Mar 2000 15:06:45 -0700 (MST)
Message-Id: <200003232206.PAA44154@harmony.village.org>
To: Brian Beattie <beattie@aracnet.com>
Subject: Re: 4.0-RELEASE boot.flp fails to boot on K6/2 
Cc: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>, current@FreeBSD.ORG
In-reply-to: Your message of "Wed, 22 Mar 2000 14:19:52 PST."
		<Pine.LNX.4.21.0003221418550.31899-100000@shell1.aracnet.com> 
References: <Pine.LNX.4.21.0003221418550.31899-100000@shell1.aracnet.com>  
Date: Thu, 23 Mar 2000 15:06:45 -0700
From: Warner Losh <imp@village.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <Pine.LNX.4.21.0003221418550.31899-100000@shell1.aracnet.com> Brian Beattie writes:
: > Winner!  Much better than my personal favorite of bigbooty.flp.  :-)
: > 
: > - Jordan
: >
: 
: Then that would make the CD LordWarfen.iso?

I had the chance to register john.net way back when.  I was going to
name the machines warfen.john.net, bigbootee.john.net,
smallberries.john.net, etc.  I kinda wish I had because now it is too
late :-(

Warner


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 14: 8:56 2000
Delivered-To: freebsd-current@freebsd.org
Received: from rover.village.org (rover.village.org [204.144.255.49])
	by hub.freebsd.org (Postfix) with ESMTP id 8E9F437C75E
	for <freebsd-current@FreeBSD.ORG>; Thu, 23 Mar 2000 14:08:46 -0800 (PST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (harmony.village.org [10.0.0.6])
	by rover.village.org (8.9.3/8.9.3) with ESMTP id PAA36034;
	Thu, 23 Mar 2000 15:08:43 -0700 (MST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id PAA44181; Thu, 23 Mar 2000 15:08:38 -0700 (MST)
Message-Id: <200003232208.PAA44181@harmony.village.org>
To: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>
Subject: Re: -current sudden panics :( 
Cc: ilmar@ints.ru, nms@otdel-1.org, freebsd-current@FreeBSD.ORG
In-reply-to: Your message of "Thu, 23 Mar 2000 10:50:25 +0900."
		<20000323105025W.shin@nd.net.fujitsu.co.jp> 
References: <20000323105025W.shin@nd.net.fujitsu.co.jp>  <Pine.BSF.4.21.0003220813250.220-100000@ws-ilmar.ints.ru> <200003222201.PAA33948@harmony.village.org> 
Date: Thu, 23 Mar 2000 15:08:38 -0700
From: Warner Losh <imp@village.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <20000323105025W.shin@nd.net.fujitsu.co.jp> Yoshinobu Inoue writes:
: I would like to narrow down the problem more and could you
: please try if this patch stop the problem or not?
: (The m_pullup() is recently added to if_rl.c. It should not be
: harmful, but I suspect that this might have invoked another
: hidden bug.)

This survived overnight.  I see that Matt Dillon has another patch,
I'll try that tonight.

Warner


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 14: 9:38 2000
Delivered-To: freebsd-current@freebsd.org
Received: from milquetoast.cs.mcgill.ca (milquetoast.CS.McGill.CA [132.206.2.5])
	by hub.freebsd.org (Postfix) with ESMTP id 03BF137C7EA
	for <freebsd-current@FreeBSD.ORG>; Thu, 23 Mar 2000 14:09:09 -0800 (PST)
	(envelope-from mat@milquetoast.cs.mcgill.ca)
Received: (from mat@localhost)
	by milquetoast.cs.mcgill.ca (8.9.3/8.9.3) id RAA06997;
	Thu, 23 Mar 2000 17:08:23 -0500 (EST)
Date: Thu, 23 Mar 2000 17:08:23 -0500
From: Mathew Kanner <mat@cs.mcgill.ca>
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: Greg Lehey <grog@lemis.com>, Soren Schmidt <sos@freebsd.dk>,
	freebsd-current@FreeBSD.ORG
Subject: Re: ata + vinum problems
Message-ID: <20000323170822.A5061@cs.mcgill.ca>
References: <20000314182259.I17156@cs.mcgill.ca> <200003150829.JAA22516@freebsd.dk> <20000315095930.A7309@cs.mcgill.ca> <20000315162903.A10174@cs.mcgill.ca> <20000315165410.A3663@mojave.worldwide.lemis.com> <20000315201301.A20777@cs.mcgill.ca> <20000323153016.A29708@cs.mcgill.ca> <200003232110.NAA04208@apollo.backplane.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mutt 0.94.15i
In-Reply-To: Matthew Dillon's message [Re: ata + vinum problems] as of Thu, Mar 23, 2000 at 01:10:21PM -0800
Organization: SOCS, McGill University, Montreal, CANADA
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Mar 23, Matthew Dillon wrote:
>     Oh, addendum... I didn't see this email regarding an actual panic.
>=20
>     There are two problems here, one of which (the nbufkv lockup) should
>     be solved by my previous email.
>=20
>     The second problem is this panic you are reporting, and I have no idea
>     what is causing it so this issue remains open.  It could be softupdat=
es,
>     it could be vinum, or it could be the ATA driver.
>=20
>     What you need to do to help solve the panic is to gdb a debug version
>     of the kernel image rather then the non debug version so the stack
>     backtrace contains source line numbers and such.
>=20
> 					-Matt
> 					Matthew Dillon=20
> 					<dillon@backplane.com>

	Included is a better backtrace.  This does not include the
patch that you suggested, I will do that tommorow.

	Thanks,
	--Mat


Script started on Thu Mar 23 17:07:47 2000
bash-2.03# gdk=08 =08b -k
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain condition=
s.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd".
(kgdb) exec-file v=08 =08kernel.3
(kgdb) c=08 =08symbol-file /usr/sr/=08 =08c/sys/compile/KAZE/kernel.debug
Reading symbols from /usr/src/sys/compile/KAZE/kernel.debug...done.
(kgdb) core-file vmcore.3
IdlePTD 4157440
initial pcb at 364ec0
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address	=3D 0x2c
fault code		=3D supervisor read, page not present
instruction pointer	=3D 0x8:0xc0175f96
stack pointer	        =3D 0x10:0xc0321948
frame pointer	        =3D 0x10:0xc0321948
code segment		=3D base 0x0, limit 0xfffff, type 0x1b
			=3D DPL 0, pres 1, def32 1, gran 1
processor eflags	=3D interrupt enabled, resume, IOPL =3D 0
current process		=3D Idle
interrupt mask		=3D bio=20
trap number		=3D 12
panic: page fault

syncing disks...=20

Fatal trap 12: page fault while in kernel mode
fault virtual address	=3D 0x30
fault code		=3D supervisor read, page not present
instruction pointer	=3D 0x8:0xc025e120
stack pointer	        =3D 0x10:0xc0321780
frame pointer	        =3D 0x10:0xc0321784
code segment		=3D base 0x0, limit 0xfffff, type 0x1b
			=3D DPL 0, pres 1, def32 1, gran 1
processor eflags	=3D interrupt enabled, resume, IOPL =3D 0
current process		=3D Idle
interrupt mask		=3D bio=20
trap number		=3D 12
panic: page fault
Uptime: 5m27s

dumping to dev #ad/0x20001, offset 3047552
dump ata0: resetting devices .. done
511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493=
 492
491 490 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 473=
 472
471 470 469 468 467 466 465 464 463 462 461 460 459 458 457 456 455 454 453=
 452
451 450 449 448 447 446 445 444 443 442 441 440 439 438 437 436 435 434 433=
 432
431 430 429 428 427 426 425 424 423 422 421 420 419 418 417 416 415 414 413=
 412
411 410 409 408 407 406 405 404 403 402 401 400 399 398 397 396 395 394 393=
 392
391 390 389 388 387 386 385 384 383 382 381 380 379 378 377 376 375 374 373=
 372
371 370 369 368 367 366 365 364 363 362 361 360 359 358 357 356 355 354 353=
 352
351 350 349 348 347 346 345 344 343 342 341 340 339 338 337 336 335 334 333=
 332
331 330 329 328 327 326 325 324 323 322 321 320 319 318 317 316 315 314 313=
 312
311 310 309 308 307 306 305 304 303 302 301 300 299 298 297 296 295 294 293=
 292
291 290 289 288 287 286 285 284 283 282 281 280 279 278 277 276 275 274 273=
 272
271 270 269 268 267 266 265 264 263 262 261 260 259 258 257 256 255 254 253=
 252
251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233=
 232
231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213=
 212
211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193=
 192
191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173=
 172
171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153=
 152
151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133=
 132
131 130 129 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=20
---
#0  boot (howto=3D260) at ../../kern/kern_shutdown.c:304
304			dumppcb.pcb_cr3 =3D rcr3();
(kgdb) where
#0  boot (howto=3D260) at ../../kern/kern_shutdown.c:304
#1  0xc017fa18 in poweroff_wait (junk=3D0xc0317dcf, howto=3D0)
    at ../../kern/kern_shutdown.c:554
#2  0xc02ba969 in trap_fatal (frame=3D0xc0321740, eva=3D48)
    at ../../i386/i386/trap.c:924
#3  0xc02ba641 in trap_pfault (frame=3D0xc0321740, usermode=3D0, eva=3D48)
    at ../../i386/i386/trap.c:817
#4  0xc02ba237 in trap (frame=3D{tf_fs =3D -1070465008, tf_es =3D -10722344=
80,=20
      tf_ds =3D -1028718576, tf_edi =3D 0, tf_esi =3D 0, tf_ebp =3D -107045=
9004,=20
      tf_isp =3D -1070459028, tf_ebx =3D -1070357604, tf_edx =3D 1074283584=
,=20
      tf_ecx =3D -1030721521, tf_eax =3D 0, tf_trapno =3D 12, tf_err =3D 0,=
=20
      tf_eip =3D -1071259360, tf_cs =3D 8, tf_eflags =3D 66050, tf_esp =3D =
-856665792,=20
      tf_ss =3D -1070458980}) at ../../i386/i386/trap.c:423
#5  0xc025e120 in acquire_lock (lk=3D0xc033a39c)
    at ../../ufs/ffs/ffs_softdep.c:282
#6  0xc0263290 in softdep_count_dependencies (bp=3D0xccf05140, wantcount=3D=
0)
    at ../../ufs/ffs/ffs_softdep.c:4535
#7  0xc02663c4 in ffs_fsync (ap=3D0xc03217f8) at ../../ufs/ffs/ffs_vnops.c:=
168
#8  0xc0264f73 in ffs_sync (mp=3D0xc2815400, waitfor=3D2, cred=3D0xc10c5900=
,=20
    p=3D0xc037c540) at vnode_if.h:537
#9  0xc01aac8f in sync (p=3D0xc037c540, uap=3D0x0) at ../../kern/vfs_syscal=
ls.c:549
#10 0xc017f467 in boot (howto=3D256) at ../../kern/kern_shutdown.c:226
#11 0xc017fa18 in poweroff_wait (junk=3D0xc0317dcf, howto=3D0)
    at ../../kern/kern_shutdown.c:554
---Type <return> to continue, or q <return> to quit---
#12 0xc02ba969 in trap_fatal (frame=3D0xc0321908, eva=3D44)
    at ../../i386/i386/trap.c:924
#13 0xc02ba641 in trap_pfault (frame=3D0xc0321908, usermode=3D0, eva=3D44)
    at ../../i386/i386/trap.c:817
#14 0xc02ba237 in trap (frame=3D{tf_fs =3D -1030815728, tf_es =3D -10710548=
32,=20
      tf_ds =3D 1074266128, tf_edi =3D -825171968, tf_esi =3D -1030754304,=
=20
      tf_ebp =3D -1070458552, tf_isp =3D -1070458572, tf_ebx =3D -103075427=
2,=20
      tf_edx =3D 23, tf_ecx =3D 0, tf_eax =3D 0, tf_trapno =3D 12, tf_err =
=3D 0,=20
      tf_eip =3D -1072210026, tf_cs =3D 8, tf_eflags =3D 66118,=20
      tf_esp =3D -1070458496, tf_ss =3D -1032529027}) at ../../i386/i386/tr=
ap.c:423
#15 0xc0175f96 in devsw (dev=3D0x0) at ../../kern/kern_conf.c:79
#16 0xc274db7d in ?? ()
#17 0xc274d3ba in ?? ()
#18 0xc01a329b in biodone (bp=3D0xc28ff020) at ../../kern/vfs_bio.c:2697
#19 0xc02913ee in ad_interrupt (request=3D0xc2abf240)
    at ../../dev/ata/ata-disk.c:555
#20 0xc028dde6 in ata_intr (data=3D0xc261f380) at ../../dev/ata/ata-all.c:1=
122
#21 0xc02ccfe1 in intr_mux (arg=3D0xc10be820)
    at ../../i386/isa/intr_machdep.c:569
(kgdb) quit
bash-2.03# exit

Script done on Thu Mar 23 17:08:23 2000


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 14: 9:59 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mail.kpnqwest.ch (mail.eunet.ch [146.228.10.7])
	by hub.freebsd.org (Postfix) with ESMTP id 859EF37C701
	for <freebsd-current@freebsd.org>; Thu, 23 Mar 2000 14:09:52 -0800 (PST)
	(envelope-from mw@kpnqwest.ch)
Received: (from mw@localhost) by mail.kpnqwest.ch (8.9.3/1.34) id WAA22966
	for freebsd-current@freebsd.org; Thu, 23 Mar 2000 22:09:49 GMT
	env-from (mw@kpnqwest.ch)
From: mw@kpnqwest.ch
Message-Id: <200003232209.WAA22966@mail.kpnqwest.ch>
Subject: Re: AMI MegaRAID lockup? not accepting commands.
In-Reply-To: <200003232150.NAA02123@mass.cdrom.com> from Mike Smith at "Mar 23,
	2000 01:50:28 pm"
To: Mike Smith <msmith@freebsd.org>
Date: Thu, 23 Mar 2000 23:09:03 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL72 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> Can you try instead the changes that I just committed to -current?  I 
> think that the problem shows up when the controller is heavily loaded; 
> your patch will keep the load on the controller down, which may mask the 
> 'real' bug.

I tried your approach (that was what I described with "fiddling with DELAY").
I even went even further to clear that loop, but it didn't help. This is 
what I currently still have in there from these experiments:

/* from linux: The "volatile" is due to gcc bugs */
#define barrier() __asm__ __volatile__("": : :"memory")

for (i = 10000, done = 0, worked = 0; (i > 0) && !done; i--) {
        s = splbio();

        /* is the mailbox free? */
        if (sc->amr_mailbox->mb_busy == 0) {
            debug("got mailbox");
            sc->amr_mailbox64->mb64_segment = 0;
            bcopy(&ac->ac_mailbox, sc->amr_mailbox, AMR_MBOX_CMDSIZE);
            sc->amr_submit_command(sc);
            done = 1;
            sc->amr_workcount++;
            TAILQ_INSERT_TAIL(&sc->amr_work, ac, ac_link);

            /* not free, try to clean up while we wait */
        } else {
            debug("busy flag %x\n", sc->amr_mailbox->mb_busy);
            /* don't do this in here for now, it involves talking to the
             * controller to see whether there's work done, and since we
             * just saw that the controller is somewhat busy, that's perhaps
             * not such a good idea? */
            /* worked += amr_done(sc); */
        }
        splx(s);

        DELAY(100);
        barrier();
    }

    /* check here for work to be done */
    s = splbio();
    worked += amr_done(sc);
    splx(s);


This did *NOT* stop the controller from crashing. Ignore the comment above,
I'll take this amr_done call back up, but I just wanted to REALLY be sure
this loop wasn't the cause for the crash.

Markus
-- 
KPNQwest Switzerland Ltd
P.O. Box 9470, Zweierstrasse 35, CH-8036 Zuerich
Tel: +41-1-298-6030, Fax: +41-1-291-4642
Markus Wild, Manager Engineering, e-mail: markus.wild@kpnqwest.ch



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 14:13:32 2000
Delivered-To: freebsd-current@freebsd.org
Received: from rover.village.org (rover.village.org [204.144.255.49])
	by hub.freebsd.org (Postfix) with ESMTP id 21C9637C81A
	for <freebsd-current@FreeBSD.ORG>; Thu, 23 Mar 2000 14:13:19 -0800 (PST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (harmony.village.org [10.0.0.6])
	by rover.village.org (8.9.3/8.9.3) with ESMTP id PAA36065;
	Thu, 23 Mar 2000 15:13:10 -0700 (MST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id PAA44243; Thu, 23 Mar 2000 15:13:06 -0700 (MST)
Message-Id: <200003232213.PAA44243@harmony.village.org>
To: mjacob@feral.com
Subject: Re: -current PCVT breakage? 
Cc: Hellmuth Michaelis <hm@hcs.de>, freebsd-current@FreeBSD.ORG
In-reply-to: Your message of "Thu, 23 Mar 2000 09:01:18 PST."
		<Pine.BSF.4.10.10003230900480.11902-100000@beppo.feral.com> 
References: <Pine.BSF.4.10.10003230900480.11902-100000@beppo.feral.com>  
Date: Thu, 23 Mar 2000 15:13:06 -0700
From: Warner Losh <imp@village.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <Pine.BSF.4.10.10003230900480.11902-100000@beppo.feral.com> Matthew Jacob writes:
: I'm an idiot - I should have paid closer attention to some other commits.

And the UPDATING file too :-)

Warner


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 14:46:58 2000
Delivered-To: freebsd-current@freebsd.org
Received: from Stalker.Alfacom.net (Stalker.Alfacom.net [62.244.36.7])
	by hub.freebsd.org (Postfix) with ESMTP id E913637BE96
	for <current@FreeBSD.ORG>; Thu, 23 Mar 2000 14:45:58 -0800 (PST)
	(envelope-from vkushnir@Alfacom.net)
Received: from kushnir1.kiev.ua (dup-95.alfacom.net [62.244.36.95])
	by Stalker.Alfacom.net (8.9.0/8.9.0) with ESMTP id AAA25695;
	Fri, 24 Mar 2000 00:45:36 +0200 (EET)
Received: from localhost (volodya@localhost)
	by kushnir1.kiev.ua (8.9.3/8.9.3) with ESMTP id AAA12435;
	Fri, 24 Mar 2000 00:45:29 +0200 (EET)
	(envelope-from volodya@kushnir1.kiev.ua)
Date: Fri, 24 Mar 2000 00:45:28 +0200 (EET)
From: Vladimir Kushnir <vkushnir@Alfacom.net>
To: Eric Jacoboni <jaco@titine.fr.eu.org>
Cc: current@FreeBSD.ORG
Subject: Re: Fatal trap 12 in 5.0-C
In-Reply-To: <877letzitb.fsf@alex.titine.fr.eu.org>
Message-ID: <Pine.BSF.4.21.0003240036500.11521-100000@kushnir1.kiev.ua>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Yes, same here, and it looks like it's after the last ATAPI commit (worked
perfectly before that, Delta 44x ATAPI CD-ROM):

 ~> gdb -k /sys/compile/KUSHNIR/kernel.debug /var/crash/vmcore.1
[...]
IdlePTD 2797568
initial pcb at 232ce0
panicstr: page fault
[...]
---
#0  boot (howto=256) at ../../kern/kern_shutdown.c:304
304			dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0  boot (howto=256) at ../../kern/kern_shutdown.c:304
#1  0xc01327ac in poweroff_wait (junk=0xc021370f, howto=-974686464)
    at ../../kern/kern_shutdown.c:554
#2  0xc01e67a6 in trap_fatal (frame=0xc63abd3c, eva=0)
    at ../../i386/i386/trap.c:924
#3  0xc01e646d in trap_pfault (frame=0xc63abd3c, usermode=0, eva=0)
    at ../../i386/i386/trap.c:817
#4  0xc01e606f in trap (frame={tf_fs = -974716912, tf_es = -974716912, 
      tf_ds = -969277424, tf_edi = 1, tf_esi = -1064896000, 
      tf_ebp = -969228920, tf_isp = -969228952, tf_ebx = -1064902656, 
      tf_edx = 1, tf_ecx = 64, tf_eax = 0, tf_trapno = 12, tf_err = 0, 
      tf_eip = -1071886132, tf_cs = 8, tf_eflags = 66118, tf_esp = -974686464, 
      tf_ss = -969265760}) at ../../i386/i386/trap.c:423
#5  0xc01c50cc in acdopen (dev=0xc086fa00, flags=1, fmt=8192, p=0xc5e77700)
    at ../../dev/ata/atapi-cd.c:497
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#6  0xc016711f in spec_open (ap=0xc63abe04)
    at ../../miscfs/specfs/spec_vnops.c:191
#7  0xc0167021 in spec_vnoperate (ap=0xc63abe04)
    at ../../miscfs/specfs/spec_vnops.c:117
#8  0xc01ab7f9 in ufs_vnoperatespec (ap=0xc63abe04)
    at ../../ufs/ufs/ufs_vnops.c:2301
#9  0xc0163a4e in vn_open (ndp=0xc63abed0, fmode=1, cmode=0) at vnode_if.h:189
#10 0xc015f8e5 in open (p=0xc5e77700, uap=0xc63abf80)
---Type <return> to continue, or q <return> to quit---
    at ../../kern/vfs_syscalls.c:994
#11 0xc01e69ce in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, 
      tf_edi = -1077937549, tf_esi = -1077939108, tf_ebp = -1077939216, 
      tf_isp = -969228332, tf_ebx = -1077937864, tf_edx = -1077937539, 
      tf_ecx = -1077937539, tf_eax = 5, tf_trapno = 12, tf_err = 2, 
      tf_eip = 134525956, tf_cs = 31, tf_eflags = 663, tf_esp = -1077940076, 
      tf_ss = 47}) at ../../i386/i386/trap.c:1073
#12 0xc01daaa6 in Xint0x80_syscall ()
#13 0x80482c2 in ?? ()
#14 0x80480f5 in ?? ()

On 23 Mar 2000, Eric Jacoboni wrote:

> Hi,
> 
> >From yesterday and today cvsup + make world + kernel build : each time
> i try to mount a cd (this is not related to a particular cd as the
> same pb arises when the drive is empty...), my system reboot :
> 
> /kernel: Fatal trap 12: page fault while in kernel mode
> /kernel: fault virtual address     = 0x0
> /kernel: fault code                = supervisor read, page not present
> /kernel: instruction pointer       = 0x8:0xc01fd360
> /kernel: stack pointer             = 0x10:0xc673fd8c
> /kernel: frame pointer             = 0x10:0xc673fd98
> /kernel: code segment              = base 0x0, limit 0xfffff, type 0x1b
> /kernel: = DPL 0, pres 1, def32 1, gran 1
> /kernel: processor eflags  = interrupt enabled, resume, IOPL = 0
> /kernel: current process           = 1477 (mount_cd9660)
> /kernel: interrupt mask            = none
> /kernel: trap number               = 12
> /kernel: panic: page fault
> /kernel:
> /kernel: syncing disks... 10 9
> /kernel: done
> /kernel: Uptime: 2m28s
> /kernel:
> /kernel: dumping to dev #ad/0x30001, offset 55280
> /kernel: dump ata0: resetting devices .. done
> 
> This is a Dell i3500 Laptop, which uses to run ok with previous world
> (4.0-C and the first of 5.0-C, was ok).
> 
> 

-- 

===========================|=======================
 Vladimir Kushnir   	   |	
 vkushnir@Alfacom.net      |	Powered by FreeBSD
 kushnir@ap3.bitp.kiev.ua  |




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 15:13:15 2000
Delivered-To: freebsd-current@freebsd.org
Received: from yana.lemis.com (yana.lemis.com [192.109.197.140])
	by hub.freebsd.org (Postfix) with ESMTP id BF3D437B523
	for <current@FreeBSD.ORG>; Thu, 23 Mar 2000 15:13:04 -0800 (PST)
	(envelope-from grog@mojave.worldwide.lemis.com)
Received: from mojave.worldwide.lemis.com ([216.88.157.130])
	by yana.lemis.com (8.8.8/8.8.8) with ESMTP id JAA02312;
	Fri, 24 Mar 2000 09:42:40 +1030 (CST)
	(envelope-from grog@mojave.worldwide.lemis.com)
Received: (from grog@localhost)
	by mojave.worldwide.lemis.com (8.9.3/8.9.3) id PAA09453;
	Thu, 23 Mar 2000 15:12:20 -0800 (PST)
	(envelope-from grog)
Date: Thu, 23 Mar 2000 15:12:20 -0800
From: Greg Lehey <grog@lemis.com>
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc: Matthew Dillon <dillon@apollo.backplane.com>, current@FreeBSD.ORG
Subject: Re: patches for test / review
Message-ID: <20000323151220.A9318@mojave.worldwide.lemis.com>
Reply-To: Greg Lehey <grog@lemis.com>
References: <200003201846.KAA70820@apollo.backplane.com> <20074.953579833@critter.freebsd.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <20074.953579833@critter.freebsd.dk>; from phk@critter.freebsd.dk on Mon, Mar 20, 2000 at 08:17:13PM +0100
WWW-Home-Page: http://www.lemis.com/~grog
X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF  13 24 52 F8 6D A4 95 EF
Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8286
Fax: +61-8-8388-8725
Mobile: +61-41-739-7062
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Monday, 20 March 2000 at 20:17:13 +0100, Poul-Henning Kamp wrote:
> In message <200003201846.KAA70820@apollo.backplane.com>, Matthew Dillon writes:
>
>>    Well, let me tell you what the fuzzy goal is first and then maybe we
>>    can work backwards.
>>
>>    Eventually all physical I/O needs a physical address.  The quickest
>>    way to get to a physical address is to be given an array of vm_page_t's
>>    (which can be trivially translated to physical addresses).
>
> Not all: PIO access to ATA needs virtual access.  RAID5 needs
> virtual access to calculate parity.

I'm not sure what you mean by "virtual access".  If you mean
file-related rather than partition-related, no: like the rest of
Vinum, RAID-5 uses only partition-related offsets.

>>    What we want to do is to try to extend VMIO (aka the vm_page_t) all
>>    the way through the I/O system - both VFS and DEV I/O, in order to
>>    remove all the nasty back and forth translations.
>
> I agree, but some drivers need mapping we need to cater for those.
> They could simply call a vm_something(struct buf *) call which would
> map the pages and things would "just work".
>
> For RAID5 we have the opposite problem also: data is created which
> has only a mapped existance and the b_pages[] array is not
> populated.

Hmm.  I really need to check that I'm not missing something here.

Greg
--
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 15:21:48 2000
Delivered-To: freebsd-current@freebsd.org
Received: from yana.lemis.com (yana.lemis.com [192.109.197.140])
	by hub.freebsd.org (Postfix) with ESMTP id A7A8837BAF0
	for <current@FreeBSD.ORG>; Thu, 23 Mar 2000 15:21:42 -0800 (PST)
	(envelope-from grog@mojave.worldwide.lemis.com)
Received: from mojave.worldwide.lemis.com ([216.88.157.130])
	by yana.lemis.com (8.8.8/8.8.8) with ESMTP id JAA02322;
	Fri, 24 Mar 2000 09:51:24 +1030 (CST)
	(envelope-from grog@mojave.worldwide.lemis.com)
Received: (from grog@localhost)
	by mojave.worldwide.lemis.com (8.9.3/8.9.3) id PAA09490;
	Thu, 23 Mar 2000 15:21:04 -0800 (PST)
	(envelope-from grog)
Date: Thu, 23 Mar 2000 15:21:04 -0800
From: Greg Lehey <grog@lemis.com>
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, current@FreeBSD.ORG
Subject: Re: patches for test / review
Message-ID: <20000323152104.B9318@mojave.worldwide.lemis.com>
Reply-To: Greg Lehey <grog@lemis.com>
References: <20074.953579833@critter.freebsd.dk> <200003202204.OAA72087@apollo.backplane.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200003202204.OAA72087@apollo.backplane.com>; from dillon@apollo.backplane.com on Mon, Mar 20, 2000 at 02:04:48PM -0800
WWW-Home-Page: http://www.lemis.com/~grog
X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF  13 24 52 F8 6D A4 95 EF
Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8286
Fax: +61-8-8388-8725
Mobile: +61-41-739-7062
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Monday, 20 March 2000 at 14:04:48 -0800, Matthew Dillon wrote:
>
>     If a particular subsystem needs b_data, then that subsystem is obviously
>     willing to take the virtual mapping / unmapping hit.  If you look at
>     Greg's current code this is, in fact, what is occuring.... the critical
>     path through the buffer cache in a heavily loaded system tends to require
>     a KVA mapping *AND* a KVA unmapping on every buffer access (just that the
>     unmappings tend to be for unrelated buffers).  The reason this occurs
>     is because even with the larger amount of KVA we made available to the
>     buffer cache in 4.x, there still isn't enough to leave mappings intact
>     for long periods of time.  A 'systat -vm 1' will show you precisely
>     what I mean (also sysctl -a | fgrep bufspace).
>
>     So we will at least not be any worse off then we are now, and probably
>     better off since many of the buffers in the new system will not have
>     to be mapped.  For example, when vinum's RAID5 breaks up a request
>     and issues a driveio() it passes a buffer which is assigned to b_data
>     which must be translated (through page table lookups) to physical
>     addresses anyway, so the fact that that vinum does not populate
>     b_pages[] does *NOT* help it in the least.  It actually makes the job
>     harder.

I think you may be confusing two things, though it doesn't seem to
make much difference.  driveio() is used only for accesses to the
configuration information; normal Vinum I/O goes via launch_requests()
(in vinumrequest.c).  And it's not just RAID-5 that breaks up a
request, it's any access that goes over more than one subdisk (even
concatenated plexes in exceptional cases).

Greg
--
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 15:25:13 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mass.cdrom.com (mg-20425418-10.ricochet.net [204.254.18.10])
	by hub.freebsd.org (Postfix) with ESMTP id 189B137C5AC
	for <current@FreeBSD.ORG>; Thu, 23 Mar 2000 15:24:35 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Received: from mass.cdrom.com (localhost [127.0.0.1])
	by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id PAA02518;
	Thu, 23 Mar 2000 15:26:47 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Message-Id: <200003232326.PAA02518@mass.cdrom.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To: Greg Lehey <grog@lemis.com>
Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>,
	Matthew Dillon <dillon@apollo.backplane.com>, current@FreeBSD.ORG
Subject: Re: patches for test / review 
In-reply-to: Your message of "Thu, 23 Mar 2000 15:12:20 PST."
             <20000323151220.A9318@mojave.worldwide.lemis.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 23 Mar 2000 15:26:47 -0800
From: Mike Smith <msmith@freebsd.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> >>    Eventually all physical I/O needs a physical address.  The quickest
> >>    way to get to a physical address is to be given an array of vm_page_t's
> >>    (which can be trivially translated to physical addresses).
> >
> > Not all: PIO access to ATA needs virtual access.  RAID5 needs
> > virtual access to calculate parity. 
> 
> I'm not sure what you mean by "virtual access".  If you mean
> file-related rather than partition-related, no: like the rest of
> Vinum, RAID-5 uses only partition-related offsets.

No, the issue here has to do with the mapping of the data buffers.  If 
you're doing PIO, or otherwise manipulating the data in the driver before 
you give it to the hardware (eg. inside vinum) then you need the data 
buffers mapped into your virtual address space.

OTOH, if you're handing the buffer information to a busmaster device, 
you don't need this, instead you need the physical address of the buffer 
sections.

> > For RAID5 we have the opposite problem also: data is created which
> > has only a mapped existance and the b_pages[] array is not
> > populated.
> 
> Hmm.  I really need to check that I'm not missing something here.

The point here is that when you create RAID5 parity data, the buffer's 
physical addresses aren't filled in.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
\\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 15:28:20 2000
Delivered-To: freebsd-current@freebsd.org
Received: from yana.lemis.com (yana.lemis.com [192.109.197.140])
	by hub.freebsd.org (Postfix) with ESMTP id 1BC4737C52C
	for <current@FreeBSD.ORG>; Thu, 23 Mar 2000 15:28:10 -0800 (PST)
	(envelope-from grog@mojave.worldwide.lemis.com)
Received: from mojave.worldwide.lemis.com ([216.88.157.130])
	by yana.lemis.com (8.8.8/8.8.8) with ESMTP id JAA02329;
	Fri, 24 Mar 2000 09:57:45 +1030 (CST)
	(envelope-from grog@mojave.worldwide.lemis.com)
Received: (from grog@localhost)
	by mojave.worldwide.lemis.com (8.9.3/8.9.3) id PAA09537;
	Thu, 23 Mar 2000 15:27:18 -0800 (PST)
	(envelope-from grog)
Date: Thu, 23 Mar 2000 15:27:18 -0800
From: Greg Lehey <grog@lemis.com>
To: Dan Nelson <dnelson@emsphone.com>
Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>,
	Alfred Perlstein <bright@wintelcom.net>,
	Matthew Dillon <dillon@apollo.backplane.com>, current@FreeBSD.ORG
Subject: Re: patches for test / review
Message-ID: <20000323152718.C9318@mojave.worldwide.lemis.com>
Reply-To: Greg Lehey <grog@lemis.com>
References: <20000320115902.C14789@fw.wintelcom.net> <20211.953581241@critter.freebsd.dk> <20000320152330.A48212@dan.emsphone.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <20000320152330.A48212@dan.emsphone.com>; from dnelson@emsphone.com on Mon, Mar 20, 2000 at 03:23:31PM -0600
WWW-Home-Page: http://www.lemis.com/~grog
X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF  13 24 52 F8 6D A4 95 EF
Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8286
Fax: +61-8-8388-8725
Mobile: +61-41-739-7062
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Monday, 20 March 2000 at 15:23:31 -0600, Dan Nelson wrote:
> In the last episode (Mar 20), Poul-Henning Kamp said:
>> In message <20000320115902.C14789@fw.wintelcom.net>, Alfred Perlstein writes:
>>> * Poul-Henning Kamp <phk@critter.freebsd.dk> [000320 11:45] wrote:
>>>>
>>>> Before we redesign the clustering, I would like to know if we
>>>> actually have any recent benchmarks which prove that clustering is
>>>> overall beneficial ?
>>>
>>> Yes it is really benificial.
>>
>> I would like to see some numbers if you have them.
>
> For hardware RAID arrays that support it, if you can get the system to
> issue writes that are larger than the entire RAID-5 stripe size, your
> immensely slow "read parity/recalc parity/write parity/write data"
> operations turn into "recalc parity for entire stripe/write entire
> stripe".  RAID-5 magically achieves RAID-0 write speeds!  Given 32k
> granularity, and 8 disks per RAID group, you'll need a write
> size of 32*7 = 224k.  Given 64K granularity and 27 disks, that's 1.6MB.
>
> I have seen the jump in write throughput as I tuned an Oracle
> database's parameters on both Solaris and DEC Unix boxes.  Get Oracle
> to write blocks larger than a RAID-5 stripe, and it flies.

Agreed.  This is on the Vinum wishlist, but it comes at the expense of
reliability (how long do you wait to cluster?  What happens if the
system fails in between?).  In addition, for Vinum it needs to be done
before entering the hardware driver.

Greg
--
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 15:29:13 2000
Delivered-To: freebsd-current@freebsd.org
Received: from yana.lemis.com (yana.lemis.com [192.109.197.140])
	by hub.freebsd.org (Postfix) with ESMTP id 365B237C54B
	for <current@FreeBSD.ORG>; Thu, 23 Mar 2000 15:29:08 -0800 (PST)
	(envelope-from grog@mojave.worldwide.lemis.com)
Received: from mojave.worldwide.lemis.com ([216.88.157.130])
	by yana.lemis.com (8.8.8/8.8.8) with ESMTP id JAA02333;
	Fri, 24 Mar 2000 09:58:33 +1030 (CST)
	(envelope-from grog@mojave.worldwide.lemis.com)
Received: (from grog@localhost)
	by mojave.worldwide.lemis.com (8.9.3/8.9.3) id PAA09554;
	Thu, 23 Mar 2000 15:28:10 -0800 (PST)
	(envelope-from grog)
Date: Thu, 23 Mar 2000 15:28:10 -0800
From: Greg Lehey <grog@lemis.com>
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc: Alfred Perlstein <bright@wintelcom.net>,
	Matthew Dillon <dillon@apollo.backplane.com>, current@FreeBSD.ORG
Subject: Re: patches for test / review
Message-ID: <20000323152810.D9318@mojave.worldwide.lemis.com>
Reply-To: Greg Lehey <grog@lemis.com>
References: <20000320115902.C14789@fw.wintelcom.net> <21213.953589179@critter.freebsd.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <21213.953589179@critter.freebsd.dk>; from phk@critter.freebsd.dk on Mon, Mar 20, 2000 at 10:52:59PM +0100
WWW-Home-Page: http://www.lemis.com/~grog
X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF  13 24 52 F8 6D A4 95 EF
Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8286
Fax: +61-8-8388-8725
Mobile: +61-41-739-7062
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Monday, 20 March 2000 at 22:52:59 +0100, Poul-Henning Kamp wrote:
> In message <20000320115902.C14789@fw.wintelcom.net>, Alfred Perlstein writes:
>> * Poul-Henning Kamp <phk@critter.freebsd.dk> [000320 11:45] wrote:
>>> In message <20000320111544.A14789@fw.wintelcom.net>, Alfred Perlstein writes:
>>>
>>>> Keeping the currect cluster code is a bad idea, if the drivers were
>>>> taught how to traverse the linked list in the buf struct rather
>>>> than just notice "a big buffer" we could avoid a lot of page
>>>> twiddling and also allow for massive IO clustering ( > 64k )
>>>
>>> Before we redesign the clustering, I would like to know if we
>>> actually have any recent benchmarks which prove that clustering
>>> is overall beneficial ?
>>
>> Yes it is really benificial.
>>
>> I'm not talking about a redesign of the clustering code as much as
>> making the drivers that take a callback from it actually traverse
>> the 'union cluster_info' rather than relying on the system to fake
>> the pages being contiguous via remapping.
>>
>> There's nothing wrong with the clustering algorithms, it's just the
>> steps it has to take to work with the drivers.
>
> Hmm, try to keep vinum/RAID5 in the picture when you look at this
> code, it complicated matters a lot.

I don't think it's that relevant, in fact.

Greg
--
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 15:34:23 2000
Delivered-To: freebsd-current@freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
	by hub.freebsd.org (Postfix) with ESMTP id 1D7CF37BE83
	for <current@freebsd.org>; Thu, 23 Mar 2000 15:34:21 -0800 (PST)
	(envelope-from kris@FreeBSD.org)
Received: from localhost (kris@localhost)
	by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id PAA34874
	for <current@freebsd.org>; Thu, 23 Mar 2000 15:34:22 -0800 (PST)
	(envelope-from kris@FreeBSD.org)
X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs
Date: Thu, 23 Mar 2000 15:34:21 -0800 (PST)
From: Kris Kennaway <kris@FreeBSD.org>
To: current@freebsd.org
Subject: Optimisation patch
Message-ID: <Pine.BSF.4.21.0003231533240.33462-100000@freefall.freebsd.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Any objections to the following?

Index: make.conf
===================================================================
RCS file: /home/ncvs/src/etc/defaults/make.conf,v
retrieving revision 1.101
diff -u -u -r1.101 make.conf
--- make.conf	2000/03/22 00:49:20	1.101
+++ make.conf	2000/03/23 23:33:13
@@ -9,7 +9,13 @@
 # You have to find the things you can put here in the Makefiles and 
 # documentation of the source tree.
 #
-# One, and probably the most common, use could be:
+# CFLAGS controls the compiler settings used when compiling C code.
+# Note that optimisation settings above -O (-O2, ...) are not recommended
+# or supported for compiling the world or the kernel - please revert any
+# nonstandard optimisation settings to "-O" before submitting bug reports
+# to the developers.
+# Note also that at this time the -O2 setting is known to produce BROKEN
+# CODE on the Alpha platform.
 #
 #CFLAGS= -O -pipe
 #

----
In God we Trust -- all others must submit an X.509 certificate.
    -- Charles Forsythe <forsythe@alum.mit.edu>



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 15:41:10 2000
Delivered-To: freebsd-current@freebsd.org
Received: from picnic.mat.net (picnic.mat.net [206.246.122.133])
	by hub.freebsd.org (Postfix) with ESMTP
	id AD46137B607; Thu, 23 Mar 2000 15:40:55 -0800 (PST)
	(envelope-from chuckr@picnic.mat.net)
Received: from localhost (chuckr@localhost [127.0.0.1])
	by picnic.mat.net (8.9.3/8.9.3) with ESMTP id SAA48763;
	Thu, 23 Mar 2000 18:39:30 -0500 (EST)
	(envelope-from chuckr@picnic.mat.net)
Date: Thu, 23 Mar 2000 18:39:30 -0500 (EST)
From: Chuck Robey <chuckr@picnic.mat.net>
To: Kris Kennaway <kris@FreeBSD.ORG>
Cc: current@FreeBSD.ORG
Subject: Re: Optimisation patch
In-Reply-To: <Pine.BSF.4.21.0003231533240.33462-100000@freefall.freebsd.org>
Message-ID: <Pine.BSF.4.21.0003231837170.47847-100000@picnic.mat.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Thu, 23 Mar 2000, Kris Kennaway wrote:

> Any objections to the following?

I don't mind at all ... I was wondering about just taking out the ability
to even USE -O2 in the compiler, but there're probably *some* non-kernel
related reasons for using it, and we shouldn't block it at that
point.  Not for FreeBSD, but for some users doing their own code on
FreeBSD.

> 
> Index: make.conf
> ===================================================================
> RCS file: /home/ncvs/src/etc/defaults/make.conf,v
> retrieving revision 1.101
> diff -u -u -r1.101 make.conf
> --- make.conf	2000/03/22 00:49:20	1.101
> +++ make.conf	2000/03/23 23:33:13
> @@ -9,7 +9,13 @@
>  # You have to find the things you can put here in the Makefiles and 
>  # documentation of the source tree.
>  #
> -# One, and probably the most common, use could be:
> +# CFLAGS controls the compiler settings used when compiling C code.
> +# Note that optimisation settings above -O (-O2, ...) are not recommended
> +# or supported for compiling the world or the kernel - please revert any
> +# nonstandard optimisation settings to "-O" before submitting bug reports
> +# to the developers.
> +# Note also that at this time the -O2 setting is known to produce BROKEN
> +# CODE on the Alpha platform.
>  #
>  #CFLAGS= -O -pipe
>  #
> 
> ----
> In God we Trust -- all others must submit an X.509 certificate.
>     -- Charles Forsythe <forsythe@alum.mit.edu>
> 
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message
> 

----------------------------------------------------------------------------
Chuck Robey            | Interests include C & Java programming, FreeBSD,
chuckr@picnic.mat.net  | electronics, communications, and signal processing.

New Year's Resolution:  I will not sphroxify gullible people into looking up
fictitious words in the dictionary.
----------------------------------------------------------------------------



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 15:42:17 2000
Delivered-To: freebsd-current@freebsd.org
Received: from yana.lemis.com (yana.lemis.com [192.109.197.140])
	by hub.freebsd.org (Postfix) with ESMTP id 6466837BF18
	for <current@FreeBSD.ORG>; Thu, 23 Mar 2000 15:42:09 -0800 (PST)
	(envelope-from grog@mojave.worldwide.lemis.com)
Received: from mojave.worldwide.lemis.com ([216.88.157.130])
	by yana.lemis.com (8.8.8/8.8.8) with ESMTP id KAA02350;
	Fri, 24 Mar 2000 10:11:47 +1030 (CST)
	(envelope-from grog@mojave.worldwide.lemis.com)
Received: (from grog@localhost)
	by mojave.worldwide.lemis.com (8.9.3/8.9.3) id PAA09602;
	Thu, 23 Mar 2000 15:41:23 -0800 (PST)
	(envelope-from grog)
Date: Thu, 23 Mar 2000 15:41:23 -0800
From: Greg Lehey <grog@lemis.com>
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: Wilko Bulte <wilko@yedi.iaf.nl>,
	Poul-Henning Kamp <phk@critter.freebsd.dk>,
	Alfred Perlstein <bright@wintelcom.net>, current@FreeBSD.ORG
Subject: Re: patches for test / review
Message-ID: <20000323154123.E9318@mojave.worldwide.lemis.com>
Reply-To: Greg Lehey <grog@lemis.com>
References: <20000320111544.A14789@fw.wintelcom.net> <20102.953580112@critter.freebsd.dk> <20000321000435.A8143@yedi.iaf.nl> <200003211729.JAA81170@apollo.backplane.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200003211729.JAA81170@apollo.backplane.com>; from dillon@apollo.backplane.com on Tue, Mar 21, 2000 at 09:29:56AM -0800
WWW-Home-Page: http://www.lemis.com/~grog
X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF  13 24 52 F8 6D A4 95 EF
Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8286
Fax: +61-8-8388-8725
Mobile: +61-41-739-7062
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Tuesday, 21 March 2000 at  9:29:56 -0800, Matthew Dillon wrote:
>>>
>>> I would think that track-caches and intelligent drives would gain
>>> much if not more of what clustering was designed to do gain.
>>
>> Hm. But I'd think that even with modern drives a smaller number of bigger
>> I/Os is preferable over lots of very small I/Os. Or have I missed the point?
>
>     As long as you do not blow away the drive's cache with your big I/O's,
>     and as long as you actually use all the returned data, it's definitely
>     more efficient to issue larger I/O's.
>
>     If you generate requests that are too large - say over 1/4 the size of
>     the drive's cache, the drive will not be able to optimize parallel
>     requests as well.

I think that in the majority of cases there's no need to transfer more
than requested.  It could only apply to reads anyway, and the drive
cache probably has this data anyway.  In RAID adapters, it seems to
almost always be due to poor firmware design.  For regular files, it
might be an idea to set a flag to indicate whether read-ahead has any
hope of being useful (for example, on an ftp server the answer would
be "yes"; for index-sequential files or such the answer would normally
be "no".

Greg
--
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 15:45:17 2000
Delivered-To: freebsd-current@freebsd.org
Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101])
	by hub.freebsd.org (Postfix) with ESMTP id 923E137C520
	for <current@FreeBSD.ORG>; Thu, 23 Mar 2000 15:45:13 -0800 (PST)
	(envelope-from dan@dan.emsphone.com)
Received: (from dan@localhost)
	by dan.emsphone.com (8.9.3/8.9.3) id RAA67589;
	Thu, 23 Mar 2000 17:44:38 -0600 (CST)
	(envelope-from dan)
Date: Thu, 23 Mar 2000 17:44:38 -0600
From: Dan Nelson <dnelson@emsphone.com>
To: Greg Lehey <grog@lemis.com>
Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>,
	Alfred Perlstein <bright@wintelcom.net>,
	Matthew Dillon <dillon@apollo.backplane.com>, current@FreeBSD.ORG
Subject: Re: patches for test / review
Message-ID: <20000323174438.B59166@dan.emsphone.com>
References: <20000320115902.C14789@fw.wintelcom.net> <20211.953581241@critter.freebsd.dk> <20000320152330.A48212@dan.emsphone.com> <20000323152718.C9318@mojave.worldwide.lemis.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.1.5i
In-Reply-To: <20000323152718.C9318@mojave.worldwide.lemis.com>; from "Greg Lehey" on Thu Mar 23 15:27:18 GMT 2000
X-OS: FreeBSD 5.0-CURRENT
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In the last episode (Mar 23), Greg Lehey said:
> 
> Agreed.  This is on the Vinum wishlist, but it comes at the expense of
> reliability (how long do you wait to cluster?  What happens if the
> system fails in between?).  In addition, for Vinum it needs to be done
> before entering the hardware driver.

For the simplest case, you can choose to optimize only when the user
sends a single huge write().  That way you don't have to worry about
caching dirty pages in vinum.  This is basically what the hardware
RAIDs I have do.  They'll only do the write optimization (they call it
"pipelining") if you actually send a single SCSI write request large
enough to span all the disks.  I don't know what would be required to
get our kernel to even be able to write blocks this big (what's the
upper limit on MAXPHYS)?

-- 
	Dan Nelson
	dnelson@emsphone.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 15:46:31 2000
Delivered-To: freebsd-current@freebsd.org
Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161])
	by hub.freebsd.org (Postfix) with ESMTP
	id 5039737B547; Thu, 23 Mar 2000 15:46:24 -0800 (PST)
	(envelope-from doconnor@gsoft.com.au)
Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97])
	by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id KAA16264;
	Fri, 24 Mar 2000 10:15:55 +1030 (CST)
	(envelope-from doconnor@gsoft.com.au)
Message-ID: <XFMail.000324101555.doconnor@gsoft.com.au>
X-Mailer: XFMail 1.4.0 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <200003231808.KAA01160@mass.cdrom.com>
Date: Fri, 24 Mar 2000 10:15:55 +1030 (CST)
From: "Daniel O'Connor" <doconnor@gsoft.com.au>
To: Mike Smith <msmith@freebsd.org>
Subject: Re: 4.0 sysinstall fails to recognize disks
Cc: freebsd-questions@FreeBSD.ORG, freebsd-current@FreeBSD.ORG,
	Matthew Dillon <dillon@apollo.backplane.com>,
	Eric Sabban <eric@clickrebates.com>,
	Forrest Aldrich <forrie@forrie.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


On 23-Mar-00 Mike Smith wrote:
>  Just rebuild sysinstall, like I told you to start with.  Or just bring 
>  the disks up by hand, which is much faster.  Or even try Warner's 
>  'diskprep' tool.

If anyone want diskprep, its at...

http://people.freebsd.org/~imp/diskprep

---
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 15:55:17 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mail.hellasnet.gr (mail.hellasnet.gr [212.54.192.3])
	by hub.freebsd.org (Postfix) with ESMTP id 0071B37C888
	for <current@FreeBSD.ORG>; Thu, 23 Mar 2000 15:55:08 -0800 (PST)
	(envelope-from keramida@ceid.upatras.gr)
Received: from hades.hell.gr (ppp2.patr.hellasnet.gr [212.54.197.17])
	by mail.hellasnet.gr (8.9.1/8.9.1) with ESMTP id BAA01623
	for <current@FreeBSD.ORG>; Fri, 24 Mar 2000 01:54:10 +0200 (GMT)
Received: (from charon@localhost)
	by hades.hell.gr (8.9.3/8.9.3) id AAA01500
	for current@freebsd.org; Fri, 24 Mar 2000 00:57:27 +0200 (EET)
	(envelope-from keramida@ceid.upatras.gr)
Date: Fri, 24 Mar 2000 00:57:27 +0200
From: Giorgos Keramidas <keramida@ceid.upatras.gr>
To: current@FreeBSD.ORG
Subject: problem solved. (was: Re: Not actually)
Message-ID: <20000324005727.G654@hades.hell.gr>
Reply-To: keramida@ceid.upatras.gr
References: <20000323000017.A2325@hades.hell.gr> <200003222208.OAA03940@mass.cdrom.com> <20000323013311.A2468@hades.hell.gr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <20000323013311.A2468@hades.hell.gr>; from keramida@ceid.upatras.gr on Thu, Mar 23, 2000 at 01:33:11AM +0200
X-PGP-Fingerprint: 62 45 D1 C9 26 F9 95 06  D6 21 2A C8 8C 16 C0 8E
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Thu, Mar 23, 2000 at 01:33:11AM +0200, Giorgos Keramidas wrote:
> 
> In the mean time, I've recompiled a freshly cvsup'ed kernel, booted it,
> and now I'm trying to build my world -- since it seems that compiling
> the kernel and/or `world' triggers the funny condition I'm running into.

I rebuilt kernel with sources cvsup'ed early this morning [Friday], this
time enabling INVARIANTS.  I built my world and installed it fine, so I
think that whatever it was, it's gone now.

Seems I was cvsup'ing while changes were being done on the repository.

- Giorgos Keramidas


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 15:59: 3 2000
Delivered-To: freebsd-current@freebsd.org
Received: from yana.lemis.com (yana.lemis.com [192.109.197.140])
	by hub.freebsd.org (Postfix) with ESMTP id 6069F37C54B
	for <current@FreeBSD.ORG>; Thu, 23 Mar 2000 15:58:57 -0800 (PST)
	(envelope-from grog@mojave.worldwide.lemis.com)
Received: from mojave.worldwide.lemis.com ([216.88.157.130])
	by yana.lemis.com (8.8.8/8.8.8) with ESMTP id KAA02363;
	Fri, 24 Mar 2000 10:28:36 +1030 (CST)
	(envelope-from grog@mojave.worldwide.lemis.com)
Received: (from grog@localhost)
	by mojave.worldwide.lemis.com (8.9.3/8.9.3) id PAA09672;
	Thu, 23 Mar 2000 15:58:13 -0800 (PST)
	(envelope-from grog)
Date: Thu, 23 Mar 2000 15:58:13 -0800
From: Greg Lehey <grog@lemis.com>
To: Dan Nelson <dnelson@emsphone.com>
Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>,
	Alfred Perlstein <bright@wintelcom.net>,
	Matthew Dillon <dillon@apollo.backplane.com>, current@FreeBSD.ORG
Subject: Write clustering (was: patches for test / review)
Message-ID: <20000323155812.F9318@mojave.worldwide.lemis.com>
Reply-To: Greg Lehey <grog@lemis.com>
References: <20000320115902.C14789@fw.wintelcom.net> <20211.953581241@critter.freebsd.dk> <20000320152330.A48212@dan.emsphone.com> <20000323152718.C9318@mojave.worldwide.lemis.com> <20000323174438.B59166@dan.emsphone.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <20000323174438.B59166@dan.emsphone.com>; from dnelson@emsphone.com on Thu, Mar 23, 2000 at 05:44:38PM -0600
WWW-Home-Page: http://www.lemis.com/~grog
X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF  13 24 52 F8 6D A4 95 EF
Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8286
Fax: +61-8-8388-8725
Mobile: +61-41-739-7062
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Thursday, 23 March 2000 at 17:44:38 -0600, Dan Nelson wrote:
> In the last episode (Mar 23), Greg Lehey said:
>>
>> Agreed.  This is on the Vinum wishlist, but it comes at the expense of
>> reliability (how long do you wait to cluster?  What happens if the
>> system fails in between?).  In addition, for Vinum it needs to be done
>> before entering the hardware driver.
>
> For the simplest case, you can choose to optimize only when the user
> sends a single huge write().

We discussed that.  Since the optimum band size is much larger than
MAXPHYS, this can't happen on a correctly configured system.

> That way you don't have to worry about caching dirty pages in vinum.
> This is basically what the hardware RAIDs I have do.

Right, but that seriously degrades normal non-band writes.

> They'll only do the write optimization (they call it "pipelining")
> if you actually send a single SCSI write request large enough to
> span all the disks.  I don't know what would be required to get our
> kernel to even be able to write blocks this big (what's the upper
> limit on MAXPHYS)?

MAXPHYS is currently 128 kB.  I recommend stripes of 256 kB to 512 kB,
so with a 9 disk RAID we're talking about bands of 2 to 4 MB.  My
current idea is to set a flag on each volume specifying that it's
prepared to wait up to n seconds for write clustering.

Greg
--
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 16: 8:10 2000
Delivered-To: freebsd-current@freebsd.org
Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87])
	by hub.freebsd.org (Postfix) with ESMTP
	id F084C37B559; Thu, 23 Mar 2000 16:08:02 -0800 (PST)
	(envelope-from dcs@newsguy.com)
Received: from newsguy.com (p39-dn02kiryunisiki.gunma.ocn.ne.jp [211.0.245.104])
	by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id JAA18205;
	Fri, 24 Mar 2000 09:07:51 +0900 (JST)
Message-ID: <38DAA6F0.853ABF01@newsguy.com>
Date: Fri, 24 Mar 2000 08:21:20 +0900
From: "Daniel C. Sobral" <dcs@newsguy.com>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en,pt-BR,ja
MIME-Version: 1.0
To: Forrest Aldrich <forrie@forrie.com>
Cc: Mike Smith <msmith@FreeBSD.ORG>,
	Eric Sabban <eric@clickrebates.com>,
	Matthew Dillon <dillon@apollo.backplane.com>,
	freebsd-current@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG
Subject: Re: 4.0 sysinstall fails to recognize disks
References: <Your message of "Thu, 23 Mar 2000 12:59:06 EST." <4.3.1.2.20000323125731.00b68100@216.67.12.69> <4.3.1.2.20000323131429.00b69410@216.67.12.69>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Forrest Aldrich wrote:
> 
> Is not sysinstall built and installed with a typical make
> buildworld/installworld?

No.

--
Daniel C. Sobral			(8-DCS)
dcs@newsguy.com
dcs@freebsd.org
capo@zurichgnomes.bsdconspiracy.net

	One Unix to rule them all, One Resolver to find them,
        One IP to bring them all and in the zone bind them.




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 16:15:57 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mail.hellasnet.gr (mail.hellasnet.gr [212.54.192.3])
	by hub.freebsd.org (Postfix) with ESMTP id 2A3D937C008
	for <current@freebsd.org>; Thu, 23 Mar 2000 16:15:49 -0800 (PST)
	(envelope-from keramida@ceid.upatras.gr)
Received: from hades.hell.gr (ppp2.patr.hellasnet.gr [212.54.197.17])
	by mail.hellasnet.gr (8.9.1/8.9.1) with ESMTP id CAA02983
	for <current@freebsd.org>; Fri, 24 Mar 2000 02:14:48 +0200 (GMT)
Received: (from charon@localhost)
	by hades.hell.gr (8.9.3/8.9.3) id CAA01451
	for current@freebsd.org; Fri, 24 Mar 2000 02:17:00 +0200 (EET)
	(envelope-from keramida@ceid.upatras.gr)
Date: Fri, 24 Mar 2000 02:16:59 +0200
From: Giorgos Keramidas <keramida@ceid.upatras.gr>
To: current@freebsd.org
Subject: /dev/acd0 related crash?
Message-ID: <20000324021659.A1312@hades.hell.gr>
Reply-To: keramida@ceid.upatras.gr
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="+QahgC5+KEYLbs62"
X-Mailer: Mutt 1.0i
X-PGP-Fingerprint: 62 45 D1 C9 26 F9 95 06  D6 21 2A C8 8C 16 C0 8E
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


--+QahgC5+KEYLbs62
Content-Type: text/plain; charset=us-ascii

I built from sources cvsup'ed about 24 hours ago, my kernel and world,
this afternoon.  After enabling INVARIANTS and INVARIANT_SUPPORT, I
booted and tried a lot of things.  Nothing seemed to make the new kernel
I had (and it's own modules + world) go crazy ;)

However, when I tried to run cdcontrol on my ATAPI cdrom, the kernel
paniced and instantly rebooted.  The related kgdb output for the crash
dump is attached.

My kernel version is:

    FreeBSD hades.hell.gr 5.0-CURRENT FreeBSD 5.0-CURRENT #0:
      Thu Mar 23 04:43:04 EET 2000
      root@hades.hell.gr:/usr/src/sys/compile/HADES  i386

Seems that it crashed in acdopen().  My version of atapi-cd.c is 1.52.

- Giorgos Keramidas

--+QahgC5+KEYLbs62
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="kgdb.6"

# gdb -k kernel.debug /var/crash/vmcore.6
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
IdlePTD 2973696
initial pcb at 263ca0
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address	= 0x0
fault code		= supervisor read, page not present
instruction pointer	= 0x8:0xc01c8c78
stack pointer	        = 0x10:0xc55add88
frame pointer	        = 0x10:0xc55add94
code segment		= base 0x0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, def32 1, gran 1
processor eflags	= interrupt enabled, resume, IOPL = 0
current process		= 299 (cdcontrol)
interrupt mask		= none


Fatal trap 12: page fault while in kernel mode
fault virtual address	= 0x0
fault code		= supervisor read, page not present
instruction pointer	= 0x8:0xc01c8c78
stack pointer	        = 0x10:0xc55add88
frame pointer	        = 0x10:0xc55add94
code segment		= base 0x0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, def32 1, gran 1
processor eflags	= interrupt enabled, resume, IOPL = 0
current process		= 299 (cdcontrol)
interrupt mask		= none
panic: from debugger
panic: from debugger
Uptime: 7m59s

dumping to dev #ad/0x20001, offset 65536
dump ata0: resetting devices .. done
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:304
304			dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0  boot (howto=256) at ../../kern/kern_shutdown.c:304
#1  0xc01367a5 in panic (fmt=0xc0222e0f "page fault")
    at ../../kern/kern_shutdown.c:554
#2  0xc01ed71a in trap_fatal (frame=0xc55f3d48, eva=0)
    at ../../i386/i386/trap.c:924
#3  0xc01ed3cd in trap_pfault (frame=0xc55f3d48, usermode=0, eva=0)
    at ../../i386/i386/trap.c:817
#4  0xc01ecf53 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 1, 
      tf_esi = -1057903872, tf_ebp = -983614060, tf_isp = -983614092, 
      tf_ebx = -1057896448, tf_edx = 1, tf_ecx = -983626240, tf_eax = 0, 
      tf_trapno = 12, tf_err = 0, tf_eip = -1071864696, tf_cs = 8, 
      tf_eflags = 66118, tf_esp = -983330496, tf_ss = -1057903872})
    at ../../i386/i386/trap.c:423
#5  0xc01ca488 in acdopen (dev=0xc0f1ab00, flags=1, fmt=8192, p=0xc55f0e00)
    at ../../dev/ata/atapi-cd.c:497
#6  0xc016cd6d in spec_open (ap=0xc55f3e10)
    at ../../miscfs/specfs/spec_vnops.c:191
#7  0xc016cc6d in spec_vnoperate (ap=0xc55f3e10)
    at ../../miscfs/specfs/spec_vnops.c:117
#8  0xc01a2b21 in ufs_vnoperatespec (ap=0xc55f3e10)
    at ../../ufs/ufs/ufs_vnops.c:2301
#9  0xc016773b in vn_open (ndp=0xc55f3edc, fmode=1, cmode=1197)
    at vnode_if.h:189
#10 0xc01636d1 in open (p=0xc55f0e00, uap=0xc55f3f80)
    at ../../kern/vfs_syscalls.c:994
#11 0xc01ed952 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, 
      tf_edi = 1, tf_esi = -1, tf_ebp = -1077937768, tf_isp = -983613484, 
      tf_ebx = -1077938792, tf_edx = 10, tf_ecx = -1077938928, tf_eax = 5, 
      tf_trapno = 12, tf_err = 2, tf_eip = 672262868, tf_cs = 31, 
      tf_eflags = 647, tf_esp = -1077938836, tf_ss = 47})
    at ../../i386/i386/trap.c:1073
#12 0xc01e1846 in Xint0x80_syscall ()
#13 0x80491ea in ?? ()
#14 0x8048e9d in ?? ()
#15 0x8048b6d in ?? ()
(kgdb) f 11
#11 0xc01ed952 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, 
      tf_edi = 1, tf_esi = -1, tf_ebp = -1077937768, tf_isp = -983613484, 
      tf_ebx = -1077938792, tf_edx = 10, tf_ecx = -1077938928, tf_eax = 5, 
      tf_trapno = 12, tf_err = 2, tf_eip = 672262868, tf_cs = 31, 
      tf_eflags = 647, tf_esp = -1077938836, tf_ss = 47})
    at ../../i386/i386/trap.c:1073
1073		error = (*callp->sy_call)(p, args);
(kgdb) list 1000
995		if (rv != KERN_SUCCESS)
996			return 1;
997	
998		return (0);
999	}
1000	
1001	/*
1002	 * System call request from POSIX system call gate interface to kernel.
1003	 * Like trap(), argument is call by reference.
1004	 */
(kgdb) 
1005	void
1006	syscall(frame)
1007		struct trapframe frame;
1008	{
1009		caddr_t params;
1010		int i;
1011		struct sysent *callp;
1012		struct proc *p = curproc;
1013		u_quad_t sticks;
1014		int error;
# exit

--+QahgC5+KEYLbs62--


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 17: 3: 3 2000
Delivered-To: freebsd-current@freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
	by hub.freebsd.org (Postfix) with ESMTP
	id 36CE637C6AD; Thu, 23 Mar 2000 17:03:01 -0800 (PST)
	(envelope-from kris@FreeBSD.org)
Received: from localhost (kris@localhost)
	by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id RAA48239;
	Thu, 23 Mar 2000 17:03:01 -0800 (PST)
	(envelope-from kris@FreeBSD.org)
X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs
Date: Thu, 23 Mar 2000 17:03:01 -0800 (PST)
From: Kris Kennaway <kris@FreeBSD.org>
To: Chuck Robey <chuckr@picnic.mat.net>
Cc: current@FreeBSD.ORG
Subject: Re: Optimisation patch
In-Reply-To: <Pine.BSF.4.21.0003231837170.47847-100000@picnic.mat.net>
Message-ID: <Pine.BSF.4.21.0003231701500.48015-100000@freefall.freebsd.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Thu, 23 Mar 2000, Chuck Robey wrote:

> On Thu, 23 Mar 2000, Kris Kennaway wrote:
> 
> > Any objections to the following?
> 
> I don't mind at all ... I was wondering about just taking out the ability
> to even USE -O2 in the compiler, but there're probably *some* non-kernel
> related reasons for using it, and we shouldn't block it at that
> point.  Not for FreeBSD, but for some users doing their own code on
> FreeBSD.

Right..I saw the discussion on -stable, and I think it would be a bad idea
as well. gcc -O2 is a tool which isn't always broken (excepting alpha
breakage), so we shouldn't limit its use in the general case.

Kris

----
In God we Trust -- all others must submit an X.509 certificate.
    -- Charles Forsythe <forsythe@alum.mit.edu>



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 17: 4: 3 2000
Delivered-To: freebsd-current@freebsd.org
Received: from fgwmail7.fujitsu.co.jp (fgwmail7.fujitsu.co.jp [192.51.44.37])
	by hub.freebsd.org (Postfix) with ESMTP id DF4E137C54B
	for <freebsd-current@FreeBSD.ORG>; Thu, 23 Mar 2000 17:03:54 -0800 (PST)
	(envelope-from shin@nd.net.fujitsu.co.jp)
Received: from m5.gw.fujitsu.co.jp by fgwmail7.fujitsu.co.jp (8.9.3/3.7W-MX0002-Fujitsu Gateway)
	id KAA03774; Fri, 24 Mar 2000 10:03:49 +0900 (JST)
	(envelope-from shin@nd.net.fujitsu.co.jp)
Received: from chisato.nd.net.fujitsu.co.jp by m5.gw.fujitsu.co.jp (8.9.3/3.7W-0003-Fujitsu Domain Master)
	id KAA24138; Fri, 24 Mar 2000 10:03:47 +0900 (JST)
Received: from localhost (dhcp7173.nd.net.fujitsu.co.jp [10.18.7.173]) by chisato.nd.net.fujitsu.co.jp (8.8.5+2.7Wbeta5/3.3W8chisato-970826) with ESMTP id KAA26448; Fri, 24 Mar 2000 10:03:46 +0900 (JST)
To: imp@village.org
Cc: dillon@apollo.backplane.com, ilmar@ints.ru, nms@otdel-1.org,
	freebsd-current@FreeBSD.ORG
Subject: Re: -current sudden panics :( 
In-Reply-To: <200003231921.MAA42799@harmony.village.org>
References: <200003222201.PAA33948@harmony.village.org>
	<20000323105025W.shin@nd.net.fujitsu.co.jp>
	<200003231921.MAA42799@harmony.village.org>
X-Mailer: Mew version 1.94 on Emacs 20.4 / Mule 4.0 (HANANOEN)
X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000324100446A.shin@nd.net.fujitsu.co.jp>
Date: Fri, 24 Mar 2000 10:04:46 +0900
From: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 16
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> :     This problem should now be fixed, it's probably the problem I just fixed
> :     a moment ago in netinet/if_ether.c based on a thread in -hackers.  The
> :     m_pullup() NULL check in arpintr() was broken, resulting in a NULL
> :     pointer dereference.  
> 
> inoue-san's patch survived the night.  I'll check into your patch and
> give it a try instead.

My patch is just a workaround to avoid m_pullup() when it is
not necessary, and his fix seems to be the real one for the
problem.
But I think my patch to if_rl.c is also better to be applied
for performance reason.

Cheers,
Yoshinobu Inoue


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 18: 9:54 2000
Delivered-To: freebsd-current@freebsd.org
Received: from smtprelay1.adelphia.net (smtprelay1.adelphia.net [64.8.25.6])
	by hub.freebsd.org (Postfix) with ESMTP id C28CB37B506
	for <current@freebsd.org>; Thu, 23 Mar 2000 18:09:49 -0800 (PST)
	(envelope-from pvlad@bigfoot.com)
Received: from bigfoot.com ([24.48.151.218]) by
          smtprelay1.adelphia.net (Netscape Messaging Server 4.05) with
          ESMTP id FRWLZ500.424 for <current@freebsd.org>; Thu, 23 Mar
          2000 21:09:05 -0500 
Message-ID: <38DA88CC.558E41CE@bigfoot.com>
Date: Thu, 23 Mar 2000 16:12:44 -0500
From: Vladik <pvlad@bigfoot.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: current@freebsd.org
Subject: [Q]4.0-Release file system
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Hello,
My FreeBSD partition is installed on a cyl. beyound
1024.  So FreeBSD boot manager does not work.
Howerver with 3.4 release I was able to use
this great boot loader called GRUB.  In there
I could mount a root file system and then load
the kernel.  Something has changed in the 4.0 Release
and while I still can mount the root file system,
the FreeBSD compains that the mounted device
is not the same as specified in /etc/fstab.  What
it means is that GRUB's understanding of the
file system format and the 4.0 mount's understanding
of the ffs are different (that means that ffs has changed).
This guess is also enforced by the fact that I can
no longer mount the FreeBSD partion from Linux
(I tried 2.2.14 kernels and 2.3.51)

What I would like to know first if there any possible
way for me besides GRUB (that does not work now)
to boot my freeBSD either from a harddrive or
from a floppy -- does not matter.

If you think that this message should go to another
news group, please do not hezitate to let me know.

Thank you in advance,
Vladislav


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 18:18:47 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mass.cdrom.com (mg131-026.ricochet.net [204.179.131.26])
	by hub.freebsd.org (Postfix) with ESMTP id 01A7937C520
	for <current@freebsd.org>; Thu, 23 Mar 2000 18:18:42 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Received: from mass.cdrom.com (localhost [127.0.0.1])
	by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id SAA01023;
	Thu, 23 Mar 2000 18:21:39 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Message-Id: <200003240221.SAA01023@mass.cdrom.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To: Vladik <pvlad@bigfoot.com>
Cc: current@freebsd.org
Subject: Re: [Q]4.0-Release file system 
In-reply-to: Your message of "Thu, 23 Mar 2000 16:12:44 EST."
             <38DA88CC.558E41CE@bigfoot.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 23 Mar 2000 18:21:39 -0800
From: Mike Smith <msmith@freebsd.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


Try loading the loader (/boot/loader) rather than the kernel.  You might 
also try using the boot0 bootmanager (see the manpage for boot0cfg) with 
the 'packet' option set, which will DTRT.

You may also need to rebuild boot1/boot2 with the 'packet mode' flags 
set; see the boot1 sources in sys/boot/i386/boot2 for this.

Note that these are experimental suggestions that I've had success with; 
YMMV and these aren't yet ready for prime time.

> Hello,
> My FreeBSD partition is installed on a cyl. beyound
> 1024.  So FreeBSD boot manager does not work.
> Howerver with 3.4 release I was able to use
> this great boot loader called GRUB.  In there
> I could mount a root file system and then load
> the kernel.  Something has changed in the 4.0 Release
> and while I still can mount the root file system,
> the FreeBSD compains that the mounted device
> is not the same as specified in /etc/fstab.  What
> it means is that GRUB's understanding of the
> file system format and the 4.0 mount's understanding
> of the ffs are different (that means that ffs has changed).
> This guess is also enforced by the fact that I can
> no longer mount the FreeBSD partion from Linux
> (I tried 2.2.14 kernels and 2.3.51)
> 
> What I would like to know first if there any possible
> way for me besides GRUB (that does not work now)
> to boot my freeBSD either from a harddrive or
> from a floppy -- does not matter.
> 
> If you think that this message should go to another
> news group, please do not hezitate to let me know.
> 
> Thank you in advance,
> Vladislav
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message
> 

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
\\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 18:37:41 2000
Delivered-To: freebsd-current@freebsd.org
Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148])
	by hub.freebsd.org (Postfix) with ESMTP
	id 0C2AD37BE5E; Thu, 23 Mar 2000 18:37:26 -0800 (PST)
	(envelope-from stuyman@confusion.net)
Received: from confusion.net (user-2ive6db.dialup.mindspring.com [165.247.25.171])
	by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id VAA26243;
	Thu, 23 Mar 2000 21:37:15 -0500 (EST)
Message-ID: <38DAD3F9.E0EBD80B@confusion.net>
Date: Thu, 23 Mar 2000 21:33:29 -0500
From: Laurence Berland <stuyman@confusion.net>
Organization: B.R.A.T.T.
X-Mailer: Mozilla 4.5 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: Eric Sabban <eric@clickrebates.com>,
	Mike Smith <msmith@FreeBSD.ORG>, Forrest Aldrich <forrie@forrie.com>,
	freebsd-current@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG
Subject: Re: 4.0 sysinstall fails to recognize disks
References: <200003231554.HAA01743@mass.cdrom.com> <200003231750.JAA02133@apollo.backplane.com> <38DA5ADE.27FD7481@clickrebates.com> <200003231806.KAA02333@apollo.backplane.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

I just had to do that a few days ago, but it didn't work.  Apparently
DOS is very stupid, and without dding the entire DOS partition it
wouldn't work.  Who knows why.  Low-levels are a bad idea.  I know
someone who managed to ruin a number of disks trying that.

Laurence

Matthew Dillon wrote:
> 
> :I normally wouldn't recommend it. But the same situation with a different (not to be mentioned) OS happened to me.
> :After hours of being frustrated, I decided the scsi controller went south. A cow-orker told me to LL the drive,
> :and voila, magic. These were IBM LVD 10kRPM drives, brand spankin new. I'd recommend updating sysinstall first, if
> :that doesn't work, LL the drives.
> :
> :-eric
> 
>     I really doubt that LLing the drive fixed your problem.  You probably
>     did something else while messing around that wound up fixing it.
> 
>     The simple answer when someone approaches you on the street and suggests
>     that you can fix the world by LLing your hard drive, is "NO" :-).
> 
>     The worst I've ever had to do to a drive to make the system recognize
>     it is zero-out the first few sectors with dd.  That way the system
>     believes that the drive does not have a valid label and lets you install
>     a new one trivially.
> 
>                                                 -Matt
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message

-- 
Laurence Berland, Stuyvesant HS Debate
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Windows 98: n.
        useless extension to a minor patch release for 
        32-bit extensions and a graphical shell for a 
        16-bit patch to an 8-bit operating system 
        originally coded for a 4-bit microprocessor, 
        written by a 2-bit company that can't stand for
        1 bit of competition.
http://stuy.debate.net
icq #7434346                    aol imer E1101
The above email Copyright (C) 2000 Laurence Berland
All rights reserved


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 20:16: 5 2000
Delivered-To: freebsd-current@freebsd.org
Received: from lamb.sas.com (lamb.sas.com [192.35.83.8])
	by hub.freebsd.org (Postfix) with ESMTP
	id 47F6737B660; Thu, 23 Mar 2000 20:15:53 -0800 (PST)
	(envelope-from brdean@unx.sas.com)
Received: from mozart (mozart.unx.sas.com [149.173.6.8])
	by lamb.sas.com (8.9.3/8.9.1) with SMTP id XAA16446;
	Thu, 23 Mar 2000 23:15:48 -0500 (EST)
Received: from dean.pc.sas.com by mozart (5.65c/SAS/Domains/5-6-90)
	id AA10589; Thu, 23 Mar 2000 23:15:17 -0500
Received: (from brdean@localhost)
	by dean.pc.sas.com (8.9.3/8.9.1) id XAA32499;
	Thu, 23 Mar 2000 23:15:16 -0500 (EST)
	(envelope-from brdean)
From: Brian Dean <brdean@unx.sas.com>
Message-Id: <200003240415.XAA32499@dean.pc.sas.com>
Subject: Re: AMI MegaRAID lockup? not accepting commands.
In-Reply-To: <200003232150.NAA02123@mass.cdrom.com> from Mike Smith at "Mar 23,
 2000 01:50:28 pm"
To: Mike Smith <msmith@FreeBSD.ORG>
Date: Thu, 23 Mar 2000 23:15:16 -0500 (EST)
Cc: mw@kpnqwest.ch, freebsd-current@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL61 (25)]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Mike Smith wrote:
> > I've played around changing the spinloop to using DELAY (like the Linux model),
> > but this didn't prevent the controller from either "just" locking up or 
> > crashing the whole machine with it. Changing various other places in a similar
> > manner (like replacing the bcopy() in amr_quartz_get_work() with similar
> > code as in the linux driver to wait for 0xFF to clear) didn't do the trick
> > either. 
> 
> Can you try instead the changes that I just committed to -current?  I 
> think that the problem shows up when the controller is heavily loaded; 
> your patch will keep the load on the controller down, which may mask the 
> 'real' bug.

Just recently (this evening), I was able to get our controller to lock
up with the latest patch.  Previously, with that patch installed, I
must not have been able to tickle the bug just right, and I believe
that Mike based his decision to make that mod based on my lack of a
lockup, which always happened quickly.  That's what made me think that
we'd solved it, but I guess I just got "lucky" on the previous lockups
that happened very quickly, making me think it was more easily
reproduceable that it actually is.

It sounds like Markus may be onto something.

-Brian
-- 
Brian Dean				brdean@unx.sas.com
SAS Institute Inc.			bsd@FreeBSD.ORG


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 20:39:59 2000
Delivered-To: freebsd-current@freebsd.org
Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133])
	by hub.freebsd.org (Postfix) with ESMTP
	id 3516C37B5CD; Thu, 23 Mar 2000 20:39:50 -0800 (PST)
	(envelope-from rcarter@pinyon.org)
Received: (from daemon@localhost)
	by smtp03.primenet.com (8.9.3/8.9.3) id VAA18533;
	Thu, 23 Mar 2000 21:39:18 -0700 (MST)
Received: from ip-26-023.prc.gblx.net(206.165.26.23), claiming to be "pinyon.org"
 via SMTP by smtp03.primenet.com, id smtpdAAANsaadK; Thu Mar 23 21:39:09 2000
Received: from chomsky.Pinyon.ORG (localhost [127.0.0.1])
	by pinyon.org (Postfix) with ESMTP
	id 1681F7F; Thu, 23 Mar 2000 21:38:30 -0700 (MST)
X-Mailer: exmh version 2.1.0 09/18/1999
To: Chuck Robey <chuckr@picnic.mat.net>
Cc: Kris Kennaway <kris@FreeBSD.ORG>, current@FreeBSD.ORG
Subject: Re: Optimisation patch 
In-Reply-To: Message from Chuck Robey <chuckr@picnic.mat.net> 
   of "Thu, 23 Mar 2000 18:39:30 EST." <Pine.BSF.4.21.0003231837170.47847-100000@picnic.mat.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 23 Mar 2000 21:38:30 -0700
From: "Russell L. Carter" <rcarter@pinyon.org>
Message-Id: <20000324043830.1681F7F@pinyon.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


Hi folks,

%On Thu, 23 Mar 2000, Kris Kennaway wrote:
%
%> Any objections to the following?
%
%I don't mind at all ... I was wondering about just taking out the ability
%to even USE -O2 in the compiler, but there're probably *some* non-kernel
%related reasons for using it, and we shouldn't block it at that
%point.  Not for FreeBSD, but for some users doing their own code on
%FreeBSD.

Wrong solution to the problem.  Don't even consider it.

Let me tell you a 4 line story:

Long long time ago a low level research guy with time to burn benchmarked 
*every* RISC system compiler option against *every* GNU compiler option and
determined that the GNU compiler was best.  Thus in 1992 a trusting
closed source default dude was converted to open source.

Right solution:

"Kernel behavior with optimization flags other than -O are strictly
unsupported!" prominantly displayed in make.conf and the various kernel config
option files.  The proposed patch below is too mild.

And then, the bike shed painting people have to be stamped down
some how, when the issue arises.

Russell

%> 
%> Index: make.conf
%> ===================================================================
%> RCS file: /home/ncvs/src/etc/defaults/make.conf,v
%> retrieving revision 1.101
%> diff -u -u -r1.101 make.conf
%> --- make.conf	2000/03/22 00:49:20	1.101
%> +++ make.conf	2000/03/23 23:33:13
%> @@ -9,7 +9,13 @@
%>  # You have to find the things you can put here in the Makefiles and 
%>  # documentation of the source tree.
%>  #
%> -# One, and probably the most common, use could be:
%> +# CFLAGS controls the compiler settings used when compiling C code.
%> +# Note that optimisation settings above -O (-O2, ...) are not recommended
%> +# or supported for compiling the world or the kernel - please revert any
%> +# nonstandard optimisation settings to "-O" before submitting bug reports
%> +# to the developers.
%> +# Note also that at this time the -O2 setting is known to produce BROKEN
%> +# CODE on the Alpha platform.
%>  #
%>  #CFLAGS= -O -pipe
%>  #
%> 
%> ----
%> In God we Trust -- all others must submit an X.509 certificate.
%>     -- Charles Forsythe <forsythe@alum.mit.edu>
%> 
%> 
%> 
%> To Unsubscribe: send mail to majordomo@FreeBSD.org
%> with "unsubscribe freebsd-current" in the body of the message
%> 
%
%----------------------------------------------------------------------------
%Chuck Robey            | Interests include C & Java programming, FreeBSD,
%chuckr@picnic.mat.net  | electronics, communications, and signal processing.
%
%New Year's Resolution:  I will not sphroxify gullible people into looking up
%fictitious words in the dictionary.
%----------------------------------------------------------------------------
%
%
%
%To Unsubscribe: send mail to majordomo@FreeBSD.org
%with "unsubscribe freebsd-current" in the body of the message
%




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 20:51:18 2000
Delivered-To: freebsd-current@freebsd.org
Received: from ws-ilmar.ints.ru (ws-ilmar.ints.ru [194.67.173.16])
	by hub.freebsd.org (Postfix) with ESMTP id 7F4F537B55E
	for <freebsd-current@FreeBSD.ORG>; Thu, 23 Mar 2000 20:51:11 -0800 (PST)
	(envelope-from ilmar@ints.ru)
Received: from localhost (localhost [127.0.0.1])
	by ws-ilmar.ints.ru (8.9.3/8.9.3) with ESMTP id HAA25740;
	Fri, 24 Mar 2000 07:50:57 +0300 (MSK)
Date: Fri, 24 Mar 2000 07:50:57 +0300 (MSK)
From: "Ilmar S. Habibulin" <ilmar@ints.ru>
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>, imp@village.org,
	nms@otdel-1.org, freebsd-current@FreeBSD.ORG
Subject: Re: -current sudden panics :( 
In-Reply-To: <200003231915.LAA03210@apollo.backplane.com>
Message-ID: <Pine.BSF.4.21.0003240750280.25732-100000@ws-ilmar.ints.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Thu, 23 Mar 2000, Matthew Dillon wrote:

>     This problem should now be fixed, it's probably the problem I just fixed
>     a moment ago in netinet/if_ether.c based on a thread in -hackers.  The
>     m_pullup() NULL check in arpintr() was broken, resulting in a NULL
>     pointer dereference.  
Ok. Uptime more than 8 hours, continue testing.



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 21:48:37 2000
Delivered-To: freebsd-current@freebsd.org
Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25])
	by hub.freebsd.org (Postfix) with SMTP id ECE4737B6FC
	for <current@FreeBSD.ORG>; Thu, 23 Mar 2000 21:48:31 -0800 (PST)
	(envelope-from bde@zeta.org.au)
Received: (qmail 25364 invoked from network); 24 Mar 2000 05:48:26 -0000
Received: from bde.zeta.org.au (203.2.228.102)
  by gidora.zeta.org.au with SMTP; 24 Mar 2000 05:48:26 -0000
Date: Fri, 24 Mar 2000 16:48:11 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-Sender: bde@alphplex.bde.org
To: Kris Kennaway <kris@FreeBSD.ORG>
Cc: current@FreeBSD.ORG
Subject: Re: Optimisation patch
In-Reply-To: <Pine.BSF.4.21.0003231533240.33462-100000@freefall.freebsd.org>
Message-ID: <Pine.BSF.4.21.0003241632250.3942-100000@alphplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Thu, 23 Mar 2000, Kris Kennaway wrote:

> Any objections to the following?
> 
> Index: make.conf
> ===================================================================
> RCS file: /home/ncvs/src/etc/defaults/make.conf,v
> retrieving revision 1.101
> diff -u -u -r1.101 make.conf
> --- make.conf	2000/03/22 00:49:20	1.101
> +++ make.conf	2000/03/23 23:33:13
> @@ -9,7 +9,13 @@
>  # You have to find the things you can put here in the Makefiles and 
>  # documentation of the source tree.
>  #
> -# One, and probably the most common, use could be:
> +# CFLAGS controls the compiler settings used when compiling C code.
> +# Note that optimisation settings above -O (-O2, ...) are not recommended
> +# or supported for compiling the world or the kernel - please revert any
> +# nonstandard optimisation settings to "-O" before submitting bug reports
> +# to the developers.
> +# Note also that at this time the -O2 setting is known to produce BROKEN
> +# CODE on the Alpha platform.
>  #
>  #CFLAGS= -O -pipe
>  #

Yes.  make.conf shouldn't even hint that globally changing CFLAGS is
supported or good.  Note that the suggested "most common use" has been
bogus since -pipe was added to the default settings in rev.1.31
(1998/05/01) of sys.mk.

Bruce



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 23:24:48 2000
Delivered-To: freebsd-current@freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
	by hub.freebsd.org (Postfix) with ESMTP
	id 6CF3837B56D; Thu, 23 Mar 2000 23:24:46 -0800 (PST)
	(envelope-from kris@FreeBSD.org)
Received: from localhost (kris@localhost)
	by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id XAA09836;
	Thu, 23 Mar 2000 23:24:46 -0800 (PST)
	(envelope-from kris@FreeBSD.org)
X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs
Date: Thu, 23 Mar 2000 23:24:46 -0800 (PST)
From: Kris Kennaway <kris@FreeBSD.org>
To: Bruce Evans <bde@zeta.org.au>
Cc: current@FreeBSD.ORG
Subject: Re: Optimisation patch
In-Reply-To: <Pine.BSF.4.21.0003241632250.3942-100000@alphplex.bde.org>
Message-ID: <Pine.BSF.4.21.0003232324000.7812-100000@freefall.freebsd.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Fri, 24 Mar 2000, Bruce Evans wrote:

> Yes.  make.conf shouldn't even hint that globally changing CFLAGS is
> supported or good.  Note that the suggested "most common use" has been
> bogus since -pipe was added to the default settings in rev.1.31
> (1998/05/01) of sys.mk.

Hmm. What is the correct way of compiling world with optimisation
or other compiler settings?

Kris

----
In God we Trust -- all others must submit an X.509 certificate.
    -- Charles Forsythe <forsythe@alum.mit.edu>



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 23:41:28 2000
Delivered-To: freebsd-current@freebsd.org
Received: from smtp02.wxs.nl (smtp02.wxs.nl [195.121.6.60])
	by hub.freebsd.org (Postfix) with ESMTP
	id 66F3437B6BC; Thu, 23 Mar 2000 23:41:20 -0800 (PST)
	(envelope-from asmodai@wxs.nl)
Received: from daemon.ninth-circle.org ([195.121.60.48]) by smtp02.wxs.nl
          (Netscape Messaging Server 3.61)  with ESMTP id AAA1A5A;
          Fri, 24 Mar 2000 08:41:18 +0100
Received: (from asmodai@localhost)
	by daemon.ninth-circle.org (8.9.3/8.9.3) id IAA23171;
	Fri, 24 Mar 2000 08:41:14 +0100 (CET)
	(envelope-from asmodai)
Date: Fri, 24 Mar 2000 08:41:13 +0100
From: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl>
To: Dan Moschuk <dan@freebsd.org>
Cc: current@freebsd.org, shin@freebsd.org
Subject: Re: -current, ep and fragment problems.
Message-ID: <20000324084113.A22872@daemon.ninth-circle.org>
References: <20000323145740.A299@spirit.jaded.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <20000323145740.A299@spirit.jaded.net>; from dan@freebsd.org on Thu, Mar 23, 2000 at 02:57:40PM -0500
Organisation: Ninth-Circle Enterprises
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

[cc:'d shin]

-On [20000324 00:04], Dan Moschuk (dan@freebsd.org) wrote:
>
>Is anyone else seeing odd behaviour with a fairly recent -current, an ep
>driver nic card and fragmented packets?

Yes.  And add to that a fxp card as well next to the ep card.

For some weird reason (almost) every packet or datagram which gets
fragmented because it is larger than the MTU will have problems.

This causes tcp stalls.  80% packetloss when pinging a 3.4-S host across
a WAN with a packetsize of 1600 bytes.

I am using natd.  Mayhaps unrelated but my firewall rules give me:

00000 divert 8668 ip from any to any via fxp0
ip_fw_ctl: invalid command
ipfw: setsockopt(IP_FW_ADD): Invalid argument
00100 allow ip from any to any via lo0

nowadays with my March 19th kernel/userland.

A few weeks before this upgrade, when I was still 4.0-CURRENT, this
whole set-up worked fine.

The ep0 card which is also in this machine serves my LAN.  If I try to
use the cvs pserver on this box from another box (ep0 -> fxp0 / 5.0 ->
4.0) It will work up until a moment where nothing less of a ifconfig
down/up of the ep0 driver will help.

But that's different from the fxp0 case with the natd.

Just to be sure:

WAN---ISDN router---(natd)fxp0(daemon)ep0---3Com hub---fxp0(celestial)

-- 
Jeroen Ruigrok vd Werven/Asmodai    asmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
Any fool can make a rule.  And every fool will mind it...


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 23:45:33 2000
Delivered-To: freebsd-current@freebsd.org
Received: from freebsd.dk (freebsd.dk [212.242.42.178])
	by hub.freebsd.org (Postfix) with ESMTP id 54E6237BD20
	for <current@FreeBSD.ORG>; Thu, 23 Mar 2000 23:45:25 -0800 (PST)
	(envelope-from sos@freebsd.dk)
Received: (from sos@localhost)
	by freebsd.dk (8.9.3/8.9.1) id IAA39337;
	Fri, 24 Mar 2000 08:45:07 +0100 (CET)
	(envelope-from sos)
From: Soren Schmidt <sos@freebsd.dk>
Message-Id: <200003240745.IAA39337@freebsd.dk>
Subject: Re: /dev/acd0 related crash?
In-Reply-To: <20000324021659.A1312@hades.hell.gr> from Giorgos Keramidas at "Mar 24, 2000 02:16:59 am"
To: keramida@ceid.upatras.gr
Date: Fri, 24 Mar 2000 08:45:07 +0100 (CET)
Cc: current@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

It seems Giorgos Keramidas wrote:
> I built from sources cvsup'ed about 24 hours ago, my kernel and world,
> this afternoon.  After enabling INVARIANTS and INVARIANT_SUPPORT, I
> booted and tried a lot of things.  Nothing seemed to make the new kernel
> I had (and it's own modules + world) go crazy ;)
> 
> However, when I tried to run cdcontrol on my ATAPI cdrom, the kernel
> paniced and instantly rebooted.  The related kgdb output for the crash
> dump is attached.

Just committed the fix for this braino...

-Søren


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Thu Mar 23 23:56:13 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mrynet.com (mrynet.com [24.234.53.177])
	by hub.freebsd.org (Postfix) with ESMTP id A928737B529
	for <freebsd-current@freebsd.org>; Thu, 23 Mar 2000 23:56:07 -0800 (PST)
	(envelope-from freebsd@mrynet.com)
Received: (from freebsd@localhost)
	by mrynet.com (8.9.3/8.9.3) id XAA02233
	for freebsd-current@freebsd.org; Thu, 23 Mar 2000 23:56:07 -0800 (PST)
	(envelope-from freebsd)
Posted-Date: Thu, 23 Mar 2000 23:56:07 -0800 (PST)
Message-Id: <200003240756.XAA02233@mrynet.com>
From: freebsd@mrynet.com (FreeBSD mailing list)
Date: Thu, 23 Mar 2000 23:56:06 +0000
X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96)
To: freebsd-current@freebsd.org
Subject: fd0: Debugger("d_iocmd botch") called.
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Accessing fd0 (1440) floppies have been impossible with CURRENT
on both test machines here since 4.0 was released.  The following
are as of cvsup yesterday:

 (83) [11:30pm]                
ttyp8:--ROOT--@mrynet (83): dd if=/dev/rfd0.1440 bs=512 >x
dd: /dev/rfd0.1440: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 2.390958 secs (0 bytes/sec)

/var/log/messages indicates:
Mar 23 23:30:09 mrynet /kernel: fd0c: hard error reading fsbn 0 of 0-127 (ST0 40<abnrml> ST1 4<sec_not_fnd> ST2 0
cyl 0 hd 0 sec 2)


 (84) [11:32pm]                         
ttyp8:--ROOT--@mrynet (84): fdformat -f 1440 fd0.1440
Format 1440K floppy `/dev/fd0.1440'? (y/n): y
Processing EEEE^C----------------------------------

/var/log/messages indicates:
Mar 23 23:32:47 mrynet /kernel: Debugger("d_iocmd botch") called.
Mar 23 23:32:49 mrynet /kernel: fd0c: hard error reading fsbn 0 of 0-17 (ST0 40<abnrml> ST1 4<sec_not_fnd> ST2 0
cyl 0 hd 0 sec 2)
Mar 23 23:32:49 mrynet /kernel: fd0c: hard error reading fsbn 0 of 0-17 (ST0 40<abnrml> ST1 4<sec_not_fnd> ST2 0
cyl 0 hd 0 sec 2)
Mar 23 23:32:49 mrynet /kernel: Debugger("d_iocmd botch") called.
Mar 23 23:32:49 mrynet /kernel: fd0c: hard error reading fsbn 18 of 18-35 (ST0 44<abnrml,top_head> ST1
4<sec_not_fnd> ST2 0 cyl 0 hd 1 sec 2)
Mar 23 23:32:49 mrynet /kernel: fd0c: hard error reading fsbn 18 of 18-35 (ST0 44<abnrml,top_head> ST1
4<sec_not_fnd> ST2 0 cyl 0 hd 1 sec 2)
Mar 23 23:32:49 mrynet /kernel: Debugger("d_iocmd botch") called.
Mar 23 23:32:50 mrynet /kernel: fd0c: hard error reading fsbn 36 of 36-53 (ST0 40<abnrml> ST1 4<sec_not_fnd> ST2
0 cyl 1 hd 0 sec 2)
Mar 23 23:32:50 mrynet /kernel: fd0c: hard error reading fsbn 36 of 36-53 (ST0 40<abnrml> ST1 4<sec_not_fnd> ST2
0 cyl 1 hd 0 sec 2)
Mar 23 23:32:50 mrynet /kernel: Debugger("d_iocmd botch") called.
Mar 23 23:32:50 mrynet /kernel: fd0c: hard error reading fsbn 54 of 54-71 (ST0 44<abnrml,top_head> ST1
4<sec_not_fnd> ST2 0 cyl 1 hd 1 sec 2)
Mar 23 23:32:51 mrynet /kernel: fd0c: hard error reading fsbn 54 of 54-71 (ST0 44<abnrml,top_head> ST1
4<sec_not_fnd> ST2 0 cyl 1 hd 1 sec 2)

and on and on, had I let it run without interrupting.

Attempting to write floppies, formatted elsewhere, with dd returns the same.

I don't recall any recent reports about floppy changes or breakage.
I've searched the mailing lists via the web page, but since the searchable
portion of the mailing lists has yet to have its indexes updated this century,
and similarly the browseable portion hasn't been updated since February 20,
I can't do any further checking.
</BOFH_WHINGER_COUNTERACT>

I have indeed replaced with alternate controllers, cables, and actually
even new floppy drives.

Since these floppy drives work in other machines, and the floppies
themselves format without problem elsewhere, I can only suspect CURRENT.

If this is a known issue, could someone drop me information on resolving
it?

If not, could someone with a recent kernel (within a few days) let me know if 
anything similar is experienced please?

dmesg follows below.

Thanks,
-scott
--
Scott G. Akmentins-Taylor     InterNet: staylor@mrynet.com
MRY Systems			        staylor@mrynet.lv
--
(kernel was freshly cvsup'd and built just prior to the stamp below)
Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
	The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #3: Thu Mar 23 21:24:35 PST 2000
    root@mrynet.com:/usr/src/sys/compile/MRYMACH6
Timecounter "i8254"  frequency 1193182 Hz
Timecounter "TSC"  frequency 451023632 Hz
CPU: AMD-K6(tm) 3D processor (451.02-MHz 586-class CPU)
  Origin = "AuthenticAMD"  Id = 0x58c  Stepping = 12
  Features=0x8021bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX>
  AMD Features=0x80000800<SYSCALL,3DNow!>
real memory  = 134217728 (131072K bytes)
avail memory = 125960192 (123008K bytes)
Preloaded elf kernel "kernel" at 0xc038f000.
VESA: v2.0, 8192k memory, flags:0x0, mode table:0xc032c422 (1000022)
VESA: ATI MACH64
K6-family MTRR support enabled (2 registers)
npx0: <math processor> on motherboard
npx0: INT 16 interface
pcib0: <AcerLabs M1541 (Aladdin-V) PCI host bridge> on motherboard
pci0: <PCI bus> on pcib0
pcib1: <AcerLabs M5243 PCI-PCI bridge> at device 1.0 on pci0
pci1: <PCI bus> on pcib1
pci1: <ATI Mach64-GZ graphics accelerator> at 0.0
pci0: <AcerLabs M5237 (Aladdin-V) USB controller> at 2.0 irq 11
isab0: <AcerLabs M1533 portable PCI-ISA bridge> at device 7.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <AcerLabs Aladdin ATA33 controller> port 0xf000-0xf00f,0x374-0x377,0x170-0x17f,0x3f4-0x3f7,0x1f0-0x1ff at device 15.0 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
ed0: <NE2000 PCI Ethernet (ProLAN)> port 0xe000-0xe01f irq 5 at device 18.0 on pci0
ed0: supplying EUI64: 00:20:78:ff:fe:12:07:39
ed0: address 00:20:78:12:07:39, type NE2000 (16 bit) 
ahc0: <Adaptec 2940 Ultra SCSI adapter> port 0xe400-0xe4ff mem 0xed000000-0xed000fff irq 10 at device 20.0 on pci0
ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs
isa0: unexpected tag 14
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: model Generic PS/2 mouse, device ID 0
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
sc0: <System console> on isa0
sc0: VGA <12 virtual consoles, flags=0x200>
fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
pca0 at port 0x40 on isa0
ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode
pps0: <Pulse per second Timing Interface> on ppbus0
ppi0: <Parallel I/O> on ppbus0
lpt0: <Printer> on ppbus0
lpt0: Interrupt-driven port
plip0: <PLIP network interface> on ppbus0
sbc0: <Creative SB AWE64> at port 0x220-0x22f,0x300-0x301,0x388-0x38b irq 9 drq 0,5 on isa0
sbc0: setting card to irq 9, drq 0, 5
pcm1: <SB DSP 4.16> on sbc0
unknown0: <Game> at port 0x200-0x207 on isa0
unknown1: <WaveTable> at port 0x620-0x623 on isa0
IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to accept, logging limited to 100 packets/entry by default
IPv6 packet filtering initialized, default to accept, logging limited to 100 packets/entry
ad0: 19470MB <WDC AC420400D> [39560/16/63] at ata0-master using UDMA33
ad1: 6679MB <Maxtor 87000D8> [14475/15/63] at ata1-master using UDMA33
Waiting 5 seconds for SCSI devices to settle
Mounting root from ufs:/dev/da0a
da1 at ahc0 bus 0 target 3 lun 0
da1: <SEAGATE ST34572W 0876> Fixed Direct Access SCSI-2 device 
da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled
da1: 4340MB (8888924 512 byte sectors: 255H 63S/T 553C)
da0 at ahc0 bus 0 target 0 lun 0
da0: <SEAGATE ST15230W SUN4.2G 0738> Fixed Direct Access SCSI-2 device 
da0: 20.000MB/s transfers (10.000MHz, offset 8, 16bit), Tagged Queueing Enabled
da0: 4095MB (8386733 512 byte sectors: 255H 63S/T 522C)
ed0: starting DAD for fe80:0001::0220:78ff:fe12:0739
ed0: starting DAD for 3ffe:1ce3:0002::0001
ed0: DAD complete for 3ffe:1ce3:0002::0001 - no duplicates found
ed0: DAD complete for fe80:0001::0220:78ff:fe12:0739 - no duplicates found
cd0 at ahc0 bus 0 target 1 lun 0
cd0: <YAMAHA CRW6416S 1.0c> Removable CD-ROM SCSI-2 device 
cd0: 10.000MB/s transfers (10.000MHz, offset 15)
cd0: cd present [207780 x 2048 byte records]


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24  0: 6:59 2000
Delivered-To: freebsd-current@freebsd.org
Received: from dt051n0b.san.rr.com (dt051n0b.san.rr.com [204.210.32.11])
	by hub.freebsd.org (Postfix) with ESMTP
	id E97B037B6C7; Fri, 24 Mar 2000 00:06:55 -0800 (PST)
	(envelope-from Doug@gorean.org)
Received: from gorean.org (doug@master [10.0.0.2])
	by dt051n0b.san.rr.com (8.9.3/8.9.3) with ESMTP id AAA99381;
	Fri, 24 Mar 2000 00:06:55 -0800 (PST)
	(envelope-from Doug@gorean.org)
Message-ID: <38DB221F.E797DA9B@gorean.org>
Date: Fri, 24 Mar 2000 00:06:55 -0800
From: Doug Barton <Doug@gorean.org>
Organization: Triborough Bridge & Tunnel Authority
X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 5.0-CURRENT-0322 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Dan Moschuk <dan@freebsd.org>
Cc: current@freebsd.org
Subject: Re: -current, ep and fragment problems.
References: <20000323145740.A299@spirit.jaded.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Dan Moschuk wrote:
> 
> Is anyone else seeing odd behaviour with a fairly recent -current, an ep
> driver nic card and fragmented packets?

	If I understand things correctly, Matt Dillon and a cast of thousands
just committed a fix to this problem. Try cvsup'ing and make'ing world
and see if that helps.

Good luck,

Doug
-- 
    "So, the cows were part of a dream that dreamed itself into
existence? Is that possible?" asked the student incredulously.
    The master simply replied, "Mu."


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24  0:15:18 2000
Delivered-To: freebsd-current@freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
	by hub.freebsd.org (Postfix) with ESMTP
	id 21BAE37B529; Fri, 24 Mar 2000 00:15:16 -0800 (PST)
	(envelope-from kris@FreeBSD.org)
Received: from localhost (kris@localhost)
	by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id AAA20669;
	Fri, 24 Mar 2000 00:15:16 -0800 (PST)
	(envelope-from kris@FreeBSD.org)
X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs
Date: Fri, 24 Mar 2000 00:15:16 -0800 (PST)
From: Kris Kennaway <kris@FreeBSD.org>
To: Paul Richards <paul@originative.co.uk>
Cc: current@FreeBSD.org
Subject: Re: RSA library problems
In-Reply-To: <38DA4E03.CB2E84A8@originative.co.uk>
Message-ID: <Pine.BSF.4.21.0003240014440.7812-100000@freefall.freebsd.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Thu, 23 Mar 2000, Paul Richards wrote:

> I stuck a dlerror() in there and the problem is
> 
> usr/lib/librsaINTL.so: Undefined symbol "BN_mod_exp_mont"

This symbol is defined in bn_ext.c and should be compiled into libcrypto -
can you verify yours has it?

Kris

----
In God we Trust -- all others must submit an X.509 certificate.
    -- Charles Forsythe <forsythe@alum.mit.edu>



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24  0:17:25 2000
Delivered-To: freebsd-current@freebsd.org
Received: from spirit.jaded.net (liv3-3.hamilton.idirect.com [209.161.208.3])
	by hub.freebsd.org (Postfix) with ESMTP id 9349937B885
	for <current@freebsd.org>; Fri, 24 Mar 2000 00:17:22 -0800 (PST)
	(envelope-from dan@spirit.jaded.net)
Received: (from dan@localhost)
	by spirit.jaded.net (8.9.3/8.9.3) id DAA06782;
	Fri, 24 Mar 2000 03:17:33 -0500 (EST)
Date: Fri, 24 Mar 2000 03:17:33 -0500
From: Dan Moschuk <dan@freebsd.org>
To: Doug Barton <Doug@gorean.org>
Cc: current@freebsd.org
Subject: Re: -current, ep and fragment problems.
Message-ID: <20000324031733.A6743@spirit.jaded.net>
References: <20000323145740.A299@spirit.jaded.net> <38DB221F.E797DA9B@gorean.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <38DB221F.E797DA9B@gorean.org>; from Doug@gorean.org on Fri, Mar 24, 2000 at 12:06:55AM -0800
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


| > Is anyone else seeing odd behaviour with a fairly recent -current, an ep
| > driver nic card and fragmented packets?
| 
| 	If I understand things correctly, Matt Dillon and a cast of thousands
| just committed a fix to this problem. Try cvsup'ing and make'ing world
| and see if that helps.

Different problems, I think.  I downgraded if_ep.c to revision 1.95 and
the problem went away.  Matthew Dodd believes he knows where the problem
is, so it should be fixed soon.

-- 
Dan Moschuk (TFreak!dan@freebsd.org)
"Waste not fresh tears on old griefs."


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24  0:43:20 2000
Delivered-To: freebsd-current@freebsd.org
Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36])
	by hub.freebsd.org (Postfix) with ESMTP
	id 8FB2E37B6A2; Fri, 24 Mar 2000 00:43:17 -0800 (PST)
	(envelope-from shin@nd.net.fujitsu.co.jp)
Received: from m5.gw.fujitsu.co.jp by fgwmail6.fujitsu.co.jp (8.9.3/3.7W-MX0002-Fujitsu Gateway)
	id RAA03816; Fri, 24 Mar 2000 17:43:15 +0900 (JST)
	(envelope-from shin@nd.net.fujitsu.co.jp)
Received: from chisato.nd.net.fujitsu.co.jp by m5.gw.fujitsu.co.jp (8.9.3/3.7W-0003-Fujitsu Domain Master)
	id RAA10555; Fri, 24 Mar 2000 17:43:15 +0900 (JST)
Received: from localhost (dhcp7173.nd.net.fujitsu.co.jp [10.18.7.173]) by chisato.nd.net.fujitsu.co.jp (8.8.5+2.7Wbeta5/3.3W8chisato-970826) with ESMTP id RAA12958; Fri, 24 Mar 2000 17:43:14 +0900 (JST)
To: asmodai@wxs.nl
Cc: dan@FreeBSD.ORG, current@FreeBSD.ORG
Subject: Re: -current, ep and fragment problems.
In-Reply-To: <20000324084113.A22872@daemon.ninth-circle.org>
References: <20000323145740.A299@spirit.jaded.net>
	<20000324084113.A22872@daemon.ninth-circle.org>
X-Mailer: Mew version 1.94 on Emacs 20.4 / Mule 4.0 (HANANOEN)
X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000324174412E.shin@nd.net.fujitsu.co.jp>
Date: Fri, 24 Mar 2000 17:44:12 +0900
From: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 14
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> [cc:'d shin]

:-) I have only fxp and fe for 4.0/5.0 machines at my work
place, but I have a 4.0 machine with ep at my home.  I think
I'can test it tonight if it also happens in my environment.

As far as I confirmed it here, many pinging with -s 1600 won't
make any problems between my 3.x/4.0/5.0 machines with fxp/fe.
Also I tried to set mtu 1200 to my fxp, and login other 
machines with mtu 1500, and did `ls -lR /`, and also there
seems to be no problem.

Cheers,
Yoshinobu Inoue


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24  0:48:30 2000
Delivered-To: freebsd-current@freebsd.org
Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25])
	by hub.freebsd.org (Postfix) with SMTP id B17A137B672
	for <current@FreeBSD.org>; Fri, 24 Mar 2000 00:48:26 -0800 (PST)
	(envelope-from bde@zeta.org.au)
Received: (qmail 31882 invoked from network); 24 Mar 2000 08:48:23 -0000
Received: from bde.zeta.org.au (203.2.228.102)
  by gidora.zeta.org.au with SMTP; 24 Mar 2000 08:48:23 -0000
Date: Fri, 24 Mar 2000 19:48:08 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-Sender: bde@alphplex.bde.org
To: Kris Kennaway <kris@FreeBSD.org>
Cc: current@FreeBSD.org
Subject: Re: Optimisation patch
In-Reply-To: <Pine.BSF.4.21.0003232324000.7812-100000@freefall.freebsd.org>
Message-ID: <Pine.BSF.4.21.0003241944400.4121-100000@alphplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Thu, 23 Mar 2000, Kris Kennaway wrote:

> On Fri, 24 Mar 2000, Bruce Evans wrote:
> 
> > Yes.  make.conf shouldn't even hint that globally changing CFLAGS is
> > supported or good.  Note that the suggested "most common use" has been
> > bogus since -pipe was added to the default settings in rev.1.31
> > (1998/05/01) of sys.mk.
> 
> Hmm. What is the correct way of compiling world with optimisation
> or other compiler settings?

`make world'.  Optimization is in the default settings (-O).

Bruce



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24  0:59:46 2000
Delivered-To: freebsd-current@freebsd.org
Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36])
	by hub.freebsd.org (Postfix) with ESMTP
	id 9135937BB8B; Fri, 24 Mar 2000 00:59:43 -0800 (PST)
	(envelope-from shin@nd.net.fujitsu.co.jp)
Received: from m2.gw.fujitsu.co.jp by fgwmail6.fujitsu.co.jp (8.9.3/3.7W-MX0002-Fujitsu Gateway)
	id RAA07521; Fri, 24 Mar 2000 17:59:43 +0900 (JST)
	(envelope-from shin@nd.net.fujitsu.co.jp)
Received: from chisato.nd.net.fujitsu.co.jp by m2.gw.fujitsu.co.jp (8.9.3/3.7W-0003-Fujitsu Domain Master)
	id RAA13394; Fri, 24 Mar 2000 17:59:42 +0900 (JST)
Received: from localhost (dhcp7173.nd.net.fujitsu.co.jp [10.18.7.173]) by chisato.nd.net.fujitsu.co.jp (8.8.5+2.7Wbeta5/3.3W8chisato-970826) with ESMTP id RAA13499; Fri, 24 Mar 2000 17:59:41 +0900 (JST)
To: asmodai@wxs.nl
Cc: dan@FreeBSD.ORG, current@FreeBSD.ORG
Subject: Re: -current, ep and fragment problems.
In-Reply-To: <20000324174412E.shin@nd.net.fujitsu.co.jp>
References: <20000323145740.A299@spirit.jaded.net>
	<20000324084113.A22872@daemon.ninth-circle.org>
	<20000324174412E.shin@nd.net.fujitsu.co.jp>
X-Mailer: Mew version 1.94 on Emacs 20.4 / Mule 4.0 (HANANOEN)
X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000324180040G.shin@nd.net.fujitsu.co.jp>
Date: Fri, 24 Mar 2000 18:00:40 +0900
From: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 9
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> Also I tried to set mtu 1200 to my fxp, and login other 
> machines with mtu 1500, and did `ls -lR /`, and also there
> seems to be no problem.

Woops, this latter check was meaningless for checking
fragments. No fragments were happening due to tcp mss
negotiation and path mtu discovery.

Yoshinobu Inoue


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24  1:46:30 2000
Delivered-To: freebsd-current@freebsd.org
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131])
	by hub.freebsd.org (Postfix) with ESMTP id 4FE5037B54F
	for <current@FreeBSD.ORG>; Fri, 24 Mar 2000 01:46:25 -0800 (PST)
	(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1])
	by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id KAA02236;
	Fri, 24 Mar 2000 10:45:55 +0100 (CET)
	(envelope-from phk@critter.freebsd.dk)
To: Greg Lehey <grog@lemis.com>
Cc: Alfred Perlstein <bright@wintelcom.net>,
	Matthew Dillon <dillon@apollo.backplane.com>, current@FreeBSD.ORG
Subject: Re: patches for test / review 
In-reply-to: Your message of "Thu, 23 Mar 2000 15:28:10 PST."
             <20000323152810.D9318@mojave.worldwide.lemis.com> 
Date: Fri, 24 Mar 2000 10:45:55 +0100
Message-ID: <2234.953891155@critter.freebsd.dk>
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <20000323152810.D9318@mojave.worldwide.lemis.com>, Greg Lehey writes
:

>> Hmm, try to keep vinum/RAID5 in the picture when you look at this
>> code, it complicated matters a lot.
>
>I don't think it's that relevant, in fact.

Yes it is, because the CPU needs to read the buffers to calculate
the parity, it cannot just DMA the data out into hardware like a
scsi controller can do.

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24  3:57:43 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id 0955737B54F
	for <freebsd-current@freebsd.org>; Fri, 24 Mar 2000 03:57:41 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id DAA10683;
	Fri, 24 Mar 2000 03:57:40 -0800 (PST)
	(envelope-from dillon)
Date: Fri, 24 Mar 2000 03:57:40 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003241157.DAA10683@apollo.backplane.com>
To: freebsd-current@freebsd.org
Subject: Anyone know why the syscall interface is using the doreti mechanism?
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

    I understand why interrupts use the doreti mechanism.  I don't understand
    why the syscall interface traps have to use it.  As far as I can tell,
    the cpl stuff does not have to be checked at all, the spl does not have
    to be set to 0 (it damn well better already be 0!), pending interrupts
    should not have to be checked because interrupts are operating just fine
    and any code that raises the spl will have dropped it prior to returning,
    So really only astpending needs to be checked... which can be done inside
    syscall() rather then doreti.

    What am I doing?  I'm experimenting with trying to remove the MP lock 
    from the syscall path (in exception.s and trap.c).  I added a per-syscall
    flag to tell syscall() whether any given syscall is MP safe or not,
    and if the syscall IS MP safe then the entire nominal path can be run
    without obtaining the MP lock.

    Alfred tried to do this several months ago but the SMP code was still
    too messy.  The SMP code is still messy, but there has been lots of
    cleanup between then and now.

    Yes, I have, in fact, successfully taken the MP lock out of the entire 
    syscall path (ok ok, I get the lock for things like ktrace and other
    non-critical-path items).  I'm running a buildworld right now and it
    hasn't crashed yet!

    This is surprising because it is almost 4:00 a.m. and the blessed thing
    actually rebooted normally the first time after I hacked in the changes.

    On a 2-way SMP P-III 450 a single process timing getuid() calls results 
    in about 1.06 uS (instead of 1.6 uS) per call, and when I have two
    processes timing they can each do it in 1.3 uS (instead of 4.8 uS with
    the MP lock).  Hoya!  Even the syscalls that need the MP lock gain a
    little.

    It was all very straightforward except for the doreti stuff that
    the two syscall gates in i386/i386/excep4tion.s return through.
    Now, I know I MUST be missing something... but the friggin system
    is working!  No lockups or anything.  I'm confident that if I *AM* 
    missing something it will be relatively easy to fix.   For the doreti
    stuff I, well, I ripped it out and replaced it with a few pops and an
    iret.  

    So question #1:  Why is my system still working, what I did has *got*
    to be illegal!  The darned thing is doing a buildworld as I type...
    still no crash.  It isn't getting stuck.  Nothing, nada.  Normal
    boring operation.  Not even a cool panic!

    I also have a second question.  As far as I can tell, the fuword() and
    copyin() functions are SMP safe (don't need the MP lock).  As far as I
    can tell if they cause a fault the fault trap will obtain the MP lock
    as necessary.  Anyone know for sure?

    (Note: I haven't tried taking copyout() or suword() out of the MP lock
    yet, I'm much less certain about them being MP safe).

    No patches available yet, I want to refine this a little more before
    I present it.  So far it's quite clean.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24  4:14:13 2000
Delivered-To: freebsd-current@freebsd.org
Received: from server.baldwin.cx (jobaldwi.campus.vt.edu [198.82.67.146])
	by hub.freebsd.org (Postfix) with ESMTP id 2247C37B623
	for <freebsd-current@FreeBSD.org>; Fri, 24 Mar 2000 04:14:09 -0800 (PST)
	(envelope-from jhb@FreeBSD.org)
Received: from john.baldwin.cx (john [10.0.0.2])
	by server.baldwin.cx (8.9.3/8.9.3) with ESMTP id HAA78741;
	Fri, 24 Mar 2000 07:13:49 -0500 (EST)
	(envelope-from jhb@FreeBSD.org)
Message-Id: <200003241213.HAA78741@server.baldwin.cx>
X-Mailer: XFMail 1.4.0 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <20000323075944.B18056@keltia.freenix.fr>
Date: Fri, 24 Mar 2000 07:13:49 -0500 (EST)
From: John Baldwin <jhb@FreeBSD.org>
To: Ollivier Robert <roberto@keltia.freenix.fr>
Subject: Re: /boot/loader is making my VAIO reboot
Cc: "FreeBSD Current Users' list" <freebsd-current@FreeBSD.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


On 23-Mar-00 Ollivier Robert wrote:
> According to Daniel C. Sobral:
>> Or just pressing space when the countdown message first appears...
> 
> No time for that.

My guess is that it is dying trying to load the kernel, since those are where the
recent changes were.  Try putting something simple in loader.rc, like just 'lsdev'.
Basically, we need a way to make the loader boot and not load anything, then you
can try to load the kernel at your leisure to ensure that is what is breaking.

-- 

John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24  4:22:22 2000
Delivered-To: freebsd-current@freebsd.org
Received: from chmls05.mediaone.net (ne.mediaone.net [24.128.1.70])
	by hub.freebsd.org (Postfix) with ESMTP id 2D23637B579
	for <freebsd-current@FreeBSD.ORG>; Fri, 24 Mar 2000 04:22:14 -0800 (PST)
	(envelope-from bloom@acm.org)
Received: from acm.org (reyim.ne.mediaone.net [24.218.251.241])
	by chmls05.mediaone.net (8.8.7/8.8.7) with ESMTP id HAA16609;
	Fri, 24 Mar 2000 07:21:50 -0500 (EST)
Message-ID: <38DB5DDE.874FB228@acm.org>
Date: Fri, 24 Mar 2000 07:21:50 -0500
From: Jim Bloom <bloom@acm.org>
X-Mailer: Mozilla 4.72 [en]C-MOENE  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: FreeBSD mailing list <freebsd@mrynet.com>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: fd0: Debugger("d_iocmd botch") called.
References: <200003240756.XAA02233@mrynet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Upgrade sys/vm/swap_pager.c to the current version.  There was a bug there which
has been fixed.

Jim Bloom
bloom@acm.org

FreeBSD mailing list wrote:
> 
> 
> /var/log/messages indicates:
> Mar 23 23:32:47 mrynet /kernel: Debugger("d_iocmd botch") called.
> Mar 23 23:32:49 mrynet /kernel: fd0c: hard error reading fsbn 0 of 0-17 (ST0 40<abnrml> ST1 4<sec_not_fnd> ST2 0
> cyl 0 hd 0 sec 2)


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24  6:25: 4 2000
Delivered-To: freebsd-current@freebsd.org
Received: from matrix.eurocontrol.fr (matrix.eurocontrol.fr [147.196.254.254])
	by hub.freebsd.org (Postfix) with ESMTP
	id 8B2C337B5B2; Fri, 24 Mar 2000 06:24:52 -0800 (PST)
	(envelope-from roberto@eurocontrol.fr)
Received: from caerdonn.eurocontrol.fr (caerdonn.eurocontrol.fr [147.196.5.62])
	by matrix.eurocontrol.fr (Postfix) with ESMTP
	id 19F905942; Fri, 24 Mar 2000 15:24:51 +0100 (CET)
	(envelope-from roberto@caerdonn.eurocontrol.fr)
Received: by caerdonn.eurocontrol.fr (Postfix, from userid 1193)
	id 8D5964E2D; Fri, 24 Mar 2000 15:24:50 +0100 (CET)
Date: Fri, 24 Mar 2000 15:24:50 +0100
From: Ollivier Robert <roberto@eurocontrol.fr>
To: John Baldwin <jhb@FreeBSD.org>
Cc: freebsd-current@FreeBSD.org
Subject: Re: /boot/loader is making my VAIO reboot
Message-ID: <20000324152450.A68608@caerdonn.eurocontrol.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
X-Operating-System: FreeBSD 5.0-CURRENT
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> My guess is that it is dying trying to load the kernel, since those are

It is rebooting before /boot/loader.rc because none of the "key" commands
I've put there are executed.

> where th e recent changes were.  Try putting something simple in
> loader.rc, like just 'lsde v'.  Basically, we need a way to make the
> loader boot and not load anything, then you can try to load the kernel at
> your leisure to ensure that is what is breaking.

The new problem I have is that after inserting the "key" in various places
in loader.rc (including at the end) and trying to load another kernel, I
can't break the boot and /kernel is hanging the machine (Neomagic problem).

I'll boot on the floppy tonight and try to correct these.

I rebooted because the kernel was hanging during compilation of a new
kernel... The disk was completely hung but I was able to ^C "make".

Everything was froken on disk access till I ^C the build. It is getting
weirder...
-- 
Ollivier ROBERT -=- Eurocontrol EEC/TEC -=- Ollivier.Robert@eurocontrol.fr
The Postman hits! The Postman hits! You have new mail.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24  7:29:47 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mimer.webgiro.com (mimer.webgiro.com [212.209.29.5])
	by hub.freebsd.org (Postfix) with ESMTP id C8D6437B758
	for <freebsd-current@freebsd.org>; Fri, 24 Mar 2000 07:29:42 -0800 (PST)
	(envelope-from abial@webgiro.com)
Received: by mimer.webgiro.com (Postfix, from userid 66)
	id C83A02DC07; Fri, 24 Mar 2000 16:33:55 +0100 (CET)
Received: by mx.webgiro.com (Postfix, from userid 1001)
	id 8D4E17811; Fri, 24 Mar 2000 16:28:05 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by mx.webgiro.com (Postfix) with ESMTP id 7F0C110E17
	for <freebsd-current@freebsd.org>; Fri, 24 Mar 2000 16:28:05 +0100 (CET)
Date: Fri, 24 Mar 2000 16:28:05 +0100 (CET)
From: Andrzej Bialecki <abial@webgiro.com>
To: freebsd-current@freebsd.org
Subject: Dynamic sysctls - patches for review
Message-ID: <Pine.BSF.4.20.0003241623050.31345-100000@mx.webgiro.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Hi,

Inspired by PR kern/16928 I implemented completely dynamic
creation/deletion of sysctl trees at runtime. The patches (relative to
-current) can be found at:

	http://www.freebsd.org/~abial/dyn_sysctl.tgz

Included is an example of KLD that creates some subtrees when loaded, and
deletes them before unloading.

I'd appreciate some feedback. Thanks!


Andrzej Bialecki

//  <abial@webgiro.com> WebGiro AB, Sweden (http://www.webgiro.com)
// -------------------------------------------------------------------
// ------ FreeBSD: The Power to Serve. http://www.freebsd.org --------
// --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ----




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24  7:36:48 2000
Delivered-To: freebsd-current@freebsd.org
Received: from server.baldwin.cx (jobaldwi.campus.vt.edu [198.82.67.146])
	by hub.freebsd.org (Postfix) with ESMTP
	id 37DF037B52D; Fri, 24 Mar 2000 07:36:35 -0800 (PST)
	(envelope-from jhb@FreeBSD.org)
Received: from john.baldwin.cx (john [10.0.0.2])
	by server.baldwin.cx (8.9.3/8.9.3) with ESMTP id KAA78949;
	Fri, 24 Mar 2000 10:36:31 -0500 (EST)
	(envelope-from jhb@FreeBSD.org)
Message-Id: <200003241536.KAA78949@server.baldwin.cx>
X-Mailer: XFMail 1.4.0 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Date: Fri, 24 Mar 2000 10:36:31 -0500 (EST)
From: John Baldwin <jhb@FreeBSD.org>
To: current@FreeBSD.org, peter@FreeBSD.org
Subject: sysinstall broken :(
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Hmph, it seems sysinstall (and thus make release) is broken in -current:

cc -O -pipe -Wall -I/usr/src/release/sysinstall/../../gnu/lib/libdialog
-I/usr/obj/usr/src/release/sysinstall -I/usr/src/release/sysinstall/../../sys   -c
/usr/src/release/sysinstall/kget.c
/usr/src/release/sysinstall/kget.c: In function `kget':
/usr/src/release/sysinstall/kget.c:83: sizeof applied to an incomplete type
/usr/src/release/sysinstall/kget.c:85: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:86: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:89: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:90: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:92: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:92: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:94: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:96: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:96: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:98: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:100: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:100: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:102: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:104: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:104: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:106: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:108: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:108: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:111: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:111: dereferencing pointer to incomplete type
/usr/src/release/sysinstall/kget.c:113: sizeof applied to an incomplete type
*** Error code 1

Stop in /usr/src/release/sysinstall.
*** Error code 1

Stop in /usr/src/release.
*** Error code 1

Stop in /usr/source/src/release.

All of these seem to be related to 'struct isa_device'.  It seems that when
the userconfig in the kernel was changed to use 'struct uc_device' instead,
that change wasn't propogated out to sysinstall.  This patch fixes all that:


Index: sys/i386/i386/userconfig.c
===================================================================
RCS file: /usr/cvs/src/sys/i386/i386/userconfig.c,v
retrieving revision 1.178
diff -u -r1.178 userconfig.c
--- sys/i386/i386/userconfig.c  2000/03/19 12:57:49     1.178
+++ sys/i386/i386/userconfig.c  2000/03/24 15:18:44
@@ -112,26 +112,6 @@
 #include <machine/md_var.h>
 #include <machine/limits.h>
 
-#define _I386_ISA_ISA_DEVICE_H_
-
-/*
- * Per device structure.  This just happens to resemble the old isa_device
- * but that is by accident.  It is NOT the same.
- */
-struct uc_device {
-       int     id_id;          /* device id */
-       char    *id_name;       /* device name */
-       int     id_iobase;      /* base i/o address */
-       u_int   id_irq;         /* interrupt request */
-       int     id_drq;         /* DMA request */
-       caddr_t id_maddr;       /* physical i/o memory address on bus (if any)*/
-       int     id_msize;       /* size of i/o memory */
-       int     id_unit;        /* unit number */
-       int     id_flags;       /* flags */
-       int     id_enabled;     /* is device enabled */
-       struct uc_device *id_next; /* used in uc_devlist in userconfig() */
-};
-
 #undef NPNP
 #define NPNP 0
 
@@ -141,6 +121,7 @@
 
 static MALLOC_DEFINE(M_DEVL, "uc_devlist", "uc_device lists in userconfig()");
 
+#include <machine/uc_device.h>
 static struct uc_device *uc_devlist;   /* list read by kget to extract changes */
 static struct uc_device *uc_devtab;    /* fake uc_device table */
 
Index: sys/i386/include/uc_device.h
===================================================================
RCS file: uc_device.h
diff -N uc_device.h
--- /dev/null   Fri Mar 24 02:17:20 2000
+++ uc_device.h Fri Mar 24 08:36:40 2000
@@ -0,0 +1,75 @@
+/**
+ ** Copyright (c) 1995
+ **      Michael Smith, msmith@freebsd.org.  All rights reserved.
+ **
+ ** This code contains a module marked :
+
+ * Copyright (c) 1991 Regents of the University of California.
+ * All rights reserved.
+ * Copyright (c) 1994 Jordan K. Hubbard
+ * All rights reserved.
+ * Copyright (c) 1994 David Greenman
+ * All rights reserved.
+ *
+ * Many additional changes by Bruce Evans
+ *
+ * This code is derived from software contributed by the
+ * University of California Berkeley, Jordan K. Hubbard,
+ * David Greenman and Bruce Evans.
+
+ ** As such, it contains code subject to the above copyrights.
+ ** The module and its copyright can be found below.
+ ** 
+ ** Redistribution and use in source and binary forms, with or without
+ ** modification, are permitted provided that the following conditions
+ ** are met:
+ ** 1. Redistributions of source code must retain the above copyright
+ **    notice, this list of conditions and the following disclaimer as
+ **    the first lines of this file unmodified.
+ ** 2. Redistributions in binary form must reproduce the above copyright
+ **    notice, this list of conditions and the following disclaimer in the
+ **    documentation and/or other materials provided with the distribution.
+ ** 3. All advertising materials mentioning features or use of this software
+ **    must display the following acknowledgment:
+ **      This product includes software developed by Michael Smith.
+ ** 4. The name of the author may not be used to endorse or promote products
+ **    derived from this software without specific prior written permission.
+ **
+ ** THIS SOFTWARE IS PROVIDED BY MICHAEL SMITH ``AS IS'' AND ANY EXPRESS OR
+ ** IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ ** OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ ** IN NO EVENT SHALL MICHAEL SMITH BE LIABLE FOR ANY DIRECT, INDIRECT,
+ ** INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ ** NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ ** DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ ** THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ ** (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ ** THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ **
+ ** $FreeBSD: src/sys/i386/i386/userconfig.c,v 1.178 2000/03/19 12:57:49 peter Exp $
+ **/
+
+#ifndef _I386_MACHINE_UC_DEVICE_H
+#define _I386_MACHINE_UC_DEVICE_H
+
+#define _I386_ISA_ISA_DEVICE_H_
+
+/*
+ * Per device structure.  This just happens to resemble the old isa_device
+ * but that is by accident.  It is NOT the same.
+ */
+struct uc_device {
+       int     id_id;          /* device id */
+       char    *id_name;       /* device name */
+       int     id_iobase;      /* base i/o address */
+       u_int   id_irq;         /* interrupt request */
+       int     id_drq;         /* DMA request */
+       caddr_t id_maddr;       /* physical i/o memory address on bus (if any)*/
+       int     id_msize;       /* size of i/o memory */
+       int     id_unit;        /* unit number */
+       int     id_flags;       /* flags */
+       int     id_enabled;     /* is device enabled */
+       struct uc_device *id_next; /* used in uc_devlist in userconfig() */
+};
+
+#endif
Index: release/sysinstall/Makefile
===================================================================
RCS file: /usr/cvs/src/release/sysinstall/Makefile,v
retrieving revision 1.92
diff -u -r1.92 Makefile
--- release/sysinstall/Makefile 2000/02/11 09:12:17     1.92
+++ release/sysinstall/Makefile 2000/03/24 15:34:23
@@ -18,7 +18,6 @@
        keymap.h
 
 CFLAGS+= -Wall -I${.CURDIR}/../../gnu/lib/libdialog -I${.OBJDIR}
-CFLAGS+= -I${.CURDIR}/../../sys
 .if ${MACHINE_ARCH} != "i386" || defined(X_AS_PKG)
 CFLAGS+= -DX_AS_PKG
 .endif
Index: release/sysinstall/kget.c
===================================================================
RCS file: /usr/cvs/src/release/sysinstall/kget.c,v
retrieving revision 1.14
diff -u -r1.14 kget.c
--- release/sysinstall/kget.c   1999/09/04 16:01:14     1.14
+++ release/sysinstall/kget.c   2000/03/24 15:29:08
@@ -37,7 +37,7 @@
 
 #include "sysinstall.h"
 #include <sys/sysctl.h>
-#include <i386/isa/isa_device.h>
+#include <machine/uc_device.h>
 
 int
 kget(char *out)
@@ -47,7 +47,7 @@
     char *mib1 = "machdep.uc_devlist";
     char name[9];
     FILE *fout = NULL;
-    struct isa_device *id;
+    struct uc_device *id;
     char *p;
  
     /* create the output file; if we end up not writing to it, we'll 
@@ -79,8 +79,8 @@
 
     i = 0;
     while (i < len) {
-       id = (struct isa_device *)(buf + i);
-       p = (buf + i + sizeof(struct isa_device));
+       id = (struct uc_device *)(buf + i);
+       p = (buf + i + sizeof(struct uc_device));
        strncpy(name, p, 8);
        if (!id->id_enabled) {
            bytes_written += fprintf(fout, "di %s%d\n", name, id->id_unit);
@@ -110,7 +110,7 @@
            bytes_written += fprintf(fout, "f %s%d %#x\n", name,
                                     id->id_unit, id->id_flags);
        }
-       i += sizeof(struct isa_device) + 8;
+       i += sizeof(struct uc_device) + 8;
     }
 
 bail:


Comments?

-- 

John Baldwin <jobaldwi@vt.edu> -- http://www.cslab.vt.edu/~jobaldwi/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24  7:55:45 2000
Delivered-To: freebsd-current@freebsd.org
Received: from rjk191.rh.psu.edu (RJK191.rh.psu.edu [128.118.193.182])
	by hub.freebsd.org (Postfix) with ESMTP id F015A37B752
	for <freebsd-current@freebsd.org>; Fri, 24 Mar 2000 07:55:39 -0800 (PST)
	(envelope-from ray@rjk191.rh.psu.edu)
Received: (from ray@localhost)
	by rjk191.rh.psu.edu (8.9.3/8.9.3) id KAA01631
	for freebsd-current@freebsd.org; Fri, 24 Mar 2000 10:55:34 -0500 (EST)
	(envelope-from ray)
Date: Fri, 24 Mar 2000 10:55:34 -0500
From: Ray Kohler <ray@rjk191.rh.psu.edu>
To: freebsd-current@freebsd.org
Subject: NOUUCP knob and /etc/uucp
Message-ID: <20000324105534.A1602@rjk191.rh.psu.edu>
Reply-To: rjk191@psu.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

I was just noticing that the files in /etc/uucp are installed anyway
if you set NOUUCP, whereas those in /etc/ssh and /etc/ssl are
affected by their respective knobs. Could /etc/uucp be wrapped
around the NOUUCP knob?

-- 
Ray Kohler <rjk191@psu.edu>
Commitment, n.:
	Commitment can be illustrated by a breakfast of ham and eggs.
The chicken was involved, the pig was committed.


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24  9:15:51 2000
Delivered-To: freebsd-current@freebsd.org
Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.139.170])
	by hub.freebsd.org (Postfix) with ESMTP id 92B5B37B621
	for <freebsd-current@FreeBSD.org>; Fri, 24 Mar 2000 09:15:46 -0800 (PST)
	(envelope-from brian@Awfulhak.org)
Received: from hak.lan.Awfulhak.org (hak.nat.Awfulhak.org [172.31.0.12])
	by storm.FreeBSD.org.uk (8.9.3/8.9.3) with ESMTP id RAA44300;
	Fri, 24 Mar 2000 17:15:43 GMT
	(envelope-from brian@Awfulhak.org)
Received: from hak.lan.Awfulhak.org (localhost [127.0.0.1])
	by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id RAA04894;
	Fri, 24 Mar 2000 17:15:39 GMT
	(envelope-from brian@hak.lan.Awfulhak.org)
Message-Id: <200003241715.RAA04894@hak.lan.Awfulhak.org>
X-Mailer: exmh version 2.1.1 10/15/1999
To: Randy Bush <randy@psg.com>
Cc: FreeBSD Current <freebsd-current@FreeBSD.org>,
	brian@hak.lan.Awfulhak.org
Subject: Re: ppp oddity 
In-Reply-To: Message from Randy Bush <randy@psg.com> 
   of "Fri, 24 Mar 2000 06:26:07 +0900." <E12YF7H-00009F-00@roam.psg.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 24 Mar 2000 17:15:39 +0000
From: Brian Somers <brian@Awfulhak.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Check out http://www.FreeBSD.org/FAQ/userppp.html.

The remote end is reflecting your data back at you.

> usually ppp from laptop (3.4+pao) to home (4.0-stable) works fine.  and then
> sometimes it will get stuck in the following mode three N in a row.
> 
> ppp[547]: tun0: Chat: Send: AT^M 
> ppp[547]: tun0: Chat: Expect(5): OK 
> ppp[547]: tun0: Chat: Received: AT^M^M 
> ppp[547]: tun0: Chat: Received: OK^M 
> ppp[547]: tun0: Chat: Send: ATE1Q0x1s7=90s11=180^M 
> ppp[547]: tun0: Chat: Expect(5): OK 
> ppp[547]: tun0: Chat: Received: ATE1Q0x1s7=90s11=180^M^M 
> ppp[547]: tun0: Chat: Received: OK^M 
> ppp[547]: tun0: Chat: Send: ATDT666-555-1212^M 
> ppp[547]: tun0: Chat: Expect(120): CONNECT 
> ppp[547]: tun0: Chat: Received: ATDT666-555-1212^M^M 
> ppp[547]: tun0: Chat: Received: CONNECT 57600^M 
> ppp[547]: tun0: Phase: deflink: dial -> carrier 
> ppp[547]: tun0: Phase: deflink: /dev/cuaa1: CD detected 
> ppp[547]: tun0: Phase: deflink: carrier -> login 
> ppp[547]: tun0: Chat: Expect(5): ogin: 
> ppp[547]: tun0: Chat: Received: ^M^M 
> ppp[547]: tun0: Chat: Received: FreeBSD/i386 (doo.com) (ttyd1)^M^M 
> ppp[547]: tun0: Chat: Received: ^M^M 
> ppp[547]: tun0: Chat: Received: login: 
> ppp[547]: tun0: Chat: Send: roamP^M 
> ppp[547]: tun0: Chat: Expect(5): word: 
> ppp[547]: tun0: Chat: Received:  ~upyour^M 
> ppp[547]: tun0: Chat: Received: Password: 
> ppp[547]: tun0: Chat: Send: wazoo^M 
> ppp[547]: tun0: Phase: deflink: login -> lcp 
> ppp[547]: tun0: LCP: FSM: Using "deflink" as a transport 
> ppp[547]: tun0: LCP: deflink: State change Initial --> Closed 
> ppp[547]: tun0: LCP: deflink: State change Closed --> Stopped 
> ppp[547]: tun0: LCP: deflink: LayerStart 
> ppp[547]: tun0: LCP: deflink: SendConfigReq(1) state = Stopped 
> ppp[547]: tun0: LCP:  ACFCOMP[2] 
> ppp[547]: tun0: LCP:  PROTOCOMP[2] 
> ppp[547]: tun0: LCP:  ACCMAP[6] 0x00000000 
> ppp[547]: tun0: LCP:  MRU[4] 1500 
> ppp[547]: tun0: LCP:  MAGICNUM[6] 0x2c18b501 
> ppp[547]: tun0: LCP: deflink: State change Stopped --> Req-Sent 
> ppp[547]: tun0: LCP: deflink: RecvConfigReq(1) state = Req-Sent 
> ppp[547]: tun0: LCP:  ACFCOMP[2] 
> ppp[547]: tun0: LCP:  PROTOCOMP[2] 
> ppp[547]: tun0: LCP:  ACCMAP[6] 0x00000000 
> ppp[547]: tun0: LCP:  MRU[4] 1500 
> ppp[547]: tun0: LCP:  MAGICNUM[6] 0x2c18b501 
> ppp[547]: tun0: LCP: Magic is same (2c18b501) - 1 times 
> ppp[547]: tun0: LCP: deflink: SendConfigNak(1) state = Req-Sent 
> ppp[547]: tun0: LCP:  MAGICNUM[6] 0x2c18b501 
> ppp[547]: tun0: LCP: deflink: RecvConfigNak(1) state = Req-Sent 
> ppp[547]: tun0: LCP:  MAGICNUM[6] 0x2c18b501 
> ppp[547]: tun0: LCP:  Magic 0x2c18b501 is NAKed! 
> ppp[547]: tun0: LCP: deflink: SendConfigReq(2) state = Req-Sent 
> ppp[547]: tun0: LCP:  ACFCOMP[2] 
> ppp[547]: tun0: LCP:  PROTOCOMP[2] 
> ppp[547]: tun0: LCP:  ACCMAP[6] 0x00000000 
> ppp[547]: tun0: LCP:  MRU[4] 1500 
> ppp[547]: tun0: LCP:  MAGICNUM[6] 0x42093812 
> ppp[547]: tun0: LCP: deflink: RecvConfigReq(2) state = Req-Sent 
> ppp[547]: tun0: LCP:  ACFCOMP[2] 
> ppp[547]: tun0: LCP:  PROTOCOMP[2] 
> ppp[547]: tun0: LCP:  ACCMAP[6] 0x00000000 
> ppp[547]: tun0: LCP:  MRU[4] 1500 
> ppp[547]: tun0: LCP:  MAGICNUM[6] 0x42093812 
> ppp[547]: tun0: LCP: Magic is same (42093812) - 2 times 
> ppp[547]: tun0: LCP: deflink: SendConfigNak(2) state = Req-Sent 
> ppp[547]: tun0: LCP:  MAGICNUM[6] 0x42093812 
> ppp[547]: tun0: LCP: deflink: RecvConfigNak(2) state = Req-Sent 
> ppp[547]: tun0: LCP:  MAGICNUM[6] 0x42093812 
> ppp[547]: tun0: LCP:  Magic 0x42093812 is NAKed! 
> ppp[547]: tun0: LCP: deflink: SendConfigReq(3) state = Req-Sent 
> ppp[547]: tun0: LCP:  ACFCOMP[2] 
> ppp[547]: tun0: LCP:  PROTOCOMP[2] 
> ppp[547]: tun0: LCP:  ACCMAP[6] 0x00000000 
> ppp[547]: tun0: LCP:  MRU[4] 1500 
> ppp[547]: tun0: LCP:  MAGICNUM[6] 0x30625651 
> 
> clues?
> 
> randy

-- 
Brian <brian@Awfulhak.org>                        <brian@[uk.]FreeBSD.org>
      <http://www.Awfulhak.org>                   <brian@[uk.]OpenBSD.org>
Don't _EVER_ lose your sense of humour !




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24  9:42:16 2000
Delivered-To: freebsd-current@freebsd.org
Received: from yana.lemis.com (yana.lemis.com [192.109.197.140])
	by hub.freebsd.org (Postfix) with ESMTP id 275DB37B59C
	for <freebsd-current@FreeBSD.ORG>; Fri, 24 Mar 2000 09:42:11 -0800 (PST)
	(envelope-from grog@mojave.worldwide.lemis.com)
Received: from mojave.worldwide.lemis.com ([216.88.157.130])
	by yana.lemis.com (8.8.8/8.8.8) with ESMTP id EAA05480;
	Sat, 25 Mar 2000 04:11:46 +1030 (CST)
	(envelope-from grog@mojave.worldwide.lemis.com)
Received: (from grog@localhost)
	by mojave.worldwide.lemis.com (8.9.3/8.9.3) id JAA01584;
	Fri, 24 Mar 2000 09:41:28 -0800 (PST)
	(envelope-from grog)
Date: Fri, 24 Mar 2000 09:41:28 -0800
From: Greg Lehey <grog@lemis.com>
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: Brad Knowles <blk@skynet.be>,
	FreeBSD-CURRENT Mailing List <freebsd-current@FreeBSD.ORG>
Subject: Re: INVARIANTS doesn't work?
Message-ID: <20000324094127.C1349@mojave.worldwide.lemis.com>
Reply-To: Greg Lehey <grog@lemis.com>
References: <v04220808b5000473e2bd@[195.238.1.121]> <200003231745.JAA02103@apollo.backplane.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200003231745.JAA02103@apollo.backplane.com>; from dillon@apollo.backplane.com on Thu, Mar 23, 2000 at 09:45:31AM -0800
WWW-Home-Page: http://www.lemis.com/~grog
X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF  13 24 52 F8 6D A4 95 EF
Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia
Phone: +61-8-8388-8286
Fax: +61-8-8388-8725
Mobile: +61-41-739-7062
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Thursday, 23 March 2000 at  9:45:31 -0800, Matthew Dillon wrote:
>> (Brad Knowles <blk@skynet.be>)
>> Folks,
>> 
>> 	It looks to me like setting INVARIANTS in your kernel doesn't
>> work in 4.0-STABLE.
>> 
>> ...
>> reference to `zerror'
>> /usr/src/sys/compile/AUDREY/../../vm/vm_zone.h:91: undefined reference to `zerror'
>> vm_zone.o: In function `zfreei':
>> /usr/src/sys/compile/AUDREY/../../vm/vm_zone.h:106: undefined reference to `zerror'
>> vm_zone.o: In function `_zget':
>> /usr/src/sys/compile/AUDREY/../../vm/vm_zone.c:373: undefined reference to `zerror'
>> *** Error code 1
>> 
>> 	The kernel config is a bit large, so I will transmit it on
>> request to interested parties, but I won't post it to the list unless
>> specifically asked to do so.  The one thing I'll note is that this
>> might be an interaction between INVARIANTS and "makeoptions
>> DEBUG=-g".  I'll try turning off DEBUG and see if I can make a kernel
>> that way....
>
>     I just did a full buildworld/installworld and complete recompile
>     of RELENG_4 last night with INVARIANTS turned on, and I use makeoptions
>     DEBUG=-g.  It worked fine.
>
>     Make sure you also specify the INVARIANT_SUPPORT options (note: this
>     one is not plural).

Is there any good reason why we have two different options if they can
only be used together?

Greg
--
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24  9:54:38 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mail.du.gtn.com (mail.du.gtn.com [194.77.9.57])
	by hub.freebsd.org (Postfix) with ESMTP id C273C37B68E
	for <current@FreeBSD.ORG>; Fri, 24 Mar 2000 09:54:27 -0800 (PST)
	(envelope-from ticso@cicely8.cicely.de)
Received: from mail.cicely.de (cicely.de [194.231.9.142])
	by mail.du.gtn.com (8.9.3/8.9.3) with ESMTP id SAA13631;
	Fri, 24 Mar 2000 18:52:56 +0100 (MET)
Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10])
	by mail.cicely.de (8.9.3/8.9.0) with ESMTP id SAA29877;
	Fri, 24 Mar 2000 18:53:49 +0100 (CET)
Received: (from ticso@localhost)
	by cicely8.cicely.de (8.9.3/8.9.2) id SAA96455;
	Fri, 24 Mar 2000 18:54:37 +0100 (CET)
	(envelope-from ticso)
Date: Fri, 24 Mar 2000 18:54:36 +0100
From: Bernd Walter <ticso@cicely.de>
To: "Niels Chr. Bank-Pedersen" <ncbp@bank-pedersen.dk>
Cc: current@FreeBSD.ORG
Subject: Re: current panics
Message-ID: <20000324185435.B95725@cicely8.cicely.de>
References: <20000323122928.E4987@bank-pedersen.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3i
In-Reply-To: <20000323122928.E4987@bank-pedersen.dk>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Thu, Mar 23, 2000 at 12:29:28PM +0100, Niels Chr. Bank-Pedersen wrote:
> Hi,
> 
> I know it isn't much (no debugger compiled in (yet)), but is
> anybody else seeing panics like this:
> 
>   mode = 0100644, inum = 214354, fs = /data0
>   panic: ffs_valloc: dup alloc
>   
>   syncing disks... 23 13 4 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 
>   giving up on 2 buffers
>   Uptime: 3m24s
>   Automatic reboot in 15 seconds - press a key on the console to abort
> 
> and
> 
>   dev = #vinum/1, block = 9757, fs = /data10
>   panic: ffs_blkfree: freeing free frag
>   
>   syncing disks... 63 13 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 
>   giving up on 1 buffers
>   Uptime: 3m34s
>   Automatic reboot in 15 seconds - press a key on the console to abort
>   Rebooting...
> 
> Happening within a couple of minutes on -current kernels from 22/3 and
> 23/3 but not on a kernel from around the 18/3.
> Running SU and vinum (both panics on a vinum fs), but otherwise
> its just a plain nfs-server.

What vinum config are you using?
'vinum list' ist best for this.

-- 
B.Walter                  COSMO-Project              http://www.cosmo-project.de
ticso@cicely.de             Usergroup                info@cosmo-project.de



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24  9:59:21 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id E4E5237B7CE
	for <freebsd-current@FreeBSD.ORG>; Fri, 24 Mar 2000 09:59:17 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id JAA14699;
	Fri, 24 Mar 2000 09:59:16 -0800 (PST)
	(envelope-from dillon)
Date: Fri, 24 Mar 2000 09:59:16 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003241759.JAA14699@apollo.backplane.com>
To: Alfred Perlstein <bright@wintelcom.net>
Cc: freebsd-current@FreeBSD.ORG
Subject: Preliminary SMP/BGL patch
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

    A preliminary BGL patch is now on my site, relative to RELENG_4.

	http://www.backplane.com/FreeBSD4/

    It is the smp-patch-03.diff item at the end of the first section.

    My test box successfully built the world.  I know I'm probably missing
    something, but so far I can't tell what it might be because nothing
    is failing :-)

    This is considered very alpha and has been made available mainly to
    endgender discussion.  You know, things like "Matt, you've really gone
    off the deep end this time! You cannot *DO* that to the syscall 
    interface!".

    My primary assumption is that read access to fields in curproc plus any
    structural references that are 'static'-like (e.g. like ucred) are legal
    without having to hold the BGL.  So getuid() can be made BGL safe
    but getppid() cannot (nor can getpid() because compatibility mode also
    returns the ppid).  Obviously there are other fine-grained solutions.

    The biggest assumption in the patch is that doreti does not have to be
    called for system calls.  Being able to get rid of it for syscalls means
    being able to do an end-run around doreti's extremely SMP-unsafe code.

    I can categorize the system calls as follows:

	* SMP safe trivially (getuid())

	* SMP safe trivially through fine-grained structural locks 
	  (e.g. getppid()).  The case where the code has no potential to 
	  block beyond obtaining a single fine-grained lock.

	* SMP safe through the use of nested locks (e.g. VM, buffer cache).
	  Less trivial because we have to utilize the spl*() mechanisms
	  to prevent interrupts from interfering and deadlocking us.

	* SMP safe but with potential nested blocking conditions

						-Matt




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 10: 1:57 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id 8C9E237B67F
	for <freebsd-current@FreeBSD.ORG>; Fri, 24 Mar 2000 10:01:49 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id KAA14754;
	Fri, 24 Mar 2000 10:01:48 -0800 (PST)
	(envelope-from dillon)
Date: Fri, 24 Mar 2000 10:01:48 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003241801.KAA14754@apollo.backplane.com>
To: Alfred Perlstein <bright@wintelcom.net>,
	freebsd-current@FreeBSD.ORG
Subject: Experts only please! (was Re: Preliminary SMP/BGL patch)
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

    Umm... ok, some people seem to be enthusiastic but I really recommend
    that ONLY experts mess around with this patch until they sign off on
    its properness (or suggest fixes for improperness).

    This is not a 'normal Matt patch' that 'just works'.  Ok, it seems to
    just work, but it's not a normal Matt patch.  If there were a 
    designation before 'early alpha' this patch would get it.

						-Matt


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 10: 2:58 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id E692B37B917
	for <freebsd-current@FreeBSD.ORG>; Fri, 24 Mar 2000 10:02:55 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id KAA14776;
	Fri, 24 Mar 2000 10:02:46 -0800 (PST)
	(envelope-from dillon)
Date: Fri, 24 Mar 2000 10:02:46 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003241802.KAA14776@apollo.backplane.com>
To: Greg Lehey <grog@lemis.com>
Cc: Brad Knowles <blk@skynet.be>,
	FreeBSD-CURRENT Mailing List <freebsd-current@FreeBSD.ORG>
Subject: Re: INVARIANTS doesn't work?
References: <v04220808b5000473e2bd@[195.238.1.121]> <200003231745.JAA02103@apollo.backplane.com> <20000324094127.C1349@mojave.worldwide.lemis.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

:Is there any good reason why we have two different options if they can
:only be used together?
:
:Greg

    I think it's so you can compile a kernel with INVARIANT_SUPPORT in
    in order to support dynamic load modules which may have been compiled
    with INVARIANTS.

						-Matt



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 10: 3: 2 2000
Delivered-To: freebsd-current@freebsd.org
Received: from dt051n0b.san.rr.com (dt051n0b.san.rr.com [204.210.32.11])
	by hub.freebsd.org (Postfix) with ESMTP
	id 24E4A37B9DF; Fri, 24 Mar 2000 10:02:57 -0800 (PST)
	(envelope-from Doug@gorean.org)
Received: from gorean.org (doug@master [10.0.0.2])
	by dt051n0b.san.rr.com (8.9.3/8.9.3) with ESMTP id KAA02953;
	Fri, 24 Mar 2000 10:02:54 -0800 (PST)
	(envelope-from Doug@gorean.org)
Message-ID: <38DBADCE.68B2D0B5@gorean.org>
Date: Fri, 24 Mar 2000 10:02:54 -0800
From: Doug Barton <Doug@gorean.org>
Organization: Triborough Bridge & Tunnel Authority
X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 5.0-CURRENT-0322 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: rjk191@psu.edu
Cc: freebsd-current@freebsd.org, dan@freebsd.org
Subject: Re: NOUUCP knob and /etc/uucp
References: <20000324105534.A1602@rjk191.rh.psu.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Ray Kohler wrote:
> 
> I was just noticing that the files in /etc/uucp are installed anyway
> if you set NOUUCP, whereas those in /etc/ssh and /etc/ssl are
> affected by their respective knobs. Could /etc/uucp be wrapped
> around the NOUUCP knob?

	I replied to Dan Moschuk's commit message for this with the additional
suggestion of including uucpd in src/libexec/Makefile too, but got no
response. I like the idea of wrapping the files in src/etc with the
NOUUCP (NO_UUCP maybe?) knob as well. Further research offers rmail in
src/bin/Makefile as a candidate as well. 

Doug
-- 
    "So, the cows were part of a dream that dreamed itself into
existence? Is that possible?" asked the student incredulously.
    The master simply replied, "Mu."


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 10:22:56 2000
Delivered-To: freebsd-current@freebsd.org
Received: from spirit.jaded.net (spirit.jaded.net [216.94.113.12])
	by hub.freebsd.org (Postfix) with ESMTP id 2CF1F37B917
	for <freebsd-current@freebsd.org>; Fri, 24 Mar 2000 10:22:53 -0800 (PST)
	(envelope-from dan@spirit.jaded.net)
Received: (from dan@localhost)
	by spirit.jaded.net (8.9.3/8.9.3) id NAA00662;
	Fri, 24 Mar 2000 13:23:03 -0500 (EST)
Date: Fri, 24 Mar 2000 13:23:03 -0500
From: Dan Moschuk <dan@freebsd.org>
To: Doug Barton <Doug@gorean.org>
Cc: rjk191@psu.edu, freebsd-current@freebsd.org
Subject: Re: NOUUCP knob and /etc/uucp
Message-ID: <20000324132303.B603@spirit.jaded.net>
References: <20000324105534.A1602@rjk191.rh.psu.edu> <38DBADCE.68B2D0B5@gorean.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <38DBADCE.68B2D0B5@gorean.org>; from Doug@gorean.org on Fri, Mar 24, 2000 at 10:02:54AM -0800
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


| > I was just noticing that the files in /etc/uucp are installed anyway
| > if you set NOUUCP, whereas those in /etc/ssh and /etc/ssl are
| > affected by their respective knobs. Could /etc/uucp be wrapped
| > around the NOUUCP knob?
| 
| 	I replied to Dan Moschuk's commit message for this with the additional
| suggestion of including uucpd in src/libexec/Makefile too, but got no
| response. I like the idea of wrapping the files in src/etc with the
| NOUUCP (NO_UUCP maybe?) knob as well. Further research offers rmail in
| src/bin/Makefile as a candidate as well. 

Oops!  I've just committed the fix.  It probably should be NO_UUCP, but no
one seems to want to make a final decision on the NOFOO vs. NO_FOO argument,
so I left it at NOUUCP for now.

-- 
Dan Moschuk (TFreak!dan@freebsd.org)
"Waste not fresh tears on old griefs."


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 10:43:37 2000
Delivered-To: freebsd-current@freebsd.org
Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228])
	by hub.freebsd.org (Postfix) with ESMTP
	id ED79537B8B2; Fri, 24 Mar 2000 10:43:34 -0800 (PST)
	(envelope-from jkh@zippy.cdrom.com)
Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1])
	by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id KAA32415;
	Fri, 24 Mar 2000 10:43:43 -0800 (PST)
	(envelope-from jkh@zippy.cdrom.com)
To: John Baldwin <jhb@FreeBSD.ORG>
Cc: current@FreeBSD.ORG, peter@FreeBSD.ORG
Subject: Re: sysinstall broken :( 
In-reply-to: Your message of "Fri, 24 Mar 2000 10:36:31 EST."
             <200003241536.KAA78949@server.baldwin.cx> 
Date: Fri, 24 Mar 2000 10:43:43 -0800
Message-ID: <32412.953923423@zippy.cdrom.com>
From: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> Hmph, it seems sysinstall (and thus make release) is broken in -current:

I don't know what version of sysinstall you're using, but it builds just
fine for me under -current.  I saw some other kvetching about kget
being broken and just tried building it last night.  Observe:

root@zippy-> make
Warning: Object directory not changed from original /usr/src/release/sysinstall
cc -O -pipe -Wall -I/usr/src/release/sysinstall/../../gnu/lib/libdialog -I/usr/src/release/sysinstall -I/usr/src/release/sysinstall/../../sys   -c kget.c
cc -O -pipe -Wall -I/usr/src/release/sysinstall/../../gnu/lib/libdialog -I/usr/src/release/sysinstall -I/usr/src/release/sysinstall/../../sys    -static -o sysinstall anonFTP.o cdrom.o command.o config.o devices.o dhcp.o kget.o disks.o dispatch.o dist.o dmenu.o doc.o dos.o floppy.o ftp.o globals.o http.o index.o install.o installUpgrade.o keymap.o label.o lndir.o main.o makedevs.o media.o menus.o misc.o mouse.o msg.o network.o nfs.o options.o package.o pccard.o system.o tape.o tcpip.o termcap.o ufs.o user.o variable.o wizard.o  -ldialog -lncurses -lmytinfo -lutil -ldisk -lftpio
root@zippy-> uname -a
FreeBSD zippy.cdrom.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Mar 15 13:05:47 PST 2000     jkh@zippy.cdrom.com:/usr/src/sys/compile/ZIPPY  i386

- Jordan


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 11:11:25 2000
Delivered-To: freebsd-current@freebsd.org
Received: from server.baldwin.cx (jobaldwi.campus.vt.edu [198.82.67.146])
	by hub.freebsd.org (Postfix) with ESMTP
	id 9EEB937B67F; Fri, 24 Mar 2000 11:11:13 -0800 (PST)
	(envelope-from jhb@FreeBSD.org)
Received: from john.baldwin.cx (john [10.0.0.2])
	by server.baldwin.cx (8.9.3/8.9.3) with ESMTP id OAA79160;
	Fri, 24 Mar 2000 14:10:49 -0500 (EST)
	(envelope-from jhb@FreeBSD.org)
Message-Id: <200003241910.OAA79160@server.baldwin.cx>
X-Mailer: XFMail 1.4.0 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <32412.953923423@zippy.cdrom.com>
Date: Fri, 24 Mar 2000 14:10:49 -0500 (EST)
From: John Baldwin <jhb@FreeBSD.org>
To: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>
Subject: Re: sysinstall broken :(
Cc: peter@FreeBSD.org, current@FreeBSD.org
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


On 24-Mar-00 Jordan K. Hubbard wrote:
>> Hmph, it seems sysinstall (and thus make release) is broken in -current:
> 
> I don't know what version of sysinstall you're using, but it builds just
> fine for me under -current.  I saw some other kvetching about kget
> being broken and just tried building it last night.  Observe:
> 
> root@zippy-> make
> Warning: Object directory not changed from original /usr/src/release/sysinstall
> cc -O -pipe -Wall -I/usr/src/release/sysinstall/../../gnu/lib/libdialog -I/usr/src/release/sysinstall
> -I/usr/src/release/sysinstall/../../sys   -c kget.c
> cc -O -pipe -Wall -I/usr/src/release/sysinstall/../../gnu/lib/libdialog -I/usr/src/release/sysinstall
> -I/usr/src/release/sysinstall/../../sys    -static -o sysinstall anonFTP.o cdrom.o command.o config.o
> devices.o dhcp.o kget.o disks.o dispatch.o dist.o dmenu.o doc.o dos.o floppy.o ftp.o globals.o http.o
> index.o install.o installUpgrade.o keymap.o label.o lndir.o main.o makedevs.o media.o menus.o misc.o
> mouse.o msg.o network.o nfs.o options.o package.o pccard.o system.o tape.o tcpip.o termcap.o ufs.o use
> r.o 
> variable.o wizard.o  -ldialog -lncurses -lmytinfo -lutil -ldisk -lftpio
> root@zippy-> uname -a
> FreeBSD zippy.cdrom.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Mar 15 13:05:47 PST 2000    
> jkh@zippy.cdrom.com:/usr/src/sys/compile/ZIPPY  i386

That's because your -current is too old:

revision 1.178
date: 2000/03/19 12:57:49;  author: peter;  state: Exp;  lines: +102 -108
Completely decouple userconfig from 'struct isa_device' and friends.
Userconfig was only using this for convenience since newbus, and even
then it was rather inconvenient.

That's the commit that broke it.  And its dated 4 days after your kernel. :)

> - Jordan

-- 

John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 11:51:41 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mass.cdrom.com (mg134-072.ricochet.net [204.179.134.72])
	by hub.freebsd.org (Postfix) with ESMTP id C123C37B8AB
	for <freebsd-current@FreeBSD.ORG>; Fri, 24 Mar 2000 11:51:32 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Received: from mass.cdrom.com (localhost [127.0.0.1])
	by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id LAA01357;
	Fri, 24 Mar 2000 11:54:32 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Message-Id: <200003241954.LAA01357@mass.cdrom.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To: Brian Dean <brdean@unx.sas.com>
Cc: mw@kpnqwest.ch, freebsd-current@FreeBSD.ORG
Subject: Re: AMI MegaRAID lockup? not accepting commands. 
In-reply-to: Your message of "Thu, 23 Mar 2000 23:15:16 EST."
             <200003240415.XAA32499@dean.pc.sas.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 24 Mar 2000 11:54:32 -0800
From: Mike Smith <msmith@freebsd.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> > Can you try instead the changes that I just committed to -current?  I 
> > think that the problem shows up when the controller is heavily loaded; 
> > your patch will keep the load on the controller down, which may mask the 
> > 'real' bug.
>
> Just recently (this evening), I was able to get our controller to lock
> up with the latest patch.  Previously, with that patch installed, I
> must not have been able to tickle the bug just right, and I believe
> that Mike based his decision to make that mod based on my lack of a
> lockup, which always happened quickly.  That's what made me think that
> we'd solved it, but I guess I just got "lucky" on the previous lockups
> that happened very quickly, making me think it was more easily
> reproduceable that it actually is.

I'm not entirely sure about that; I think there are probably several sets 
of problems here.

Can you be more specific about "locking up" though?  The "controller 
wedged" bug is almost certainly not the same as the "lost interrupt" bug.

> It sounds like Markus may be onto something.

I'm somewhat corralled here today, but I might get some time to apply his 
suggestions on Monday, especially if you're happy it works for you as 
well.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
\\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 11:54:32 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mrynet.com (mrynet.com [24.234.53.177])
	by hub.freebsd.org (Postfix) with ESMTP id 5CD3E37BBAA
	for <freebsd-current@freebsd.org>; Fri, 24 Mar 2000 11:54:27 -0800 (PST)
	(envelope-from freebsd@mrynet.com)
Received: (from freebsd@localhost)
	by mrynet.com (8.9.3/8.9.3) id LAA00546;
	Fri, 24 Mar 2000 11:54:22 -0800 (PST)
	(envelope-from freebsd)
Posted-Date: Fri, 24 Mar 2000 11:54:22 -0800 (PST)
Message-Id: <200003241954.LAA00546@mrynet.com>
From: freebsd@mrynet.com (FreeBSD mailing list)
Date: Fri, 24 Mar 2000 11:54:22 +0000
X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96)
To: Jim Bloom <bloom@acm.org>
Subject: Re: fd0: Debugger("d_iocmd botch") called.
Cc: freebsd-current@freebsd.org
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Jim Bloom wrote:
> Upgrade sys/vm/swap_pager.c to the current version.  There was a bug there which
> has been fixed.
> 
> Jim Bloom
> bloom@acm.org
> 
> FreeBSD mailing list wrote:
> > 
> > 
> > /var/log/messages indicates:
> > Mar 23 23:32:47 mrynet /kernel: Debugger("d_iocmd botch") called.
> > Mar 23 23:32:49 mrynet /kernel: fd0c: hard error reading fsbn 0 of 0-17 (ST0 40<abnrml> ST1 4<sec_not_fnd> ST2 0
> > cyl 0 hd 0 sec 2)

I cvsup'd once more this morning...  Nothing significant has changed since the
last one.

For reference:
	ttyp9:staylor@mrynet (4): grep \$FreeBSD /sys/vm/swap_pager.c
 	* $FreeBSD: src/sys/vm/swap_pager.c,v 1.134 2000/03/22 08:40:13 phk Exp $

Nonetheless, I built a new kernel using "config -r".  No change in floppy operation.

Thanks,
-scott
--
Scott G. Akmentins-Taylor     InterNet: staylor@mrynet.com
MRY Systems			        staylor@mrynet.lv


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 11:56:50 2000
Delivered-To: freebsd-current@freebsd.org
Received: from gate.lustig.com (h08002be407ad.ne.mediaone.net [24.128.152.155])
	by hub.freebsd.org (Postfix) with SMTP id B927537BA1B
	for <current@FreeBSD.org>; Fri, 24 Mar 2000 11:56:46 -0800 (PST)
	(envelope-from barry@lustig.com)
Received: (qmail 20254 invoked from network); 24 Mar 2000 19:56:36 -0000
Received: from devious.lustig.com (205.246.2.244)
  by gate.lustig.com with SMTP; 24 Mar 2000 19:56:36 -0000
Received: (qmail 4562 invoked by uid 1001); 24 Mar 2000 19:56:35 -0000
Message-ID: <20000324195635.4561.qmail@devious.lustig.com>
Content-Type: text/plain
MIME-Version: 1.0 (NeXT Mail 4.2mach_patches v148.2)
In-Reply-To: <Pine.BSF.4.21.0003240014440.7812-100000@freefall.freebsd.org>
X-Nextstep-Mailer: Mail 4.2mach_patches [i386] (Enhance 2.2p2)
Received: by NeXT.Mailer (1.148.2.RR)
From: Barry Lustig <barry@lustig.com>
Date: Fri, 24 Mar 2000 14:56:35 -0500
To: current@FreeBSD.org
Subject: Proper location for certs (Now that openssl is in the base system)
Reply-To: barry@Lustig.COM
References: <Pine.BSF.4.21.0003240014440.7812-100000@freefall.freebsd.org>
X-Organizations: Barry Lustig & Associates, Inc.
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

User added certificates used to go in /usr/local/openssl/certs when openssl  
was a port.  What is the correct location for certs now?


barry


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 11:57: 2 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7])
	by hub.freebsd.org (Postfix) with ESMTP id 4656B37B756
	for <freebsd-current@FreeBSD.ORG>; Fri, 24 Mar 2000 11:56:55 -0800 (PST)
	(envelope-from drosih@rpi.edu)
Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47])
	by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id OAA350260;
	Fri, 24 Mar 2000 14:56:32 -0500
Mime-Version: 1.0
X-Sender: drosih@mail.rpi.edu
Message-Id: <v04210110b50178e7bb92@[128.113.24.47]>
In-Reply-To: <200003241801.KAA14754@apollo.backplane.com>
References: <200003241801.KAA14754@apollo.backplane.com>
Date: Fri, 24 Mar 2000 14:57:11 -0500
To: Matthew Dillon <dillon@apollo.backplane.com>,
	Alfred Perlstein <bright@wintelcom.net>, freebsd-current@FreeBSD.ORG
From: Garance A Drosihn <drosih@rpi.edu>
Subject: Re: Experts only please! (was Re: Preliminary SMP/BGL patch)
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

At 10:01 AM -0800 3/24/00, Matthew Dillon wrote:
>    This is not a 'normal Matt patch' that 'just works'.  Ok, it seems to
>    just work, but it's not a normal Matt patch.  If there were a
>    designation before 'early alpha' this patch would get it.

"Rough-draft proposal for early alpha version"


---
Garance Alistair Drosehn           =   gad@eclipse.acs.rpi.edu
Senior Systems Programmer          or  drosih@rpi.edu
Rensselaer Polytechnic Institute


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 12:10:16 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mail.rdc1.ct.home.com (ha1.rdc1.ct.home.com [24.2.0.66])
	by hub.freebsd.org (Postfix) with ESMTP id AA19937BA78
	for <current@FreeBSD.ORG>; Fri, 24 Mar 2000 12:10:12 -0800 (PST)
	(envelope-from tsikora@home.com)
Received: from home.com ([24.2.168.186]) by mail.rdc1.ct.home.com
          (InterMail v4.01.01.07 201-229-111-110) with ESMTP
          id <20000324201011.UCZ24587.mail.rdc1.ct.home.com@home.com>
          for <current@FreeBSD.ORG>; Fri, 24 Mar 2000 12:10:11 -0800
Message-ID: <38DBCBCE.6517C95B@home.com>
Date: Fri, 24 Mar 2000 15:10:54 -0500
From: Ted Sikora <tsikora@home.com>
Reply-To: tsikora@powerusersbbs.com
Organization: Jtl Development
X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.12 i386)
X-Accept-Language: en-US,en-GB
MIME-Version: 1.0
To: "current@FreeBSD.ORG" <current@FreeBSD.ORG>
Subject: Re: sysinstall broken :(
References: <200003241536.KAA78949@server.baldwin.cx>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

John Baldwin wrote:
> 
> Hmph, it seems sysinstall (and thus make release) is broken in -current:
> 
> cc -O -pipe -Wall -I/usr/src/release/sysinstall/../../gnu/lib/libdialog
> -I/usr/obj/usr/src/release/sysinstall -I/usr/src/release/sysinstall/../../sys   -c

> 
>  bail:
> 
> Comments?

It's broken for me too! I just did a 4.0-RELEASE install last night and
cvs'upd this morning to -current. I get the kget message also:

src/release/sysinstall -I/usr/src/release/sysinstall/../../sys   -c
kget.c
kget.c: In function `kget':
kget.c:83: sizeof applied to an incomplete type
kget.c:85: dereferencing pointer to incomplete type
kget.c:86: dereferencing pointer to incomplete type
kget.c:89: dereferencing pointer to incomplete type

--
Ted Sikora
Jtl Development Group 
tsikora@powerusersbbs.com
http://powerusersbbs.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 12:33:49 2000
Delivered-To: freebsd-current@freebsd.org
Received: from dt051n0b.san.rr.com (dt051n0b.san.rr.com [204.210.32.11])
	by hub.freebsd.org (Postfix) with ESMTP
	id EAA4137B511; Fri, 24 Mar 2000 12:33:44 -0800 (PST)
	(envelope-from Doug@gorean.org)
Received: from slave (doug@slave [10.0.0.1])
	by dt051n0b.san.rr.com (8.9.3/8.9.3) with ESMTP id MAA03710;
	Fri, 24 Mar 2000 12:33:43 -0800 (PST)
	(envelope-from Doug@gorean.org)
Date: Fri, 24 Mar 2000 12:33:43 -0800 (PST)
From: Doug Barton <Doug@gorean.org>
X-Sender: doug@dt051n0b.san.rr.com
To: Dan Moschuk <dan@freebsd.org>
Cc: rjk191@psu.edu, freebsd-current@freebsd.org
Subject: Re: NOUUCP knob and /etc/uucp
In-Reply-To: <20000324132303.B603@spirit.jaded.net>
Message-ID: <Pine.BSF.4.21.0003241231340.3660-100000@dt051n0b.san.rr.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Fri, 24 Mar 2000, Dan Moschuk wrote:

> Oops!  I've just committed the fix. 

	No sweat! We're all busy. I'm just glad to see it done. It's
something I've wanted for a long time. 

> It probably should be NO_UUCP, but no
> one seems to want to make a final decision on the NOFOO vs. NO_FOO argument,
> so I left it at NOUUCP for now.

	heh...I know that feeling. 

Doug (wondering if he should push his luck and ask for an MFC... :)
-- 
    "So, the cows were part of a dream that dreamed itself into
existence? Is that possible?" asked the student incredulously.
    The master simply replied, "Mu."




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 12:36:26 2000
Delivered-To: freebsd-current@freebsd.org
Received: from reyim.ne.mediaone.net (reyim.ne.mediaone.net [24.218.251.241])
	by hub.freebsd.org (Postfix) with ESMTP id EE8D037B7B8
	for <freebsd-current@freebsd.org>; Fri, 24 Mar 2000 12:36:19 -0800 (PST)
	(envelope-from bloom@acm.org)
Received: from acm.org (localhost [127.0.0.1])
	by reyim.ne.mediaone.net (8.9.3/8.9.3) with ESMTP id PAA00285;
	Fri, 24 Mar 2000 15:35:35 -0500 (EST)
	(envelope-from bloom@acm.org)
Message-ID: <38DBD197.29AD6744@acm.org>
Date: Fri, 24 Mar 2000 15:35:35 -0500
From: Jim Bloom <bloom@acm.org>
Reply-To: bloom@acm.org
X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386)
X-Accept-Language: en
MIME-Version: 1.0
To: FreeBSD mailing list <freebsd@mrynet.com>
Cc: freebsd-current@freebsd.org, phk@critter.freebsd.dk
Subject: Re: fd0: Debugger("d_iocmd botch") called.
References: <200003241954.LAA00546@mrynet.com>
Content-Type: multipart/mixed;
 boundary="------------7D0E1521E15DD9B4A3213A24"
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

This is a multi-part message in MIME format.
--------------7D0E1521E15DD9B4A3213A24
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I reproduced the problem and have attached a patch.  It was the exact
same problem as in swap_pager.c (assuming B_WRITE was 0).  Hopefully phk
will commit this fix shortly.

Jim Bloom
bloom@acm.org


\
FreeBSD mailing list wrote:
> 
> I cvsup'd once more this morning...  Nothing significant has changed since the
> last one.
> 
> For reference:
>         ttyp9:staylor@mrynet (4): grep \$FreeBSD /sys/vm/swap_pager.c
>         * $FreeBSD: src/sys/vm/swap_pager.c,v 1.134 2000/03/22 08:40:13 phk Exp $
> 
> Nonetheless, I built a new kernel using "config -r".  No change in floppy operation.
--------------7D0E1521E15DD9B4A3213A24
Content-Type: text/plain; charset=us-ascii;
 name="fd.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="fd.patch"

Index: sys/isa/fd.c
===================================================================
RCS file: /users/ncvs/src/sys/isa/fd.c,v
retrieving revision 1.179
diff -u -r1.179 fd.c
--- sys/isa/fd.c	2000/03/20 11:28:39	1.179
+++ sys/isa/fd.c	2000/03/24 20:20:53
@@ -2228,6 +2228,7 @@
 	BUF_LOCKINIT(bp);
 	BUF_LOCK(bp, LK_EXCLUSIVE);
 	bp->b_flags = B_PHYS | B_FORMAT;
+	bp->b_iocmd = BIO_WRITE;
 
 	/*
 	 * calculate a fake blkno, so fdstrategy() would initiate a

--------------7D0E1521E15DD9B4A3213A24--



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 12:39:58 2000
Delivered-To: freebsd-current@freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
	by hub.freebsd.org (Postfix) with ESMTP
	id E909137B7B5; Fri, 24 Mar 2000 12:39:55 -0800 (PST)
	(envelope-from kris@FreeBSD.org)
Received: from localhost (kris@localhost)
	by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id MAA45869;
	Fri, 24 Mar 2000 12:39:56 -0800 (PST)
	(envelope-from kris@FreeBSD.org)
X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs
Date: Fri, 24 Mar 2000 12:39:56 -0800 (PST)
From: Kris Kennaway <kris@FreeBSD.org>
To: Barry Lustig <barry@lustig.com>
Cc: current@FreeBSD.org
Subject: Re: Proper location for certs (Now that openssl is in the base
 system)
In-Reply-To: <20000324195635.4561.qmail@devious.lustig.com>
Message-ID: <Pine.BSF.4.21.0003241239200.45620-100000@freefall.freebsd.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Fri, 24 Mar 2000, Barry Lustig wrote:

> User added certificates used to go in /usr/local/openssl/certs when openssl  
> was a port.  What is the correct location for certs now?

/etc/ssl/certs - I think I forgot to add the directory.

Kris

----
In God we Trust -- all others must submit an X.509 certificate.
    -- Charles Forsythe <forsythe@alum.mit.edu>



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 12:50:17 2000
Delivered-To: freebsd-current@freebsd.org
Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228])
	by hub.freebsd.org (Postfix) with ESMTP
	id 62D6537BB7F; Fri, 24 Mar 2000 12:50:05 -0800 (PST)
	(envelope-from jkh@zippy.cdrom.com)
Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1])
	by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id MAA33368;
	Fri, 24 Mar 2000 12:50:08 -0800 (PST)
	(envelope-from jkh@zippy.cdrom.com)
To: John Baldwin <jhb@FreeBSD.org>
Cc: peter@FreeBSD.org, current@FreeBSD.org
Subject: Re: sysinstall broken :( 
In-reply-to: Your message of "Fri, 24 Mar 2000 14:10:49 EST."
             <200003241910.OAA79160@server.baldwin.cx> 
Date: Fri, 24 Mar 2000 12:50:08 -0800
Message-ID: <33365.953931008@zippy.cdrom.com>
From: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Urk, sorry guys, I've been cvsupping the repo faithfully but evidently not
cvs updating my tree as faithfully. :-)

I'll find and fix it.

- Jordan

> On 24-Mar-00 Jordan K. Hubbard wrote:
> >> Hmph, it seems sysinstall (and thus make release) is broken in -current:
> > 
> > I don't know what version of sysinstall you're using, but it builds just
> > fine for me under -current.  I saw some other kvetching about kget
> > being broken and just tried building it last night.  Observe:
> > 
> > root@zippy-> make
> > Warning: Object directory not changed from original /usr/src/release/sysins
tall
> > cc -O -pipe -Wall -I/usr/src/release/sysinstall/../../gnu/lib/libdialog -I/
usr/src/release/sysinstall
> > -I/usr/src/release/sysinstall/../../sys   -c kget.c
> > cc -O -pipe -Wall -I/usr/src/release/sysinstall/../../gnu/lib/libdialog -I/
usr/src/release/sysinstall
> > -I/usr/src/release/sysinstall/../../sys    -static -o sysinstall anonFTP.o 
cdrom.o command.o config.o
> > devices.o dhcp.o kget.o disks.o dispatch.o dist.o dmenu.o doc.o dos.o flopp
y.o ftp.o globals.o http.o
> > index.o install.o installUpgrade.o keymap.o label.o lndir.o main.o makedevs
.o media.o menus.o misc.o
> > mouse.o msg.o network.o nfs.o options.o package.o pccard.o system.o tape.o 
tcpip.o termcap.o ufs.o use
> > r.o 
> > variable.o wizard.o  -ldialog -lncurses -lmytinfo -lutil -ldisk -lftpio
> > root@zippy-> uname -a
> > FreeBSD zippy.cdrom.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Mar 15 13:0
5:47 PST 2000    
> > jkh@zippy.cdrom.com:/usr/src/sys/compile/ZIPPY  i386
> 
> That's because your -current is too old:
> 
> revision 1.178
> date: 2000/03/19 12:57:49;  author: peter;  state: Exp;  lines: +102 -108
> Completely decouple userconfig from 'struct isa_device' and friends.
> Userconfig was only using this for convenience since newbus, and even
> then it was rather inconvenient.
> 
> That's the commit that broke it.  And its dated 4 days after your kernel. :)
> 
> > - Jordan
> 
> -- 
> 
> John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
> PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
> "Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 12:52:47 2000
Delivered-To: freebsd-current@freebsd.org
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131])
	by hub.freebsd.org (Postfix) with ESMTP id A711737BC6C
	for <freebsd-current@FreeBSD.ORG>; Fri, 24 Mar 2000 12:51:56 -0800 (PST)
	(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1])
	by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id VAA05499;
	Fri, 24 Mar 2000 21:51:00 +0100 (CET)
	(envelope-from phk@critter.freebsd.dk)
To: bloom@acm.org
Cc: FreeBSD mailing list <freebsd@mrynet.com>,
	freebsd-current@FreeBSD.ORG
Subject: Re: fd0: Debugger("d_iocmd botch") called. 
In-reply-to: Your message of "Fri, 24 Mar 2000 15:35:35 EST."
             <38DBD197.29AD6744@acm.org> 
Date: Fri, 24 Mar 2000 21:51:00 +0100
Message-ID: <5497.953931060@critter.freebsd.dk>
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


I belive Joerg Wunsh is already on this case ?

Poul-Henning

In message <38DBD197.29AD6744@acm.org>, Jim Bloom writes:
>This is a multi-part message in MIME format.
>--------------7D0E1521E15DD9B4A3213A24
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>I reproduced the problem and have attached a patch.  It was the exact
>same problem as in swap_pager.c (assuming B_WRITE was 0).  Hopefully phk
>will commit this fix shortly.
>
>Jim Bloom
>bloom@acm.org
>
>
>\
>FreeBSD mailing list wrote:
>> 
>> I cvsup'd once more this morning...  Nothing significant has changed since the
>> last one.
>> 
>> For reference:
>>         ttyp9:staylor@mrynet (4): grep \$FreeBSD /sys/vm/swap_pager.c
>>         * $FreeBSD: src/sys/vm/swap_pager.c,v 1.134 2000/03/22 08:40:13 phk Exp $
>> 
>> Nonetheless, I built a new kernel using "config -r".  No change in floppy operation.
>--------------7D0E1521E15DD9B4A3213A24
>Content-Type: text/plain; charset=us-ascii;
> name="fd.patch"
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline;
> filename="fd.patch"
>
>Index: sys/isa/fd.c
>===================================================================
RCS file: /users/ncvs/src/sys/isa/fd.c,v
>retrieving revision 1.179
>diff -u -r1.179 fd.c
>--- sys/isa/fd.c	2000/03/20 11:28:39	1.179
>+++ sys/isa/fd.c	2000/03/24 20:20:53
>@@ -2228,6 +2228,7 @@
> 	BUF_LOCKINIT(bp);
> 	BUF_LOCK(bp, LK_EXCLUSIVE);
> 	bp->b_flags = B_PHYS | B_FORMAT;
>+	bp->b_iocmd = BIO_WRITE;
> 
> 	/*
> 	 * calculate a fake blkno, so fdstrategy() would initiate a
>
>--------------7D0E1521E15DD9B4A3213A24--
>
>
>
>To Unsubscribe: send mail to majordomo@FreeBSD.org
>with "unsubscribe freebsd-current" in the body of the message
>

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 13:17:19 2000
Delivered-To: freebsd-current@freebsd.org
Received: from lamb.sas.com (lamb.sas.com [192.35.83.8])
	by hub.freebsd.org (Postfix) with ESMTP
	id 5F53537B818; Fri, 24 Mar 2000 13:16:51 -0800 (PST)
	(envelope-from brdean@unx.sas.com)
Received: from mozart (mozart.unx.sas.com [149.173.6.8])
	by lamb.sas.com (8.9.3/8.9.1) with SMTP id QAA10261;
	Fri, 24 Mar 2000 16:16:44 -0500 (EST)
Received: from dean.pc.sas.com by mozart (5.65c/SAS/Domains/5-6-90)
	id AA16153; Fri, 24 Mar 2000 16:16:13 -0500
Received: (from brdean@localhost)
	by dean.pc.sas.com (8.9.3/8.9.1) id QAA36563;
	Fri, 24 Mar 2000 16:16:13 -0500 (EST)
	(envelope-from brdean)
From: Brian Dean <brdean@unx.sas.com>
Message-Id: <200003242116.QAA36563@dean.pc.sas.com>
Subject: Re: AMI MegaRAID lockup? not accepting commands.
In-Reply-To: <200003241954.LAA01357@mass.cdrom.com> from Mike Smith at "Mar 24,
 2000 11:54:32 am"
To: Mike Smith <msmith@FreeBSD.ORG>
Date: Fri, 24 Mar 2000 16:16:13 -0500 (EST)
Cc: mw@kpnqwest.ch, freebsd-current@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL61 (25)]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Mike Smith wrote:
> > Just recently (this evening), I was able to get our controller to lock
> > up with the latest patch.  Previously, with that patch installed, I
> > must not have been able to tickle the bug just right, and I believe
> > that Mike based his decision to make that mod based on my lack of a
> > lockup, which always happened quickly.  That's what made me think that
> > we'd solved it, but I guess I just got "lucky" on the previous lockups
> > that happened very quickly, making me think it was more easily
> > reproduceable that it actually is.
> 
> I'm not entirely sure about that; I think there are probably several sets 
> of problems here.
> 
> Can you be more specific about "locking up" though?  The "controller 
> wedged" bug is almost certainly not the same as the "lost interrupt" bug.

Here's a snippet of the messages from my syslog file:

[...]
Mar 24 12:35:19 cvsstage /kernel: amr0: controller wedged (not taking commands)
Mar 24 12:35:19 cvsstage /kernel: amr0: I/O error - dead
Mar 24 12:35:19 cvsstage /kernel: amr0: cmd 2  ident 17  drive 0
Mar 24 12:35:19 cvsstage /kernel: amr0: blkcount 12  lba 129695792
Mar 24 12:35:19 cvsstage /kernel: amr0: virtaddr 0xd1a5d000  length 6144
Mar 24 12:35:19 cvsstage /kernel: amr0: physaddr 00007800  nsg 2
Mar 24 12:35:19 cvsstage /kernel: amr0:   1a11e000/4096
Mar 24 12:35:19 cvsstage /kernel: amr0:   1993f000/2048
Mar 24 12:35:19 cvsstage /kernel: amr0: controller wedged (not taking commands)
Mar 24 12:35:19 cvsstage /kernel: amr0: I/O error - dead
Mar 24 12:35:19 cvsstage /kernel: amr0: cmd 2  ident 17  drive 0
Mar 24 12:35:19 cvsstage /kernel: amr0: blkcount 12  lba 129826864
Mar 24 12:35:19 cvsstage /kernel: amr0: virtaddr 0xd1a4d000  length 6144
Mar 24 12:35:19 cvsstage /kernel: amr0: physaddr 00007800  nsg 2
Mar 24 12:35:19 cvsstage /kernel: amr0:   71ce000/4096
Mar 24 12:35:19 cvsstage /kernel: amr0:   402f000/2048
Mar 24 12:35:19 cvsstage /kernel: amr0: controller wedged (not taking commands)
Mar 24 12:35:19 cvsstage /kernel: amr0: I/O error - dead
Mar 24 12:35:19 cvsstage /kernel: amr0: cmd 2  ident 17  drive 0
Mar 24 12:35:19 cvsstage /kernel: amr0: blkcount 12  lba 129630256
Mar 24 12:35:19 cvsstage /kernel: amr0: virtaddr 0xd1a3d000  length 6144
Mar 24 12:35:19 cvsstage /kernel: amr0: physaddr 00007800  nsg 2
Mar 24 12:35:19 cvsstage /kernel: amr0:   1befe000/4096
Mar 24 12:35:19 cvsstage /kernel: amr0:   1869f000/2048
[...]

In a separate lock up, there are no messages to syslog, but all
accesses to the card are hung.  A ps shows my 26 bonnie processes are
in either in 'wswbuf0' or 'biord' (going from memory here, I may not
have the exact state text correct).  This is the one I believe we are
calling the "lost interrupt" bug.

I'm running a patched 3/13 on this machine which I can't readily do a
full cvs update on it.  I believe that 3/13 was before Poul made his
B_READ changes, so I did not incorporate Poul's 1.8 revision for amr.c
(because I assume it would be incorrect to do so without getting all of
his changes throughout the rest of the kernel).  However, I did get
all of your changes at 1.9.

I also incorporated Markus' patch, with the exception that I set maxio
to 253 instead of 127 or 254 like the card reports (thinking possibly
that there was an off by one issue, i.e., 254 available, 0-253).  It
is this kernel that produced the messages above.  Just for sanity's
sake, I'll try Markus' maxio of 127 and verify whether or not my 26
simultaneous bonnie processes can finish without locking it up.

I agree that we are probably chasing more than one problem.  Also, I
don't necessarily think you should back out the "volatile" change;
even though it did not fix this problem, I think it should still be
there.

> > It sounds like Markus may be onto something.
> 
> I'm somewhat corralled here today, but I might get some time to apply his 
> suggestions on Monday, especially if you're happy it works for you as 
> well.

What we're thinking about doing here is that if scaling back the
number of outstanding io requests hides/avoids the problem, then we
may do that here as a temporary fix, especially if we can still get
good performance.  We have the need to get this machine into
production soon.  Ultimately, I'd like to get another card that we can
play with and experiment with a bit more so that we can diagnose the
real cause, and then be able to run the card a full steam.

I am still able to work on this, though, at least for a few days.  One
area I thought about spending some time was where you maintain whether
the card has interrupts enabled or not and based on this info, you
issue commands with the expectation of getting an interrupt back or
use polled mode.  The next thing I was going to check was to review
that part of the code thinking maybe that the software state might
possibly have gotten out of sync with reality at some point.  Also,
I'm open to other suggestions if you think there's a more productive
area I should spend time on.

Thanks for your help on this.  This card has a lot of promise, and the
driver seems to be "so close".  The fix is probably really simple,
it's just eluding us for the moment.

-Brian


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 13:17:56 2000
Delivered-To: freebsd-current@freebsd.org
Received: from server.baldwin.cx (jobaldwi.campus.vt.edu [198.82.67.146])
	by hub.freebsd.org (Postfix) with ESMTP
	id 8031937BA11; Fri, 24 Mar 2000 13:17:46 -0800 (PST)
	(envelope-from jhb@FreeBSD.org)
Received: from john.baldwin.cx (john [10.0.0.2])
	by server.baldwin.cx (8.9.3/8.9.3) with ESMTP id QAA79290;
	Fri, 24 Mar 2000 16:17:37 -0500 (EST)
	(envelope-from jhb@FreeBSD.org)
Message-Id: <200003242117.QAA79290@server.baldwin.cx>
X-Mailer: XFMail 1.4.0 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <33365.953931008@zippy.cdrom.com>
Date: Fri, 24 Mar 2000 16:17:37 -0500 (EST)
From: John Baldwin <jhb@FreeBSD.org>
To: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>
Subject: Re: sysinstall broken :(
Cc: current@FreeBSD.org, peter@FreeBSD.org
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


On 24-Mar-00 Jordan K. Hubbard wrote:
> Urk, sorry guys, I've been cvsupping the repo faithfully but evidently not
> cvs updating my tree as faithfully. :-)
> 
> I'll find and fix it.

Well, my patch fixes it as far as I can tell, it's quite simple.  Right now
I'm still running it through a test release build, but both GENERIC and
sysinstall compiled fine with the patch I submitted earlier.

> - Jordan

-- 

John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 14: 6:55 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mrynet.com (mrynet.com [24.234.53.177])
	by hub.freebsd.org (Postfix) with ESMTP id 03D1837BC6C
	for <freebsd-current@freebsd.org>; Fri, 24 Mar 2000 14:06:50 -0800 (PST)
	(envelope-from freebsd@mrynet.com)
Received: (from freebsd@localhost)
	by mrynet.com (8.9.3/8.9.3) id OAA00645;
	Fri, 24 Mar 2000 14:06:26 -0800 (PST)
	(envelope-from freebsd)
Posted-Date: Fri, 24 Mar 2000 14:06:26 -0800 (PST)
Message-Id: <200003242206.OAA00645@mrynet.com>
From: freebsd@mrynet.com (FreeBSD mailing list)
Date: Fri, 24 Mar 2000 14:06:26 +0000
X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96)
To: bloom@acm.org
Subject: Re: fd0: Debugger("d_iocmd botch") called.
Cc: freebsd-current@freebsd.org
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Jim Bloom wrote:
> I reproduced the problem and have attached a patch.  It was the exact
> same problem as in swap_pager.c (assuming B_WRITE was 0).  Hopefully phk
> will commit this fix shortly.
> 
> Index: sys/isa/fd.c
> ===================================================================
> RCS file: /users/ncvs/src/sys/isa/fd.c,v
> retrieving revision 1.179
> diff -u -r1.179 fd.c
> --- sys/isa/fd.c	2000/03/20 11:28:39	1.179
> +++ sys/isa/fd.c	2000/03/24 20:20:53
> @@ -2228,6 +2228,7 @@
>  	BUF_LOCKINIT(bp);
>  	BUF_LOCK(bp, LK_EXCLUSIVE);
>  	bp->b_flags = B_PHYS | B_FORMAT;
> +	bp->b_iocmd = BIO_WRITE;
>  
>  	/*
>  	 * calculate a fake blkno, so fdstrategy() would initiate a

This patch does indeed fix the writing of floppies.  However, fdformat(1)
still fails as follows:

ttyp7:--ROOT--@mrynet (22): fdformat -f 1440 fd0.1440
Format 1440K floppy `/dev/fd0.1440'? (y/n): y
Processing EE^C------------------------------------

with /var/log/messages indicating:
Mar 24 13:51:13 mrynet /kernel: fd0c: hard error reading fsbn 0 of 0-17 (ST0 40<abnrml> ST1 4<sec_not_fnd> ST2 0
cyl 0 hd 0 sec 2)
Mar 24 13:51:13 mrynet /kernel: fd0c: hard error reading fsbn 0 of 0-17 (ST0 40<abnrml> ST1 4<sec_not_fnd> ST2 0
cyl 0 hd 0 sec 2)
Mar 24 13:51:13 mrynet /kernel: fd0c: hard error reading fsbn 18 of 18-35 (ST0 44<abnrml,top_head> ST1
4<sec_not_fnd> ST2 0 cyl 0 hd 1 sec 2)
Mar 24 13:51:13 mrynet /kernel: fd0c: hard error reading fsbn 18 of 18-35 (ST0 44<abnrml,top_head> ST1
4<sec_not_fnd> ST2 0 cyl 0 hd 1 sec 2)
Mar 24 13:51:14 mrynet /kernel: fd0c: hard error reading fsbn 36 of 36-53 (ST0 40<abnrml> ST1 4<sec_not_fnd> ST2 0
cyl 1 hd 0 sec 2)
Mar 24 13:51:14 mrynet /kernel: fd0c: hard error reading fsbn 36 of 36-53 (ST0 40<abnrml> ST1 4<sec_not_fnd> ST2 0
cyl 1 hd 0 sec 2)
(and continuing).

Additionally, reading a floppy returns errors for any read:
(This is a freshly formatted floppy verified on other machines)

ttyp7:--ROOT--@mrynet (7): dd if=/dev/rfd0.1440 | wc
dd: /dev/rfd0.1440: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 2.395566 secs (0 bytes/sec)
       0       0       0

with /var/log/messages indicating:
Mar 24 14:04:28 mrynet /kernel: fd0c: hard error reading fsbn 0 (ST0 40<abnrml> ST1 4<sec_not_fnd> ST2 0 cyl 0 hd 0
sec 2)
Mar 24 14:04:38 mrynet /kernel: fd0c: hard error reading fsbn 0 (ST0 40<abnrml> ST1 4<sec_not_fnd> ST2 0 cyl 0 hd 0
sec 2)


Thanks,
-scott
--
Scott G. Akmentins-Taylor     InterNet: staylor@mrynet.com
MRY Systems			        staylor@mrynet.lv


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 14:10:43 2000
Delivered-To: freebsd-current@freebsd.org
Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100])
	by hub.freebsd.org (Postfix) with ESMTP id E9E3137B791
	for <freebsd-current@freebsd.org>; Fri, 24 Mar 2000 14:10:34 -0800 (PST)
	(envelope-from stevek@tislabs.com)
Received: by sentry.gw.tislabs.com; id RAA26915; Fri, 24 Mar 2000 17:11:49 -0500 (EST)
Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5)
	id xma026908; Fri, 24 Mar 00 17:11:46 -0500
Received: from mufasa.va.tislabs.com (mufasa.va.tislabs.com [192.168.10.18])
	by clipper.gw.tislabs.com (8.9.3/8.9.1) with ESMTP id RAA01708
	for <freebsd-current@freebsd.org>; Fri, 24 Mar 2000 17:09:13 -0500 (EST)
Received: from localhost (stevek@localhost)
	by mufasa.va.tislabs.com (8.9.3/8.9.3) with ESMTP id RAA13895
	for <freebsd-current@freebsd.org>; Fri, 24 Mar 2000 17:12:32 -0500 (EST)
	(envelope-from stevek@mufasa.va.tislabs.com)
Date: Fri, 24 Mar 2000 17:12:32 -0500 (EST)
From: Steve Kiernan <stevek@tislabs.com>
To: freebsd-current@freebsd.org
Subject: breakage still in sys/systm.h
Message-ID: <Pine.BSF.4.10.10003241706260.13885-100000@mufasa.va.tislabs.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

The definitions of major() and minor() in sys/systm.h break usage of the
header.  Since sys/types.h defines major() and minor() as macros which
compute the major and minor numbers, this creates an order dependency on
sys/systm.h and sys/types.h.  Is this not a bad thing?

--
Stephen Kiernan
stevek@tislabs.com
NAI Labs, A Division of Network Associates, Inc.



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 14:15:48 2000
Delivered-To: freebsd-current@freebsd.org
Received: from katroo.Sendmail.COM (katroo.Sendmail.COM [209.246.26.35])
	by hub.freebsd.org (Postfix) with ESMTP id 271BF37B7A7
	for <freebsd-current@freebsd.org>; Fri, 24 Mar 2000 14:15:44 -0800 (PST)
	(envelope-from chrisd@sendmail.com)
Received: from sendmail.com (gabriel.Sendmail.COM [10.210.100.74])
	by katroo.Sendmail.COM (8.9.3/8.9.3) with ESMTP id OAA19418
	for <freebsd-current@freebsd.org>; Fri, 24 Mar 2000 14:15:42 -0800 (PST)
Message-ID: <38DBE90E.5059CE9C@sendmail.com>
Date: Fri, 24 Mar 2000 14:15:42 -0800
From: Christian DeKonink <chrisd@sendmail.com>
Organization: Sendmail, Inc - Services Department
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: freebsd-current@freebsd.org
Subject: test
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


--


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 14:18:15 2000
Delivered-To: freebsd-current@freebsd.org
Received: from katroo.Sendmail.COM (katroo.Sendmail.COM [209.246.26.35])
	by hub.freebsd.org (Postfix) with ESMTP id BEE8537BB9B
	for <freebsd-current@freebsd.org>; Fri, 24 Mar 2000 14:18:10 -0800 (PST)
	(envelope-from chrisd@sendmail.com)
Received: from sendmail.com (gabriel.Sendmail.COM [10.210.100.74])
	by katroo.Sendmail.COM (8.9.3/8.9.3) with ESMTP id OAA20049
	for <freebsd-current@freebsd.org>; Fri, 24 Mar 2000 14:18:09 -0800 (PST)
Message-ID: <38DBE9A1.5F2D9118@sendmail.com>
Date: Fri, 24 Mar 2000 14:18:09 -0800
From: Christian DeKonink <chrisd@sendmail.com>
Organization: Sendmail, Inc - Services Department
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: freebsd-current@freebsd.org
Subject: perl not working
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Hi,
	I just installed 4.0 and when I try to run perl I get

perl: warning Setting locale failed
perl: warning: Please check that you locale settings:
        LC_ALL = C
        LC_CTYPE = en_US
        LANG = C
      are supported and installed on your system
perl: warning: Falling back to standard locale ("C").


Is there any way to fix this. I've dedicated my hard disk to freebsd 4.0
and I can't run my killer app

Thanks,

-- 
Christian DeKonink


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 14:19:43 2000
Delivered-To: freebsd-current@freebsd.org
Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193])
	by hub.freebsd.org (Postfix) with ESMTP id 7B2E137BBDB
	for <freebsd-current@FreeBSD.ORG>; Fri, 24 Mar 2000 14:19:38 -0800 (PST)
	(envelope-from wollman@khavrinen.lcs.mit.edu)
Received: (from wollman@localhost)
	by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id RAA46260;
	Fri, 24 Mar 2000 17:19:34 -0500 (EST)
	(envelope-from wollman)
Date: Fri, 24 Mar 2000 17:19:34 -0500 (EST)
From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Message-Id: <200003242219.RAA46260@khavrinen.lcs.mit.edu>
To: Steve Kiernan <stevek@tislabs.com>
Cc: freebsd-current@FreeBSD.ORG
Subject: breakage still in sys/systm.h
In-Reply-To: <Pine.BSF.4.10.10003241706260.13885-100000@mufasa.va.tislabs.com>
References: <Pine.BSF.4.10.10003241706260.13885-100000@mufasa.va.tislabs.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

<<On Fri, 24 Mar 2000 17:12:32 -0500 (EST), Steve Kiernan <stevek@tislabs.com> said:

> The definitions of major() and minor() in sys/systm.h break usage of the
> header.  Since sys/types.h defines major() and minor() as macros which
> compute the major and minor numbers, this creates an order dependency on
> sys/systm.h and sys/types.h.  Is this not a bad thing?

No, since they don't conflict.  <sys/types.h> defines the major and
minor macros iff _KERNEL is not defined, and <sys/systm.h> is a
kernel-only header.

-GAWollman

--
Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
wollman@lcs.mit.edu  | O Siem / The fires of freedom 
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA|                     - Susan Aglukark and Chad Irschick


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 14:24:56 2000
Delivered-To: freebsd-current@freebsd.org
Received: from 1Cust199.tnt1.waldorf.md.da.uu.net (localhost [127.0.0.1])
	by hub.freebsd.org (Postfix) with ESMTP
	id 7196B37C0E5; Fri, 24 Mar 2000 14:24:45 -0800 (PST)
	(envelope-from green@FreeBSD.org)
Date: Fri, 24 Mar 2000 17:13:55 -0500 (EST)
From: Brian Fundakowski Feldman <green@FreeBSD.org>
X-Sender: green@green.dyndns.org
To: Steve Kiernan <stevek@tislabs.com>
Cc: freebsd-current@freebsd.org
Subject: Re: breakage still in sys/systm.h
In-Reply-To: <Pine.BSF.4.10.10003241706260.13885-100000@mufasa.va.tislabs.com>
Message-ID: <Pine.BSF.4.21.0003241712380.1223-100000@green.dyndns.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Fri, 24 Mar 2000, Steve Kiernan wrote:

> The definitions of major() and minor() in sys/systm.h break usage of the
> header.  Since sys/types.h defines major() and minor() as macros which
> compute the major and minor numbers, this creates an order dependency on
> sys/systm.h and sys/types.h.  Is this not a bad thing?

The sys/types.h header is meant to be included in userland code; the
sys/systm.h header is not to be included from outside of kernel code.
What possible reason would you have for systm.h in userland code?

> --
> Stephen Kiernan
> stevek@tislabs.com
> NAI Labs, A Division of Network Associates, Inc.

--
 Brian Fundakowski Feldman           \  FreeBSD: The Power to Serve!  /
 green@FreeBSD.org                    `------------------------------'



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 14:37:41 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mail.hcisp.net (Stargate.hcisp.net [208.60.89.18])
	by hub.freebsd.org (Postfix) with SMTP id 9B28237B7DA
	for <freebsd-current@FreeBSD.ORG>; Fri, 24 Mar 2000 14:37:35 -0800 (PST)
	(envelope-from tim@mysql.com)
Received: (qmail 12964 invoked from network); 24 Mar 2000 22:43:42 -0000
Received: from modem2.hcsip.net (HELO threads.polyesthetic.msg) (208.60.89.68)
  by stargate.hcisp.net with SMTP; 24 Mar 2000 22:43:42 -0000
Received: (qmail 37701 invoked by uid 1001); 24 Mar 2000 22:36:44 -0000
From: "Thimble Smith" <tim@mysql.com>
Date: Fri, 24 Mar 2000 17:36:44 -0500
To: Christian DeKonink <chrisd@sendmail.com>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: perl not working
Message-ID: <20000324173644.G37030@threads.polyesthetic.msg>
References: <38DBE9A1.5F2D9118@sendmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <38DBE9A1.5F2D9118@sendmail.com>; from chrisd@sendmail.com on Fri, Mar 24, 2000 at 02:18:09PM -0800
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Fri, Mar 24, 2000 at 02:18:09PM -0800, Christian DeKonink wrote:
>Hi,
>	I just installed 4.0 and when I try to run perl I get

Just so you know, I think 4.0 is being discussed on -stable now.

>perl: warning Setting locale failed
>perl: warning: Please check that you locale settings:
>        LC_ALL = C
>        LC_CTYPE = en_US
>        LANG = C
>      are supported and installed on your system
>perl: warning: Falling back to standard locale ("C").

Just do something like this in your /etc/profile or whatever is
appropriate:

LC_ALL=C
LC_CTYPE=C
LANG=C
export LC_ALL LC_CTYPE LANG

Tim


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 14:38:32 2000
Delivered-To: freebsd-current@freebsd.org
Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100])
	by hub.freebsd.org (Postfix) with ESMTP id 6761237BE77
	for <freebsd-current@FreeBSD.ORG>; Fri, 24 Mar 2000 14:38:19 -0800 (PST)
	(envelope-from stevek@tislabs.com)
Received: by sentry.gw.tislabs.com; id RAA27210; Fri, 24 Mar 2000 17:39:52 -0500 (EST)
Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5)
	id xma027203; Fri, 24 Mar 00 17:39:39 -0500
Received: from mufasa.va.tislabs.com (mufasa.va.tislabs.com [192.168.10.18])
	by clipper.gw.tislabs.com (8.9.3/8.9.1) with ESMTP id RAA02312;
	Fri, 24 Mar 2000 17:37:06 -0500 (EST)
Received: from localhost (stevek@localhost)
	by mufasa.va.tislabs.com (8.9.3/8.9.3) with ESMTP id RAA13956;
	Fri, 24 Mar 2000 17:40:26 -0500 (EST)
	(envelope-from stevek@mufasa.va.tislabs.com)
Date: Fri, 24 Mar 2000 17:40:26 -0500 (EST)
From: Steve Kiernan <stevek@tislabs.com>
To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Cc: Steve Kiernan <stevek@tislabs.com>, freebsd-current@FreeBSD.ORG
Subject: Re: breakage still in sys/systm.h
In-Reply-To: <200003242219.RAA46260@khavrinen.lcs.mit.edu>
Message-ID: <Pine.BSF.4.10.10003241739320.13885-100000@mufasa.va.tislabs.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Fri, 24 Mar 2000, Garrett Wollman wrote:

> <<On Fri, 24 Mar 2000 17:12:32 -0500 (EST), Steve Kiernan <stevek@tislabs.com> said:
> 
> > The definitions of major() and minor() in sys/systm.h break usage of the
> > header.  Since sys/types.h defines major() and minor() as macros which
> > compute the major and minor numbers, this creates an order dependency on
> > sys/systm.h and sys/types.h.  Is this not a bad thing?
> 
> No, since they don't conflict.  <sys/types.h> defines the major and
> minor macros iff _KERNEL is not defined, and <sys/systm.h> is a

Ah, okay, I see what the problem is with my filesystem driver.  Looks like
the #define switched from KERNEL to _KERNEL from 3.x to -CURRENT.

Thanks.

--
Stephen Kiernan
stevek@tislabs.com
NAI Labs, A Division of Network Associates, Inc.



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 14:40:52 2000
Delivered-To: freebsd-current@freebsd.org
Received: from 1Cust199.tnt1.waldorf.md.da.uu.net (localhost [127.0.0.1])
	by hub.freebsd.org (Postfix) with ESMTP
	id 586FB37BCB4; Fri, 24 Mar 2000 14:40:28 -0800 (PST)
	(envelope-from green@FreeBSD.org)
Date: Fri, 24 Mar 2000 17:38:40 -0500 (EST)
From: Brian Fundakowski Feldman <green@FreeBSD.org>
X-Sender: green@green.dyndns.org
To: Andrzej Bialecki <abial@webgiro.com>
Cc: freebsd-current@freebsd.org
Subject: Re: Dynamic sysctls - patches for review
In-Reply-To: <Pine.BSF.4.20.0003241623050.31345-100000@mx.webgiro.com>
Message-ID: <Pine.BSF.4.21.0003241735050.1223-100000@green.dyndns.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Fri, 24 Mar 2000, Andrzej Bialecki wrote:

> I'd appreciate some feedback. Thanks!
> 

Note this is not an actual peer review (yet), but... Good job!  This
is another big step in the right direction, and the code looks good
to me :)  The only problems I can see right now are just all style
bugs (^_^)

> Andrzej Bialecki
> 
> //  <abial@webgiro.com> WebGiro AB, Sweden (http://www.webgiro.com)
> // -------------------------------------------------------------------
> // ------ FreeBSD: The Power to Serve. http://www.freebsd.org --------
> // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ----

--
 Brian Fundakowski Feldman           \  FreeBSD: The Power to Serve!  /
 green@FreeBSD.org                    `------------------------------'



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 15:32:12 2000
Delivered-To: freebsd-current@freebsd.org
Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20])
	by hub.freebsd.org (Postfix) with ESMTP id 3072E37B772
	for <freebsd-current@FreeBSD.ORG>; Fri, 24 Mar 2000 15:32:07 -0800 (PST)
	(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
	by fw.wintelcom.net (8.10.0/8.10.0) id e2ONtqO01296;
	Fri, 24 Mar 2000 15:55:52 -0800 (PST)
Date: Fri, 24 Mar 2000 15:55:52 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: Preliminary SMP/BGL patch
Message-ID: <20000324155552.V21029@fw.wintelcom.net>
References: <200003241759.JAA14699@apollo.backplane.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200003241759.JAA14699@apollo.backplane.com>; from dillon@apollo.backplane.com on Fri, Mar 24, 2000 at 09:59:16AM -0800
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

* Matthew Dillon <dillon@apollo.backplane.com> [000324 10:23] wrote:
>     A preliminary BGL patch is now on my site, relative to RELENG_4.
> 
> 	http://www.backplane.com/FreeBSD4/
> 
>     It is the smp-patch-03.diff item at the end of the first section.
> 
>     My test box successfully built the world.  I know I'm probably missing
>     something, but so far I can't tell what it might be because nothing
>     is failing :-)
> 
>     This is considered very alpha and has been made available mainly to
>     endgender discussion.  You know, things like "Matt, you've really gone
>     off the deep end this time! You cannot *DO* that to the syscall 
>     interface!".

Do it! do it! do it! :)

>     My primary assumption is that read access to fields in curproc plus any
>     structural references that are 'static'-like (e.g. like ucred) are legal
>     without having to hold the BGL.  So getuid() can be made BGL safe
>     but getppid() cannot (nor can getpid() because compatibility mode also
>     returns the ppid).  Obviously there are other fine-grained solutions.
> 
>     The biggest assumption in the patch is that doreti does not have to be
>     called for system calls.  Being able to get rid of it for syscalls means
>     being able to do an end-run around doreti's extremely SMP-unsafe code.

This sort of concerns me, but if I remeber correctly, unmasking
spl will cause a soft intr if there are pending interupts, the only
problem is that completely software initiated interupts wouldn't
get processed, or would they?  Can you explain how they are being
scheduled/run if you remove doreti()?  One alternative would be to
call doreti() only in the syscalls with the MPunsafe flag set,
although I'm probably missing something that makes doreti() totally
unnessesary, it may be that clock interupts are covering your
removal of doreti().

FYI, I was tempted to commit this with "Submitted by: dillon" and
watch the fur fly, it is 5.0 after all. :)

As things progress I think multi-subsystem locks expressing intent
for structure manipulation would be a very cool idea, although I
need to think about it more.

thanks,
-Alfred



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 15:40: 1 2000
Delivered-To: freebsd-current@freebsd.org
Received: from trinity.skynet.be (trinity.skynet.be [195.238.2.38])
	by hub.freebsd.org (Postfix) with ESMTP id DAD4A37BB8B
	for <freebsd-current@FreeBSD.ORG>; Fri, 24 Mar 2000 15:39:57 -0800 (PST)
	(envelope-from blk@skynet.be)
Received: from [194.78.234.186] (dialup1722.brussels.skynet.be [194.78.234.186])
	by trinity.skynet.be (Postfix) with ESMTP
	id C90E318119; Sat, 25 Mar 2000 00:39:41 +0100 (MET)
Mime-Version: 1.0
X-Sender: blk@pop.skynet.be
Message-Id: <v04220805b5019e640ed5@[195.238.1.121]>
In-Reply-To: <v04210110b50178e7bb92@[128.113.24.47]>
References: <200003241801.KAA14754@apollo.backplane.com>
 <v04210110b50178e7bb92@[128.113.24.47]>
Date: Fri, 24 Mar 2000 23:38:03 +0100
To: Garance A Drosihn <drosih@rpi.edu>,
	Matthew Dillon <dillon@apollo.backplane.com>,
	Alfred Perlstein <bright@wintelcom.net>, freebsd-current@FreeBSD.ORG
From: Brad Knowles <blk@skynet.be>
Subject: Re: Experts only please! (was Re: Preliminary SMP/BGL patch)
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

At 2:57 PM -0500 2000/3/24, Garance A Drosihn wrote:

>  At 10:01 AM -0800 3/24/00, Matthew Dillon wrote:
>>     This is not a 'normal Matt patch' that 'just works'.  Ok, it seems to
>>     just work, but it's not a normal Matt patch.  If there were a
>>     designation before 'early alpha' this patch would get it.
>
>  "Rough-draft proposal for early alpha version"

	"Theoretical basis for early access to code virtually guaranteed 
to mess up your system in highly entertaining ways, although the 
complete reinstall and rebuild might be rather annoying"

--
   These are my opinions -- not to be taken as official Skynet policy
======================================================================
Brad Knowles, <blk@skynet.be>                || 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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 16: 4:18 2000
Delivered-To: freebsd-current@freebsd.org
Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243])
	by hub.freebsd.org (Postfix) with ESMTP
	id 1B20537BC8A; Fri, 24 Mar 2000 16:04:05 -0800 (PST)
	(envelope-from asami@cs.berkeley.edu)
Received: from silvia.hip.berkeley.edu (sji-ca6-109.ix.netcom.com [205.186.213.109])
	by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id SAA09719;
	Fri, 24 Mar 2000 18:52:47 -0500 (EST)
Received: (from asami@localhost) by silvia.hip.berkeley.edu (8.9.3/8.6.9) id PAA24441; Fri, 24 Mar 2000 15:52:36 -0800 (PST)
To: "R. Imura" <imura@af.airnet.ne.jp>
Cc: nsayer@freebsd.org, will@freebsd.org, freebsd-ports@freebsd.org,
	freebsd-current@freebsd.org
Subject: Re: KDE kdm problem with packaged version (make release  issue?)
References: <38C9823F.5FCDCF40@sftw.com> <20000323213103K.imura@cs.titech.ac.jp>
From: asami@freebsd.org (Satoshi - Ports Wraith - Asami)
Date: 24 Mar 2000 15:52:27 -0800
In-Reply-To: "R. Imura"'s message of "Thu, 23 Mar 2000 21:31:03 +0900"
Message-ID: <vqc3dpgylhg.fsf@silvia.hip.berkeley.edu>
Lines: 13
X-Mailer: Gnus v5.7/Emacs 20.6
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

 * From: "R. Imura" <imura@af.airnet.ne.jp>

 * It's because, there are no /usr/X11R6/bin/X in Asami-san's chroot
 * environment, I bet.

Hmm.  So kdm looks at the X symlink to decide whether to build with X
support or not?

I can add that to my X package, but what exactly do I need?  Just the
symlink (to nowhere), or do I need it to be pointing to one of the
servers?  (Or even an empty file with that name?)

Satoshi


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 16:24:51 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id 9DC9137B771
	for <freebsd-current@FreeBSD.ORG>; Fri, 24 Mar 2000 16:24:35 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id QAA17399;
	Fri, 24 Mar 2000 16:24:33 -0800 (PST)
	(envelope-from dillon)
Date: Fri, 24 Mar 2000 16:24:33 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003250024.QAA17399@apollo.backplane.com>
To: Alfred Perlstein <bright@wintelcom.net>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: Preliminary SMP/BGL patch
References: <200003241759.JAA14699@apollo.backplane.com> <20000324155552.V21029@fw.wintelcom.net>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

:This sort of concerns me, but if I remeber correctly, unmasking
:spl will cause a soft intr if there are pending interupts, the only
:problem is that completely software initiated interupts wouldn't
:get processed, or would they?  Can you explain how they are being
:scheduled/run if you remove doreti()?  One alternative would be to
:call doreti() only in the syscalls with the MPunsafe flag set,
:although I'm probably missing something that makes doreti() totally
:unnessesary, it may be that clock interupts are covering your
:removal of doreti().

    Ditto on the concern.  I almost have the second version of the patch ready,
    which cleans up a huge number of accretions from things
    people were testing but never finished.  I've removed _cil and _cml,
    I've removed all the _LOCK macros that all devolve down into the mp_lock
    and simply have them call get_mplock.  I've removed the sti code in
    MPgetlock_edx which was there solely to deal with one case in swtch.s
    where interrupts weren't enabled at the time the MP lock was attempted
    (interrupts have to be enabled when spinning on the MP lock in order
    to be able to take IPI's, so things like cpu shutdowns work).  Actually,
    that's the one piece I still haven't fixed all the cases for that's 
    holding up the second patch.  'reboot' isn't working right due to IPI's
    not getting through :-).

    With all the cleanups and the weirder conditional code removed, it's 
    become a whole lot more readable and the doreti picture is becoming much
    clearer.  I think, at worst, I may be missing an AST check there.

    I have created a document outlining a 'new' SMP mechanism proposal,
    with emphasis on the interrupt handling (keep in mind that most 
    interrupts will be synchronously switched to or use the BSDI mechanism,
    so overhead is not as bad as it may seem to a layperson).  I haven't
    implemented the interrupt mechanism yet - doh!  That's a lot work :-),
    but I have removed all the weird interrupt optimizations that were in
    there before that don't make much sense with regards to the direction
    we appear to be heading for interrupt handling.

	http://www.backplane.com/FreeBSD4/smp-api.html

:FYI, I was tempted to commit this with "Submitted by: dillon" and
:watch the fur fly, it is 5.0 after all. :)
:
:As things progress I think multi-subsystem locks expressing intent
:for structure manipulation would be a very cool idea, although I
:need to think about it more.
:
:thanks,
:-Alfred

    Well, as implemented in the interrupt, trap, and syscall code this
    idea is a failure.  It doesn't help the critical path at all (it can't,
    since you are still causing L1 cache invalidations on every entry!).  
    It's all gone in the new patch.

    I think there is definitely a place for per-structure spinlocks,
    especially in non-blocking situations (think: the critical path in
    the signal mask code).  But it's too early to discuss that.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 16:29:30 2000
Delivered-To: freebsd-current@freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
	by hub.freebsd.org (Postfix) with ESMTP
	id 450A337BAA6; Fri, 24 Mar 2000 16:29:29 -0800 (PST)
	(envelope-from kris@FreeBSD.org)
Received: from localhost (kris@localhost)
	by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id QAA85779;
	Fri, 24 Mar 2000 16:29:29 -0800 (PST)
	(envelope-from kris@FreeBSD.org)
X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs
Date: Fri, 24 Mar 2000 16:29:28 -0800 (PST)
From: Kris Kennaway <kris@FreeBSD.org>
To: Bruce Evans <bde@zeta.org.au>
Cc: current@FreeBSD.org
Subject: Re: Optimisation patch
In-Reply-To: <Pine.BSF.4.21.0003241944400.4121-100000@alphplex.bde.org>
Message-ID: <Pine.BSF.4.21.0003241628210.84338-100000@freefall.freebsd.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Fri, 24 Mar 2000, Bruce Evans wrote:

> > Hmm. What is the correct way of compiling world with optimisation
> > or other compiler settings?
> 
> `make world'.  Optimization is in the default settings (-O).

Fair enough - but how about platform-specific code generation settings,
e.g. -march=pentium?

Kris

----
In God we Trust -- all others must submit an X.509 certificate.
    -- Charles Forsythe <forsythe@alum.mit.edu>



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 17:12: 2 2000
Delivered-To: freebsd-current@freebsd.org
Received: from trinity.skynet.be (trinity.skynet.be [195.238.2.38])
	by hub.freebsd.org (Postfix) with ESMTP
	id 4330037BFD8; Fri, 24 Mar 2000 17:11:53 -0800 (PST)
	(envelope-from blk@skynet.be)
Received: from [194.78.234.186] (dialup1722.brussels.skynet.be [194.78.234.186])
	by trinity.skynet.be (Postfix) with ESMTP
	id 6057018149; Sat, 25 Mar 2000 02:11:49 +0100 (MET)
Mime-Version: 1.0
X-Sender: blk@pop.skynet.be
Message-Id: <v0422080db501c0b61c4f@[194.78.234.186]>
In-Reply-To:
 <Pine.BSF.4.21.0003241628210.84338-100000@freefall.freebsd.org>
References:
 <Pine.BSF.4.21.0003241628210.84338-100000@freefall.freebsd.org>
Date: Sat, 25 Mar 2000 02:05:46 +0100
To: Kris Kennaway <kris@FreeBSD.ORG>, Bruce Evans <bde@zeta.org.au>
From: Brad Knowles <blk@skynet.be>
Subject: Re: Optimisation patch
Cc: current@FreeBSD.ORG
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

At 4:29 PM -0800 2000/3/24, Kris Kennaway wrote:

>>  `make world'.  Optimization is in the default settings (-O).
>
>  Fair enough - but how about platform-specific code generation settings,
>  e.g. -march=pentium?

	Whatever the official position is, it should be documented in 
/etc/make.conf, and warnings should be exceptionally clear and the 
potential consequences laid out as being exceptionally dire, if one 
was so "adventurous" as to enable them by default for all compiles or 
to enable them for the process of making the kernel.

	There's no sense wasting everyone's time when you get a lot of 
"Doctor, doctor -- it hurts when I do this!" to which our reply is 
only going to be "So don't do that, you moron!"

--
   These are my opinions -- not to be taken as official Skynet policy
======================================================================
Brad Knowles, <blk@skynet.be>                || 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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 17:14:38 2000
Delivered-To: freebsd-current@freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
	by hub.freebsd.org (Postfix) with ESMTP
	id 5C7D237BEDA; Fri, 24 Mar 2000 17:14:35 -0800 (PST)
	(envelope-from kris@FreeBSD.org)
Received: from localhost (kris@localhost)
	by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id RAA93476;
	Fri, 24 Mar 2000 17:14:35 -0800 (PST)
	(envelope-from kris@FreeBSD.org)
X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs
Date: Fri, 24 Mar 2000 17:14:34 -0800 (PST)
From: Kris Kennaway <kris@FreeBSD.org>
To: Brad Knowles <blk@skynet.be>
Cc: Bruce Evans <bde@zeta.org.au>, current@FreeBSD.ORG
Subject: Re: Optimisation patch
In-Reply-To: <v0422080db501c0b61c4f@[194.78.234.186]>
Message-ID: <Pine.BSF.4.21.0003241713500.84338-100000@freefall.freebsd.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Sat, 25 Mar 2000, Brad Knowles wrote:

> 	Whatever the official position is, it should be documented in 
> /etc/make.conf, and warnings should be exceptionally clear and the 
> potential consequences laid out as being exceptionally dire, if one 
> was so "adventurous" as to enable them by default for all compiles or 
> to enable them for the process of making the kernel.

Err, this thread started with a patch to do that, which is what we're
currently discussing.

Kris

----
In God we Trust -- all others must submit an X.509 certificate.
    -- Charles Forsythe <forsythe@alum.mit.edu>



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 17:16:50 2000
Delivered-To: freebsd-current@freebsd.org
Received: from dt051n0b.san.rr.com (dt051n0b.san.rr.com [204.210.32.11])
	by hub.freebsd.org (Postfix) with ESMTP
	id 11AA737B796; Fri, 24 Mar 2000 17:16:46 -0800 (PST)
	(envelope-from Doug@gorean.org)
Received: from slave (doug@slave [10.0.0.1])
	by dt051n0b.san.rr.com (8.9.3/8.9.3) with ESMTP id RAA06937;
	Fri, 24 Mar 2000 17:16:36 -0800 (PST)
	(envelope-from Doug@gorean.org)
Date: Fri, 24 Mar 2000 17:16:36 -0800 (PST)
From: Doug Barton <Doug@gorean.org>
X-Sender: doug@dt051n0b.san.rr.com
To: John Baldwin <jhb@FreeBSD.org>
Cc: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>, peter@FreeBSD.org,
	current@FreeBSD.org
Subject: Re: sysinstall broken :(
In-Reply-To: <200003241910.OAA79160@server.baldwin.cx>
Message-ID: <Pine.BSF.4.21.0003241713570.6914-100000@dt051n0b.san.rr.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Fri, 24 Mar 2000, John Baldwin wrote:

> 
> On 24-Mar-00 Jordan K. Hubbard wrote:
> >> Hmph, it seems sysinstall (and thus make release) is broken in -current:
> > 
> > I don't know what version of sysinstall you're using, but it builds just
> > fine for me under -current.  I saw some other kvetching about kget
> > being broken and just tried building it last night.  Observe:

> > root@zippy-> uname -a
> > FreeBSD zippy.cdrom.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Mar 15 13:05:47 PST 2000    
> > jkh@zippy.cdrom.com:/usr/src/sys/compile/ZIPPY  i386
> 
> That's because your -current is too old:

	Actually it was broken in -Current when I tried to compile around
11pm PST on wednesday. That's why in my "kvetching" I was careful to
specify that I had up to the minute sources in _MY_ tree. :)

Doug (FreeBSD kvetcher at large)
-- 
    "So, the cows were part of a dream that dreamed itself into
existence? Is that possible?" asked the student incredulously.
    The master simply replied, "Mu."




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 17:54:40 2000
Delivered-To: freebsd-current@freebsd.org
Received: from morpheus.skynet.be (morpheus.skynet.be [195.238.2.39])
	by hub.freebsd.org (Postfix) with ESMTP
	id 7BA6B37B708; Fri, 24 Mar 2000 17:54:36 -0800 (PST)
	(envelope-from blk@skynet.be)
Received: from [194.78.234.186] (dialup1722.brussels.skynet.be [194.78.234.186])
	by morpheus.skynet.be (Postfix) with ESMTP
	id E9B60DB70; Sat, 25 Mar 2000 02:54:06 +0100 (MET)
Mime-Version: 1.0
X-Sender: blk@pop.skynet.be
Message-Id: <v04220814b501cc0ec64e@[194.78.234.186]>
In-Reply-To:
 <Pine.BSF.4.21.0003241713500.84338-100000@freefall.freebsd.org>
References:
 <Pine.BSF.4.21.0003241713500.84338-100000@freefall.freebsd.org>
Date: Sat, 25 Mar 2000 02:52:00 +0100
To: Kris Kennaway <kris@FreeBSD.org>
From: Brad Knowles <blk@skynet.be>
Subject: Re: Optimisation patch
Cc: Bruce Evans <bde@zeta.org.au>, current@FreeBSD.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

At 5:14 PM -0800 2000/3/24, Kris Kennaway wrote:

>  Err, this thread started with a patch to do that, which is what we're
>  currently discussing.

	Understood.  I just didn't want to lose sight of the real goal of 
the proposed patch, and what led up to the proposed patch.

--
   These are my opinions -- not to be taken as official Skynet policy
======================================================================
Brad Knowles, <blk@skynet.be>                || 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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 17:57:17 2000
Delivered-To: freebsd-current@freebsd.org
Received: from firehouse.net (networkoperations.com [209.42.203.32])
	by hub.freebsd.org (Postfix) with SMTP id 35FC137B820
	for <freebsd-current@FreeBSD.ORG>; Fri, 24 Mar 2000 17:57:11 -0800 (PST)
	(envelope-from abc@firehouse.net)
Received: (qmail 392 invoked by uid 1000); 25 Mar 2000 01:56:58 -0000
Date: Fri, 24 Mar 2000 20:56:58 -0500
From: Alan Clegg <abc@bsdi.com>
To: freebsd-current@FreeBSD.ORG
Subject: reproducable system crash in 4.0-STABLE
Message-ID: <20000324205658.A320@ecto.greenpeas.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
	protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N"
X-Mailer: Mutt 1.0.1i
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


--fUYQa+Pmc3FrFX/N
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

I know this is not "current", but it was last week, so give me a break.

On a dual PII system, access to /dev/smb0 (system management bus) by=20
wmhm (/usr/ports/sysutils/wmhm) or gkrellm (/usr/ports/sysutils/gkrellm)
causes an immediate system panic.

I have the following in dmesg:

   smbus0: <System Management Bus> on bti2c0
   smb0: <SMBus general purpose I/O> on smbus0

and I have system dumps available to whoever wants.

Traceback follows:

(kgdb) where
#0  boot (howto=3D256) at ../../kern/kern_shutdown.c:304
#1  0xc017f2c0 in poweroff_wait (junk=3D0xc032b34f, howto=3D-936451424)
    at ../../kern/kern_shutdown.c:554
#2  0xc02d2323 in trap_fatal (frame=3D0xc832accc, eva=3D64)
    at ../../i386/i386/trap.c:924
#3  0xc02d1fb9 in trap_pfault (frame=3D0xc832accc, usermode=3D0, eva=3D64)
    at ../../i386/i386/trap.c:817
#4  0xc02d1bb7 in trap (frame=3D{tf_fs =3D -936247272, tf_es =3D 16, tf_ds =
=3D 16,=20
      tf_edi =3D 0, tf_esi =3D -1056958976, tf_ebp =3D -936202996,=20
      tf_isp =3D -936203016, tf_ebx =3D -1063630240, tf_edx =3D -1057000192=
,=20
      tf_ecx =3D -1056958976, tf_eax =3D 0, tf_trapno =3D 12, tf_err =3D 0,=
=20
      tf_eip =3D -1072143334, tf_cs =3D 8, tf_eflags =3D 66118, tf_esp =3D =
-936202972,=20
      tf_ss =3D -1072262237}) at ../../i386/i386/trap.c:423
#5  0xc018641a in device_get_softc (dev=3D0x0) at ../../kern/subr_bus.c:982
#6  0xc01693a3 in iicbus_request_bus (bus=3D0x0, dev=3D0xc1001600, how=3D3)
    at ../../dev/iicbus/iiconf.c:103
#7  0xc022fd68 in bti2c_smb_callback (dev=3D0xc1001600, index=3D1, data=3D0=
xc832ad88)
    at ../../dev/bktr/bktr_i2c.c:228
#8  0xc0166c78 in SMBUS_CALLBACK (dev=3D0xc1001600, index=3D1,=20
    data=3D0xc832ad88 "\003") at smbus_if.c:37
#9  0xc01670a1 in smbus_request_bus (bus=3D0xc1001400, dev=3D0xc1001380, ho=
w=3D3)
    at ../../dev/smbus/smbconf.c:136
#10 0xc016739c in smbioctl (dev=3D0xc1001300, cmd=3D2148821255,=20
    data=3D0xc832aebc "'", flags=3D3, p=3D0xc82ee2a0) at ../../dev/smbus/sm=
b.c:202
#11 0xc01b4aca in spec_ioctl (ap=3D0xc832adf8)
    at ../../miscfs/specfs/spec_vnops.c:304
#12 0xc01b47f5 in spec_vnoperate (ap=3D0xc832adf8)
    at ../../miscfs/specfs/spec_vnops.c:117
#13 0xc026c435 in ufs_vnoperatespec (ap=3D0xc832adf8)
    at ../../ufs/ufs/ufs_vnops.c:2301
#14 0xc01afc08 in vn_ioctl (fp=3D0xc110e3c0, com=3D2148821255,=20
    data=3D0xc832aebc "'", p=3D0xc82ee2a0) at vnode_if.h:429
#15 0xc018c793 in ioctl (p=3D0xc82ee2a0, uap=3D0xc832af80) at ../../sys/fil=
e.h:171
#16 0xc02d25aa in syscall (frame=3D{tf_fs =3D 47, tf_es =3D 47, tf_ds =3D 4=
7,=20
      tf_edi =3D -1077937988, tf_esi =3D 7, tf_ebp =3D -1077938052,=20
      tf_isp =3D -936202284, tf_ebx =3D -1077938072, tf_edx =3D 0, tf_ecx =
=3D 0,=20
      tf_eax =3D 54, tf_trapno =3D 12, tf_err =3D 2, tf_eip =3D 674565904, =
tf_cs =3D 31,=20
      tf_eflags =3D 659, tf_esp =3D -1077938128, tf_ss =3D 47})
    at ../../i386/i386/trap.c:1073
#17 0xc02c06b1 in Xint0x80_syscall ()


--fUYQa+Pmc3FrFX/N
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: RA5zTp+gIBMXNg7DvECc/m1hUB3gY2ku

iQA/AwUBONwc6fcyv/gweBpYEQJP3ACgz+IknuQkSBRd+ot036gboXEFlFMAoPAN
tsmUhsNy3bjM6WxKHMn5ntyS
=cSOL
-----END PGP SIGNATURE-----

--fUYQa+Pmc3FrFX/N--


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 17:58:11 2000
Delivered-To: freebsd-current@freebsd.org
Received: from morpheus.skynet.be (morpheus.skynet.be [195.238.2.39])
	by hub.freebsd.org (Postfix) with ESMTP id 3326B37B7BD
	for <freebsd-current@freebsd.org>; Fri, 24 Mar 2000 17:58:08 -0800 (PST)
	(envelope-from blk@skynet.be)
Received: from [194.78.234.186] (dialup1722.brussels.skynet.be [194.78.234.186])
	by morpheus.skynet.be (Postfix) with ESMTP id 9EC09DAC7
	for <freebsd-current@freebsd.org>; Sat, 25 Mar 2000 02:58:06 +0100 (MET)
Mime-Version: 1.0
X-Sender: blk@pop.skynet.be
Message-Id: <v04220816b501cd2c0970@[194.78.234.186]>
Date: Sat, 25 Mar 2000 02:57:51 +0100
To: FreeBSD-CURRENT Mailing List <freebsd-current@freebsd.org>
From: Brad Knowles <blk@skynet.be>
Subject: Accessing FreeBSD 3.4-STABLE filesystems from 4.0-STABLE...
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Folks,

	I gotta be doing something stupid here.  I haven't been able to 
access the existing 3.4-STABLE filesystems on this machine since I 
upgraded it to 4.0-STABLE on a second hard drive, and I likewise 
can't access the 4.0-STABLE filesystems from 3.4-STABLE.

	Anybody got any ideas what I might have done wrong, and what 
parts of the archives I should go searching in (and what I should be 
searching for ;-), in order to find the answers?


	Thanks!

--
   These are my opinions -- not to be taken as official Skynet policy
======================================================================
Brad Knowles, <blk@skynet.be>                || 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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 18: 4:46 2000
Delivered-To: freebsd-current@freebsd.org
Received: from pawn.primelocation.net (pawn.primelocation.net [205.161.238.235])
	by hub.freebsd.org (Postfix) with ESMTP id B3C1337B7C7
	for <freebsd-current@FreeBSD.ORG>; Fri, 24 Mar 2000 18:04:41 -0800 (PST)
	(envelope-from cdf.lists@fxp.org)
Received: by pawn.primelocation.net (Postfix, from userid 1016)
	id ADCF99B17; Fri, 24 Mar 2000 21:04:40 -0500 (EST)
Received: from localhost (localhost [127.0.0.1])
	by pawn.primelocation.net (Postfix) with ESMTP
	id A450ABA1D; Fri, 24 Mar 2000 21:04:40 -0500 (EST)
Date: Fri, 24 Mar 2000 21:04:40 -0500 (EST)
From: "Chris D. Faulhaber" <jedgar@fxp.org>
X-Sender: cdf.lists@pawn.primelocation.net
To: Alan Clegg <abc@bsdi.com>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: reproducable system crash in 4.0-STABLE
In-Reply-To: <20000324205658.A320@ecto.greenpeas.org>
Message-ID: <Pine.BSF.4.10.10003242101270.14291-100000@pawn.primelocation.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Fri, 24 Mar 2000, Alan Clegg wrote:

> I know this is not "current", but it was last week, so give me a break.
> 
> On a dual PII system, access to /dev/smb0 (system management bus) by 
> wmhm (/usr/ports/sysutils/wmhm) or gkrellm (/usr/ports/sysutils/gkrellm)
> causes an immediate system panic.
> 
> I have the following in dmesg:
> 
>    smbus0: <System Management Bus> on bti2c0
>    smb0: <SMBus general purpose I/O> on smbus0
> 
> and I have system dumps available to whoever wants.
> 

I got similiar panics when I was working on my {wm}lmmon ports.  You need:

device          intpm

in your kernel config (or use the /dev/io method).

I reported this when I found it a few months ago, but no one seemed to
care.  The system shouldn't panic if the device isn't present in the
kernel, but...

-----
Chris D. Faulhaber - jedgar@fxp.org - jedgar@FreeBSD.org
--------------------------------------------------------
FreeBSD: The Power To Serve   -   http://www.FreeBSD.org



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 18:16:22 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id 7496237B5F9
	for <freebsd-current@FreeBSD.ORG>; Fri, 24 Mar 2000 18:16:19 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id SAA18264;
	Fri, 24 Mar 2000 18:16:18 -0800 (PST)
	(envelope-from dillon)
Date: Fri, 24 Mar 2000 18:16:18 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003250216.SAA18264@apollo.backplane.com>
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: Alfred Perlstein <bright@wintelcom.net>,
	freebsd-current@FreeBSD.ORG
Subject: SMP/BGL patch 04
References: <200003241759.JAA14699@apollo.backplane.com> <20000324155552.V21029@fw.wintelcom.net> <200003250024.QAA17399@apollo.backplane.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

    Patch 04 is ready.

    http://www.backplane.com/FreeBSD4/
    http://www.backplane.com/FreeBSD4/smp-patch-04.diff

    Contains lots of cleanup of stale SMP code.  There are still a few places
    where get_mplock is being called with interrupts disabled which I haven't
    found, so I put the sti test back in.

    I also removed the FAST_SIMPLELOCK optimization, which had been turned
    on - mainly because it's not useful if we are moving to an interrupt 
    thread scheme (as in it's still a global interrupt lock, whereas the
    thread scheme will allow concurrent interrupt execution), but also 
    because it makes too many assumptions about what can run outside the 
    MP lock.

    I'm going to let people bang on this for a few days, and then I think
    it should be committed into -CURRENT (5.x) in order to allow people
    to start banging on optimizing the BGL/syscall paths.  All comments
    welcome (but not necessary acted upon) :-).

						-Matt



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 18:54:31 2000
Delivered-To: freebsd-current@freebsd.org
Received: from firehouse.net (networkoperations.com [209.42.203.32])
	by hub.freebsd.org (Postfix) with SMTP id 197F037B5EF
	for <freebsd-current@FreeBSD.ORG>; Fri, 24 Mar 2000 18:54:23 -0800 (PST)
	(envelope-from abc@firehouse.net)
Received: (qmail 362 invoked by uid 1000); 25 Mar 2000 02:54:19 -0000
Date: Fri, 24 Mar 2000 21:54:19 -0500
From: Alan Clegg <abc@bsdi.com>
To: freebsd-current@FreeBSD.ORG
Subject: Re: reproducable system crash in 4.0-STABLE
Message-ID: <20000324215419.A288@ecto.greenpeas.org>
References: <20000324205658.A320@ecto.greenpeas.org> <Pine.BSF.4.10.10003242101270.14291-100000@pawn.primelocation.net>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
	protocol="application/pgp-signature"; boundary="UlVJffcvxoiEqYs2"
X-Mailer: Mutt 1.0.1i
In-Reply-To: <Pine.BSF.4.10.10003242101270.14291-100000@pawn.primelocation.net>; from jedgar@fxp.org on Fri, Mar 24, 2000 at 09:04:40PM -0500
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


--UlVJffcvxoiEqYs2
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

BTW, this is from sources cvsup'd at 3:00 this afternoon, Fri, March 24.

Out of the ether, Chris D. Faulhaber spewed forth the following bitstream:

> > On a dual PII system, access to /dev/smb0 (system management bus) by=20
> > wmhm (/usr/ports/sysutils/wmhm) or gkrellm (/usr/ports/sysutils/gkrellm)
> > causes an immediate system panic.

> I got similiar panics when I was working on my {wm}lmmon ports.  You need:
>=20
> device          intpm

Even with:

	device          smbus           # Bus support, required for smb below.
	device          intpm
	device          alpm
	device          smb
	device          iicbus          # Bus support, required for ic/iic/iicsmb =
below.
	device          iicbb
	device          ic
	device          iic
	device          iicsmb          # smb over i2c bridge

And finding:

iicbb0: <I2C generic bit-banging driver> on bti2c0
iicbus0: <Philips I2C bus> on iicbb0 master-only
iicsmb0: <I2C to SMB bridge> on iicbus0
smbus0: <System Management Bus> on iicsmb0
smb0: <SMBus general purpose I/O> on smbus0
iic0: <I2C general purpose I/O> on iicbus0
smbus1: <System Management Bus> on bti2c0
smb1: <SMBus general purpose I/O> on smbus1

It still panics:

#0  boot (howto=3D256) at ../../kern/kern_shutdown.c:304
#1  0xc018041c in poweroff_wait (junk=3D0xc032e60f, howto=3D-936382208)
    at ../../kern/kern_shutdown.c:554
#2  0xc02d4f23 in trap_fatal (frame=3D0xc8327c54, eva=3D64)
    at ../../i386/i386/trap.c:924
#3  0xc02d4bb9 in trap_pfault (frame=3D0xc8327c54, usermode=3D0, eva=3D64)
    at ../../i386/i386/trap.c:817
#4  0xc02d47b7 in trap (frame=3D{tf_fs =3D 24, tf_es =3D -1055850480,=20
      tf_ds =3D 16777232, tf_edi =3D 0, tf_esi =3D -1056946688, tf_ebp =3D =
-936215404,=20
      tf_isp =3D -936215424, tf_ebx =3D -1063630272, tf_edx =3D -1056996864=
,=20
      tf_ecx =3D -1056946688, tf_eax =3D 0, tf_trapno =3D 12, tf_err =3D 0,=
=20
      tf_eip =3D -1072138890, tf_cs =3D 8, tf_eflags =3D 66118, tf_esp =3D =
-936215380,=20
      tf_ss =3D -1072271193}) at ../../i386/i386/trap.c:423
#5  0xc0187576 in device_get_softc (dev=3D0x0) at ../../kern/subr_bus.c:982
#6  0xc01670a7 in smbus_request_bus (bus=3D0x0, dev=3D0xc1004600, how=3D3)
    at ../../dev/smbus/smbconf.c:131
#7  0xc0230f3c in bti2c_iic_callback (dev=3D0xc1004600, index=3D1, data=3D0=
xc8327d38)
    at ../../dev/bktr/bktr_i2c.c:265
#8  0xc016909c in IICBB_CALLBACK (dev=3D0xc1004600, index=3D1,=20
    data=3D0xc8327d38 "\003") at iicbb_if.c:27
#9  0xc0168e9e in iicbb_callback (dev=3D0xc1004580, index=3D1,=20
    data=3D0xc8327d38 "\003") at ../../dev/iicbus/iicbb.c:236
#10 0xc01698d0 in IICBUS_CALLBACK (dev=3D0xc1004580, index=3D1,=20
    data=3D0xc8327d38 "\003") at iicbus_if.c:37
#11 0xc0169aed in iicbus_request_bus (bus=3D0xc1004500, dev=3D0xc1004480, h=
ow=3D3)
    at ../../dev/iicbus/iiconf.c:108
#12 0xc01692c8 in iicsmb_callback (dev=3D0xc1004480, index=3D1,=20
    data=3D0xc8327d88 "\003") at ../../dev/iicbus/iicsmb.c:242
#13 0xc0166c98 in SMBUS_CALLBACK (dev=3D0xc1004480, index=3D1,=20
    data=3D0xc8327d88 "\003") at smbus_if.c:37
#14 0xc01670c1 in smbus_request_bus (bus=3D0xc1004380, dev=3D0xc1004300, ho=
w=3D3)
    at ../../dev/smbus/smbconf.c:136
#15 0xc01673bc in smbioctl (dev=3D0xc1004280, cmd=3D2148821255,=20
    data=3D0xc8327ebc "GP\006(P=FA=BF=BFZ\222\004\b\013=F9=BF=BF=A4=FA=BF=
=BF\020=B4\206=C0 =C18=C07",=20
    flags=3D1, p=3D0xc82ff100) at ../../dev/smbus/smb.c:202
#16 0xc01b5c26 in spec_ioctl (ap=3D0xc8327df8)
    at ../../miscfs/specfs/spec_vnops.c:304
#17 0xc01b5951 in spec_vnoperate (ap=3D0xc8327df8)
    at ../../miscfs/specfs/spec_vnops.c:117
#18 0xc026f039 in ufs_vnoperatespec (ap=3D0xc8327df8)
    at ../../ufs/ufs/ufs_vnops.c:2301
#19 0xc01b0d64 in vn_ioctl (fp=3D0xc110c300, com=3D2148821255,=20
    data=3D0xc8327ebc "GP\006(P=FA=BF=BFZ\222\004\b\013=F9=BF=BF=A4=FA=BF=
=BF\020=B4\206=C0 =C18=C07",=20
    p=3D0xc82ff100) at vnode_if.h:429
#20 0xc018d8ef in ioctl (p=3D0xc82ff100, uap=3D0xc8327f80) at ../../sys/fil=
e.h:171
#21 0xc02d51aa in syscall (frame=3D{tf_fs =3D 47, tf_es =3D 47, tf_ds =3D 4=
7,=20
      tf_edi =3D -1077937696, tf_esi =3D 134543628, tf_ebp =3D -1077937888,=
=20
      tf_isp =3D -936214572, tf_ebx =3D -1077937500, tf_edx =3D 4,=20
      tf_ecx =3D 672750752, tf_eax =3D 54, tf_trapno =3D 12, tf_err =3D 2,=
=20
      tf_eip =3D 672513808, tf_cs =3D 31, tf_eflags =3D 659, tf_esp =3D -10=
77937948,=20
      tf_ss =3D 47}) at ../../i386/i386/trap.c:1073
#22 0xc02c32b1 in Xint0x80_syscall ()
#23 0x8049255 in ?? ()
#24 0x8048d9d in ?? ()


--UlVJffcvxoiEqYs2
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: OF1cXgoGSkArvHtLmFR5dDYFE+Ehtwoq

iQA/AwUBONwqWvcyv/gweBpYEQIdmwCfTTaR843tujipQ4aLru9OsSH/PukAoK8s
rKREZqblhEcmZ0y/MBJbN9EN
=LplT
-----END PGP SIGNATURE-----

--UlVJffcvxoiEqYs2--


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 20:43:14 2000
Delivered-To: freebsd-current@freebsd.org
Received: from reyim.ne.mediaone.net (reyim.ne.mediaone.net [24.218.251.241])
	by hub.freebsd.org (Postfix) with ESMTP id E3AD237B522
	for <freebsd-current@freebsd.org>; Fri, 24 Mar 2000 20:43:10 -0800 (PST)
	(envelope-from bloom@acm.org)
Received: from acm.org (localhost [127.0.0.1])
	by reyim.ne.mediaone.net (8.9.3/8.9.3) with ESMTP id XAA00419;
	Fri, 24 Mar 2000 23:42:35 -0500 (EST)
	(envelope-from bloom@acm.org)
Message-ID: <38DC43BA.D9849E8C@acm.org>
Date: Fri, 24 Mar 2000 23:42:35 -0500
From: Jim Bloom <bloom@acm.org>
Reply-To: bloom@acm.org
X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386)
X-Accept-Language: en
MIME-Version: 1.0
To: FreeBSD mailing list <freebsd@mrynet.com>
Cc: freebsd-current@freebsd.org
Subject: Re: fd0: Debugger("d_iocmd botch") called.
References: <200003242206.OAA00645@mrynet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

FreeBSD mailing list wrote:
> 
> This patch does indeed fix the writing of floppies.  However, fdformat(1)
> still fails as follows:

That is very strange.  My patch only applies to formatting floppies.  It
did not touch any routine used in writing a floppy.  I have no idea at
this time what is causing your other problems.

I am unable to write to a floppy at this time.  I'm not seeing any
errors, but nothings is getting written.

Jim Bloom
bloom@acm.org

> 
> ttyp7:--ROOT--@mrynet (22): fdformat -f 1440 fd0.1440
> Format 1440K floppy `/dev/fd0.1440'? (y/n): y
> Processing EE^C------------------------------------
> 
> with /var/log/messages indicating:
> Mar 24 13:51:13 mrynet /kernel: fd0c: hard error reading fsbn 0 of 0-17 (ST0 40<abnrml> ST1 4<sec_not_fnd> ST2 0
> cyl 0 hd 0 sec 2)
> Mar 24 13:51:13 mrynet /kernel: fd0c: hard error reading fsbn 0 of 0-17 (ST0 40<abnrml> ST1 4<sec_not_fnd> ST2 0
> cyl 0 hd 0 sec 2)
> Mar 24 13:51:13 mrynet /kernel: fd0c: hard error reading fsbn 18 of 18-35 (ST0 44<abnrml,top_head> ST1
> 4<sec_not_fnd> ST2 0 cyl 0 hd 1 sec 2)
> Mar 24 13:51:13 mrynet /kernel: fd0c: hard error reading fsbn 18 of 18-35 (ST0 44<abnrml,top_head> ST1
> 4<sec_not_fnd> ST2 0 cyl 0 hd 1 sec 2)
> Mar 24 13:51:14 mrynet /kernel: fd0c: hard error reading fsbn 36 of 36-53 (ST0 40<abnrml> ST1 4<sec_not_fnd> ST2 0
> cyl 1 hd 0 sec 2)
> Mar 24 13:51:14 mrynet /kernel: fd0c: hard error reading fsbn 36 of 36-53 (ST0 40<abnrml> ST1 4<sec_not_fnd> ST2 0
> cyl 1 hd 0 sec 2)
> (and continuing).
> 
> Additionally, reading a floppy returns errors for any read:
> (This is a freshly formatted floppy verified on other machines)
> 
> ttyp7:--ROOT--@mrynet (7): dd if=/dev/rfd0.1440 | wc
> dd: /dev/rfd0.1440: Input/output error
> 0+0 records in
> 0+0 records out
> 0 bytes transferred in 2.395566 secs (0 bytes/sec)
>        0       0       0
> 
> with /var/log/messages indicating:
> Mar 24 14:04:28 mrynet /kernel: fd0c: hard error reading fsbn 0 (ST0 40<abnrml> ST1 4<sec_not_fnd> ST2 0 cyl 0 hd 0
> sec 2)
> Mar 24 14:04:38 mrynet /kernel: fd0c: hard error reading fsbn 0 (ST0 40<abnrml> ST1 4<sec_not_fnd> ST2 0 cyl 0 hd 0
> sec 2)
> 
> Thanks,
> -scott
> --
> Scott G. Akmentins-Taylor     InterNet: staylor@mrynet.com
> MRY Systems                             staylor@mrynet.lv


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 20:58:57 2000
Delivered-To: freebsd-current@freebsd.org
Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99])
	by hub.freebsd.org (Postfix) with ESMTP id 658EF37B7FB
	for <current@freebsd.org>; Fri, 24 Mar 2000 20:58:50 -0800 (PST)
	(envelope-from winter@jurai.net)
Received: from localhost (winter@localhost)
	by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id XAA99243
	for <current@freebsd.org>; Fri, 24 Mar 2000 23:58:48 -0500 (EST)
Date: Fri, 24 Mar 2000 23:58:48 -0500 (EST)
From: "Matthew N. Dodd" <winter@jurai.net>
To: current@freebsd.org
Subject: Testers Wanted! (EtherExpress 16 & 3C507 owners/users)
Message-ID: <Pine.BSF.4.21.0003242350560.50194-300000@sasami.jurai.net>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="0-1422078545-953960328=:50194"
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--0-1422078545-953960328=:50194
Content-Type: TEXT/PLAIN; charset=US-ASCII

I'm working on converting the 'ie' driver to newbus.

I've rewritten the code that identifies the cards and am in need of wider
testing since I've only got a lone Intel EtherExpress 16.

I have a non-invasive test 'driver' that just looks for the cards and
figures out the resources they are using.

Please do the following if you own/use an Intel EtherExpress 16 or a 3Com
3C507 Etherlink 16 and are running -CURRENT:

	- save the attachment if_ie_isa.c to src/sys/dev/ie
	- save the attachment ie_test.patch to /tmp/
	- cd /sys && patch < /tmp/ie_test.patch
	- edit your kernel config file and add the following line:
	
		device	ie_test0

	- config and build your kernel
	- boot verbose and look for 'if_ie' in the messages.
	- compare the reported values with the values your card
	  actually uses.
	- report success or failure to me.

Thanks!

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| winter@jurai.net |       2 x '84 Volvo 245DL        | ix86,sparc,pmax |
| http://www.jurai.net/~winter | This Space For Rent  | ISO8802.5 4ever |

--0-1422078545-953960328=:50194
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="ie_test.patch"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.BSF.4.21.0003242358480.50194@sasami.jurai.net>
Content-Description: 
Content-Disposition: attachment; filename="ie_test.patch"

SW5kZXg6IGNvbmYvZmlsZXMNCj09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJD
UyBmaWxlOiAvY3ZzL3NyYy9zeXMvY29uZi9maWxlcyx2DQpyZXRyaWV2aW5n
IHJldmlzaW9uIDEuMzQyDQpkaWZmIC11IC1yMS4zNDIgZmlsZXMNCi0tLSBj
b25mL2ZpbGVzCTIwMDAvMDMvMjAgMTQ6MDg6MzcJMS4zNDINCisrKyBjb25m
L2ZpbGVzCTIwMDAvMDMvMjUgMDM6Mjk6NDANCkBAIC0xNjgsNiArMTczLDcg
QEANCiBkZXYvaGZhL2ZvcmVfdHJhbnNtaXQuYwlvcHRpb25hbCBoZmENCiBk
ZXYvaGZhL2ZvcmVfdmNtLmMJb3B0aW9uYWwgaGZhDQogZGV2L2llL2lmX2ll
LmMJCW9wdGlvbmFsIGllIGlzYQ0KK2Rldi9pZS9pZl9pZV9pc2EuYwlvcHRp
b25hbCBpZV90ZXN0IGlzYQ0KIGRldi9pZGEvaWRhLmMJCW9wdGlvbmFsIGlk
YQ0KIGRldi9pZGEvaWRhX2Rpc2suYwlvcHRpb25hbCBpZGENCiBkZXYvaWRh
L2lkYV9laXNhLmMJb3B0aW9uYWwgaWRhIGVpc2ENCg==
--0-1422078545-953960328=:50194
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="if_ie_isa.c"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.BSF.4.21.0003242358481.50194@sasami.jurai.net>
Content-Description: 
Content-Disposition: attachment; filename="if_ie_isa.c"

I2luY2x1ZGUgPHN5cy9wYXJhbS5oPg0KI2luY2x1ZGUgPHN5cy9zeXN0bS5o
Pg0KI2luY2x1ZGUgPHN5cy9rZXJuZWwuaD4NCiNpbmNsdWRlIDxzeXMvbW9k
dWxlLmg+DQojaW5jbHVkZSA8c3lzL2J1cy5oPg0KDQojaW5jbHVkZSA8bWFj
aGluZS9idXNfcGlvLmg+DQojaW5jbHVkZSA8bWFjaGluZS9idXMuaD4NCiNp
bmNsdWRlIDxtYWNoaW5lL3Jlc291cmNlLmg+DQojaW5jbHVkZSA8c3lzL3Jt
YW4uaD4NCg0KI2luY2x1ZGUgPG1hY2hpbmUvY2xvY2suaD4NCg0KI2luY2x1
ZGUgPGlzYS9pc2F2YXIuaD4NCiNpbmNsdWRlIDxpc2EvcG5wdmFyLmg+DQoN
CiNpbmNsdWRlIDxpMzg2L2lzYS9lbGluay5oPg0KDQojaW5jbHVkZSA8ZGV2
L2llL2lmX2llNTA3Lmg+DQojaW5jbHVkZSA8ZGV2L2llL2lmX2llZTE2Lmg+
DQoNCnN0YXRpYyB2b2lkCQlpZV9pc2FfM0M1MDdfaWRlbnRpZnkJKGRyaXZl
cl90ICosIGRldmljZV90KTsNCnN0YXRpYyBpbnQJCWllXzNDNTA3X3BvcnRf
Y2hlY2sJKHVfaW50MzJfdCk7DQoNCnN0YXRpYyB2b2lkCQlpZV9pc2FfZWUx
Nl9pZGVudGlmeQkoZHJpdmVyX3QgKiwgZGV2aWNlX3QpOw0Kc3RhdGljIHVf
aW50MTZfdAlpZV9lZTE2X2h3X3JlYWRfZWVwcm9tCSh1X2ludDMyX3QgcG9y
dCwgaW50IGxvYyk7DQoNCiNkZWZpbmUgSUVfM0M1MDdfSU9CQVNFX0xPVwkw
eDIwMA0KI2RlZmluZSBJRV8zQzUwN19JT0JBU0VfSElHSAkweDNlMA0KI2Rl
ZmluZSBJRV8zQzUwN19JT1NJWkUJCTE2DQoNCiNkZWZpbmUgSUVfM0M1MDdf
SVJRX01BU0sJMHgwZg0KDQojZGVmaW5lIElFXzNDNTA3X01BRERSX0hJR0gJ
MHgyMA0KI2RlZmluZSBJRV8zQzUwN19NQUREUl9NQVNLCTB4MWMNCiNkZWZp
bmUgSUVfM0M1MDdfTUFERFJfQkFTRQkweGMwMDAwDQojZGVmaW5lIElFXzND
NTA3X01BRERSX1NISUZUCTEyDQoNCiNkZWZpbmUgSUVfM0M1MDdfTVNJWkVf
TUFTSwkzDQojZGVmaW5lIElFXzNDNTA3X01TSVpFX1NISUZUCTE0DQoNCi8q
DQogKiAzQ29tIDNDNTA3IEV0aGVybGluayAxNg0KICovDQpzdGF0aWMgdm9p
ZA0KaWVfaXNhXzNDNTA3X2lkZW50aWZ5IChkcml2ZXJfdCAqZHJpdmVyLCBk
ZXZpY2VfdCBwYXJlbnQpDQp7DQoJY2hhciAqCQlkZXNjID0gIjNDb20gM0M1
MDcgRXRoZXJsaW5rIDE2IjsNCgl1X2ludDMyX3QJcG9ydDsNCgl1X2ludDMy
X3QJbWFkZHI7DQoJdV9pbnQzMl90CW1zaXplOw0KCXVfaW50OF90CWlycTsN
Cgl1X2ludDhfdAlkYXRhOw0KDQoJLyogUmVzZXQgYW5kIHB1dCBjYXJkIGlu
IENPTkZJRyBzdGF0ZSB3aXRob3V0IGNoYW5naW5nIGFkZHJlc3MuICovDQoJ
ZWxpbmtfcmVzZXQoKTsNCglvdXRiKEVMSU5LX0lEX1BPUlQsIDApOw0KCWVs
aW5rX2lkc2VxKEVMSU5LXzUwN19QT0xZKTsNCgllbGlua19pZHNlcShFTElO
S181MDdfUE9MWSk7DQoJb3V0YihFTElOS19JRF9QT1JULCAweGZmKTsNCg0K
CWZvciAocG9ydCA9IElFXzNDNTA3X0lPQkFTRV9MT1c7DQoJICAgICBwb3J0
IDw9IElFXzNDNTA3X0lPQkFTRV9ISUdIOw0KCSAgICAgcG9ydCArPSBJRV8z
QzUwN19JT1NJWkUpIHsNCg0KCQlpZiAoaWVfM0M1MDdfcG9ydF9jaGVjayhw
b3J0KSkgew0KCQkJaWYgKGJvb3R2ZXJib3NlKSB7DQojaWYgMA0KCQkJCWRl
dmljZV9wcmludGYocGFyZW50LCAiaWZfaWU6ICgzQzUwNykgbm90IGZvdW5k
IGF0IHBvcnQgJSN4XG4iLA0KCQkJCQlwb3J0KTsNCiNlbmRpZg0KCQkJfQ0K
CQkJY29udGludWU7DQoJCX0NCg0KCQlvdXRiKHBvcnQgKyBJRTUwN19DVFJM
LCBFTF9DVFJMX05SU1QpOw0KDQoJCWRhdGEgPSBpbmIocG9ydCArIElFNTA3
X0lSUSk7DQoJCWlycSA9IGRhdGEgJiBJRV8zQzUwN19JUlFfTUFTSzsNCg0K
CQlkYXRhID0gaW5iKHBvcnQgKyBJRTUwN19NQUREUik7DQoNCgkJaWYgKGRh
dGEgJiBJRV8zQzUwN19NQUREUl9ISUdIKSB7DQoJCQlpZiAoYm9vdHZlcmJv
c2UpIHsNCgkJCQlkZXZpY2VfcHJpbnRmKHBhcmVudCwgImlmX2VmOiBjYW4n
dCBtYXAgM0M1MDcgUkFNIGluIGhpZ2ggbWVtb3J5XG4iKTsNCgkJCX0NCgkJ
CWNvbnRpbnVlOw0KCQl9DQoNCgkJbWFkZHIgPSBJRV8zQzUwN19NQUREUl9C
QVNFICsNCgkJCSgoZGF0YSAmIElFXzNDNTA3X01BRERSX01BU0spDQoJCQk8
PCBJRV8zQzUwN19NQUREUl9TSElGVCk7DQoJCW1zaXplID0gKChkYXRhICYg
SUVfM0M1MDdfTVNJWkVfTUFTSykgKyAxKQ0KCQkJPDwgSUVfM0M1MDdfTVNJ
WkVfU0hJRlQ7DQoNCgkJb3V0Yihwb3J0ICsgSUU1MDdfQ1RSTCwgRUxfQ1RS
TF9OT1JNQUwpOw0KDQoJCS8qIENsZWFyIHRoZSBpbnRlcnJ1cHQgbGF0Y2gg
anVzdCBpbiBjYXNlLiAqLw0KCQlvdXRiKHBvcnQgKyBJRTUwN19JQ1RSTCwg
MSk7DQoNCiNpZiAwDQoJCWNoaWxkID0gQlVTX0FERF9DSElMRChwYXJlbnQs
IElTQV9PUkRFUl9TUEVDVUxBVElWRSwgImllIiwgLTEpOw0KCQlkZXZpY2Vf
c2V0X2Rlc2NfY29weShjaGlsZCwgZGVzYyk7DQoJCWRldmljZV9zZXRfZHJp
dmVyKGNoaWxkLCBkcml2ZXIpOw0KCQlidXNfc2V0X3Jlc291cmNlKGNoaWxk
LCBTWVNfUkVTX0lSUSwgMCwgaXJxLCAxKTsNCgkJYnVzX3NldF9yZXNvdXJj
ZShjaGlsZCwgU1lTX1JFU19JT1BPUlQsIDAsIHBvcnQsIElFXzNDNTA3X0lP
U0laRSk7DQoJCWJ1c19zZXRfcmVzb3VyY2UoY2hpbGQsIFNZU19SRVNfTUVN
T1JZLCAwLCBtYWRkciwgbXNpemUpOw0KI2VuZGlmDQoNCgkJaWYgKGJvb3R2
ZXJib3NlKSB7DQoJCQlkZXZpY2VfcHJpbnRmKHBhcmVudCwgImlmX2llOiA8
JXM+IGF0IHBvcnQgJSN4LSUjeCBpcnEgJWQgaW9tZW0gJSNseC0lI2x4ICgl
ZEtCKVxuIiwNCgkJCQlkZXNjLCBwb3J0LCAocG9ydCArIElFXzNDNTA3X0lP
U0laRSkgLSAxLCBpcnEsDQoJCQkJKHVfbG9uZyltYWRkciwgKHVfbG9uZyko
bWFkZHIgKyBtc2l6ZSkgLSAxLA0KCQkJCShtc2l6ZSAvIDEwMjQpKTsNCgkJ
fQ0KCX0NCg0KCS8qIGdvIHRvIFJVTiBzdGF0ZSAqLw0KCW91dGIoRUxJTktf
SURfUE9SVCwgMHgwMCk7DQoJZWxpbmtfaWRzZXEoRUxJTktfNTA3X1BPTFkp
Ow0KCW91dGIoRUxJTktfSURfUE9SVCwgMHgwMCk7DQoNCglyZXR1cm47DQp9
DQoNCnN0YXRpYyBpbnQNCmllXzNDNTA3X3BvcnRfY2hlY2sgKHVfaW50MzJf
dCBwb3J0KQ0Kew0KCXVfY2hhciAqCXNpZ25hdHVyZSA9ICIqM0NPTSoiOw0K
CWludAkJaTsNCg0KCWZvciAoaSA9IDA7IGkgPCA2OyBpKyspDQoJCWlmIChp
bmIocG9ydCArIGkpICE9IHNpZ25hdHVyZVtpXSkNCgkJCXJldHVybiAoRU5Y
SU8pOw0KDQoJcmV0dXJuICgwKTsNCn0NCg0KI2RlZmluZSBJRV9FRTE2X0lE
X1BPUlQJCQkweDBmDQojZGVmaW5lIElFX0VFMTZfSUQJCQkweGJhYmENCiNk
ZWZpbmUgSUVfRUUxNl9FRVBST01fQ09ORklHMQkJMHgwMA0KI2RlZmluZSBJ
RV9FRTE2X0VFUFJPTV9JUlFfTUFTSwkJMHhlMDAwDQojZGVmaW5lIElFX0VF
MTZfRUVQUk9NX0lSUV9TSElGVAkxMw0KI2RlZmluZSBJRV9FRTE2X0VFUFJP
TV9NRU1DRkcJCTB4MDYNCiNkZWZpbmUgSUVfRUUxNl9JT1NJWkUJCQkxNg0K
DQovKg0KICogSW50ZWwgRXRoZXJFeHByZXNzIDE2DQogKg0KICogVE9ETzoN
CiAqCQlUZXN0IGZvciA4LzE2IGJpdCBtb2RlLg0KICoJCVRlc3QgZm9yIGlu
dmFsaWQgbWVtIHNpemVzLg0KICovDQpzdGF0aWMgdm9pZA0KaWVfaXNhX2Vl
MTZfaWRlbnRpZnkgKGRyaXZlcl90ICpkcml2ZXIsIGRldmljZV90IHBhcmVu
dCkNCnsNCgljaGFyICoJCWRlc2MgPSAiSW50ZWwgRXRoZXJFeHByZXNzIDE2
IjsNCgl1X2ludDE2X3QJcG9ydHNbXSA9IHsNCgkJCQkweDMwMCwgMHgzMTAs
IDB4MzIwLCAweDMzMCwNCgkJCQkweDM0MCwgMHgzNTAsIDB4MzYwLCAweDM3
MCwNCgkJCQkweDIwMCwgMHgyMTAsIDB4MjIwLCAweDIzMCwNCgkJCQkweDI0
MCwgMHgyNTAsIDB4MjYwLCAweDI3MCwNCgkJCQkwDQoJCQl9Ow0KCXVfaW50
MTZfdAlpcnFzW10gPSB7IDAsIDB4MDksIDB4MDMsIDB4MDQsIDB4MDUsIDB4
MGEsIDB4MGIsIDAgfTsNCgl1X2ludDMyX3QJcG9ydDsNCgl1X2ludDMyX3QJ
bWFkZHI7DQoJdV9pbnQzMl90CW1zaXplOw0KCXVfaW50OF90CWlycTsNCgl1
X2ludDhfdAlkYXRhOw0KCXVfaW50MTZfdAlkYXRhMTsNCglpbnQJCWksIGo7
DQoNCglmb3IgKGkgPSAwOyBwb3J0c1tpXSAhPSAwOyBpKyspIHsNCgkJdV9p
bnQxNl90CWJvYXJkX2lkOw0KDQoJCWJvYXJkX2lkID0gMDsNCgkJcG9ydCA9
IHBvcnRzW2ldOw0KDQoJCWZvciAoaiA9IDA7IGogPCA0OyBqKyspIHsNCgkJ
CWRhdGEgPSBpbmIocG9ydCArIElFX0VFMTZfSURfUE9SVCk7DQoJCQlib2Fy
ZF9pZCB8PSAoKGRhdGEgPj4gNCkgPDwgKChkYXRhICYgMHgwMykgPDwgMikp
Ow0KCQl9DQoNCgkJaWYgKGJvYXJkX2lkICE9IElFX0VFMTZfSUQpIHsNCiNp
ZiAwDQoJCQlkZXZpY2VfcHJpbnRmKHBhcmVudCwgImlmX2llOiAoRUUxNikg
bm90IGZvdW5kIGF0IHBvcnQgJSN4XG4iLA0KCQkJCXBvcnQpOw0KI2VuZGlm
DQoJCQljb250aW51ZTsNCgkJfQ0KDQoJCS8qIHJlc2V0IGFueSBlZTE2IGF0
IHRoZSBjdXJyZW50IGlvYmFzZSAqLw0KCQlvdXRiKHBvcnQgKyBJRUUxNl9F
Q1RSTCwgSUVFMTZfUkVTRVRfQVNJQyk7DQoJCW91dGIocG9ydCArIElFRTE2
X0VDVFJMLCAwKTsNCgkJREVMQVkoMjQwKTsNCg0KCQlkYXRhMSA9IGllX2Vl
MTZfaHdfcmVhZF9lZXByb20ocG9ydCwgSUVfRUUxNl9FRVBST01fQ09ORklH
MSk7DQoJCWlycSA9IGlycXNbKChkYXRhMSAmIElFX0VFMTZfRUVQUk9NX0lS
UV9NQVNLKQ0KCQkJICAgPj4gSUVfRUUxNl9FRVBST01fSVJRX1NISUZUKV07
DQoNCgkJZGF0YTEgPSBpZV9lZTE2X2h3X3JlYWRfZWVwcm9tKHBvcnQsIElF
X0VFMTZfRUVQUk9NX01FTUNGRyk7DQoJCW1hZGRyID0gMHhjMDAwMCArICgo
ZmZzKGRhdGExICYgMHgwMGZmKSAtIDEpICogMHg0MDAwKTsNCgkJbXNpemUg
PSAoZmxzKChkYXRhMSAmIDB4MDBmZikgPj4gKGZmcyhkYXRhMSAmIDB4MDBm
ZikgLSAxKSkpDQoJCQkqIDB4NDAwMDsNCg0KI2lmIDANCgkJY2hpbGQgPSBC
VVNfQUREX0NISUxEKHBhcmVudCwgSVNBX09SREVSX1NQRUNVTEFUSVZFLCAi
aWUiLCAtMSk7DQoJCWRldmljZV9zZXRfZGVzY19jb3B5KGNoaWxkLCBkZXNj
KTsNCgkJZGV2aWNlX3NldF9kcml2ZXIoY2hpbGQsIGRyaXZlcik7DQoJCWJ1
c19zZXRfcmVzb3VyY2UoY2hpbGQsIFNZU19SRVNfSVJRLCAwLCBpcnEsIDEp
Ow0KCQlidXNfc2V0X3Jlc291cmNlKGNoaWxkLCBTWVNfUkVTX0lPUE9SVCwg
MCwgcG9ydCwgSUVfRUUxNl9JT1NJWkUpOw0KCQlidXNfc2V0X3Jlc291cmNl
KGNoaWxkLCBTWVNfUkVTX01FTU9SWSwgMCwgbWFkZHIsIG1zaXplKTsNCiNl
bmRpZg0KCQlpZiAoYm9vdHZlcmJvc2UpIHsNCgkJCWRldmljZV9wcmludGYo
cGFyZW50LCAiaWZfaWU6IDwlcz4gYXQgcG9ydCAlI3gtJSN4IGlycSAlZCBp
b21lbSAlI2x4LSUjbHggKCVkS0IpXG4iLA0KCQkJCWRlc2MsIHBvcnQsIChw
b3J0ICsgSUVfRUUxNl9JT1NJWkUpIC0gMSwgaXJxLA0KCQkJCSh1X2xvbmcp
bWFkZHIsICh1X2xvbmcpKG1hZGRyICsgbXNpemUpIC0gMSwNCgkJCQkobXNp
emUgLyAxMDI0KSk7DQoJCX0NCgl9DQoNCglyZXR1cm47DQp9DQoNCnN0YXRp
YyB2b2lkDQppZV9lZTE2X2h3X2VlcHJvbV9jbG9jayAodV9pbnQzMl90IHBv
cnQsIGludCBzdGF0ZSkNCnsNCgl1X2ludDhfdAllY3RybDsNCg0KCWVjdHJs
ID0gaW5iKHBvcnQgKyBJRUUxNl9FQ1RSTCk7DQoJZWN0cmwgJj0gfihJRUUx
Nl9SRVNFVF9BU0lDIHwgSUVFMTZfRUNUUkxfRUVTSyk7DQoNCglpZiAoc3Rh
dGUpIHsNCgkJZWN0cmwgfD0gSUVFMTZfRUNUUkxfRUVTSzsNCgl9DQoJb3V0
Yihwb3J0ICsgSUVFMTZfRUNUUkwsIGVjdHJsKTsNCglERUxBWSg5KTsJCS8q
IEVFU0sgbXVzdCBiZSBzdGFibGUgZm9yIDguMzggdVNlYyAqLw0KfQ0KDQpz
dGF0aWMgdm9pZA0KaWVfZWUxNl9od19lZXByb21fb3V0ICh1X2ludDMyX3Qg
cG9ydCwgdV9pbnQxNl90IGVkYXRhLCBpbnQgY291bnQpDQp7DQoJdV9pbnQ4
X3QJZWN0cmw7DQoJaW50CQlpOw0KDQoJZWN0cmwgPSBpbmIocG9ydCArIElF
RTE2X0VDVFJMKTsNCgllY3RybCAmPSB+SUVFMTZfUkVTRVRfQVNJQzsNCg0K
CWZvciAoaSA9IGNvdW50IC0gMTsgaSA+PSAwOyBpLS0pIHsNCgkJZWN0cmwg
Jj0gfklFRTE2X0VDVFJMX0VFREk7DQoJCWlmIChlZGF0YSAmICgxIDw8IGkp
KSB7DQoJCQllY3RybCB8PSBJRUUxNl9FQ1RSTF9FRURJOw0KCQl9DQoJCW91
dGIocG9ydCArIElFRTE2X0VDVFJMLCBlY3RybCk7DQoJCURFTEFZKDEpOyAg
ICAgICAvKiBlZXByb20gZGF0YSBtdXN0IGJlIHNldHVwIGZvciAwLjQgdVNl
YyAqLw0KCQlpZV9lZTE2X2h3X2VlcHJvbV9jbG9jayhwb3J0LCAxKTsNCgkJ
aWVfZWUxNl9od19lZXByb21fY2xvY2socG9ydCwgMCk7DQoJfQ0KCWVjdHJs
ICY9IH5JRUUxNl9FQ1RSTF9FRURJOw0KCW91dGIocG9ydCArIElFRTE2X0VD
VFJMLCBlY3RybCk7DQoJREVMQVkoMSk7ICAgICAgICAgICAgICAgLyogZWVw
cm9tIGRhdGEgbXVzdCBiZSBoZWxkIGZvciAwLjQgdVNlYyAqLw0KDQoJcmV0
dXJuOw0KfQ0KDQpzdGF0aWMgdV9pbnQxNl90DQppZV9lZTE2X2h3X2VlcHJv
bV9pbiAodV9pbnQzMl90IHBvcnQpDQp7DQoJdV9pbnQ4X3QJZWN0cmw7DQoJ
dV9pbnQxNl90CWVkYXRhOw0KCWludAkJaTsNCg0KCWVjdHJsID0gaW5iKHBv
cnQgKyBJRUUxNl9FQ1RSTCk7DQoJZWN0cmwgJj0gfklFRTE2X1JFU0VUX0FT
SUM7DQoNCglmb3IgKGVkYXRhID0gMCwgaSA9IDA7IGkgPCAxNjsgaSsrKSB7
DQoJCWVkYXRhID0gZWRhdGEgPDwgMTsNCgkJaWVfZWUxNl9od19lZXByb21f
Y2xvY2socG9ydCwgMSk7DQoJCWVjdHJsID0gaW5iKHBvcnQgKyBJRUUxNl9F
Q1RSTCk7DQoJCWlmIChlY3RybCAmIElFRTE2X0VDVFJMX0VFRE8pIHsNCgkJ
CWVkYXRhIHw9IDE7DQoJCX0NCgkJaWVfZWUxNl9od19lZXByb21fY2xvY2so
cG9ydCwgMCk7DQoJfQ0KCXJldHVybiAoZWRhdGEpOw0KfQ0KDQpzdGF0aWMg
dV9pbnQxNl90DQppZV9lZTE2X2h3X3JlYWRfZWVwcm9tICh1X2ludDMyX3Qg
cG9ydCwgaW50IGxvYykNCnsNCgl1X2ludDhfdAllY3RybDsNCgl1X2ludDE2
X3QJZWRhdGE7DQoNCgllY3RybCA9IGluYihwb3J0ICsgSUVFMTZfRUNUUkwp
Ow0KCWVjdHJsICY9IElFRTE2X0VDVFJMX01BU0s7DQoJZWN0cmwgfD0gSUVF
MTZfRUNUUkxfRUVDUzsNCglvdXRiKHBvcnQgKyBJRUUxNl9FQ1RSTCwgZWN0
cmwpOw0KDQoJaWVfZWUxNl9od19lZXByb21fb3V0KHBvcnQsIElFRTE2X0VF
UFJPTV9SRUFELCBJRUUxNl9FRVBST01fT1BTSVpFMSk7DQoJaWVfZWUxNl9o
d19lZXByb21fb3V0KHBvcnQsIGxvYywgSUVFMTZfRUVQUk9NX0FERFJfU0la
RSk7DQoJZWRhdGEgPSBpZV9lZTE2X2h3X2VlcHJvbV9pbihwb3J0KTsNCg0K
CWVjdHJsID0gaW5iKHBvcnQgKyBJRUUxNl9FQ1RSTCk7DQoJZWN0cmwgJj0g
fihJRUUxNl9SRVNFVF9BU0lDIHwgSUVFMTZfRUNUUkxfRUVESSB8IElFRTE2
X0VDVFJMX0VFQ1MpOw0KCW91dGIocG9ydCArIElFRTE2X0VDVFJMLCBlY3Ry
bCk7DQoNCglpZV9lZTE2X2h3X2VlcHJvbV9jbG9jayhwb3J0LCAxKTsNCglp
ZV9lZTE2X2h3X2VlcHJvbV9jbG9jayhwb3J0LCAwKTsNCg0KCXJldHVybiAo
ZWRhdGEpOw0KfQ0KDQpzdGF0aWMgZGV2Y2xhc3NfdCBpZV9kZXZjbGFzczsN
Cg0Kc3RhdGljIGRldmljZV9tZXRob2RfdCBpZV9pc2FfM0M1MDdfbWV0aG9k
c1tdID0gew0KCURFVk1FVEhPRChkZXZpY2VfaWRlbnRpZnksCWllX2lzYV8z
QzUwN19pZGVudGlmeSksDQoJeyAwLCAwIH0NCn07DQpzdGF0aWMgZHJpdmVy
X3QgaWVfaXNhXzNDNTA3X2RyaXZlciA9IHsNCgkiaWUiLA0KCWllX2lzYV8z
QzUwN19tZXRob2RzLA0KCTEgLyogc2l6ZW9mKHN0cnVjdCBpZV9zb2Z0Yykg
Ki8sIA0KfTsNCkRSSVZFUl9NT0RVTEUoaWVfM0M1MDcsIGlzYSwgaWVfaXNh
XzNDNTA3X2RyaXZlciwgaWVfZGV2Y2xhc3MsIDAsIDApOw0KDQpzdGF0aWMg
ZGV2aWNlX21ldGhvZF90IGllX2lzYV9lZTE2X21ldGhvZHNbXSA9IHsNCglE
RVZNRVRIT0QoZGV2aWNlX2lkZW50aWZ5LAlpZV9pc2FfZWUxNl9pZGVudGlm
eSksDQoJeyAwLCAwIH0NCn07DQpzdGF0aWMgZHJpdmVyX3QgaWVfaXNhX2Vl
MTZfZHJpdmVyID0gew0KCSJpZSIsDQoJaWVfaXNhX2VlMTZfbWV0aG9kcywN
CgkxIC8qIHNpemVvZihzdHJ1Y3QgaWVfc29mdGMpICovLCANCn07DQpEUklW
RVJfTU9EVUxFKGllX2VlMTYsIGlzYSwgaWVfaXNhX2VlMTZfZHJpdmVyLCBp
ZV9kZXZjbGFzcywgMCwgMCk7DQo=
--0-1422078545-953960328=:50194--


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 21:28: 9 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id AC06437B8B5
	for <freebsd-current@FreeBSD.ORG>; Fri, 24 Mar 2000 21:27:57 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id VAA19096;
	Fri, 24 Mar 2000 21:27:57 -0800 (PST)
	(envelope-from dillon)
Date: Fri, 24 Mar 2000 21:27:57 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003250527.VAA19096@apollo.backplane.com>
To: Alfred Perlstein <bright@wintelcom.net>,
	freebsd-current@FreeBSD.ORG
Subject: Why are all accesses to the cpl surrounded by a lock?
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

    I've been doing more SMP cleanup and for the life of me I can't figure
    out why cpl operations are surrounded by its own [S]CPL_LOCK ??

    As far as I can tell, the cpl is only accessed/modified:

	* by mainline code while the MP lock is held 
	* by an interrupt while the MP lock is held

    Since any modification of the cpl within an interrupt is paired and
    thus from the point of view of mainline code the cpl does not change
    at all (i.e. s = splvm(); ... splx(s);), I don't see why the cpl needs 
    to be locked at all.  We shouldn't even need to use a 'lock' prefix.

    Now, I understand that we eventually want to get out from under the MP
    lock's thumb, but it needs to be pointed out that the cpl mechanism
    itself is likely to be depreciated in favor of something more 
    thread-friendly.  I don't see any point in trying to make the cpl
    operate independantly of the MP lock at this time.

    Does anyone know why all the locking was added to the cpl code?

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 21:40: 4 2000
Delivered-To: freebsd-current@freebsd.org
Received: from web122.yahoomail.com (web122.yahoomail.com [205.180.60.57])
	by hub.freebsd.org (Postfix) with SMTP id A65EB37B70B
	for <current@FreeBSD.ORG>; Fri, 24 Mar 2000 21:39:56 -0800 (PST)
	(envelope-from ixkatl@yahoo.com)
Received: (qmail 20421 invoked by uid 60001); 25 Mar 2000 05:39:55 -0000
Message-ID: <20000325053955.20420.qmail@web122.yahoomail.com>
Received: from [207.172.144.229] by web122.yahoomail.com; Fri, 24 Mar 2000 21:39:55 PST
Date: Fri, 24 Mar 2000 21:39:55 -0800 (PST)
From: Andrew Sherrod <ixkatl@yahoo.com>
Subject: Re: -current, ep and fragment problems.
To: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>, asmodai@wxs.nl
Cc: dan@FreeBSD.ORG, current@FreeBSD.ORG
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


My 3.4 machine at work has periodic problems with the
fxp. No performance issues (perhaps a little slow, but
the network is congested enough that this is hard to
measure). However it does periodically display an
error message about "PHYS" and "unsupported". I am
home right now, so I can't reproduce the exact
message.

I'll post a more complete description on Monday
morning. (The worker sitting next to me, also running
3.4 on a Compaq experiences the same error messages.)

AGS

--- Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp> wrote:
> > [cc:'d shin]
> 
> :-) I have only fxp and fe for 4.0/5.0 machines at
> my work
> place, but I have a 4.0 machine with ep at my home. 
> I think
> I'can test it tonight if it also happens in my
> environment.
> 
> As far as I confirmed it here, many pinging with -s
> 1600 won't
> make any problems between my 3.x/4.0/5.0 machines
> with fxp/fe.
> Also I tried to set mtu 1200 to my fxp, and login
> other 
> machines with mtu 1500, and did `ls -lR /`, and also
> there
> seems to be no problem.
> 
> Cheers,
> Yoshinobu Inoue
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of
> the message
> 

=====
'During my service in the United States Congress, I took the initiative in creating the Internet.' - Al Gore, March 9, 1999: On CNN's Late Edition

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 21:51:57 2000
Delivered-To: freebsd-current@freebsd.org
Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4])
	by hub.freebsd.org (Postfix) with ESMTP id 6A4E037B60F
	for <freebsd-current@FreeBSD.ORG>; Fri, 24 Mar 2000 21:51:54 -0800 (PST)
	(envelope-from freebsd@gndrsh.dnsmgr.net)
Received: (from freebsd@localhost)
	by gndrsh.dnsmgr.net (8.9.3/8.9.3) id VAA01280;
	Fri, 24 Mar 2000 21:51:35 -0800 (PST)
	(envelope-from freebsd)
From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>
Message-Id: <200003250551.VAA01280@gndrsh.dnsmgr.net>
Subject: Re: Experts only please! (was Re: Preliminary SMP/BGL patch)
In-Reply-To: <v04220805b5019e640ed5@[195.238.1.121]> from Brad Knowles at "Mar 24, 2000 11:38:03 pm"
To: blk@skynet.be (Brad Knowles)
Date: Fri, 24 Mar 2000 21:51:34 -0800 (PST)
Cc: drosih@rpi.edu (Garance A Drosihn),
	dillon@apollo.backplane.com (Matthew Dillon),
	bright@wintelcom.net (Alfred Perlstein), freebsd-current@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> At 2:57 PM -0500 2000/3/24, Garance A Drosihn wrote:
> 
> >  At 10:01 AM -0800 3/24/00, Matthew Dillon wrote:
> >>     This is not a 'normal Matt patch' that 'just works'.  Ok, it seems to
> >>     just work, but it's not a normal Matt patch.  If there were a
> >>     designation before 'early alpha' this patch would get it.
> >
> >  "Rough-draft proposal for early alpha version"
> 
> 	"Theoretical basis for early access to code virtually guaranteed 
> to mess up your system in highly entertaining ways, although the 
> complete reinstall and rebuild might be rather annoying"

Proof Of Concept (POC) is probably the more accurate term...


-- 
Rod Grimes - KD7CAX @ CN85sl - (RWG25)               rgrimes@gndrsh.dnsmgr.net


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 22: 5:53 2000
Delivered-To: freebsd-current@freebsd.org
Received: from shidahara1.planet.sci.kobe-u.ac.jp (shidahara1.planet.sci.kobe-u.ac.jp [133.30.50.200])
	by hub.freebsd.org (Postfix) with ESMTP id B36F037B54A
	for <current@freebsd.org>; Fri, 24 Mar 2000 22:05:49 -0800 (PST)
	(envelope-from takawata@shidahara1.planet.sci.kobe-u.ac.jp)
Received: from libr.scitec.kobe-u.ac.jp (cs2d304.ppp.infoweb.ne.jp [202.219.174.212])
	by shidahara1.planet.sci.kobe-u.ac.jp (8.8.8+2.7Wbeta7/8.8.8) with ESMTP id PAA10758;
	Sat, 25 Mar 2000 15:05:13 +0900 (JST)
Received: from shidahara1.planet.kobe-u.ac.jp (localhost [127.0.0.1]) by libr.scitec.kobe-u.ac.jp (8.9.1/3.5Wpl7) with ESMTP id PAA06834; Sat, 25 Mar 2000 15:00:41 +0900 (JST)
From: takawata@shidahara1.planet.sci.kobe-u.ac.jp
Message-Id: <200003250600.PAA06834@libr.scitec.kobe-u.ac.jp>
To: Alan Clegg <abc@bsdi.com>
Cc: current@freebsd.org
Subject: Re: reproducable system crash in 4.0-STABLE 
In-reply-to: Your message of "Fri, 24 Mar 2000 21:54:19 EST."
             <20000324215419.A288@ecto.greenpeas.org> 
Date: Sat, 25 Mar 2000 15:00:40 +0900
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <20000324215419.A288@ecto.greenpeas.org>, Alan Clegg $B$5$s$$$o$/(B:
>> > On a dual PII system, access to /dev/smb0 (system management bus) by=20

In SMP Environment 'intpm' driver will not work correctly,because it drops
intrrupt. I made a patch so that it uses polling at

http://www.planet.sci.kobe-u.ac.jp/~takawata/smbus/sys/intpmpoll.diff

.

>> > wmhm (/usr/ports/sysutils/wmhm) or gkrellm (/usr/ports/sysutils/gkrellm)
>> > causes an immediate system panic.

But the panic seems to be another reason.It accesses i2c bus on 
video capture card , not on south bridge.Is it surely PIIX4?
Before PIIX4, there is no SMBus interface on south bridge.
And I don't write the driver for i8xx chipset yet.






To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 22:51:33 2000
Delivered-To: freebsd-current@freebsd.org
Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25])
	by hub.freebsd.org (Postfix) with SMTP id 7BC8337B761
	for <freebsd-current@FreeBSD.ORG>; Fri, 24 Mar 2000 22:51:26 -0800 (PST)
	(envelope-from bde@zeta.org.au)
Received: (qmail 2198 invoked from network); 25 Mar 2000 06:51:21 -0000
Received: from bde.zeta.org.au (203.2.228.102)
  by gidora.zeta.org.au with SMTP; 25 Mar 2000 06:51:21 -0000
Date: Sat, 25 Mar 2000 17:51:06 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-Sender: bde@alphplex.bde.org
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: Anyone know why the syscall interface is using the doreti
 mechanism?
In-Reply-To: <200003241157.DAA10683@apollo.backplane.com>
Message-ID: <Pine.BSF.4.21.0003251654510.405-100000@alphplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Fri, 24 Mar 2000, Matthew Dillon wrote:

>     I understand why interrupts use the doreti mechanism.  I don't understand
>     why the syscall interface traps have to use it.  As far as I can tell,

To handle AST's (for signals and forced context switches, etc), and
to do the special stuff before iret (magic addresses for error handling,
and giant lock releasing) in a uniform way.  AST's must be checked
for somehow, and doreti has an efficient method for doing so.  I once
put the AST-pending bit in `ipending' so that it could be checked in
the same instruction that checks for pending interrupts.  This turned
out to have been not worth doing, so I went back to the old (386BSD-0.0?)
way last July.  I profiled inlining the `ipending' check at the end of
Xsyscall() long ago when i486's were fast.  Unsurprisingly, it was not
worth doing (it only saved approximately one jump instruction).  Branch
target buffers, etc. in modern x86's probably don't make much difference.
Inlining the separate `astpending' check is more likely to be right, but
duplication the complications before iret at the end of several syscall
routines would be ugly.

>     the cpl stuff does not have to be checked at all, the spl does not have
>     to be set to 0 (it damn well better already be 0!), pending interrupts
>     should not have to be checked because interrupts are operating just fine
>     and any code that raises the spl will have dropped it prior to returning,

Correct.

>     So really only astpending needs to be checked... which can be done inside
>     syscall() rather then doreti.

The duplication for this would be ugly (see above).  Note that astpending
still has to be checked for after an interrupt, since if the interrupt
occurred in user mode then it may have generated an AST.

>     What am I doing?  I'm experimenting with trying to remove the MP lock 
>     from the syscall path (in exception.s and trap.c).  I added a per-syscall

Of course, if you need non-uniform handing before iret, then jumping to
doreti to get uniform handling is wrong.

>     flag to tell syscall() whether any given syscall is MP safe or not,
>     and if the syscall IS MP safe then the entire nominal path can be run
>     without obtaining the MP lock.

I think luoqi has already done something like this.  In fact, I was
motivated by his work to remove the AST-pending bit from `ipending'.
He has some other changes related to AST-pending and SMP (`astpending'
cannot work right for SMP since it is not per-cpu...).  Development
seems to have stalled.

>     It was all very straightforward except for the doreti stuff that
>     the two syscall gates in i386/i386/excep4tion.s return through.
>     Now, I know I MUST be missing something... but the friggin system
>     is working!  No lockups or anything.  I'm confident that if I *AM* 
>     missing something it will be relatively easy to fix.   For the doreti
>     stuff I, well, I ripped it out and replaced it with a few pops and an
>     iret.  
> 
>     So question #1:  Why is my system still working, what I did has *got*
>     to be illegal!  The darned thing is doing a buildworld as I type...
>     still no crash.  It isn't getting stuck.  Nothing, nada.  Normal
>     boring operation.  Not even a cool panic!

Well, returning from syscall() without jumping to doreti would break only
AST's and trapping of invalid user stacks and segment registers.  This
loss is not important in normal operation.  AST's are needed mainly to
kill CPU hogs and to deliver signals promptly.  Trapping invalid user
stacks, etc., is needed mainly to stop the kernel panicing for invalid
contexts in sigreturn().

Bruce



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 23: 8:32 2000
Delivered-To: freebsd-current@freebsd.org
Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25])
	by hub.freebsd.org (Postfix) with SMTP id 21D3337B7AF
	for <freebsd-current@FreeBSD.ORG>; Fri, 24 Mar 2000 23:08:28 -0800 (PST)
	(envelope-from bde@zeta.org.au)
Received: (qmail 2773 invoked from network); 25 Mar 2000 07:08:25 -0000
Received: from bde.zeta.org.au (203.2.228.102)
  by gidora.zeta.org.au with SMTP; 25 Mar 2000 07:08:25 -0000
Date: Sat, 25 Mar 2000 18:08:10 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-Sender: bde@alphplex.bde.org
To: Jim Bloom <bloom@acm.org>
Cc: FreeBSD mailing list <freebsd@mrynet.com>,
	freebsd-current@FreeBSD.ORG
Subject: Re: fd0: Debugger("d_iocmd botch") called.
In-Reply-To: <38DC43BA.D9849E8C@acm.org>
Message-ID: <Pine.BSF.4.21.0003251804150.473-100000@alphplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Fri, 24 Mar 2000, Jim Bloom wrote:

> FreeBSD mailing list wrote:
> > 
> > This patch does indeed fix the writing of floppies.  However, fdformat(1)
> > still fails as follows:
> 
> That is very strange.  My patch only applies to formatting floppies.  It
> did not touch any routine used in writing a floppy.  I have no idea at
> this time what is causing your other problems.
> 
> I am unable to write to a floppy at this time.  I'm not seeing any
> errors, but nothings is getting written.

Reading of floppies is broken too.  The wrong flags are passed to
isa_dmastart(), so the DMA direction is wrong.  It defaults to the most
dangerous direction (ISADMA_WRITE), of course.

Bruce



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Fri Mar 24 23:11:54 2000
Delivered-To: freebsd-current@freebsd.org
Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87])
	by hub.freebsd.org (Postfix) with ESMTP
	id BCCB437B867; Fri, 24 Mar 2000 23:11:50 -0800 (PST)
	(envelope-from dcs@newsguy.com)
Received: from newsguy.com (p15-dn03kiryunisiki.gunma.ocn.ne.jp [210.232.224.144])
	by peach.ocn.ne.jp (8.9.1a/OCN) with ESMTP id QAA04781;
	Sat, 25 Mar 2000 16:11:45 +0900 (JST)
Message-ID: <38DC4C6F.5DB89998@newsguy.com>
Date: Sat, 25 Mar 2000 14:19:43 +0900
From: "Daniel C. Sobral" <dcs@newsguy.com>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en,pt-BR,ja
MIME-Version: 1.0
To: Ollivier Robert <roberto@eurocontrol.fr>
Cc: John Baldwin <jhb@FreeBSD.ORG>, freebsd-current@FreeBSD.ORG
Subject: Re: /boot/loader is making my VAIO reboot
References: <20000324152450.A68608@caerdonn.eurocontrol.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Ollivier Robert wrote:
> 
> It is rebooting before /boot/loader.rc because none of the "key" commands
> I've put there are executed.

Forth syntax can be picky. Would you mind sending me what you have after
changes? Or, better yet, just test them with the functional loader, to
see if they work?

--
Daniel C. Sobral			(8-DCS)
dcs@newsguy.com
dcs@freebsd.org
capo@zurichgnomes.bsdconspiracy.net

	One Unix to rule them all, One Resolver to find them,
        One IP to bring them all and in the zone bind them.




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25  0: 5:22 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mail.af.airnet.ne.jp (mail.af.airnet.ne.jp [210.159.66.49])
	by hub.freebsd.org (Postfix) with ESMTP
	id C010B37B8A1; Sat, 25 Mar 2000 00:05:16 -0800 (PST)
	(envelope-from imura@cs.titech.ac.jp)
Received: from imura.af.airnet.ne.jp (tok066.airnet.ne.jp [210.159.88.66])
	by mail.af.airnet.ne.jp (8.8.8/3.6W/06/13/98-AF.AIRNET.NE.JP) with ESMTP id RAA33580;
	Sat, 25 Mar 2000 17:05:13 +0900
Posted-Date: Sat, 25 Mar 2000 17:04:08 +0900 (JST)
To: asami@freebsd.org
Cc: nsayer@freebsd.org, will@freebsd.org, freebsd-ports@freebsd.org,
	freebsd-current@freebsd.org
Subject: Re: KDE kdm problem with packaged version (make release 
 issue?)
From: "R. Imura" <imura@af.airnet.ne.jp>
In-Reply-To: <vqc3dpgylhg.fsf@silvia.hip.berkeley.edu>
References: <38C9823F.5FCDCF40@sftw.com>
	<20000323213103K.imura@cs.titech.ac.jp>
	<vqc3dpgylhg.fsf@silvia.hip.berkeley.edu>
X-Mailer: Mew version 1.94b20 on Emacs 19.34 / Mule 2.3
 =?iso-2022-jp?B?KBskQkt2RSYyVhsoQik=?=
X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000325170406U.imura@cs.titech.ac.jp>
Date: Sat, 25 Mar 2000 17:04:06 +0900
X-Dispatcher: imput version 990401(IM113)
Lines: 19
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

>  * It's because, there are no /usr/X11R6/bin/X in Asami-san's chroot
>  * environment, I bet.
> 
> Hmm.  So kdm looks at the X symlink to decide whether to build with X
> support or not?
> 
> I can add that to my X package, but what exactly do I need?  Just the
> symlink (to nowhere), or do I need it to be pointing to one of the
> servers?  (Or even an empty file with that name?)
> 
> Satoshi

kdm determines X path as 'test -f $PATH/bin/X', so touching X is enough.

Thank you. :)

-- R. Imura
// my private mail address has changed.
// imura@cs.titech.ac.jp ====> imura@af.airnet.ne.jp /(-.-)y-~~


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25  0: 7:21 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mail.af.airnet.ne.jp (mail.af.airnet.ne.jp [210.159.66.49])
	by hub.freebsd.org (Postfix) with ESMTP
	id 890B237B8A1; Sat, 25 Mar 2000 00:07:15 -0800 (PST)
	(envelope-from imura@cs.titech.ac.jp)
Received: from imura.af.airnet.ne.jp (tok066.airnet.ne.jp [210.159.88.66])
	by mail.af.airnet.ne.jp (8.8.8/3.6W/06/13/98-AF.AIRNET.NE.JP) with ESMTP id RAA13072;
	Sat, 25 Mar 2000 17:07:13 +0900
Posted-Date: Sat, 25 Mar 2000 17:06:19 +0900 (JST)
To: asami@freebsd.org
Cc: nsayer@freebsd.org, will@freebsd.org, freebsd-ports@freebsd.org,
	freebsd-current@freebsd.org
Subject: Re: KDE kdm problem with packaged version (make release 
 issue?)
From: "R. Imura" <imura@af.airnet.ne.jp>
In-Reply-To: <20000325170406U.imura@cs.titech.ac.jp>
References: <20000323213103K.imura@cs.titech.ac.jp>
	<vqc3dpgylhg.fsf@silvia.hip.berkeley.edu>
	<20000325170406U.imura@cs.titech.ac.jp>
X-Mailer: Mew version 1.94b20 on Emacs 19.34 / Mule 2.3
 =?iso-2022-jp?B?KBskQkt2RSYyVhsoQik=?=
X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000325170618R.imura@cs.titech.ac.jp>
Date: Sat, 25 Mar 2000 17:06:18 +0900
X-Dispatcher: imput version 990401(IM113)
Lines: 7
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> kdm determines X path as 'test -f $PATH/bin/X', so touching X is enough.
                                   ^^^^^^^^^^^ $PATH/X


-- R. Imura
// my private mail address has changed.
// imura@cs.titech.ac.jp ====> imura@af.airnet.ne.jp /(-.-)y-~~


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25  0:26:13 2000
Delivered-To: freebsd-current@freebsd.org
Received: from smtp03.wxs.nl (smtp03.wxs.nl [195.121.6.37])
	by hub.freebsd.org (Postfix) with ESMTP
	id 2F8D337BD31; Sat, 25 Mar 2000 00:26:06 -0800 (PST)
	(envelope-from asmodai@wxs.nl)
Received: from daemon.ninth-circle.org ([195.121.225.175]) by smtp03.wxs.nl
          (Netscape Messaging Server 3.61)  with ESMTP id AAAE09;
          Sat, 25 Mar 2000 09:26:04 +0100
Received: (from asmodai@localhost)
	by daemon.ninth-circle.org (8.9.3/8.9.3) id IAA30050;
	Sat, 25 Mar 2000 08:46:25 +0100 (CET)
	(envelope-from asmodai)
Date: Sat, 25 Mar 2000 08:46:25 +0100
From: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl>
To: Andrew Sherrod <ixkatl@yahoo.com>
Cc: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>, dan@FreeBSD.ORG,
	current@FreeBSD.ORG
Subject: Re: -current, ep and fragment problems.
Message-ID: <20000325084625.B29887@daemon.ninth-circle.org>
References: <20000325053955.20420.qmail@web122.yahoomail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <20000325053955.20420.qmail@web122.yahoomail.com>; from ixkatl@yahoo.com on Fri, Mar 24, 2000 at 09:39:55PM -0800
Organisation: Ninth-Circle Enterprises
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

-On [20000325 08:00], Andrew Sherrod (ixkatl@yahoo.com) wrote:
>
>My 3.4 machine at work has periodic problems with the
>fxp. No performance issues (perhaps a little slow, but
>the network is congested enough that this is hard to
>measure). However it does periodically display an
>error message about "PHYS" and "unsupported". I am
>home right now, so I can't reproduce the exact
>message.

That is unrelated to what Dan was asking.

Wrt your fxp, we're working on that.

-- 
Jeroen Ruigrok vd Werven/Asmodai    asmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project <http://home.wxs.nl/~asmodai>
Any fool can make a rule.  And every fool will mind it...


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25  1:13:33 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mrynet.com (mrynet.com [24.234.53.177])
	by hub.freebsd.org (Postfix) with ESMTP id 8F16437B5AC
	for <freebsd-current@freebsd.org>; Sat, 25 Mar 2000 01:13:30 -0800 (PST)
	(envelope-from freebsd@mrynet.com)
Received: (from freebsd@localhost)
	by mrynet.com (8.9.3/8.9.3) id BAA01976;
	Sat, 25 Mar 2000 01:13:13 -0800 (PST)
	(envelope-from freebsd)
Posted-Date: Sat, 25 Mar 2000 01:13:13 -0800 (PST)
Message-Id: <200003250913.BAA01976@mrynet.com>
From: freebsd@mrynet.com (FreeBSD mailing list)
Date: Sat, 25 Mar 2000 01:13:12 +0000
X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96)
To: Bruce Evans <bde@zeta.org.au>
Subject: Re: fd0: Debugger("d_iocmd botch") called.
Cc: freebsd-current@freebsd.org
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Bruce wrote:
> On Fri, 24 Mar 2000, Jim Bloom wrote:
> 
> > FreeBSD mailing list wrote:
> > > 
> > > This patch does indeed fix the writing of floppies.  However, fdformat(1)
> > > still fails as follows:
> > 
> > That is very strange.  My patch only applies to formatting floppies.  It
> > did not touch any routine used in writing a floppy.  I have no idea at
> > this time what is causing your other problems.
> > 
> > I am unable to write to a floppy at this time.  I'm not seeing any
> > errors, but nothings is getting written.
> 
> Reading of floppies is broken too.  The wrong flags are passed to
> isa_dmastart(), so the DMA direction is wrong.  It defaults to the most
> dangerous direction (ISADMA_WRITE), of course.

I've confirmed that writing floppies seemingly works just fine, although
I can't read at all.  I've written a number of floppy boot images and
checked them out, as well as performed a newfs_msdos and verified it on
DOS machines.

Cheers,
-scott
--
Scott G. Akmentins-Taylor     InterNet: staylor@mrynet.com
MRY Systems			        staylor@mrynet.lv


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25  2:12:44 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id AF0E037B520
	for <freebsd-current@FreeBSD.ORG>; Sat, 25 Mar 2000 02:12:35 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id CAA19991;
	Sat, 25 Mar 2000 02:12:07 -0800 (PST)
	(envelope-from dillon)
Date: Sat, 25 Mar 2000 02:12:07 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003251012.CAA19991@apollo.backplane.com>
To: Bruce Evans <bde@zeta.org.au>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: Anyone know why the syscall interface is using the doreti
 mechanism?
References:  <Pine.BSF.4.21.0003251654510.405-100000@alphplex.bde.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

    Ah, excellent summary Bruce!  Now I know what to look for and test
    re: syscall returns.  I'm confident I can at least test for the 
    cases without needing the MP lock, which is all we really need to be
    able to optimize the critical path.

    I have also successfully removed all the nasty *CPL_LOCK stuff.  It
    was only half-implemented anyway and virtually none of it would have
    been useful for interrupt threads.  It's kinda nice having the SMP 
    spl*() call overhead back down to the UP case.  I'll post the new patch
    tomorrow.  

    It's getting clean enough that you can almost understand the interrupt 
    code :-)

						-Matt



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25  2:17:27 2000
Delivered-To: freebsd-current@freebsd.org
Received: from fgwmail7.fujitsu.co.jp (fgwmail7.fujitsu.co.jp [192.51.44.37])
	by hub.freebsd.org (Postfix) with ESMTP id 9065737B7AE
	for <current@FreeBSD.ORG>; Sat, 25 Mar 2000 02:17:14 -0800 (PST)
	(envelope-from shin@nd.net.fujitsu.co.jp)
Received: from m3.gw.fujitsu.co.jp by fgwmail7.fujitsu.co.jp (8.9.3/3.7W-MX0002-Fujitsu Gateway)
	id TAA03863; Sat, 25 Mar 2000 19:16:05 +0900 (JST)
	(envelope-from shin@nd.net.fujitsu.co.jp)
Received: from incapgw.fujitsu.co.jp by m3.gw.fujitsu.co.jp (8.9.3/3.7W-0003-Fujitsu Domain Master)
	id TAA21357; Sat, 25 Mar 2000 19:16:03 +0900 (JST)
Received: from localhost ([192.168.245.122]) by incapgw.fujitsu.co.jp (8.9.3/3.7W-0002)
	id TAA27733; Sat, 25 Mar 2000 19:16:01 +0900 (JST)
To: bmah@CA.Sandia.GOV
Cc: bde@zeta.org.au, nnd@mail.nsk.ru, current@FreeBSD.ORG
Subject: Re: 'machine/param.h' required for 'sys/socket.h' 
In-Reply-To: <200003211853.e2LIrUg87051@nimitz.ca.sandia.gov>
References: <Pine.BSF.4.21.0003220428230.4710-100000@alphplex.bde.org>
	<20000322024911Q.shin@nd.net.fujitsu.co.jp>
	<200003211853.e2LIrUg87051@nimitz.ca.sandia.gov>
X-Mailer: Mew version 1.94 on Emacs 20.4 / Mule 4.0 (HANANOEN)
X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000325191659G.shin@nd.net.fujitsu.co.jp>
Date: Sat, 25 Mar 2000 19:16:59 +0900
From: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 64
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> Arrgh.  Now it seems I might need to reverse my position.  I looked
> through some code fragments in UNIX Network Programming (Volume 1,
> Second Edition, pp. 362-365), and there's some precedent for needing
> <sys/param.h> with the CMSG*() macros.
> 
> On the other hand, RFC 2292 and draft-ietf-ipngwg-rfc2292bis (the
> references I was originally working from) don't mention this requirement
> at all; they just say that CMSG*() are defined with <sys/socket.h>.  I'm
> slightly confused by now.
> 
> I'm going to send off a note to the authors of 
> draft-ietf-ipngwg-rfc229bis asking for some clarification.  In the 
> meantime, maybe we should hold off on doing any changes.
> 
> Bruce.

There seems to be no message from bmah related to this, so I
now add a follow-up here.

The authors' reply is that,

>The X/Open (as well as POSIX I think) man pages for sendmsg()
>only list socket.h as an include file.
>The old BSD man pages list both param.h and socket.h.

And, from `man sendmsg` on FreeBSD, only,

>SYNOPSIS
>     #include <sys/types.h>
>     #include <sys/socket.h>

are required.

So I think machine/param.h should be included from
sys/socket.h for more portability.

It is my fault and sorry for bmah and possibly other ports
maintainers.
I'll also create an ERRATA entry for this.

And I'll fix it on current and stable tree.
I checked the following patch on 5.0 and make world was OK.
I'll commit this, so if param.h inclusion related problem
happens for any of ports, please let me know.

Thanks,
Yoshinobu Inoue

===================================================================
RCS file: /home/ncvs/src/sys/sys/socket.h,v
retrieving revision 1.39
diff -u -r1.39 socket.h
--- socket.h	2000/03/11 19:51:04	1.39
+++ socket.h	2000/03/25 10:13:45
@@ -37,6 +37,9 @@
 #ifndef _SYS_SOCKET_H_
 #define	_SYS_SOCKET_H_
 
+/* for ALIGN() */
+#include <machine/param.h>
+
 /*
  * Definitions related to sockets: types, address families, options.
  */


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25  2:31: 3 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mail.surf1.de (mail.Surf1.de [194.25.165.21])
	by hub.freebsd.org (Postfix) with ESMTP id 3475837B672
	for <freebsd-current@FreeBSD.ORG>; Sat, 25 Mar 2000 02:30:55 -0800 (PST)
	(envelope-from alex@cichlids.com)
Received: from cichlids.com (pC19F54A7.dip0.t-ipconnect.de [193.159.84.167])
	by mail.surf1.de (8.9.3/8.9.3) with ESMTP id KAA03594;
	Sat, 25 Mar 2000 10:31:11 +0100
Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10])
	by cichlids.com (Postfix) with ESMTP
	id 9BD6AAC2C; Sat, 25 Mar 2000 11:32:43 +0100 (CET)
Received: (from alex@localhost)
	by cichlids.cichlids.com (8.9.3/8.9.3) id LAA04379;
	Sat, 25 Mar 2000 11:30:52 +0100 (CET)
	(envelope-from alex)
Date: Sat, 25 Mar 2000 11:30:52 +0100
From: Alexander Langer <alex@big.endian.de>
To: Brad Knowles <blk@skynet.be>
Cc: FreeBSD-CURRENT Mailing List <freebsd-current@FreeBSD.ORG>
Subject: Re: Accessing FreeBSD 3.4-STABLE filesystems from 4.0-STABLE...
Message-ID: <20000325113052.A4192@cichlids.cichlids.com>
Mail-Followup-To: Brad Knowles <blk@skynet.be>,
	FreeBSD-CURRENT Mailing List <freebsd-current@FreeBSD.ORG>
References: <v04220816b501cd2c0970@[194.78.234.186]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <v04220816b501cd2c0970@[194.78.234.186]>; from blk@skynet.be on Sat, Mar 25, 2000 at 02:57:51AM +0100
X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8  A8 E3 BA F3 4E 60 7D 7F
X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung.
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Thus spake Brad Knowles (blk@skynet.be):

> upgraded it to 4.0-STABLE on a second hard drive, and I likewise 
> can't access the 4.0-STABLE filesystems from 3.4-STABLE.

If you don't tell us where it fails (and how), we can't help you.


Alex


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25  3: 4:42 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by hub.freebsd.org (Postfix) with ESMTP id 8FD9837B6AA
	for <current@FreeBSD.ORG>; Sat, 25 Mar 2000 03:04:37 -0800 (PST)
	(envelope-from bde@zeta.org.au)
Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102])
	by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id WAA15900;
	Sat, 25 Mar 2000 22:12:13 +1100
Date: Sat, 25 Mar 2000 22:04:02 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-Sender: bde@alphplex.bde.org
To: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>
Cc: bmah@CA.Sandia.GOV, nnd@mail.nsk.ru, current@FreeBSD.ORG
Subject: Re: 'machine/param.h' required for 'sys/socket.h' 
In-Reply-To: <20000325191659G.shin@nd.net.fujitsu.co.jp>
Message-ID: <Pine.BSF.4.21.0003252142050.654-100000@alphplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Sat, 25 Mar 2000, Yoshinobu Inoue wrote:

> ...
> There seems to be no message from bmah related to this, so I
> now add a follow-up here.
> 
> The authors' reply is that,
> 
> >The X/Open (as well as POSIX I think) man pages for sendmsg()
> >only list socket.h as an include file.
> >The old BSD man pages list both param.h and socket.h.
> 
> And, from `man sendmsg` on FreeBSD, only,
> 
> >SYNOPSIS
> >     #include <sys/types.h>
> >     #include <sys/socket.h>
> 
> are required.

Same in the not-so-old BSD man pages (Lite1).

> So I think machine/param.h should be included from
> sys/socket.h for more portability.

<machine/param.h> can't be included in any standard header
(except in <sys/param.h>) because it gives massive, undocumented
namespace pollution.  The macro `MACHINE' is especially likely
to conflict with an application macro.

Instead, CMSG* should use _ALIGN() and _ALIGN() should be implemented
somewhere that doesn't add any namespace pollution.  We currently
use <machine/ansi.h> for things like this, but it is already too
overloaded.

Bruce



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25  3:28:55 2000
Delivered-To: freebsd-current@freebsd.org
Received: from fgwmail7.fujitsu.co.jp (fgwmail7.fujitsu.co.jp [192.51.44.37])
	by hub.freebsd.org (Postfix) with ESMTP id EE05437B5E4
	for <current@FreeBSD.ORG>; Sat, 25 Mar 2000 03:28:52 -0800 (PST)
	(envelope-from shin@nd.net.fujitsu.co.jp)
Received: from m2.gw.fujitsu.co.jp by fgwmail7.fujitsu.co.jp (8.9.3/3.7W-MX0002-Fujitsu Gateway)
	id UAA07192; Sat, 25 Mar 2000 20:28:16 +0900 (JST)
	(envelope-from shin@nd.net.fujitsu.co.jp)
Received: from incapgw.fujitsu.co.jp by m2.gw.fujitsu.co.jp (8.9.3/3.7W-0003-Fujitsu Domain Master)
	id UAA25866; Sat, 25 Mar 2000 20:28:14 +0900 (JST)
Received: from localhost ([192.168.245.157]) by incapgw.fujitsu.co.jp (8.9.3/3.7W-0002)
	id UAA29445; Sat, 25 Mar 2000 20:28:12 +0900 (JST)
To: bde@zeta.org.au
Cc: bmah@CA.Sandia.GOV, nnd@mail.nsk.ru, current@FreeBSD.ORG
Subject: Re: 'machine/param.h' required for 'sys/socket.h' 
In-Reply-To: <Pine.BSF.4.21.0003252142050.654-100000@alphplex.bde.org>
References: <20000325191659G.shin@nd.net.fujitsu.co.jp>
	<Pine.BSF.4.21.0003252142050.654-100000@alphplex.bde.org>
X-Mailer: Mew version 1.94 on Emacs 20.4 / Mule 4.0 (HANANOEN)
X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000325202906C.shin@nd.net.fujitsu.co.jp>
Date: Sat, 25 Mar 2000 20:29:06 +0900
From: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 20
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> > So I think machine/param.h should be included from
> > sys/socket.h for more portability.
> 
> <machine/param.h> can't be included in any standard header
> (except in <sys/param.h>) because it gives massive, undocumented
> namespace pollution.  The macro `MACHINE' is especially likely
> to conflict with an application macro.

Thanks again for your advice(and sorry for my ignorance).

> Instead, CMSG* should use _ALIGN() and _ALIGN() should be implemented
> somewhere that doesn't add any namespace pollution.  We currently
> use <machine/ansi.h> for things like this, but it is already too
> overloaded.
> 
> Bruce

OK, then how about creating machine/align.h?

Yoshinobu Inoue


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25  4:23:39 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by hub.freebsd.org (Postfix) with ESMTP id 35B1E37B6AA
	for <current@FreeBSD.ORG>; Sat, 25 Mar 2000 04:23:34 -0800 (PST)
	(envelope-from bde@zeta.org.au)
Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102])
	by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id XAA18497;
	Sat, 25 Mar 2000 23:31:11 +1100
Date: Sat, 25 Mar 2000 23:22:59 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-Sender: bde@alphplex.bde.org
To: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>
Cc: bmah@CA.Sandia.GOV, nnd@mail.nsk.ru, current@FreeBSD.ORG
Subject: Re: 'machine/param.h' required for 'sys/socket.h' 
In-Reply-To: <20000325202906C.shin@nd.net.fujitsu.co.jp>
Message-ID: <Pine.BSF.4.21.0003252304180.815-100000@alphplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Sat, 25 Mar 2000, Yoshinobu Inoue wrote:

> > Instead, CMSG* should use _ALIGN() and _ALIGN() should be implemented
> > somewhere that doesn't add any namespace pollution.  We currently
> > use <machine/ansi.h> for things like this, but it is already too
> > overloaded.

> OK, then how about creating machine/align.h?

That approach in general would give too many headers.

<machine/ansi.h> is more wrongly loaded than overloaded.  It is used
to avoid certain namespace problems in general, not just ones in ANSI
headers.  It is mainly used to avoid namespace problems with typedefs.
Typedefs should all be handled in <machine/types.h>, but currently
aren't because <machine/types.h> would give namespace pollution in
ANSI headers.  I think headers like <machine/param.h> and <machine/types.h>
should define only names in the implementation namespace, so that they
can be used in standard headers.  The standard headers then export
precisely the names specified by the applicable standard, if any.

Bruce



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25  6:35:21 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mail-2.viaduk.net (mail-2.viaduk.net [195.5.4.28])
	by hub.freebsd.org (Postfix) with ESMTP id 24D3837B78C
	for <freebsd-current@freebsd.org>; Sat, 25 Mar 2000 06:35:15 -0800 (PST)
	(envelope-from maxkol@viaduk.net)
Received: from resolver.viaduk.net (maxkol@ns.viaduk.net [195.5.4.1])
	by mail-2.viaduk.net (8.9.1/8.9.1) with ESMTP id QAA27489
	for <freebsd-current@freebsd.org>; Sat, 25 Mar 2000 16:35:13 +0200 (EET)
Received: from localhost (maxkol@localhost)
	by resolver.viaduk.net (8.9.3/8.9.1) with ESMTP id QAA56333
	for <freebsd-current@freebsd.org>; Sat, 25 Mar 2000 16:35:13 +0200 (EET)
	(envelope-from maxkol@viaduk.net)
Date: Sat, 25 Mar 2000 16:35:12 +0200 (EET)
From: Maxim Kolinko <maxkol@viaduk.net>
X-Sender: maxkol@res
To: freebsd-current@freebsd.org
Subject: 2.2.8 to 4.0 upgrade
Message-ID: <Pine.BSF.4.21.0003251620510.28973-100000@res>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


how to upgrade 2.2.8-STABLE to 4.0-STABLE ?

cd /usr/src; make aout-to-elf-build

--------------------------------------------------------------
>>> stage 3: cross tools
--------------------------------------------------------------
cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/aout/i386/usr/src/ibm-pc
DESTDIR=/usr/obj/aout/i386/usr/src/ibm-pc  INSTALL="sh
/usr/src/tools/install.sh"  MACHINE_ARCH=ibm-pc
TOOLS_PREFIX=/usr/obj/aout/i386/usr/src/ibm-pc
PATH=/usr/obj/aout/i386/usr/src/ibm-pc/usr/sbin:/usr/obj/aout/i386/usr/src/ibm-pc/usr/bin:/usr/obj/aout/i386/usr/src/ibm-pc/usr/games:/sbin:/bin:/usr/sbin:/usr/bin
TARGET_ARCH=i386 make -f Makefile.inc1 -DNOMAN -DNOINFO -DNOHTML
-DNO_FORTRAN -DNO_GDB cross-tools
cd /usr/src/usr.sbin/btxld;  make obj;  make depend;  make all;  make
install
/usr/obj/aout/i386/usr/src/ibm-pc/usr/src/usr.sbin/btxld created for
/usr/src/usr.sbin/btxld
rm -f .depend
mkdep -f .depend -a    -I/usr/obj/aout/i386/usr/src/ibm-pc/usr/include
/usr/src/usr.sbin/btxld/btxld.c /usr/src/usr.sbin/btxld/elfh.c
cd /usr/src/usr.sbin/btxld; make _EXTRADEPEND
echo btxld: `cc -Wl,-f -O -pipe -Wall
-I/usr/obj/aout/i386/usr/src/ibm-pc/usr/include    ` >> .depend
cc -O -pipe -Wall   -I/usr/obj/aout/i386/usr/src/ibm-pc/usr/include -c
/usr/src/usr.sbin/btxld/btxld.c
In file included from /usr/src/usr.sbin/btxld/btxld.c:47:
/usr/src/usr.sbin/btxld/btx.h:42: parse error before `uint8_t'
/usr/src/usr.sbin/btxld/btx.h:42: warning: no semicolon at end of struct
or union
/usr/src/usr.sbin/btxld/btx.h:43: warning: data definition has no type or
storage class
/usr/src/usr.sbin/btxld/btx.h:44: parse error before `btx_magic'
/usr/src/usr.sbin/btxld/btx.h:44: warning: data definition has no type or
storage class
/usr/src/usr.sbin/btxld/btx.h:45: parse error before `btx_majver'
/usr/src/usr.sbin/btxld/btx.h:45: warning: data definition has no type or
storage class
/usr/src/usr.sbin/btxld/btx.h:46: parse error before `btx_minver'
/usr/src/usr.sbin/btxld/btx.h:46: warning: data definition has no type or
storage class
/usr/src/usr.sbin/btxld/btx.h:47: parse error before `btx_flags'
/usr/src/usr.sbin/btxld/btx.h:47: warning: data definition has no type or
storage class
/usr/src/usr.sbin/btxld/btx.h:48: parse error before `btx_pgctl'
/usr/src/usr.sbin/btxld/btx.h:48: warning: data definition has no type or
storage class
/usr/src/usr.sbin/btxld/btx.h:49: parse error before `btx_textsz'
/usr/src/usr.sbin/btxld/btx.h:49: warning: data definition has no type or
storage class
/usr/src/usr.sbin/btxld/btx.h:50: parse error before `btx_entry'
/usr/src/usr.sbin/btxld/btx.h:50: warning: data definition has no type or
storage class
/usr/src/usr.sbin/btxld/btxld.c:67: parse error before `uint32_t'
/usr/src/usr.sbin/btxld/btxld.c:67: warning: no semicolon at end of struct
or union
/usr/src/usr.sbin/btxld/btxld.c:68: warning: data definition has no type
or storage class
/usr/src/usr.sbin/btxld/btxld.c:69: parse error before `size'
/usr/src/usr.sbin/btxld/btxld.c:69: warning: data definition has no type
or storage class
/usr/src/usr.sbin/btxld/btxld.c:70: parse error before `text'
/usr/src/usr.sbin/btxld/btxld.c:70: warning: data definition has no type
or storage class
/usr/src/usr.sbin/btxld/btxld.c:71: parse error before `data'
/usr/src/usr.sbin/btxld/btxld.c:71: warning: data definition has no type
or storage class
/usr/src/usr.sbin/btxld/btxld.c:72: parse error before `bss'
/usr/src/usr.sbin/btxld/btxld.c:72: warning: data definition has no type
or storage class
/usr/src/usr.sbin/btxld/btxld.c:73: parse error before `org'
/usr/src/usr.sbin/btxld/btxld.c:73: warning: data definition has no type
or storage class
/usr/src/usr.sbin/btxld/btxld.c:74: parse error before `entry'
/usr/src/usr.sbin/btxld/btxld.c:74: warning: data definition has no type
or storage class
/usr/src/usr.sbin/btxld/btxld.c:99: parse error before `centry'
/usr/src/usr.sbin/btxld/btxld.c:99: warning: data definition has no type
or storage class
/usr/src/usr.sbin/btxld/btxld.c:100: parse error before `lentry'
/usr/src/usr.sbin/btxld/btxld.c:100: warning: data definition has no type
or storage class
/usr/src/usr.sbin/btxld/btxld.c:120: parse error before `optaddr'
/usr/src/usr.sbin/btxld/btxld.c:120: warning: data definition has no type
or storage class
/usr/src/usr.sbin/btxld/btxld.c: In function `btxld':
/usr/src/usr.sbin/btxld/btxld.c:195: storage size of `btx' isn't known
/usr/src/usr.sbin/btxld/btxld.c:196: storage size of `ihdr' isn't known
/usr/src/usr.sbin/btxld/btxld.c:196: storage size of `ohdr' isn't known
/usr/src/usr.sbin/btxld/btxld.c:196: warning: unused variable `ohdr'
/usr/src/usr.sbin/btxld/btxld.c:196: warning: unused variable `ihdr'
/usr/src/usr.sbin/btxld/btxld.c:195: warning: unused variable `btx'
/usr/src/usr.sbin/btxld/btxld.c: In function `getbtx':
/usr/src/usr.sbin/btxld/btxld.c:299: dereferencing pointer to incomplete
type
/usr/src/usr.sbin/btxld/btxld.c:299: dereferencing pointer to incomplete
type
/usr/src/usr.sbin/btxld/btxld.c:300: dereferencing pointer to incomplete
type
/usr/src/usr.sbin/btxld/btxld.c:301: dereferencing pointer to incomplete
type
/usr/src/usr.sbin/btxld/btxld.c:302: dereferencing pointer to incomplete
type
/usr/src/usr.sbin/btxld/btxld.c: In function `gethdr':
/usr/src/usr.sbin/btxld/btxld.c:319: dereferencing pointer to incomplete
type
/usr/src/usr.sbin/btxld/btxld.c:324: dereferencing pointer to incomplete
type
/usr/src/usr.sbin/btxld/btxld.c:325: dereferencing pointer to incomplete
type
/usr/src/usr.sbin/btxld/btxld.c:328: dereferencing pointer to incomplete
type
/usr/src/usr.sbin/btxld/btxld.c:332: dereferencing pointer to incomplete
type
/usr/src/usr.sbin/btxld/btxld.c:333: dereferencing pointer to incomplete
type
/usr/src/usr.sbin/btxld/btxld.c:339: dereferencing pointer to incomplete
type
/usr/src/usr.sbin/btxld/btxld.c:341: dereferencing pointer to incomplete
type
/usr/src/usr.sbin/btxld/btxld.c:342: dereferencing pointer to incomplete
type
/usr/src/usr.sbin/btxld/btxld.c:343: dereferencing pointer to incomplete
type
/usr/src/usr.sbin/btxld/btxld.c:344: dereferencing pointer to incomplete
type
/usr/src/usr.sbin/btxld/btxld.c:346: dereferencing pointer to incomplete
type
/usr/src/usr.sbin/btxld/btxld.c:351: dereferencing pointer to incomplete
type
/usr/src/usr.sbin/btxld/btxld.c:352: dereferencing pointer to incomplete
type
/usr/src/usr.sbin/btxld/btxld.c:354: `uint8_t' undeclared (first use this
function)
/usr/src/usr.sbin/btxld/btxld.c:354: (Each undeclared identifier is
reported only once
/usr/src/usr.sbin/btxld/btxld.c:354: for each function it appears in.)
/usr/src/usr.sbin/btxld/btxld.c:354: parse error before `)'
/usr/src/usr.sbin/btxld/btxld.c:359: dereferencing pointer to incomplete
type
/usr/src/usr.sbin/btxld/btxld.c:360: dereferencing pointer to incomplete
type
/usr/src/usr.sbin/btxld/btxld.c:362: dereferencing pointer to incomplete
type
/usr/src/usr.sbin/btxld/btxld.c:365: dereferencing pointer to incomplete
type
/usr/src/usr.sbin/btxld/btxld.c:366: dereferencing pointer to incomplete
type
/usr/src/usr.sbin/btxld/btxld.c:374: deref incomplete type
/usr/src/usr.sbin/btxld/btxld.c: At top level:
/usr/src/usr.sbin/btxld/btxld.c:500: parse error before `optaddr'
/usr/src/usr.sbin/btxld/btxld.c:501: warning: return-type defaults to
`int'
*** Error code 1

Stop in /usr/src/usr.sbin/btxld.
*** Error code 1




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25  7:20:22 2000
Delivered-To: freebsd-current@freebsd.org
Received: from lucifer.bart.nl (lucifer.bart.nl [194.158.168.74])
	by hub.freebsd.org (Postfix) with ESMTP id E9EDF37B521
	for <freebsd-current@FreeBSD.ORG>; Sat, 25 Mar 2000 07:20:15 -0800 (PST)
	(envelope-from asmodai@lucifer.bart.nl)
Received: (from asmodai@localhost)
	by lucifer.bart.nl (8.9.3/8.9.3) id QAA62713;
	Sat, 25 Mar 2000 16:20:13 +0100 (CET)
	(envelope-from asmodai)
Date: Sat, 25 Mar 2000 16:20:12 +0100
From: Jeroen Ruigrok van der Werven <asmodai@bart.nl>
To: Brad Knowles <blk@skynet.be>
Cc: FreeBSD-CURRENT Mailing List <freebsd-current@FreeBSD.ORG>
Subject: Re: Accessing FreeBSD 3.4-STABLE filesystems from 4.0-STABLE...
Message-ID: <20000325162012.B62552@lucifer.bart.nl>
References: <v04220816b501cd2c0970@[194.78.234.186]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <v04220816b501cd2c0970@[194.78.234.186]>; from blk@skynet.be on Sat, Mar 25, 2000 at 02:57:51AM +0100
Organisation: bART Internet Services B.V.
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

-On [20000325 03:05], Brad Knowles (blk@skynet.be) wrote:
>	I gotta be doing something stupid here.  I haven't been able to 
>access the existing 3.4-STABLE filesystems on this machine since I 
>upgraded it to 4.0-STABLE on a second hard drive, and I likewise 
>can't access the 4.0-STABLE filesystems from 3.4-STABLE.

Block/character device collapsing breaking you up now?

/dev/ Should only be character devices now.

-- 
Jeroen Ruigrok van der Werven          Network- and systemadministrator
<asmodai@bart.nl>                      VIA NET.WORKS The Netherlands
BSD: Technical excellence at its best  http://www.bart.nl
Like cures like...


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25  7:33:49 2000
Delivered-To: freebsd-current@freebsd.org
Received: from mail.surf1.de (mail.Surf1.de [194.25.165.21])
	by hub.freebsd.org (Postfix) with ESMTP id 438EF37B520
	for <freebsd-current@FreeBSD.org>; Sat, 25 Mar 2000 07:33:36 -0800 (PST)
	(envelope-from alex@cichlids.com)
Received: from cichlids.com (pC19F5485.dip0.t-ipconnect.de [193.159.84.133])
	by mail.surf1.de (8.9.3/8.9.3) with ESMTP id PAA16457;
	Sat, 25 Mar 2000 15:33:51 +0100
Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10])
	by cichlids.com (Postfix) with ESMTP
	id 23976AC2C; Sat, 25 Mar 2000 16:35:24 +0100 (CET)
Received: (from alex@localhost)
	by cichlids.cichlids.com (8.9.3/8.9.3) id QAA15990;
	Sat, 25 Mar 2000 16:33:33 +0100 (CET)
	(envelope-from alex)
Date: Sat, 25 Mar 2000 16:33:33 +0100
From: Alexander Langer <alex@big.endian.de>
To: Maxim Kolinko <maxkol@viaduk.net>
Cc: freebsd-current@FreeBSD.org
Subject: Re: 2.2.8 to 4.0 upgrade
Message-ID: <20000325163333.A15932@cichlids.cichlids.com>
Mail-Followup-To: Maxim Kolinko <maxkol@viaduk.net>,
	freebsd-current@FreeBSD.org
References: <Pine.BSF.4.21.0003251620510.28973-100000@res>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <Pine.BSF.4.21.0003251620510.28973-100000@res>; from maxkol@viaduk.net on Sat, Mar 25, 2000 at 04:35:12PM +0200
X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8  A8 E3 BA F3 4E 60 7D 7F
X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung.
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Thus spake Maxim Kolinko (maxkol@viaduk.net):

> how to upgrade 2.2.8-STABLE to 4.0-STABLE ?
> cd /usr/src; make aout-to-elf-build

upgrade to RELENG_3 first.

Alex


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25  7:36:44 2000
Delivered-To: freebsd-current@freebsd.org
Received: from lucifer.bart.nl (lucifer.bart.nl [194.158.168.74])
	by hub.freebsd.org (Postfix) with ESMTP id 679FC37B683
	for <freebsd-current@FreeBSD.ORG>; Sat, 25 Mar 2000 07:36:38 -0800 (PST)
	(envelope-from asmodai@lucifer.bart.nl)
Received: (from asmodai@localhost)
	by lucifer.bart.nl (8.9.3/8.9.3) id QAA62810;
	Sat, 25 Mar 2000 16:36:15 +0100 (CET)
	(envelope-from asmodai)
Date: Sat, 25 Mar 2000 16:36:14 +0100
From: Jeroen Ruigrok van der Werven <asmodai@bart.nl>
To: Alexander Langer <alex@big.endian.de>
Cc: Maxim Kolinko <maxkol@viaduk.net>, freebsd-current@FreeBSD.ORG
Subject: Re: 2.2.8 to 4.0 upgrade
Message-ID: <20000325163614.D62552@lucifer.bart.nl>
References: <Pine.BSF.4.21.0003251620510.28973-100000@res> <20000325163333.A15932@cichlids.cichlids.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <20000325163333.A15932@cichlids.cichlids.com>; from alex@big.endian.de on Sat, Mar 25, 2000 at 04:33:33PM +0100
Organisation: bART Internet Services B.V.
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

-On [20000325 16:35], Alexander Langer (alex@big.endian.de) wrote:
>Thus spake Maxim Kolinko (maxkol@viaduk.net):
>
>> how to upgrade 2.2.8-STABLE to 4.0-STABLE ?
>> cd /usr/src; make aout-to-elf-build
>
>upgrade to RELENG_3 first.

Yeah.  I recently did a 3.0 -> 3.4 upgrade by source.  That was paying
attention as well.

-- 
Jeroen Ruigrok van der Werven          Network- and systemadministrator
<asmodai@bart.nl>                      VIA NET.WORKS The Netherlands
BSD: Technical excellence at its best  http://www.bart.nl
I may know many things, I may be ignorant...


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25  7:44:16 2000
Delivered-To: freebsd-current@freebsd.org
Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36])
	by hub.freebsd.org (Postfix) with ESMTP id 365B137B679
	for <current@FreeBSD.ORG>; Sat, 25 Mar 2000 07:44:13 -0800 (PST)
	(envelope-from shin@nd.net.fujitsu.co.jp)
Received: from m3.gw.fujitsu.co.jp by fgwmail6.fujitsu.co.jp (8.9.3/3.7W-MX0002-Fujitsu Gateway)
	id AAA12715; Sun, 26 Mar 2000 00:43:22 +0900 (JST)
	(envelope-from shin@nd.net.fujitsu.co.jp)
Received: from incapgw.fujitsu.co.jp by m3.gw.fujitsu.co.jp (8.9.3/3.7W-0003-Fujitsu Domain Master)
	id AAA22533; Sun, 26 Mar 2000 00:43:21 +0900 (JST)
Received: from localhost ([192.168.245.184]) by incapgw.fujitsu.co.jp (8.9.3/3.7W-0002)
	id AAA06469; Sun, 26 Mar 2000 00:43:19 +0900 (JST)
To: bde@zeta.org.au
Cc: bmah@CA.Sandia.GOV, nnd@mail.nsk.ru, current@FreeBSD.ORG
Subject: Re: 'machine/param.h' required for 'sys/socket.h' 
In-Reply-To: <Pine.BSF.4.21.0003252304180.815-100000@alphplex.bde.org>
References: <20000325202906C.shin@nd.net.fujitsu.co.jp>
	<Pine.BSF.4.21.0003252304180.815-100000@alphplex.bde.org>
X-Mailer: Mew version 1.94 on Emacs 20.4 / Mule 4.0 (HANANOEN)
X-Prom-Mew: Prom-Mew 1.93.4 (procmail reader for Mew)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000326004417L.shin@nd.net.fujitsu.co.jp>
Date: Sun, 26 Mar 2000 00:44:17 +0900
From: Yoshinobu Inoue <shin@nd.net.fujitsu.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 53
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> > > Instead, CMSG* should use _ALIGN() and _ALIGN() should be implemented
> > > somewhere that doesn't add any namespace pollution.  We currently
> > > use <machine/ansi.h> for things like this, but it is already too
> > > overloaded.
> 
> > OK, then how about creating machine/align.h?
> 
> That approach in general would give too many headers.
>
> <machine/ansi.h> is more wrongly loaded than overloaded.  It is used
> to avoid certain namespace problems in general, not just ones in ANSI
> headers.  It is mainly used to avoid namespace problems with typedefs.
> Typedefs should all be handled in <machine/types.h>, but currently
> aren't because <machine/types.h> would give namespace pollution in
> ANSI headers.  I think headers like <machine/param.h> and <machine/types.h>
> should define only names in the implementation namespace, so that they
> can be used in standard headers.  The standard headers then export
> precisely the names specified by the applicable standard, if any.


Then, how about defining a macro which specifies name space
polluted part, for short term solution.

machine/param.h:
#ifdef _NO_NAME_SPACE_POLLUTION
#define _ALIGN(x) ......
....
#else
....
#endif

sys/socket.h:
#ifdef  _NO_NAME_SPACE_POLLUTION
#include <machine/param.h>
#else
#define _NO_NAME_SPACE_POLLUTION
#include <machine/param.h>
#undef _NO_NAME_SPACE_POLLUTION
#endif


The macro might be also handy for fixing each of apps which
depends on current machine/param.h and machine/types.h one by
one. It can be specified for each apps, each dir, or in
make.conf.

When all apps are fixed, then the macro and name space
polluted part in machine/param.h and machine/types.h can be
removed.

Or am I still too optimistic?

Yoshinobu Inoue


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25  9:17:48 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id 543D937B699
	for <freebsd-current@FreeBSD.ORG>; Sat, 25 Mar 2000 09:17:46 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id JAA23734;
	Sat, 25 Mar 2000 09:17:46 -0800 (PST)
	(envelope-from dillon)
Date: Sat, 25 Mar 2000 09:17:46 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003251717.JAA23734@apollo.backplane.com>
To: freebsd-current@FreeBSD.ORG
Subject: smp-patch-05.diff now available
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

    At:

	http://www.backplane.com/FreeBSD4/

    I haven't fixed the syscall exit checks yet, but that's next on my
    list.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25 11: 0:26 2000
Delivered-To: freebsd-current@freebsd.org
Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228])
	by hub.freebsd.org (Postfix) with ESMTP id C9F2637B816
	for <current@freebsd.org>; Sat, 25 Mar 2000 11:00:23 -0800 (PST)
	(envelope-from jkh@zippy.cdrom.com)
Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1])
	by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id LAA04473
	for <current@freebsd.org>; Sat, 25 Mar 2000 11:01:32 -0800 (PST)
	(envelope-from jkh@zippy.cdrom.com)
To: current@freebsd.org
Subject: Somebody broke alpha kernel builds?
Date: Sat, 25 Mar 2000 11:01:32 -0800
Message-ID: <4470.954010892@zippy.cdrom.com>
From: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

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  -D_KERNEL -include opt_global.h -elf  -mno-fp-regs -Wa,-mev56  ../../alpha/alpha/clock.c
../../alpha/alpha/clock.c:83: syntax error before `alpha_get_timecount'
../../alpha/alpha/clock.c:83: warning: type defaults to `int' in declaration of `alpha_get_timecount'
../../alpha/alpha/clock.c:83: warning: data definition has no type or storage class
..


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25 11: 5: 3 2000
Delivered-To: freebsd-current@freebsd.org
Received: from feral.com (feral.com [192.67.166.1])
	by hub.freebsd.org (Postfix) with ESMTP id D8DDE37B8FB
	for <current@FreeBSD.ORG>; Sat, 25 Mar 2000 11:04:59 -0800 (PST)
	(envelope-from mjacob@feral.com)
Received: from beppo.feral.com (beppo [192.67.166.79])
	by feral.com (8.9.3/8.9.3) with ESMTP id LAA18205;
	Sat, 25 Mar 2000 11:04:56 -0800
Date: Sat, 25 Mar 2000 11:04:53 -0800 (PST)
From: Matthew Jacob <mjacob@feral.com>
Reply-To: mjacob@feral.com
To: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>
Cc: current@FreeBSD.ORG
Subject: Re: Somebody broke alpha kernel builds?
In-Reply-To: <4470.954010892@zippy.cdrom.com>
Message-ID: <Pine.BSF.4.10.10003251104220.18169-100000@beppo.feral.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


Yes, this was broken for several days. I was just getting ready to fix it when
David O'Brien fixed it (after asking Poul who had made the changes causing
it).


On Sat, 25 Mar 2000, Jordan K. Hubbard 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  -D_KERNEL -include opt_global.h -elf  -mno-fp-regs -Wa,-mev56  ../../alpha/alpha/clock.c
> ../../alpha/alpha/clock.c:83: syntax error before `alpha_get_timecount'
> ../../alpha/alpha/clock.c:83: warning: type defaults to `int' in declaration of `alpha_get_timecount'
> ../../alpha/alpha/clock.c:83: warning: data definition has no type or storage class
> ..
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message
> 



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25 11:50:44 2000
Delivered-To: freebsd-current@freebsd.org
Received: from sharmas.dhs.org (c62443-a.frmt1.sfba.home.com [24.0.69.165])
	by hub.freebsd.org (Postfix) with ESMTP id 85FAE37B7B9
	for <freebsd-current@freebsd.org>; Sat, 25 Mar 2000 11:50:42 -0800 (PST)
	(envelope-from adsharma@sharmas.dhs.org)
Received: (from adsharma@localhost)
	by sharmas.dhs.org (8.9.3/8.9.3) id LAA10553
	for freebsd-current@freebsd.org; Sat, 25 Mar 2000 11:50:45 -0800
Date: Sat, 25 Mar 2000 11:50:45 -0800
From: Arun Sharma <adsharma@sharmas.dhs.org>
To: FreeBSD Current <freebsd-current@freebsd.org>
Subject: malloc.conf
Message-ID: <20000325115045.A10546@sharmas.dhs.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.6i
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

After upgrading to 4.0 from source, I had a simple program which called
malloc core dump on me. After ktrace'ing it and creating /etc/malloc.conf
it was happier.

But I can't find malloc.conf anywhere in /usr/src. How does it get
created during the build ?

	-Arun


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25 11:56: 6 2000
Delivered-To: freebsd-current@freebsd.org
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131])
	by hub.freebsd.org (Postfix) with ESMTP id 975D137B936
	for <freebsd-current@FreeBSD.ORG>; Sat, 25 Mar 2000 11:55:57 -0800 (PST)
	(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1])
	by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id UAA00694;
	Sat, 25 Mar 2000 20:55:17 +0100 (CET)
	(envelope-from phk@critter.freebsd.dk)
To: Arun Sharma <adsharma@sharmas.dhs.org>
Cc: FreeBSD Current <freebsd-current@FreeBSD.ORG>
Subject: Re: malloc.conf 
In-reply-to: Your message of "Sat, 25 Mar 2000 11:50:45 PST."
             <20000325115045.A10546@sharmas.dhs.org> 
Date: Sat, 25 Mar 2000 20:55:16 +0100
Message-ID: <692.954014116@critter.freebsd.dk>
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


Please read the malloc(3) manual page.

In message <20000325115045.A10546@sharmas.dhs.org>, Arun Sharma writes:
>After upgrading to 4.0 from source, I had a simple program which called
>malloc core dump on me. After ktrace'ing it and creating /etc/malloc.conf
>it was happier.
>
>But I can't find malloc.conf anywhere in /usr/src. How does it get
>created during the build ?
>
>	-Arun
>
>
>To Unsubscribe: send mail to majordomo@FreeBSD.org
>with "unsubscribe freebsd-current" in the body of the message
>

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25 12: 2: 1 2000
Delivered-To: freebsd-current@freebsd.org
Received: from sharmas.dhs.org (c62443-a.frmt1.sfba.home.com [24.0.69.165])
	by hub.freebsd.org (Postfix) with ESMTP id 2249037B929
	for <freebsd-current@FreeBSD.ORG>; Sat, 25 Mar 2000 12:01:58 -0800 (PST)
	(envelope-from adsharma@sharmas.dhs.org)
Received: (from adsharma@localhost)
	by sharmas.dhs.org (8.9.3/8.9.3) id MAA10579;
	Sat, 25 Mar 2000 12:01:59 -0800
Date: Sat, 25 Mar 2000 12:01:59 -0800
From: Arun Sharma <adsharma@sharmas.dhs.org>
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc: FreeBSD Current <freebsd-current@FreeBSD.ORG>
Subject: Re: malloc.conf
Message-ID: <20000325120159.A10568@sharmas.dhs.org>
References: <20000325115045.A10546@sharmas.dhs.org> <692.954014116@critter.freebsd.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.6i
In-Reply-To: <692.954014116@critter.freebsd.dk>; from Poul-Henning Kamp on Sat, Mar 25, 2000 at 08:55:16PM +0100
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Sat, Mar 25, 2000 at 08:55:16PM +0100, Poul-Henning Kamp wrote:
> 
> Please read the malloc(3) manual page.
> 

I did and created malloc.conf as documented there. And things were
fine after that. Wouldn't it be better if the build process created
a default /etc/malloc.conf ?

	-Arun


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25 12: 5:26 2000
Delivered-To: freebsd-current@freebsd.org
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131])
	by hub.freebsd.org (Postfix) with ESMTP id D91ED37B74F
	for <freebsd-current@FreeBSD.ORG>; Sat, 25 Mar 2000 12:05:22 -0800 (PST)
	(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1])
	by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id VAA00774;
	Sat, 25 Mar 2000 21:05:18 +0100 (CET)
	(envelope-from phk@critter.freebsd.dk)
To: Arun Sharma <adsharma@sharmas.dhs.org>
Cc: FreeBSD Current <freebsd-current@FreeBSD.ORG>
Subject: Re: malloc.conf 
In-reply-to: Your message of "Sat, 25 Mar 2000 12:01:59 PST."
             <20000325120159.A10568@sharmas.dhs.org> 
Date: Sat, 25 Mar 2000 21:05:18 +0100
Message-ID: <772.954014718@critter.freebsd.dk>
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <20000325120159.A10568@sharmas.dhs.org>, Arun Sharma writes:
>On Sat, Mar 25, 2000 at 08:55:16PM +0100, Poul-Henning Kamp wrote:
>> 
>> Please read the malloc(3) manual page.
>> 
>
>I did and created malloc.conf as documented there. And things were
>fine after that. Wouldn't it be better if the build process created
>a default /etc/malloc.conf ?

Exactly how did you create it ?

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25 12: 6:55 2000
Delivered-To: freebsd-current@freebsd.org
Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9])
	by hub.freebsd.org (Postfix) with ESMTP id 622B437B5FA
	for <current@freebsd.org>; Sat, 25 Mar 2000 12:06:51 -0800 (PST)
	(envelope-from jlemon@flugsvamp.com)
Received: (from jlemon@localhost)
	by prism.flugsvamp.com (8.9.3/8.9.3) id OAA20866;
	Sat, 25 Mar 2000 14:09:24 -0600 (CST)
	(envelope-from jlemon)
Date: Sat, 25 Mar 2000 14:09:24 -0600 (CST)
From: Jonathan Lemon <jlemon@flugsvamp.com>
Message-Id: <200003252009.OAA20866@prism.flugsvamp.com>
To: jkh@zippy.cdrom.com, current@freebsd.org
Subject: Re: Somebody broke alpha kernel builds?
X-Newsgroups: local.mail.freebsd-current
In-Reply-To: <local.mail.freebsd-current/4470.954010892@zippy.cdrom.com>
Organization: 
Cc: 
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In article <local.mail.freebsd-current/4470.954010892@zippy.cdrom.com> you write:
>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 
>-D_KERNEL -include opt_global.h -elf  -mno-fp-regs -Wa,-mev56 
>../../alpha/alpha/clock.c
>../../alpha/alpha/clock.c:83: syntax error before `alpha_get_timecount'
>../../alpha/alpha/clock.c:83: warning: type defaults to `int' in
>declaration of `alpha_get_timecount'
>../../alpha/alpha/clock.c:83: warning: data definition has no type or
>storage class
>..

Speaking of which, why is /home/ncvs on beast not pointing to 
the current CVS repository?  I got bit by the same error after
doing (what I thought) was a correct `cvs update' on beast.

On Freefall:
	 /home/ncvs@ -> /x/ncvs

On Beast:
	freefall:/x on /.amd_mnt/freefall/host/x
	/home/ncvs@ -> /j/ncvs

--
Jonathan


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25 12:11:10 2000
Delivered-To: freebsd-current@freebsd.org
Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228])
	by hub.freebsd.org (Postfix) with ESMTP id 9670737B93B
	for <freebsd-current@FreeBSD.ORG>; Sat, 25 Mar 2000 12:11:08 -0800 (PST)
	(envelope-from jkh@zippy.cdrom.com)
Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1])
	by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id MAA04706;
	Sat, 25 Mar 2000 12:11:50 -0800 (PST)
	(envelope-from jkh@zippy.cdrom.com)
To: Arun Sharma <adsharma@sharmas.dhs.org>
Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>,
	FreeBSD Current <freebsd-current@FreeBSD.ORG>
Subject: Re: malloc.conf 
In-reply-to: Your message of "Sat, 25 Mar 2000 12:01:59 PST."
             <20000325120159.A10568@sharmas.dhs.org> 
Date: Sat, 25 Mar 2000 12:11:50 -0800
Message-ID: <4703.954015110@zippy.cdrom.com>
From: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> I did and created malloc.conf as documented there. And things were
> fine after that. Wouldn't it be better if the build process created
> a default /etc/malloc.conf ?

It's purely an optional file; one doesn't need to be installed by
default in order for things to behave as expected.  Consider it
a debugging feature.

- Jordan


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25 12:14:21 2000
Delivered-To: freebsd-current@freebsd.org
Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228])
	by hub.freebsd.org (Postfix) with ESMTP id 2AE0337B851
	for <current@freebsd.org>; Sat, 25 Mar 2000 12:14:19 -0800 (PST)
	(envelope-from jkh@zippy.cdrom.com)
Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1])
	by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id MAA04731;
	Sat, 25 Mar 2000 12:15:21 -0800 (PST)
	(envelope-from jkh@zippy.cdrom.com)
To: Jonathan Lemon <jlemon@flugsvamp.com>
Cc: current@freebsd.org
Subject: Re: Somebody broke alpha kernel builds? 
In-reply-to: Your message of "Sat, 25 Mar 2000 14:09:24 CST."
             <200003252009.OAA20866@prism.flugsvamp.com> 
Date: Sat, 25 Mar 2000 12:15:21 -0800
Message-ID: <4728.954015321@zippy.cdrom.com>
From: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> Speaking of which, why is /home/ncvs on beast not pointing to 
> the current CVS repository?  I got bit by the same error after
> doing (what I thought) was a correct `cvs update' on beast.

Sorry, "my bad"; the alpha releases were falling over on some sort of
NFS bogon (and cvs checkouts using ssh weren't working either) so I
was forced to copy the repository over to /j on beast and start using
cvsup to synchronize it.  Now that 4.0-RELEASE is behind us and we
don't have another coming up for a few months, I'll point it back.
Done!

- Jordan


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25 12:29: 9 2000
Delivered-To: freebsd-current@freebsd.org
Received: from sharmas.dhs.org (c62443-a.frmt1.sfba.home.com [24.0.69.165])
	by hub.freebsd.org (Postfix) with ESMTP id B205E37B74F
	for <freebsd-current@FreeBSD.ORG>; Sat, 25 Mar 2000 12:29:04 -0800 (PST)
	(envelope-from adsharma@sharmas.dhs.org)
Received: (from adsharma@localhost)
	by sharmas.dhs.org (8.9.3/8.9.3) id MAA10634;
	Sat, 25 Mar 2000 12:29:02 -0800
Date: Sat, 25 Mar 2000 12:29:02 -0800
From: Arun Sharma <adsharma@sharmas.dhs.org>
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc: FreeBSD Current <freebsd-current@FreeBSD.ORG>
Subject: Re: malloc.conf
Message-ID: <20000325122902.A10626@sharmas.dhs.org>
References: <20000325120159.A10568@sharmas.dhs.org> <772.954014718@critter.freebsd.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.6i
In-Reply-To: <772.954014718@critter.freebsd.dk>; from Poul-Henning Kamp on Sat, Mar 25, 2000 at 09:05:18PM +0100
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Sat, Mar 25, 2000 at 09:05:18PM +0100, Poul-Henning Kamp wrote:
> In message <20000325120159.A10568@sharmas.dhs.org>, Arun Sharma writes:
> >On Sat, Mar 25, 2000 at 08:55:16PM +0100, Poul-Henning Kamp wrote:
> >> 
> >> Please read the malloc(3) manual page.
> >> 
> >
> >I did and created malloc.conf as documented there. And things were
> >fine after that. Wouldn't it be better if the build process created
> >a default /etc/malloc.conf ?
> 
> Exactly how did you create it ?

Just as it is documented:

ln -s 'A<' /etc/malloc.conf

	-Arun



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25 12:31:50 2000
Delivered-To: freebsd-current@freebsd.org
Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131])
	by hub.freebsd.org (Postfix) with ESMTP id CEB8D37B929
	for <freebsd-current@FreeBSD.ORG>; Sat, 25 Mar 2000 12:31:39 -0800 (PST)
	(envelope-from phk@critter.freebsd.dk)
Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1])
	by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id VAA00929;
	Sat, 25 Mar 2000 21:31:34 +0100 (CET)
	(envelope-from phk@critter.freebsd.dk)
To: Arun Sharma <adsharma@sharmas.dhs.org>
Cc: FreeBSD Current <freebsd-current@FreeBSD.ORG>
Subject: Re: malloc.conf 
In-reply-to: Your message of "Sat, 25 Mar 2000 12:29:02 PST."
             <20000325122902.A10626@sharmas.dhs.org> 
Date: Sat, 25 Mar 2000 21:31:34 +0100
Message-ID: <927.954016294@critter.freebsd.dk>
From: Poul-Henning Kamp <phk@critter.freebsd.dk>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <20000325122902.A10626@sharmas.dhs.org>, Arun Sharma writes:
>On Sat, Mar 25, 2000 at 09:05:18PM +0100, Poul-Henning Kamp wrote:
>> In message <20000325120159.A10568@sharmas.dhs.org>, Arun Sharma writes:
>> >On Sat, Mar 25, 2000 at 08:55:16PM +0100, Poul-Henning Kamp wrote:
>> >> 
>> >> Please read the malloc(3) manual page.
>> >> 
>> >
>> >I did and created malloc.conf as documented there. And things were
>> >fine after that. Wouldn't it be better if the build process created
>> >a default /etc/malloc.conf ?
>> 
>> Exactly how did you create it ?
>
>Just as it is documented:
>
>ln -s 'A<' /etc/malloc.conf

And that made your program not dump core ?

In that case you should rather try:

	ln -sf 'AJ' /etc/malloc.conf

and fix the bug in your program.

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25 12:36: 8 2000
Delivered-To: freebsd-current@freebsd.org
Received: from sharmas.dhs.org (c62443-a.frmt1.sfba.home.com [24.0.69.165])
	by hub.freebsd.org (Postfix) with ESMTP id E264537B6D1
	for <freebsd-current@FreeBSD.ORG>; Sat, 25 Mar 2000 12:36:02 -0800 (PST)
	(envelope-from adsharma@sharmas.dhs.org)
Received: (from adsharma@localhost)
	by sharmas.dhs.org (8.9.3/8.9.3) id MAA10653;
	Sat, 25 Mar 2000 12:35:55 -0800
Date: Sat, 25 Mar 2000 12:35:55 -0800
From: Arun Sharma <adsharma@sharmas.dhs.org>
To: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>
Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>,
	FreeBSD Current <freebsd-current@FreeBSD.ORG>
Subject: Re: malloc.conf
Message-ID: <20000325123555.B10626@sharmas.dhs.org>
References: <20000325120159.A10568@sharmas.dhs.org> <4703.954015110@zippy.cdrom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.6i
In-Reply-To: <4703.954015110@zippy.cdrom.com>; from Jordan K. Hubbard on Sat, Mar 25, 2000 at 12:11:50PM -0800
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Sat, Mar 25, 2000 at 12:11:50PM -0800, Jordan K. Hubbard wrote:
> > I did and created malloc.conf as documented there. And things were
> > fine after that. Wouldn't it be better if the build process created
> > a default /etc/malloc.conf ?
> 
> It's purely an optional file; one doesn't need to be installed by
> default in order for things to behave as expected.  Consider it
> a debugging feature.

You're right. It works for the default case. I was doing an unsupported
operation: experimenting with rfork and the clone() call from Linuxthreads
port.

However, the mere presence of clone() in the same executable
makes malloc unhappy. 
 
  8668 test     CALL  readlink(0x280f1114,0xbfbff7b8,0x3f)
  8668 test     NAMI  "/etc/malloc.conf"
  8668 test     RET   readlink -1 errno 2 No such file or directory
  8668 test     CALL  sigprocmask(0x1,0x28060000,0x28060010)
  8668 test     RET   sigprocmask 0
  8668 test     CALL  sigprocmask(0x3,0x28060010,0)
  8668 test     RET   sigprocmask 0
  8668 test     PSIG  SIGSEGV SIG_DFL
  8668 test     NAMI  "test.core"

The program is:

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>

#include <sys/types.h>
#include <sys/wait.h>

main()
{
        int status;
        pid_t pid;
        void *stack;

        stack = malloc(4096);
}

It works fine stand alone. But when linked with some other stuff, it core
dumps. If I create /etc/malloc.conf, it's ok.

	-Arun


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25 12:38:33 2000
Delivered-To: freebsd-current@freebsd.org
Received: from rover.village.org (rover.village.org [204.144.255.49])
	by hub.freebsd.org (Postfix) with ESMTP id 573B537B5FA
	for <freebsd-current@FreeBSD.ORG>; Sat, 25 Mar 2000 12:38:28 -0800 (PST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (harmony.village.org [10.0.0.6])
	by rover.village.org (8.9.3/8.9.3) with ESMTP id NAA46330;
	Sat, 25 Mar 2000 13:38:24 -0700 (MST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id NAA73468; Sat, 25 Mar 2000 13:38:13 -0700 (MST)
Message-Id: <200003252038.NAA73468@harmony.village.org>
To: Matthew Dillon <dillon@apollo.backplane.com>
Subject: Re: Anyone know why the syscall interface is using the doreti mechanism? 
Cc: Bruce Evans <bde@zeta.org.au>, freebsd-current@FreeBSD.ORG
In-reply-to: Your message of "Sat, 25 Mar 2000 02:12:07 PST."
		<200003251012.CAA19991@apollo.backplane.com> 
References: <200003251012.CAA19991@apollo.backplane.com>  <Pine.BSF.4.21.0003251654510.405-100000@alphplex.bde.org> 
Date: Sat, 25 Mar 2000 13:38:13 -0700
From: Warner Losh <imp@village.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <200003251012.CAA19991@apollo.backplane.com> Matthew Dillon writes:
:     It's getting clean enough that you can almost understand the interrupt 
:     code :-)

Cool.  That's one part of the kernel that I've not quite fully
understood.  I always figured there was something I was missing about
the code and why it needed to be as complex as it was...

Warner


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25 12:40:21 2000
Delivered-To: freebsd-current@freebsd.org
Received: from rover.village.org (rover.village.org [204.144.255.49])
	by hub.freebsd.org (Postfix) with ESMTP id C3E5537B90A
	for <freebsd-current@FreeBSD.ORG>; Sat, 25 Mar 2000 12:40:17 -0800 (PST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (harmony.village.org [10.0.0.6])
	by rover.village.org (8.9.3/8.9.3) with ESMTP id NAA46342;
	Sat, 25 Mar 2000 13:40:15 -0700 (MST)
	(envelope-from imp@harmony.village.org)
Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id NAA73491; Sat, 25 Mar 2000 13:40:05 -0700 (MST)
Message-Id: <200003252040.NAA73491@harmony.village.org>
To: Jeroen Ruigrok van der Werven <asmodai@bart.nl>
Subject: Re: Accessing FreeBSD 3.4-STABLE filesystems from 4.0-STABLE... 
Cc: Brad Knowles <blk@skynet.be>,
	FreeBSD-CURRENT Mailing List <freebsd-current@FreeBSD.ORG>
In-reply-to: Your message of "Sat, 25 Mar 2000 16:20:12 +0100."
		<20000325162012.B62552@lucifer.bart.nl> 
References: <20000325162012.B62552@lucifer.bart.nl>  <v04220816b501cd2c0970@[194.78.234.186]> 
Date: Sat, 25 Mar 2000 13:40:05 -0700
From: Warner Losh <imp@village.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In message <20000325162012.B62552@lucifer.bart.nl> Jeroen Ruigrok van der Werven writes:
: Block/character device collapsing breaking you up now?
: 
: /dev/ Should only be character devices now.

I was surprised how many block devices were in my /dev when I did a ls
-l /dev | grep ^b.

Maybe we should put something in /etc/daily in -current to whine about
all block devices in /dev :-)

Warner


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25 12:41: 6 2000
Delivered-To: freebsd-current@freebsd.org
Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20])
	by hub.freebsd.org (Postfix) with ESMTP id AC2DE37B91A
	for <freebsd-current@FreeBSD.ORG>; Sat, 25 Mar 2000 12:41:01 -0800 (PST)
	(envelope-from bright@fw.wintelcom.net)
Received: (from bright@localhost)
	by fw.wintelcom.net (8.10.0/8.10.0) id e2PL4l601561;
	Sat, 25 Mar 2000 13:04:47 -0800 (PST)
Date: Sat, 25 Mar 2000 13:04:47 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: freebsd-current@FreeBSD.ORG
Subject: Re: Why are all accesses to the cpl surrounded by a lock?
Message-ID: <20000325130447.I21029@fw.wintelcom.net>
References: <200003250527.VAA19096@apollo.backplane.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200003250527.VAA19096@apollo.backplane.com>; from dillon@apollo.backplane.com on Fri, Mar 24, 2000 at 09:27:57PM -0800
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

* Matthew Dillon <dillon@apollo.backplane.com> [000324 21:52] wrote:
>     I've been doing more SMP cleanup and for the life of me I can't figure
>     out why cpl operations are surrounded by its own [S]CPL_LOCK ??
> 
>     As far as I can tell, the cpl is only accessed/modified:
> 
> 	* by mainline code while the MP lock is held 
> 	* by an interrupt while the MP lock is held
> 
>     Since any modification of the cpl within an interrupt is paired and
>     thus from the point of view of mainline code the cpl does not change
>     at all (i.e. s = splvm(); ... splx(s);), I don't see why the cpl needs 
>     to be locked at all.  We shouldn't even need to use a 'lock' prefix.
> 
>     Now, I understand that we eventually want to get out from under the MP
>     lock's thumb, but it needs to be pointed out that the cpl mechanism
>     itself is likely to be depreciated in favor of something more 
>     thread-friendly.  I don't see any point in trying to make the cpl
>     operate independantly of the MP lock at this time.
> 
>     Does anyone know why all the locking was added to the cpl code?

It doesn't make much sense to me either.  I spoke to Terry about
the history of the SMP work and he said that it was originally much
more thread safe and used spl as part of the subsystem locking, if
that's true then it makes sense to lock spl to realize that.

Otherwise right now your guess is as good as mine.

As a side note, it seems silly that we do this:

        MPLOCKED incl _cnt+V_SYSCALL
        SYSCALL_LOCK
        call    _syscall

I think per-cpu statistics would be an interesting optimization,
since you're testing all of this, have you been able to measure
the getuid() loop with and without this (MPLOCKED incl _cnt+V_SYSCALL),
especially with 2 processes doing a getuid() loop?

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25 13:14:12 2000
Delivered-To: freebsd-current@freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
	by hub.freebsd.org (Postfix) with ESMTP
	id 3996B37B91A; Sat, 25 Mar 2000 13:14:10 -0800 (PST)
	(envelope-from kris@FreeBSD.org)
Received: from localhost (kris@localhost)
	by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id NAA86730;
	Sat, 25 Mar 2000 13:14:10 -0800 (PST)
	(envelope-from kris@FreeBSD.org)
X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs
Date: Sat, 25 Mar 2000 13:14:09 -0800 (PST)
From: Kris Kennaway <kris@FreeBSD.org>
To: Maxim Kolinko <maxkol@viaduk.net>
Cc: freebsd-current@freebsd.org
Subject: Re: 2.2.8 to 4.0 upgrade
In-Reply-To: <Pine.BSF.4.21.0003251620510.28973-100000@res>
Message-ID: <Pine.BSF.4.21.0003251312320.84252-100000@freefall.freebsd.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Sat, 25 Mar 2000, Maxim Kolinko wrote:

> 
> how to upgrade 2.2.8-STABLE to 4.0-STABLE ?
> 

1) Do a binary upgrade. This will be *by far* the easiest for you
2) Upgrade to 3.2-RELEASE, then upgrade to 4.0-STABLE for the 3->4 upgrade
be sure to follow all the steps listed in /usr/src/UPDATING, closely)

Kris



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25 14:11:42 2000
Delivered-To: freebsd-current@freebsd.org
Received: from dt051n0b.san.rr.com (dt051n0b.san.rr.com [204.210.32.11])
	by hub.freebsd.org (Postfix) with ESMTP id 9B13637B8FE
	for <freebsd-current@FreeBSD.ORG>; Sat, 25 Mar 2000 14:11:38 -0800 (PST)
	(envelope-from Doug@gorean.org)
Received: from gorean.org (master [10.0.0.2])
	by dt051n0b.san.rr.com (8.9.3/8.9.3) with ESMTP id OAA06424;
	Sat, 25 Mar 2000 14:11:19 -0800 (PST)
	(envelope-from Doug@gorean.org)
Message-ID: <38DD3986.6316C100@gorean.org>
Date: Sat, 25 Mar 2000 14:11:18 -0800
From: Doug Barton <Doug@gorean.org>
Organization: Triborough Bridge & Tunnel Authority
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Warner Losh <imp@village.org>
Cc: Jeroen Ruigrok van der Werven <asmodai@bart.nl>,
	Brad Knowles <blk@skynet.be>,
	FreeBSD-CURRENT Mailing List <freebsd-current@FreeBSD.ORG>
Subject: Re: Accessing FreeBSD 3.4-STABLE filesystems from 4.0-STABLE...
References: <20000325162012.B62552@lucifer.bart.nl>  <v04220816b501cd2c0970@[194.78.234.186]> <200003252040.NAA73491@harmony.village.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Warner Losh wrote:
> 
> In message <20000325162012.B62552@lucifer.bart.nl> Jeroen Ruigrok van der Werven writes:
> : Block/character device collapsing breaking you up now?
> :
> : /dev/ Should only be character devices now.
> 
> I was surprised how many block devices were in my /dev when I did a ls
> -l /dev | grep ^b.
> 
> Maybe we should put something in /etc/daily in -current to whine about
> all block devices in /dev :-)

	Well, there is a message in the boot scroll, but if you use a splash
screen you'll miss it (like I did until I started doing some boot debugging
recently). I was also pretty shocked at how much cruft I had. I took the
extreme route of 'rm *' and started from the beginning again. 

Doug
-- 
    "So, the cows were part of a dream that dreamed itself into
existence? Is that possible?" asked the student incredulously.
    The master simply replied, "Mu."


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25 15: 8:59 2000
Delivered-To: freebsd-current@freebsd.org
Received: from sabre.velocet.net (sabre.velocet.net [198.96.118.66])
	by hub.freebsd.org (Postfix) with ESMTP
	id A0E8437B8AA; Sat, 25 Mar 2000 15:08:52 -0800 (PST)
	(envelope-from dgilbert@office.tor.velocet.net)
Received: from office.tor.velocet.net (trooper.velocet.net [216.126.82.226])
	by sabre.velocet.net (Postfix) with ESMTP
	id C9CB2137FB3; Sat, 25 Mar 2000 18:08:50 -0500 (EST)
Received: (from dgilbert@localhost)
	by office.tor.velocet.net (8.9.3/8.9.3) id SAA09328;
	Sat, 25 Mar 2000 18:08:50 -0500 (EST)
	(envelope-from dgilbert)
From: David Gilbert <dgilbert@velocet.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14557.18178.239025.747850@trooper.velocet.net>
Date: Sat, 25 Mar 2000 18:08:50 -0500 (EST)
To: freebsd-current@freebsd.org, freebsd-scsi@freebsd.org
Subject: MegaRAID jiggles clock?
X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs  Lucid
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

I'm wondering if the AMI MegaRAID controller/driver might be the
reason that I'm getting a large number of clock resets from ntpd.
About every half hour, ntpd seems to feel the need to reset the clock
on the server by about 1/3 of a second.  The server has a moderate NFS 
load (going out through 12 dc interfaces) and an AMI MegaRAID 1400
controller with 8 disks in a RAID-5 config.

I have other servers with 12 dc ports, and havn't seen any
particularly bad time performance from them, which is why I'm
suspicious of the megaraid.  This machine is also using a motherboard
common to many of our other machines.  None of our other servers (we
have a "ring" of 5 time servers to which all our internal hosts
connect) or clients appear to have any issues.

I have considered setting the option on ntpd to only adjust time by
adjusting the frequency ... to see if this is just a bogon clock chip
or somesuch.

ideas?

Dave.

-- 
============================================================================
|David Gilbert, Velocet Communications.       | Two things can only be     |
|Mail:       dgilbert@velocet.net             |  equal if and only if they |
|http://www.velocet.net/~dgilbert             |   are precisely opposite.  |
=========================================================GLO================


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25 15:39:21 2000
Delivered-To: freebsd-current@freebsd.org
Received: from celery.dragondata.com (celery.dragondata.com [205.253.12.6])
	by hub.freebsd.org (Postfix) with ESMTP
	id D794937B50B; Sat, 25 Mar 2000 15:39:10 -0800 (PST)
	(envelope-from toasty@celery.dragondata.com)
Received: (from toasty@localhost)
	by celery.dragondata.com (8.9.3/8.9.3) id RAA55426;
	Sat, 25 Mar 2000 17:39:02 -0600 (CST)
	(envelope-from toasty)
From: Kevin Day <toasty@dragondata.com>
Message-Id: <200003252339.RAA55426@celery.dragondata.com>
Subject: Re: MegaRAID jiggles clock?
To: dgilbert@velocet.ca (David Gilbert)
Date: Sat, 25 Mar 2000 17:39:01 -0600 (CST)
Cc: freebsd-current@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG
In-Reply-To: <14557.18178.239025.747850@trooper.velocet.net> from "David Gilbert" at Mar 25, 2000 06:08:50 PM
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> 
> I'm wondering if the AMI MegaRAID controller/driver might be the
> reason that I'm getting a large number of clock resets from ntpd.
> About every half hour, ntpd seems to feel the need to reset the clock
> on the server by about 1/3 of a second.  The server has a moderate NFS 
> load (going out through 12 dc interfaces) and an AMI MegaRAID 1400
> controller with 8 disks in a RAID-5 config.
> 
> I have other servers with 12 dc ports, and havn't seen any
> particularly bad time performance from them, which is why I'm
> suspicious of the megaraid.  This machine is also using a motherboard
> common to many of our other machines.  None of our other servers (we
> have a "ring" of 5 time servers to which all our internal hosts
> connect) or clients appear to have any issues.
> 
> I have considered setting the option on ntpd to only adjust time by
> adjusting the frequency ... to see if this is just a bogon clock chip
> or somesuch.
> 
> ideas?
> 
> Dave.
> 

Granted, this is an old 4.0-current machine(from around September), but....
I've seen heavy NFS server load affect the clocks on all three of my NFS
servers. The heavier the load, the faster the clock seems to run.

Mar 25 10:00:01 nfs ntpdate[75363]: adjust time server 192.160.127.90 offset -0.028636
Mar 25 11:00:02 nfs ntpdate[75406]: adjust time server 192.160.127.90 offset -0.033046
Mar 25 12:00:01 nfs ntpdate[75448]: adjust time server 192.160.127.90 offset -0.031371
Mar 25 13:00:01 nfs ntpdate[75490]: adjust time server 192.160.127.90 offset -0.030030
Mar 25 14:00:01 nfs ntpdate[75532]: adjust time server 192.160.127.90 offset -0.031346
Mar 25 15:00:00 nfs ntpdate[75573]: adjust time server 192.160.127.90 offset -0.030992
Mar 25 16:00:00 nfs ntpdate[75616]: adjust time server 192.160.127.90 offset -0.031654
Mar 25 17:00:00 nfs ntpdate[75657]: adjust time server 192.160.127.90 offset -0.031354

Because my NFS load isn't consistant throughout the day, xntpd seems to
really freak out about trying to keep it balanced. 

Relevant info:


Timecounter "i8254"  frequency 1193182 Hz
Timecounter "TSC"  frequency 337194185 Hz
CPU: AMD-K6(tm) 3D processor (337.19-MHz 586-class CPU)
  Origin = "AuthenticAMD"  Id = 0x580  Stepping = 0
  Features=0x8001bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX>
  AMD Features=0x80000800<SYSCALL,3DNow!>
real memory  = 134217728 (131072K bytes)
avail memory = 126246912 (123288K bytes)
vinum: loaded
npx0: <math processor> on motherboard
npx0: INT 16 interface
pcib0: <AcerLabs M1541 (Aladdin-V) PCI host bridge> on motherboard
pci0: <PCI bus> on pcib0
pcib1: <AcerLabs M5243 PCI-PCI bridge> at device 1.0 on pci0
pci1: <PCI bus> on pcib1
isab0: <AcerLabs M1533 portable PCI-ISA bridge> at device 7.0 on pci0
isa0: <ISA bus> on isab0
fxp0: <Intel EtherExpress Pro 10/100B Ethernet> irq 11 at device 14.0 on pci0
fxp0: Ethernet address 00:90:27:34:c1:ec
ata-pci0: <AcerLabs Aladdin IDE controller> irq 0 at device 15.0 on pci0
ata-pci0: Busmastering DMA supported
ata0 at 0x01f0 irq 14 on ata-pci0
ata1 at 0x0170 irq 15 on ata-pci0
vga-pci0: <ATI model 4750 graphics accelerator> at device 16.0 on pci0
pn0: <82c169 PNIC 10/100BaseTX> irq 10 at device 18.0 on pci0
pn0: Ethernet address: 00:a0:cc:3e:c6:3d
pn0: autoneg complete, link status good (full-duplex, 100Mbps)
ahc0: <Adaptec 2940A Ultra SCSI adapter> irq 9 at device 20.0 on pci0
ahc0: aic7860 Single Channel A, SCSI Id=7, 3/255 SCBs
ata0: master: setting up UDMA2 mode on Aladdin chip OK


-- Kevin



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25 15:46:32 2000
Delivered-To: freebsd-current@freebsd.org
Received: from sabre.velocet.net (sabre.velocet.net [198.96.118.66])
	by hub.freebsd.org (Postfix) with ESMTP
	id 0564C37B533; Sat, 25 Mar 2000 15:46:25 -0800 (PST)
	(envelope-from dgilbert@office.tor.velocet.net)
Received: from office.tor.velocet.net (trooper.velocet.net [216.126.82.226])
	by sabre.velocet.net (Postfix) with ESMTP
	id 2D0F3137FB5; Sat, 25 Mar 2000 18:45:46 -0500 (EST)
Received: (from dgilbert@localhost)
	by office.tor.velocet.net (8.9.3/8.9.3) id SAA12320;
	Sat, 25 Mar 2000 18:45:46 -0500 (EST)
	(envelope-from dgilbert)
From: David Gilbert <dgilbert@velocet.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14557.20394.91811.148485@trooper.velocet.net>
Date: Sat, 25 Mar 2000 18:45:46 -0500 (EST)
To: Kevin Day <toasty@dragondata.com>
Cc: dgilbert@velocet.ca (David Gilbert), freebsd-current@FreeBSD.ORG,
	freebsd-scsi@FreeBSD.ORG
Subject: Re: MegaRAID jiggles clock?
In-Reply-To: <200003252339.RAA55426@celery.dragondata.com>
References: <14557.18178.239025.747850@trooper.velocet.net>
	<200003252339.RAA55426@celery.dragondata.com>
X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs  Lucid
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

>>>>> "Kevin" == Kevin Day <toasty@dragondata.com> writes:

[about clock jiggling]

Kevin> Granted, this is an old 4.0-current machine(from around
Kevin> September), but....  I've seen heavy NFS server load affect the
Kevin> clocks on all three of my NFS servers. The heavier the load,
Kevin> the faster the clock seems to run.

Kevin> Mar 25 10:00:01 nfs ntpdate[75363]: adjust time server
Kevin> 192.160.127.90 offset -0.028636

Mmm.... but that adjustment is 10x smaller than mine:

Mar 25 16:53:29 raid1 xntpd[19242]: time reset (step) -0.340983 s

Dave.

-- 
============================================================================
|David Gilbert, Velocet Communications.       | Two things can only be     |
|Mail:       dgilbert@velocet.net             |  equal if and only if they |
|http://www.velocet.net/~dgilbert             |   are precisely opposite.  |
=========================================================GLO================


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25 16:39:17 2000
Delivered-To: freebsd-current@freebsd.org
Received: from trinity.skynet.be (trinity.skynet.be [195.238.2.38])
	by hub.freebsd.org (Postfix) with ESMTP id 4478F37B9F2
	for <freebsd-current@freebsd.org>; Sat, 25 Mar 2000 16:39:11 -0800 (PST)
	(envelope-from blk@skynet.be)
Received: from [195.238.19.160] (dialup160.brussels.skynet.be [195.238.19.160])
	by trinity.skynet.be (Postfix) with ESMTP
	id A97F318423; Sun, 26 Mar 2000 01:39:05 +0100 (MET)
Mime-Version: 1.0
X-Sender: blk@pop.skynet.be
Message-Id: <v04220808b5030b297e83@[195.238.19.160]>
In-Reply-To: <200003260018.KAA07524@shad.internal.en-bio>
References: <200003260018.KAA07524@shad.internal.en-bio>
Date: Sun, 26 Mar 2000 01:38:48 +0100
To: Tony Maher <Tony.Maher@eBioinformatics.com>
From: Brad Knowles <blk@skynet.be>
Subject: Re: Accessing FreeBSD 3.4-STABLE filesystems from
 4.0-STABLE...
Cc: FreeBSD-CURRENT Mailing List <freebsd-current@freebsd.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

At 10:18 AM +1000 2000/3/26, Tony Maher wrote:

>  No, sd is deprecated.
>  AFAIK its da only in 4.0, and only character devices.
>  3.4 has sd compatability and has block devices.

	Hmm.  Okay, well I note that what's being used right now is 
da1s1a through da1s1h, and I had copied these entries as appropriate 
for da0.  Only, they didn't work.  Yes, I did check the device 
entries for da0s1a through da0s1h, and they do exist and appear to be 
correct.

	When I try to mount my 3.4-STABLE root filesystem on /old, here's 
what I get:

		$ mount /old
		mount: /dev/da0s1a on /old: incorrect super block


	Perhaps a listing of the devices would be useful:

$ ls -la /dev/da[01]s1?
crw-r-----  1 root  operator   13, 0x00020000 Mar 20 09:38 /dev/da0s1a
crw-r-----  1 root  operator   13, 0x00020001 Mar 20 09:38 /dev/da0s1b
crw-r-----  1 root  operator   13, 0x00020002 Mar 20 09:38 /dev/da0s1c
crw-r-----  1 root  operator   13, 0x00020003 Mar 20 09:38 /dev/da0s1d
crw-r-----  1 root  operator   13, 0x00020004 Mar 20 09:38 /dev/da0s1e
crw-r-----  1 root  operator   13, 0x00020005 Mar 20 09:38 /dev/da0s1f
crw-r-----  1 root  operator   13, 0x00020006 Mar 20 09:38 /dev/da0s1g
crw-r-----  1 root  operator   13, 0x00020007 Mar 20 09:38 /dev/da0s1h
crw-r-----  1 root  operator   13, 0x00020008 Mar 18 21:45 /dev/da1s1a
crw-r-----  1 root  operator   13, 0x00020009 Mar 18 21:45 /dev/da1s1b
crw-r-----  1 root  operator   13, 0x0002000a Mar 18 21:45 /dev/da1s1c
crw-r-----  1 root  operator   13, 0x0002000b Mar 18 21:45 /dev/da1s1d
crw-r-----  1 root  operator   13, 0x0002000c Mar 18 21:45 /dev/da1s1e
crw-r-----  1 root  operator   13, 0x0002000d Mar 18 21:45 /dev/da1s1f
crw-r-----  1 root  operator   13, 0x0002000e Mar 23 12:34 /dev/da1s1g
crw-r-----  1 root  operator   13, 0x0002000f Mar 18 21:45 /dev/da1s1h


	Anyone got any other advice, or is there any other information I 
need to provide?  Thanks!

--
   These are my opinions -- not to be taken as official Skynet policy
======================================================================
Brad Knowles, <blk@skynet.be>                || 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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25 18:23: 6 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id A0C6237B7F7
	for <freebsd-current@FreeBSD.ORG>; Sat, 25 Mar 2000 18:23:02 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id SAA26218;
	Sat, 25 Mar 2000 18:23:01 -0800 (PST)
	(envelope-from dillon)
Date: Sat, 25 Mar 2000 18:23:01 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003260223.SAA26218@apollo.backplane.com>
To: Alfred Perlstein <bright@wintelcom.net>
Cc: freebsd-current@FreeBSD.ORG
Subject: SMP syscall timing program (was Re: Why are all accesses to the cpl surrounded by a lock?)
References: <200003250527.VAA19096@apollo.backplane.com> <20000325130447.I21029@fw.wintelcom.net>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

:Otherwise right now your guess is as good as mine.
:
:As a side note, it seems silly that we do this:
:
:        MPLOCKED incl _cnt+V_SYSCALL
:        SYSCALL_LOCK
:        call    _syscall
:
:I think per-cpu statistics would be an interesting optimization,
:since you're testing all of this, have you been able to measure
:the getuid() loop with and without this (MPLOCKED incl _cnt+V_SYSCALL),
:especially with 2 processes doing a getuid() loop?
:
:-- 
:-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]

    Well, in my patch SYSCALL_LOCK is no longer called there so
    we can't move the incl and remove the MPLOCKED prefix.  A competing
    locked instruction costs around 200 nS.  I.E. it's expensive, which
    is why zone locks aren't a good idea and structural locks are.

    I've enclosed my syscall timing program.  I will also put it on
    my site.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>



/*
 * SMPTIME.C
 *
 *	cc smptime.c -o smptime -Wall -DOP=OPn
 *	./smptime NFORK
 *
 *	e.g.
 *
 *	cc smptime.c -o smptime -Wall -DOP=OP3
 *	./smptime 1
 *	./smptime 2
 */

#include <sys/types.h>
#include <sys/time.h>
#include <sys/mman.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <signal.h>
#include <setjmp.h>

void deltatime(struct timeval *tv1);
void FigureOutUseCount(void);

#define OP1 sigprocmask(SIG_BLOCK, &sset, &oset);
#define OP2 getpid()
#define OP3 getuid()		/* CLEAN OF MP LOCK */
#define OP4 __asm __volatile("addl $1,(%0)"::"r"(global_tmp):"memory")
#define OP5 __asm __volatile("lock; addl $1,(%0)"::"r"(global_tmp):"memory")
#define OP6
#ifndef OP
#error "Missing -DOP=OPn option to cc"
#endif

#define OPNAME(V)	#V

int *global_tmp;
int UseCount = 1;

int
main(int ac, char **av)
{
    int i;
    int count = 0;
    int nproc = 2;
    sigset_t sset;
    sigset_t oset;
    struct timeval tv1;

    if (ac == 2)
	nproc = strtol(av[1], NULL, 0);

    sigemptyset(&sset);
    sigemptyset(&oset);
    gettimeofday(&tv1, NULL);
    global_tmp = mmap(NULL, getpagesize(), PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANON, -1, 0);

    FigureOutUseCount();

    for (i = 1; i < nproc; ++i) {
	if (fork() == 0) {
	    /*
	     * child
	     */
	    for (;;) {
		OP;
	    }
	    _exit(0);
	}
    }
    /*
     * parent
     */
    for (;;) {
	OP;
	if (++count == UseCount) {
	    deltatime(&tv1);
	    count = 0;
	}
    }
    return(0);
}

void
deltatime(struct timeval *tv1)
{
    struct timeval tv2;
    int usec;

    gettimeofday(&tv2, NULL);
    usec = tv2.tv_usec + 1000000 - tv1->tv_usec + 1000000 * (tv2.tv_sec - tv1->tv_sec - 1);
    *tv1 = tv2;
    printf("%d nsec/call\n", usec / (UseCount / 1000));
}


/*
 *  Time one second's worth of loops to get a baseline.
 */

jmp_buf TimeEnv;

void
sigAlrm(int sigNo)
{
    longjmp(TimeEnv, 1);
}

void
FigureOutUseCount(void)
{
    struct itimerval it;

    bzero(&it, sizeof(it));
    it.it_value.tv_sec = 1;

    signal(SIGALRM, sigAlrm);
    setitimer(ITIMER_REAL, &it, NULL);
    if (setjmp(TimeEnv) == 0) {
	for (;;) {
	    OP;
	    ++UseCount;
	}
	/* NOT REACHED */
    }
    signal(SIGALRM, SIG_IGN);
}



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25 18:26:34 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id B5FCF37B7D4
	for <freebsd-current@FreeBSD.ORG>; Sat, 25 Mar 2000 18:26:31 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id SAA26289;
	Sat, 25 Mar 2000 18:26:28 -0800 (PST)
	(envelope-from dillon)
Date: Sat, 25 Mar 2000 18:26:28 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003260226.SAA26289@apollo.backplane.com>
To: Warner Losh <imp@village.org>
Cc: Bruce Evans <bde@zeta.org.au>, freebsd-current@FreeBSD.ORG
Subject: Re: Anyone know why the syscall interface is using the doreti mechanism? 
References: <200003251012.CAA19991@apollo.backplane.com>  <Pine.BSF.4.21.0003251654510.405-100000@alphplex.bde.org>  <200003252038.NAA73468@harmony.village.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


:
:In message <200003251012.CAA19991@apollo.backplane.com> Matthew Dillon writes:
::     It's getting clean enough that you can almost understand the interrupt 
::     code :-)
:
:Cool.  That's one part of the kernel that I've not quite fully
:understood.  I always figured there was something I was missing about
:the code and why it needed to be as complex as it was...
:
:Warner

    I think most of the complexity was due to all the conditional
    assembly.  A lot of things were tried during development and at
    some point something 'stuck' and became a working base.  Then all further
    development seemed to add complexity to do endruns around problems 
    or inefficiencies with the base piece.

    Conceptually it really isn't that big a deal.  I'll document the 
    routines more in the next patch.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25 18:49:12 2000
Delivered-To: freebsd-current@freebsd.org
Received: from ns.gaos.net (ns.gaos.net [210.226.166.226])
	by hub.freebsd.org (Postfix) with ESMTP
	id 1D6F237B81B; Sat, 25 Mar 2000 18:48:50 -0800 (PST)
	(envelope-from esuemu@feel.to)
Received: from gera13 ([210.254.163.69] (may be forged))
          by ns.gaos.net (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
	  id LAA01402; Sun, 26 Mar 2000 11:31:32 +0900
Message-ID: <009f01a92a81$a87de700$050aa8c0@geragera.com>
From: "esuemu" <esuemu@feel.to>
To: <Undisclosed-Recipient:;@ns.gaos.net;>
Subject: =?iso-2022-jp?B?GyRCO1hEaiROPXdALSFKQ04/TUV5IUskTiNBI1YkckwpJCskSzsjGyhC?=
	=?iso-2022-jp?B?GyRCMUYkNyReJDkbKEI=?=
Date: Wed, 26 Mar 1980 11:08:21 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

$B!J=>Mh>R2p@)$G9T$C$F$$$?%5!<%S%9$r;n83E*$KEE;R(BDM$B$G$40FFb$7$F$$$^$9!#(B
$B<uIU=*N;8e!":F<uIU3+;O$40FFb$N$*LsB+$J$I$O$G$-$^$;$s$N$G$4N;>5$/$@$5$$!K(B

$B$"$J$?$N;XDj$7$?=w@-$KBP$7$F0MMj$rIz$;$?$^$^%"%@%k%H%S%G%*=P1i$r8r>D!&;#1F$7(B
$B$^$9!#(B
$BCOJ}$b2D!#7W#3L>$^$GJd7g;XDj$b$G$-$^$9!#;#1F8e$N%^%9%?!<%F!<%W$O$*0zEO$7$7$^(B
$B$9!#(B

$B!|%S%G%*$K$D$$$F$O0J2<$NDL$j$G$9!#(B
$B!&0aAu$O;XL>$N:]$KA*Br$G$-$^$9!J%\%s%G!<%8!"4G8nIX!"%9%A%e%o!<%G%9!"%;!<(B
$B%i!<!K!#(B
$B!&40@.HG$O!"I}#8%;%s%ADxEY$N%"%$%^%9%/CeMQ$G$9$,!"0MMj<T$K$O%^%9%/CeC&A08e$N(B
$B1GA|$r1#$7;#$j$7$?$b$N$r$*IU$1$7$F$*FO$1$7$^$9!#(B
$B!&FbMF$O!"6[G{$N>e!"@e!"<j!"%P%$%VEy$G6;$d6IIt1d!9$H@U$a$k$b$N$G!"CK@-@-4o$H(B
$B$N@\?($O0l@Z$"$j$^$;$s!#(B
$B!&>e#2E@$O0lHL$N#A#V$KHf$Y$F$b%=%U%H$J>r7o$G$9$,!"$^$C$?$/$NAG?M$K=P1i8r>D$9(B
$B$k:]$N%-!<%]%$%s%H$G$9$N$G$4N;>5$/$@$5$$!#(B
$B!&;#1FJ*$O#4?MJ,$:$D$^$H$a$F#3#0#0K\DxEY!"2q0w@)DL?.HNGd$5$l$^$9!#(B
$BE9F,$KJB$s$@$j!"1GA|$N0lIt$,;(;o$J$I$K:\$k$3$H$O@dBP$"$j$^$;$s!#(B
$B!|0MMj<T$N$"$J$?$+$i$O!";XL>NA$H$7$F7W#1#0K|1_$r>5$j$^$9!#(B
$B!&$?$@$7!"COJ}!JBP>]<T$N=;=j!&DL6PDL3X@h$N$$$:$l$+$,4XEl#1ET#68)!&;3M|$N>l9g(B
$B0J30!K$N>l9g#1#5K|1_$H$J$j$^$9!#(B
$BDI2CNA6b$O$3$l0J300l@Z$"$j$^$;$s!#(B
$B!&$&$A#5K|1_$OA0G<!JCOJ}$bF1!K$G!"K|0l8r>D$K<:GT$7$?>l9g$O4JC1$J8r>D7P2a%j(B
$B%]!<%H$r$D$1$FA43[JV6b$7$^$9!#(B
$B!|=>Mh<B@S$G$O8r>D$N@.8yN($O#83d$G$9!#(B
$B!&6bA,>r7o$@$1$G$J$/FH<+$N%N%&%O%&$G8r>D$7$^$9$N$G!"7P:QE*$KIT<+M3$N$J$$=w(B
$B@-!"7x$$;E;v$N=w@-!"?M:J$G$b$5$[$I@.8yN($O2<$,$j$^$;$s!#(B
$B!J$?$@$7!"K=NO$J$I0cK!$J8r>D<jCJ$O0l@Z<h$j$^$;$s$7!"$=$&$7$?9T0Y$rA0Ds$K8r>D(B
$B@.8y$rC4J]$9$k$40MMj$K$b1~$8$i$l$^$;$s!K(B
$B!&M%@h=g0L$r$D$1$F#3L>$^$GF1;~;XL>$r$*<u$1$G$-$^$9$,!"A40wF1;~$K8r>D4uK>$N>l(B
$B9g$ONA6b$,?M?tJ,$H$J$j$^$9!#(B
$B!|A06bF~6b8e#1%v7n0JFb$K;#1F$r=*$(!"JT=8A0AG:`1GA|$9$Y$F!J#S!]#V#H#S%*%j%8%J(B
$B%k$*$h$S%N!<%^%k#V#H#S%@%S%s%0$NN>%P!<%8%g%s!"3F#6#0J,DxEY!!;#1F$7$?$=$N$^$^(B
$B$N>uBV$G$9!K$r$*Aw$j$7$^$9!#(B
$B!&<uNN8e#2=54V0JFb$K8e6b$rF~6b$7$FD:$-$^$9!#(B
$B!&;XL>0MMj$N;v<B$O0l@ZBP>]<T$K$O$*65$($7$^$;$s$7!"0MMj<T$N?H85$b;G$$$^$;$s(B
$B$,!"1GA|$r8x3+$7$?$j6<Gw$KMQ$$$k$3$H$O@dBP$K$7$J$$$G$/$@$5$$!#(B
$B!&%F!<%W$O!"=;=j;XL>$r$*J9$-$7$J$$$^$^6IN1$a$G$*Aw$j$7$^$9!J>\$7$/$O$=$N:]O"(B
$BMm!K!#(B
$B!&BP>]<T$K$D$$$F$O!"9qFb:_=;$N#1#8:P0J>e#5#0:P0J2<(B($B@53N$JG/NpITL@$G$b2D!K$N(B
$B=w@-$G!"7Y;!4X78<T!"M-L>?M$O$*0z$-<u$1$G$-$^$;$s!#(B
$B!&0MMj<T$K$D$$$F$O@-JL$b$U$/$aITLd$G$9$,!"EvA3#1#8:PL$K~$O$41sN8$/$@$5$$!#(B
$B!&BP>]<T$K$D$$$F$O!"<+Bp=;=j$J$I$,$o$+$i$J$$>l9g!"K\?M$rFCDj$G$-$k:GDc8B$N(B
$B%G!<%?!J@+$H?&>l$J$I!K$O$4MQ0U$/$@$5$$!#(B

$B"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#(B
$B:#2sA06bF~6b$H$$$&7A$G$N$_0MMj$r$*<u$1$7!"$3$A$i$+$i%a!<%kO"Mm$7$^$9!#!!!!!!(B
$B!!!!!!(B
$BK\%a!<%k$X$NJV?.$OL58z$H$J$k>l9g$,$"$j$^$9!#(B
$BF~6b8e#3F|7P2a$7$FO"Mm$rF@$i$l$J$$J}!"Dy@ZD62a8e$N<uIU$N2DH]$r3NG'$J$5$j$?$$(B
$BJ}$O2<5-6[5^O"Mm@h$K%"%I%l%9$r$*CN$i$;$/$@$5$$!JD>@\<ALd$O$*<u$1$G$-$^$;(B
$B$s!K!#(B
090-811-31410$B!JN1<iEE(B24$B;~4V<uIU!K$^$?$O!!(B03-5459-6897
$BEl5~ETK-Eg6h@>CSB^(B1-29-14$B!!%*%U%#%9!!%(%9!!%"%s%I!!%(%`!!KL;30+(B
$B"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#"#(B

$B!|;XL>0MMj4uK>$NJ}$O!"$^$:%[%C%H%a!<%k(Bhttp://www.hotmail.co.jp/
$B$GO"MmMQ$N%a!<%k%"%I%l%9$r<hF@$7$F$/$@$5$$!#(B
$BB(;~H/9T$5$l!"Aw<u?.$b$U$/$a$9$Y$F%[!<%`%Z!<%8>e$G=hM}$5$l$^$9$N$G!"%a!<%k%=(B
$B%U%H$r@_Dj$7D>$9I,MW$O$"$j$^$;$s!#(B
$B<!$K!"=;M'6d9TCSB^;YE9!!IaDL(B2417496$B!!%-%?%d%^!&%"%+%M$"$F$KA06b$rEE?.?69~$7(B
$B$F$/$@$5$$!#(B
$B!&$=$N:]!"?69~?ML>5A$K>e$N%a!<%k%"%I%l%9$N(B@$B$NA0$NItJ,$r!JBgJ8;z$KJQ$($F$b(B
$B2D!K$r5-$7$F$/$@$5$$!#(B
  $BNc!!(Byamada@hotmail.com$B$N>l9g(B    $B#Y#A#M#A#D#A(B
$B!&@^$jJV$75-F~$N%"%I%l%9$K$3$A$i$+$iO"Mm$$$?$7$^$9$N$G!";XL>BP>]<T$H0aAu;XDj(B
$B$r$*65$($/$@$5$$!#(B

$B!|Dy$a@Z$j!JD>@\<uIU4|4V!K$O:#2s!"K\%a!<%kH/?.8e#2F|0JFb!JH/?.F|$*$h$SEZF|:W(B
$BF|$O=|$/!K$H$7$^$9!#(B
$B$=$l0J9_$OD>@\F~6b$;$:$K!">e5-O"Mm@h$K%a!<%k%"%I%l%9$rEA$($F<uIU$N2DH]$r$43N(B
$BG'$/$@$5$$!#(B





To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25 19:34:12 2000
Delivered-To: freebsd-current@freebsd.org
Received: from dt051n0b.san.rr.com (dt051n0b.san.rr.com [204.210.32.11])
	by hub.freebsd.org (Postfix) with ESMTP id 645C937B879
	for <freebsd-current@freebsd.org>; Sat, 25 Mar 2000 19:34:09 -0800 (PST)
	(envelope-from Doug@gorean.org)
Received: from gorean.org (doug@master [10.0.0.2])
	by dt051n0b.san.rr.com (8.9.3/8.9.3) with ESMTP id TAA08193;
	Sat, 25 Mar 2000 19:33:58 -0800 (PST)
	(envelope-from Doug@gorean.org)
Message-ID: <38DD8526.572973B6@gorean.org>
Date: Sat, 25 Mar 2000 19:33:58 -0800
From: Doug Barton <Doug@gorean.org>
Organization: Triborough Bridge & Tunnel Authority
X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 5.0-CURRENT-0322 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Brad Knowles <blk@skynet.be>
Cc: Tony Maher <Tony.Maher@eBioinformatics.com>,
	FreeBSD-CURRENT Mailing List <freebsd-current@freebsd.org>
Subject: Re: Accessing FreeBSD 3.4-STABLE filesystems from4.0-STABLE...
References: <200003260018.KAA07524@shad.internal.en-bio> <v04220808b5030b297e83@[195.238.19.160]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Brad Knowles wrote:

>         When I try to mount my 3.4-STABLE root filesystem on /old, here's
> what I get:
> 
>                 $ mount /old
>                 mount: /dev/da0s1a on /old: incorrect super block

	'fsck -y /dev/da0s1a'

-- 
    "So, the cows were part of a dream that dreamed itself into
existence? Is that possible?" asked the student incredulously.
    The master simply replied, "Mu."


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25 19:53:11 2000
Delivered-To: freebsd-current@freebsd.org
Received: from cs.rice.edu (cs.rice.edu [128.42.1.30])
	by hub.freebsd.org (Postfix) with ESMTP
	id CE54A37B83A; Sat, 25 Mar 2000 19:53:01 -0800 (PST)
	(envelope-from aron@cs.rice.edu)
Received: (from aron@localhost)
	by cs.rice.edu (8.9.0/8.9.0) id VAA04089;
	Sat, 25 Mar 2000 21:53:00 -0600 (CST)
From: Mohit Aron <aron@cs.rice.edu>
Message-Id: <200003260353.VAA04089@cs.rice.edu>
Subject: emacs-20.6 core dumps in FreeBSD-4.0-RELEASE
To: freebsd-bugs@freebsd.org
Date: Sat, 25 Mar 2000 21:53:00 -0600 (CST)
Cc: freebsd-current@freebsd.org
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Hi,
	I installed the package for emacs-20.6 on my machine running 
FreeBSD-4.0-RELEASE and it core dumps upon issuing the command 'emacs -nw'. 
This package was obtained from:

     ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/4.0-RELEASE/packages/All/emacs-20.6.tgz


However, it runs fine if I instead install the package from:
     ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/3.4-STABLE/packages/All/emacs-20.6.tgz


The difference between the above two packages seems to be that the former
links against libc.so.4 while the latter links against libc.so.3 (in
/usr/lib/compat). It seems that libc.so.4 in FreeBSD-4.0-RELEASE has some bugs.

I also downloaded emacs-20.6 from: 
  ftp://ftp.gnu.org/pub/gnu/emacs/emacs-20.6.tar.gz
and compiled it. It has the same 'core dump' problem - it also links against
libc.so.4.

Here's the output of 'uname -a' for my machine:

FreeBSD luzern.cs.rice.edu 4.0-RELEASE FreeBSD 4.0-RELEASE #0: Thu Mar 16
19:14:31 CST 2000     aron@luzern.cs.rice.edu:/usr/src/sys/compile/LUZERN  i386


- Mohit


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25 20: 7:50 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP id CDFE737B986
	for <freebsd-current@FreeBSD.ORG>; Sat, 25 Mar 2000 20:07:43 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id UAA26945;
	Sat, 25 Mar 2000 20:07:34 -0800 (PST)
	(envelope-from dillon)
Date: Sat, 25 Mar 2000 20:07:34 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003260407.UAA26945@apollo.backplane.com>
To: Bruce Evans <bde@zeta.org.au>
Cc: freebsd-current@FreeBSD.ORG
Subject: smp-patch-06 (hopefully w/ proper syscall return handling) ready
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

    smp-patch-06 is now ready. 

	http://www.backplane.com/FreeBSD4/
	http://www.backplane.com/FreeBSD4/smp-patch-06.diff

    Bruce, I'd appreciate a quick review of my solution to the AST issue.
    Search for 'syscall_ast_exit' in i386/i386/exception.s after patching.

    I moved astpending to the per-cpu structure and made it a u_int.  I then
    test it in the syscall code and, if non-zero, it obtains the MP lock,
    pushes the dummy state, and jumps to _doreti.

    (This patch also adds lots of comments to the assembly).

    I am also in need of some C code to test it.  I *think* the below code
    will test it, but I'm not sure.  Bruce?

							-Matt

#include <sys/types.h>
#include <sys/errno.h>

#include <stdio.h>
#include <unistd.h>
#include <signal.h>

int
main(int ac, char **av)
{
    signal(SIGALRM, (void *)-1);
    alarm(1);
    for (;;)
        ;
}




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25 20:37:22 2000
Delivered-To: freebsd-current@freebsd.org
Received: from neodymium.btinternet.com (neodymium.btinternet.com [194.73.73.83])
	by hub.freebsd.org (Postfix) with ESMTP id 576F637B90D
	for <freebsd-current@freebsd.org>; Sat, 25 Mar 2000 20:37:17 -0800 (PST)
	(envelope-from mark@ukug.uk.freebsd.org)
Received: from [62.6.97.205] (helo=parish.my.domain)
	by ruthenium.btinternet.com with esmtp (Exim 2.05 #1)
	id 12Yzx9-0000KR-00; Sat, 25 Mar 2000 23:26:48 +0000
Received: (from mark@localhost)
	by parish.my.domain (8.9.3/8.9.3) id XAA01363;
	Sat, 25 Mar 2000 23:24:21 GMT
	(envelope-from mark)
Date: Sat, 25 Mar 2000 23:24:20 +0000
From: Mark Ovens <mark@ukug.uk.freebsd.org>
To: Warner Losh <imp@village.org>
Cc: Jeroen Ruigrok van der Werven <asmodai@bart.nl>,
	Brad Knowles <blk@skynet.be>,
	FreeBSD-CURRENT Mailing List <freebsd-current@freebsd.org>
Subject: Re: Accessing FreeBSD 3.4-STABLE filesystems from 4.0-STABLE...
Message-ID: <20000325232420.F234@parish>
References: <20000325162012.B62552@lucifer.bart.nl> <v04220816b501cd2c0970@[194.78.234.186]> <20000325162012.B62552@lucifer.bart.nl> <200003252040.NAA73491@harmony.village.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <200003252040.NAA73491@harmony.village.org>; from imp@village.org on Sat, Mar 25, 2000 at 01:40:05PM -0700
Organization: Total lack of
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Sat, Mar 25, 2000 at 01:40:05PM -0700, Warner Losh wrote:
> In message <20000325162012.B62552@lucifer.bart.nl> Jeroen Ruigrok van der Werven writes:
> : Block/character device collapsing breaking you up now?
> : 
> : /dev/ Should only be character devices now.
> 
> I was surprised how many block devices were in my /dev when I did a ls
> -l /dev | grep ^b.
> 
> Maybe we should put something in /etc/daily in -current to whine about
> all block devices in /dev :-)
> 

At a slight tangent; could removal of block devices be the cause of
this message when starting the ddd debugger?

gdb: warning: cannot set file to non-blocking mode: Resource
temporarily unavailable

and when exiting:

gdb: warning: cannot restore file mode: Resource temporarily unavailable

Possibly trying to set a device (the pipe?) to non-blocking when it
already is?

> Warner
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message

-- 
Seminars, n.:
       From "semi" and "arse", hence, any half-assed discussion.
________________________________________________________________
      FreeBSD - The Power To Serve http://www.freebsd.org
      My Webpage http://ukug.uk.freebsd.org/~mark/
mailto:mark@ukug.uk.freebsd.org             http://www.radan.com



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message


From owner-freebsd-current  Sat Mar 25 22:46:28 2000
Delivered-To: freebsd-current@freebsd.org
Received: from bilby.prth.tensor.pgs.com (bilby.prth.tensor.pgs.com [157.147.232.237])
	by hub.freebsd.org (Postfix) with ESMTP id C144237B91A
	for <current@freebsd.org>; Sat, 25 Mar 2000 22:46:16 -0800 (PST)
	(envelope-from shocking@bandicoot.prth.tensor.pgs.com)
Received: from bandicoot.prth.tensor.pgs.com (bandicoot.prth.tensor.pgs.com [157.147.224.1])
	by bilby.prth.tensor.pgs.com (8.9.3/8.8.8) with ESMTP id OAA28475
	for <current@freebsd.org>; Sun, 26 Mar 2000 14:44:01 +0800 (WST)
Received: from ariadne.prth.tensor.pgs.com (ariadne [157.147.227.36])
	by bandicoot.prth.tensor.pgs.com (8.9.3/8.8.8) with ESMTP id OAA12490
	for <current@freebsd.org>; Sun, 26 Mar 2000 14:46:10 +0800 (WST)
From: Stephen Hocking-Senior Programmer PGS SPS Perth <shocking@prth.pgs.com>
Received: (from shocking@localhost)
	by ariadne.prth.tensor.pgs.com (8.9.3+Sun/8.9.0) id OAA15530
	for current@freebsd.org; Sun, 26 Mar 2000 14:46:10 +0800 (WST)
Date: Sun, 26 Mar 2000 14:46:10 +0800 (WST)
Message-Id: <200003260646.OAA15530@ariadne.prth.tensor.pgs.com>
To: current@freebsd.org
Subject: Updating examples /usr/share/examples/ld
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


Can someone please update the examples in /usr/share/examples/kld?

It's a bit confusing when it doesn't even compile.


	Stephen


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message