Re: it's time...
"Matthew N. Dodd" wrote: > > Agreed. I like what I see there. Maybe it is time to hoist something > > like that into bus_subr.c > Lets define exactly what we want before we start our charge. > What should be printed? > device ID > attachment point > resource reservation > device additional > When should it be printed? > bootverbose levels? Years ago I provided diffs to the kernel boot to report some probes Before as well as after, so one could see which probe was about to hang, - more use than which probe was last to pass. Idea was rejected as some thought it was too verbose, but Nobody (me included) thought of having a bootverbose levels switch to hang on it on. ... Nice Idea ! Some Computer mags reccomend MS-* users to keep a boot flop for Linux or BSD, as we provide much more diagnostics than MS*, Before-probe-announcements would make it more valuable still. Imagine if the more competent of the MS crowd actually wanted to keep a FreeBSD boot floppy around :-) Julian Julian H. Staceyhttp://www.freebsd.org/~jhs/ Considering Linux ? Then also consider the 2000+ free packages for FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On Fri, 13 Aug 1999 09:48:47 EST, "Matt Crawford" wrote: > load kernel > load -t splash_image_data daemon_640.bmp > load vesa > load splash_bmp > boot Why boot and not autoboot? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
> Surely if you don't want to see the boot messages for cosmetic > reasons a splash screen is the most cosmeticly pleasing solution. Speaking of splash screens (a bit far from the thread's original topic), I've got my laptop set up to show the daemon-and-sunset picture on boot, but it seems I now have an extremely small window of time to press a key to get to the boot prompt. What do I need to insert to get this window back up to several seconds? My loader.rc file looks like this: \ Loader.rc \ \ Includes additional commands include /boot/loader.4th \ Reads and processes loader.rc \ start \ Unless set otherwise, autoboot is automatic at this point load kernel load -t splash_image_data daemon_640.bmp load vesa load splash_bmp boot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On 12-Aug-99 Ben Rosengart wrote: > On Wed, 11 Aug 1999, Brian F. Feldman wrote: > >> What in the world would be the point of doing this? What would be so >> great >> about not seeing the system boot up? > > One might want minimal or no boot messages, just to look nice, while > still wanting the dmesg stuff around in case something goes wrong or > they need to configure a kernel. It's certainly chrome, but I'd like > it. Surely if you don't want to see the boot messages for cosmetic reasons a splash screen is the most cosmeticly pleasing solution. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
> On Wed, 11 Aug 1999, Brian F. Feldman wrote: > > > What in the world would be the point of doing this? What would be so great > > about not seeing the system boot up? > > One might want minimal or no boot messages, just to look nice, while > still wanting the dmesg stuff around in case something goes wrong or > they need to configure a kernel. It's certainly chrome, but I'd like > it. Spash screen. That being said, the capability to have what comes out during a verbose boot go somewhere else for later review, while only the "normal" messages are seen on the console would be sorta cool. I think you could do this by converting the printf()'s in the kernel to something like syslog() with explicity verbosity/priority specifications. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On Wed, 11 Aug 1999, Brian F. Feldman wrote: > What in the world would be the point of doing this? What would be so great > about not seeing the system boot up? One might want minimal or no boot messages, just to look nice, while still wanting the dmesg stuff around in case something goes wrong or they need to configure a kernel. It's certainly chrome, but I'd like it. -- Ben UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On Wed, 11 Aug 1999, Warner Losh wrote: > In message <[EMAIL PROTECTED]> "Matthew N. >Dodd" writes: > : check out eisa_reg_print() and eisa_print_child() in > : sys/i386/eisa/eisaconf.c > : > : Sanity in output is a good thing. > > Agreed. I like what I see there. Maybe it is time to hoist something > like that into bus_subr.c Lets define exactly what we want before we start our charge. What should be printed? device ID attachment point resource reservation device additional When should it be printed? bootverbose levels? How should it printed? ???N: on ???N ... or... Since we've got things partway tied up with new_bus, maybe we should complete the job, and define a device method for printing out the device additional information so it can be dispatched from a single place. How are we going to enforce the use of this 'pretty printer'? Should we embed this logic in device_printf()? This would be practical if our goal were not only impose order on the probe/attach messages but also anything a driver printed (nothing more annoying that stray error messages for which the issuing device is unknown.) I'm not sure this is our goal at this time? Will we ever have such a goal? I see our goal as follows. 1. one unified format for devce probe/attach ammouncments. 2. the ability to control the amount of information printed during the device probe/attach. Anyhow, just trying to stir up some ideas here; please don't take any of my statements as an indication of intended course. I really don't have any good answers at this point and would like to hear the opinions of others. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
[[ cc trimmed. ]] In message <[EMAIL PROTECTED]> "Matthew N. Dodd" writes: : check out eisa_reg_print() and eisa_print_child() in : sys/i386/eisa/eisaconf.c : : Sanity in output is a good thing. Agreed. I like what I see there. Maybe it is time to hoist something like that into bus_subr.c Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On Wed, 11 Aug 1999, Brian F. Feldman wrote: > What in the world would be the point of doing this? What would be so > great about not seeing the system boot up? The same reason that when you type 'cp foo /tmp/' it doesn't say '1 file copied, 3425 bytes.' or other nonesense. If nothings wrong then print nothing. Granted, you and I would have our 'boot_verbose' envar set to '1' or '2' or something that gave us the correct amount of feedback we've grown acustom to. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On Wed, 11 Aug 1999, Warner Losh wrote: > After taking a break from this discussion, I do think that I like the > idea of wrapping boot messages in a sane way at column n (= 80 by > default) so long as one knows where messages from one device end and > the next one begin. > > I'd also oppose things like > > foo0: .. irq > foo0: 9 > > as opposed to > > foo0: .. > foo0: irq 9 > > Unless there were so many that this couldn't be avoided... check out eisa_reg_print() and eisa_print_child() in sys/i386/eisa/eisaconf.c Sanity in output is a good thing. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On Wed, 11 Aug 1999, Warner Losh wrote: > > No! At some point they should use a facility similar to solaris/sysv > where they don't display, but do make it into the dmesg buffer... > > Warner > What in the world would be the point of doing this? What would be so great about not seeing the system boot up? Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
After taking a break from this discussion, I do think that I like the idea of wrapping boot messages in a sane way at column n (= 80 by default) so long as one knows where messages from one device end and the next one begin. I'd also oppose things like foo0: .. irq foo0: 9 as opposed to foo0: .. foo0: irq 9 Unless there were so many that this couldn't be avoided... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On Wed, 11 Aug 1999, Warner Losh wrote: > It also would allow one to kick the VGA display into 132 columns in > the boot loader and have more of a chance to get more of the boot > process on the screen. syscons already supports parts of this... I was just reading through the thread again, and I was thinking about a Sun style boot where the screen is kicked into the VESA mode of your choice, we could have a FreeBSD daemon displaying in the upper left corner, etc. > There is no reason to hard code 80 into the kernel. Otherwise one > could argue why have stty columns at all :-). I have to agree with this, flexibility == AGoodThing(TM). > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > > - ( Adam Strohl ) - - UNIX Operations/Systems http://www.digitalspark.net - - adams (at) digitalspark.netxxx.xxx. x - - ( DigitalSpark.NET )--- - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
Nate Williams scribbled this message on Aug 11: > > : The line wrapping stuff I brought back for the EISA bus stuff in -current > > : makes it easy to define the wrap point. If some small number of people > > : want the ability to wrap at 132 or 40 or whatever, I don't think its > > : unreasonable to provide them the knob to tweak in the boot loader. > > > > Despite what nate think about 80 columns, my PDA cannot display more > > than between 30-45 characters, depending on the font, so having a knob > > for that would be useful in the long term. > > And you plan on booting FreeBSD on your PDA? I've booted my FreeBSD box w/ my hp48... and that can't do more than about 34 columns in a sucky 3x5 or 4x5 font... and it works great... :) right now my hp48 is the only serial device that I can get close enough to my server, and I don't have any free slots for a mono or vga card.. -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 "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: it's time...
Warner Losh wrote in list.freebsd-current: > In message <[EMAIL PROTECTED]> Nate Williams writes: > : And you plan on booting FreeBSD on your PDA? > > Yes. I'm already booting NetBSD/hpcmips on it But that's another > thread all by itself... As a small sidenote: Most PDAs can be used as (simple) serial consoles, so it's definitely useful to be able to see the bootmessages there. I already tried that with a PalmPilot. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
> : stty columns is only effective *AFTER* you have a shell and the box has > : booted. > > Yes I know that, but you seem to be arguing that all terminals have 80 > columns... This is not the case, although many of them do. Most of them do. It is the 'least common denominator' that FreeBSD runs into. More than 132 columns is an exception, as well as less than 80 columns. My point was not changing the boot message to more than 80 columns, like you suggested. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
In message <[EMAIL PROTECTED]> Nate Williams writes: : And you plan on booting FreeBSD on your PDA? Yes. I'm already booting NetBSD/hpcmips on it But that's another thread all by itself... : stty columns is only effective *AFTER* you have a shell and the box has : booted. Yes I know that, but you seem to be arguing that all terminals have 80 columns... This is not the case, although many of them do. I was following your line of reasoning to its logical conclusion (since all terminals have 80 columns, why do we need to tell the kernel how big our terminals are). I agree 100% that 80 shall be the default, since that's how wide these things usually have been since 1890 and this man named Hollereth(sp?)... I just want to make sure that I can change that default. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
> : The line wrapping stuff I brought back for the EISA bus stuff in -current > : makes it easy to define the wrap point. If some small number of people > : want the ability to wrap at 132 or 40 or whatever, I don't think its > : unreasonable to provide them the knob to tweak in the boot loader. > > Despite what nate think about 80 columns, my PDA cannot display more > than between 30-45 characters, depending on the font, so having a knob > for that would be useful in the long term. And you plan on booting FreeBSD on your PDA? > It also would allow one to kick the VGA display into 132 columns in > the boot loader and have more of a chance to get more of the boot > process on the screen. syscons already supports parts of this... My firewall doesn't have a VGA display. :( > There is no reason to hard code 80 into the kernel. Otherwise one > could argue why have stty columns at all :-). stty columns is only effective *AFTER* you have a shell and the box has booted. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
In message <[EMAIL PROTECTED]> "Matthew N. Dodd" writes: : The line wrapping stuff I brought back for the EISA bus stuff in -current : makes it easy to define the wrap point. If some small number of people : want the ability to wrap at 132 or 40 or whatever, I don't think its : unreasonable to provide them the knob to tweak in the boot loader. Despite what nate think about 80 columns, my PDA cannot display more than between 30-45 characters, depending on the font, so having a knob for that would be useful in the long term. It also would allow one to kick the VGA display into 132 columns in the boot loader and have more of a chance to get more of the boot process on the screen. syscons already supports parts of this... There is no reason to hard code 80 into the kernel. Otherwise one could argue why have stty columns at all :-). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On Wed, 11 Aug 1999, Nate Williams wrote: > The most common case for a console is an 80 column wide console (this is > the default for the virtual terminals, most printers, most text > terminals, etc..) > > Changing it is silly, and non-standard. The line wrapping stuff I brought back for the EISA bus stuff in -current makes it easy to define the wrap point. If some small number of people want the ability to wrap at 132 or 40 or whatever, I don't think its unreasonable to provide them the knob to tweak in the boot loader. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On Wed, 11 Aug 1999, Warner Losh wrote: > Then we disagree. There are several scripts floating around that use > them for purposes where there isn't a kernel interface... It would be > ideal if there were interfaces for all this info, but there isn't > always. Fine. Due to flux in the bus-system between versions, probe/attach information is essentially a non supported interface for gathering this data. If you do wish to gather it from this source its up to you to DTRT. If you dislike this then your input on a standard interface to this information would likely be of use. > : An interface to query the resource manager directly is likely to be a > : better solution to your problem. > > Well, only kinda. That was one example. The other example is finding > out what the ide driver thought the disk geometry of a disk was... If that information needs to be presented I see no reason why drivers can't do some magic and make /kern/foo/wd0/geometry spit out the right thing. Granted, this is more complex, but depending on boot messages for this information is setting yourself up for problems. > : Besides, if your perl skills aren't able to cope with getting all 'fooX:' > : lines, and stripping out the 'fooX:' bits before parsing then you have > : other problems. > > Hah! You presume too much. None of these scripts are written in > perl, so the size of my perl schl*** isn't at issue here :-) You also > assume that the wrapping would be of the form fooX:. FreeBSD's boot > messages aren't consistant about this right now, witness the > difference between isa and pci devices: > > sio1 at port 0x2f8-0x2ff irq 3 on isa0 > sio1: type 16550A > > vs > > ahc0: irq 10 at device 16.0 on pci0 > ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs > > The "proper" way to do this would be > > sio1 at isa0 port 0x2f8-0x2ff irq 3: type 16550A > ahc0 at pci0 irq 10 device 16.0: > ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs Incorrect. The device name should be separated from the rest of the line by a ':'. > if you must introduce wrapping. Each phrase should either fit on the > current line or be bumped to the next line. However, what is a line? > > Also, I use "proper" in quotes because others will reasonably differ > with the exact details... Indeed. But you've still prooved my point that the probe/attach messages are an unsupported source for such information. > : Correct, but the nature of the kernel probe/attach messages is to convey > : information in a readable, consistent, useful manner. > > Agreed. However, what's magical about 80 columns? My editors go out > to 180 sometimes. The console can easily be placed into a mode where > it is > 80. This is especially true for the serial console where it > might be connected to a 132 column printer. In the beginning was the punch card... > : If we didn't want pretty line wrapping we'd all be using linux and have > : stupid stuff like copyright messages as well. :) > > Don't even get me started on linux' boot messages. :-) > > I happen to like the stark elegance of the OpenBSD/NetBSD boot > messages. Here's the entire dmesg from the boot of my rPC44 MIPS > machine when booted under OpenBSD. > > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > Copyright (c) 1995-1999 OpenBSD. All rights reserved. > http://www.OpenBSD.org > > OpenBSD 2.4-current (IMP-PCCARD) #37: Mon Feb 1 13:28:06 MST 1999 > [EMAIL PROTECTED]:/home/imp/src/sys/arch/arc/compile/IMP-PCCARD > real mem = 32235520 > avail mem = 27754496 > using 419 buffers containing 1716224 bytes of memory > mainbus0 (root) > cpu0 at mainbus0: MIPS R4400 CPU Rev. 4.0 with MIPS R4010 FPC Rev. 0.0 > L1 Cache I size 16kb(16 line), D size 16kb(16 line), direct mapped. > L2 cache doesn't snoop uncached cpu accesses. > isabr0 at mainbus0 > isa0 at isabr0 isa_io_base 0xb000 isa_mem_base 0xa000 > com0 at isa0 port 0x3f8-0x3ff irq 4: ns16450, no fifo > com1 at isa0 port 0x2f8-0x2ff irq 3: ns16450, no fifo > wdc0 at isa0 port 0x1f0-0x1f7 irq 14 > wd0 at wdc0 drive 0: > wd0: 2060MB, 4186 cyl, 16 head, 63 sec, 512 bytes/sec, 4219488 sec total > wd0: using 16-sector 16-bit pio transfers, lba addressing (109KB cache) > clock0 at isa0 port 0x70-0x6d5 irq 0: mc146818 or compatible > pcprobe: reset error 1 > pc0 at isa0 port 0x60-0x6c5 irq 1: color > joy0 at isa0 port 0x201: joystick not connected > ed0 at isa0 port 0x300-0x31f irq 5: address 00:00:1b:1e:52:a7, type NE2000 (16-bit) > boot device: wd0. > root on wd0a > rootdev=0x400 rrootdev=0x1200 rawdev=0x1202 > > Where OpenBSD has > > com0 at isa0 port 0x3f8-0x3ff irq 4: ns16450, no fifo > com1 at isa0 port 0x2f8-0x2ff irq 3: ns16450, no fifo > > FreeBSD we has > > 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 > sio2: configured irq 5 not in bitmap of probed irqs 0 > sio3: conf
Re: it's time...
> : Correct, but the nature of the kernel probe/attach messages is to convey > : information in a readable, consistent, useful manner. > > Agreed. However, what's magical about 80 columns? What's magical is that almost every text console is limited to 80 columns (think serial console), as well as the standard default size for terminal emulators is 80 columns. My editors go out > to 180 sometimes. The console can easily be placed into a mode where > it is > 80. This is especially true for the serial console where it > might be connected to a 132 column printer. Just because it *can* be connected to a 132 column printer doesn't mean it *will* be connected. Most printers that I use are 80 columns wide. Heck, almost *every* printer I use is that wide, hence the whole 80 column thing. The most common case for a console is an 80 column wide console (this is the default for the virtual terminals, most printers, most text terminals, etc..) Changing it is silly, and non-standard. > No! At some point they should use a facility similar to solaris/sysv > where they don't display, but do make it into the dmesg buffer... On my Solaris box, they are displayed at boot time. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
In message <[EMAIL PROTECTED]> "Matthew N.
Dodd" writes:
: On Tue, 10 Aug 1999, Warner Losh wrote:
: > I'd be very careful of line wrapping probe messages. I have scripts
: > that rely on them being on one line to get a list of irqs, etc.
:
: I would consider information from the kernel probe/attach to be useful
: only for humans.
Then we disagree. There are several scripts floating around that use
them for purposes where there isn't a kernel interface... It would be
ideal if there were interfaces for all this info, but there isn't
always.
: An interface to query the resource manager directly is likely to be a
: better solution to your problem.
Well, only kinda. That was one example. The other example is finding
out what the ide driver thought the disk geometry of a disk was...
: Besides, if your perl skills aren't able to cope with getting all 'fooX:'
: lines, and stripping out the 'fooX:' bits before parsing then you have
: other problems.
Hah! You presume too much. None of these scripts are written in
perl, so the size of my perl schl*** isn't at issue here :-) You also
assume that the wrapping would be of the form fooX:. FreeBSD's boot
messages aren't consistant about this right now, witness the
difference between isa and pci devices:
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
vs
ahc0: irq 10 at device 16.0 on pci0
ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs
The "proper" way to do this would be
sio1 at isa0 port 0x2f8-0x2ff irq 3: type 16550A
ahc0 at pci0 irq 10 device 16.0:
ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs
if you must introduce wrapping. Each phrase should either fit on the
current line or be bumped to the next line. However, what is a line?
Also, I use "proper" in quotes because others will reasonably differ
with the exact details...
: Correct, but the nature of the kernel probe/attach messages is to convey
: information in a readable, consistent, useful manner.
Agreed. However, what's magical about 80 columns? My editors go out
to 180 sometimes. The console can easily be placed into a mode where
it is > 80. This is especially true for the serial console where it
might be connected to a 132 column printer.
: If we didn't want pretty line wrapping we'd all be using linux and have
: stupid stuff like copyright messages as well. :)
Don't even get me started on linux' boot messages. :-)
I happen to like the stark elegance of the OpenBSD/NetBSD boot
messages. Here's the entire dmesg from the boot of my rPC44 MIPS
machine when booted under OpenBSD.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-1999 OpenBSD. All rights reserved.
http://www.OpenBSD.org
OpenBSD 2.4-current (IMP-PCCARD) #37: Mon Feb 1 13:28:06 MST 1999
[EMAIL PROTECTED]:/home/imp/src/sys/arch/arc/compile/IMP-PCCARD
real mem = 32235520
avail mem = 27754496
using 419 buffers containing 1716224 bytes of memory
mainbus0 (root)
cpu0 at mainbus0: MIPS R4400 CPU Rev. 4.0 with MIPS R4010 FPC Rev. 0.0
L1 Cache I size 16kb(16 line), D size 16kb(16 line), direct mapped.
L2 cache doesn't snoop uncached cpu accesses.
isabr0 at mainbus0
isa0 at isabr0 isa_io_base 0xb000 isa_mem_base 0xa000
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16450, no fifo
com1 at isa0 port 0x2f8-0x2ff irq 3: ns16450, no fifo
wdc0 at isa0 port 0x1f0-0x1f7 irq 14
wd0 at wdc0 drive 0:
wd0: 2060MB, 4186 cyl, 16 head, 63 sec, 512 bytes/sec, 4219488 sec total
wd0: using 16-sector 16-bit pio transfers, lba addressing (109KB cache)
clock0 at isa0 port 0x70-0x6d5 irq 0: mc146818 or compatible
pcprobe: reset error 1
pc0 at isa0 port 0x60-0x6c5 irq 1: color
joy0 at isa0 port 0x201: joystick not connected
ed0 at isa0 port 0x300-0x31f irq 5: address 00:00:1b:1e:52:a7, type NE2000 (16-bit)
boot device: wd0.
root on wd0a
rootdev=0x400 rrootdev=0x1200 rawdev=0x1202
Where OpenBSD has
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16450, no fifo
com1 at isa0 port 0x2f8-0x2ff irq 3: ns16450, no fifo
FreeBSD we has
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
sio2: configured irq 5 not in bitmap of probed irqs 0
sio3: configured irq 9 not in bitmap of probed irqs 0
which is much more verbose. The entire boot process (including rc
output) fits on the 48x132 mode that my rPC/44 comes up in. With the
same config on FreeBSD, the kernel messages it wouldn't even fit, let
alone the rc output.
: At some point all of the boot messages should be wrapped by 'if
: (bootverbose) { ... }' anyway.
No! At some point they should use a facility similar to solaris/sysv
where they don't display, but do make it into the dmesg buffer...
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On Tue, 10 Aug 1999, Warner Losh wrote:
> I'd be very careful of line wrapping probe messages. I have scripts
> that rely on them being on one line to get a list of irqs, etc.
I would consider information from the kernel probe/attach to be useful
only for humans.
An interface to query the resource manager directly is likely to be a
better solution to your problem.
Besides, if your perl skills aren't able to cope with getting all 'fooX:'
lines, and stripping out the 'fooX:' bits before parsing then you have
other problems.
> However, the whole issue of how probe messages should print, and how
> much is a religious war that I try to steer clear of...
Correct, but the nature of the kernel probe/attach messages is to convey
information in a readable, consistent, useful manner.
If we didn't want pretty line wrapping we'd all be using linux and have
stupid stuff like copyright messages as well. :)
At some point all of the boot messages should be wrapped by 'if
(bootverbose) { ... }' anyway.
--
| Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD |
| [EMAIL PROTECTED] | 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
In message <[EMAIL PROTECTED]> Peter Wemm writes: : This still needs more work to handle line wraps etc. Matthew Dodd did some : work in this area for the EISA code which should be able to be used. I'd be very careful of line wrapping probe messages. I have scripts that rely on them being on one line to get a list of irqs, etc. However, the whole issue of how probe messages should print, and how much is a religious war that I try to steer clear of... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On Tue, 10 Aug 1999, Alex Zepeda wrote: :* an rc.audio or rc.multimedia (this could perhaps contain some bt484 :related things). : :But if it goes into "the" rc.conf, that would mean that whenever it runs :at shutdown, it edits rc.conf; this isn't IMO a real great idea. :Anything automated (even sysinstall) editing rc.conf in any way shape or :form makes me leery because it's so much more error prone. Why not create such a file, and update it whenever a change is made? The settings are always in whatever state you last set them to, no matter when it was, and you don't have to race shutdown. Jamie Bowden -- If we've got to fight over grep, sign me up. But boggle can go. -Ted Faber (on Hasbro's request for removal of /usr/games/boggle) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
"Cameron Grant" wrote:
> to let newpcm out of the cage so you can all get your grubby little hands on
> it.
>
> http://www.vilnya.demon.co.uk/newpcm+dfrpnp-19990807.diff.gz
>
> this is a patch against a recent -current. if you have a pci or isapnp
> soundcard, you should have pnp0 and pcm0 in your kernel config as
> appropriate. isapnp cards should not need any pnp lines in kernel.conf.
>
> the list of supported cards is as for luigi's driver, with the addition of a
> couple more mss-clones, and trident 4dwave. there is a part done aureal
> vortex driver which is as yet nonfunctional. mmap() is supported but not
> well tested. format conversions are supported. the code seems to be
> stable.
>
> please test it and email me success and failure reports.
>
> - cameron
You're missing a bit of the patch I sent you to fix some resource problems
caused by excessive cut/paste in Doug's code. Also, I implemented a proper
(but still a hack) resource printer so you see all ranges.
Before:
pcm0: at port 0x220-0x22f,0x530-0x537 irq 5 drq 0,1 on isa0
After:
pcm0: at port 0x220-0x22f,0x530-0x537,0x388-0x38b,0x330-0x331,\
0x370-0x371 irq 5 drq 0,1 on isa0
This still needs more work to handle line wraps etc. Matthew Dodd did some
work in this area for the EISA code which should be able to be used.
Patch appended. I don't think it's too critical since ISA_NPORT_IVARS is
the largest range, but the lower layers might end up trying to allocate on
rids that the upper layers can't handle.
Cheers,
-Peter
diff -ru3 --exclude=CVS /home/peter/merge/isa/isa_common.c ./isa/isa_common.c
--- /home/peter/merge/isa/isa_common.c Tue Aug 10 20:17:51 1999
+++ ./isa/isa_common.c Sat Aug 7 21:20:04 1999
@@ -270,12 +270,12 @@
{
device_t dev = device_get_parent(child);
int success, i;
- struct resource *res[ISA_NPORT];
+ struct resource *res[ISA_NIRQ];
/*
* First clear out any existing resource definitions.
*/
- for (i = 0; i < ISA_NPORT; i++) {
+ for (i = 0; i < ISA_NIRQ; i++) {
ISA_DELETE_RESOURCE(dev, child, SYS_RES_IRQ, i);
res[i] = NULL;
}
@@ -300,7 +300,7 @@
}
/*
-* If we didn't find a place for port range i, then
+* If we didn't find a place for irq range i, then
* give up now.
*/
if (!res[i]) {
@@ -309,7 +309,7 @@
}
}
- for (i = 0; i < ISA_NPORT; i++) {
+ for (i = 0; i < ISA_NIRQ; i++) {
if (res[i])
bus_release_resource(child, SYS_RES_IRQ,
i, res[i]);
@@ -330,12 +330,12 @@
{
device_t dev = device_get_parent(child);
int success, i;
- struct resource *res[ISA_NPORT];
+ struct resource *res[ISA_NDRQ];
/*
* First clear out any existing resource definitions.
*/
- for (i = 0; i < ISA_NPORT; i++) {
+ for (i = 0; i < ISA_NDRQ; i++) {
ISA_DELETE_RESOURCE(dev, child, SYS_RES_DRQ, i);
res[i] = NULL;
}
@@ -360,7 +360,7 @@
}
/*
-* If we didn't find a place for port range i, then
+* If we didn't find a place for drq range i, then
* give up now.
*/
if (!res[i]) {
@@ -369,7 +369,7 @@
}
}
- for (i = 0; i < ISA_NPORT; i++) {
+ for (i = 0; i < ISA_NDRQ; i++) {
if (res[i])
bus_release_resource(child, SYS_RES_DRQ,
i, res[i]);
@@ -507,26 +507,27 @@
isa_print_resources(struct resource_list *rl, const char *name, int type,
const char *format)
{
- struct resource_list_entry *rle0 = resource_list_find(rl, type, 0);
- struct resource_list_entry *rle1 = resource_list_find(rl, type, 1);
+ struct resource_list_entry *rle;
+ int printed;
+ int i;
- if (rle0 || rle1) {
- printf(" %s ", name);
- if (rle0) {
- printf(format, rle0->start);
- if (rle0->count > 1) {
- printf("-");
- printf(format, rle0->start + rle0->count - 1);
- }
- }
- if (rle1) {
- if (rle0)
+ printed = 0;
+ for (i = 0; i < 16; i++) { /* arbitary limit of 16 for now */
+ rle = resource_list_find(rl, type, i);
+ if (rle) {
+ if (printed == 0)
+ printf(" %s ", name);
+ else if (printed > 0)
printf(",");
- printf(format, rle1->start);
- if (rle1
Re: it's time...
On Mon, 9 Aug 1999, Brian F. Feldman wrote: > On Mon, 9 Aug 1999, Alex Zepeda wrote: > > > One could stuff it into rc.conf, but this means it's harder to > > automagically save the state upon shutdown/reboot. But something like: > > Not really. You could do it with grep, awk, sed, or whatever you want, > easily. The only possible problem would be... Getting it actually run > at shutdown. I missed jkh's argument, but as far as I'm concerned, my first choice for this audio init stuff would be: * a SysV style script (and then having rc.shutdown call /usr/local/etc/rc.d/* w/ $1==stop; but that's another thread). * an rc.audio or rc.multimedia (this could perhaps contain some bt484 related things). But if it goes into "the" rc.conf, that would mean that whenever it runs at shutdown, it edits rc.conf; this isn't IMO a real great idea. Anything automated (even sysinstall) editing rc.conf in any way shape or form makes me leery because it's so much more error prone. > It's at http://janus.syracuse.net/~green/rc.audio.patch, not vapor :) When I wake up today, I'll check that out :^) - alex Experience something different With our new imported dolly She's lovely, warm, inflatable And we guarantee her joy - The Police To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On Tue, 10 Aug 1999, Daniel O'Connor wrote: > The sound card shuts up after reset, and only starts outputing noise again > after the sound card has been probed/attached. Perhaps the attach routine (or rc.something) should explicitly zero all the volumes, so that the card will remain silent until the knobs are called. - alex Experience something different With our new imported dolly She's lovely, warm, inflatable And we guarantee her joy - The Police To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On 10-Aug-99 Brian F. Feldman wrote: > > I have a radio connected to line in on my sound card. > Then that would be playing during the entire bootup, wouldn't it? What, > does it play only after the card has been detected? The sound card shuts up after reset, and only starts outputing noise again after the sound card has been probed/attached. --- 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 PGP signature
Re: it's time...
On Tue, 10 Aug 1999, Daniel O'Connor wrote: > > On 10-Aug-99 Brian F. Feldman wrote: > > > Sure.. but you still have window of time where the audio is at its default > > > level before the rc stuff is run.. > > Why... would audio be playing from rc? Bear in mind, it would be set > > even before rc.local... > > I have a radio connected to line in on my sound card. Then that would be playing during the entire bootup, wouldn't it? What, does it play only after the card has been detected? > > --- > 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 > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On 10-Aug-99 Brian F. Feldman wrote: > > Sure.. but you still have window of time where the audio is at its default > > level before the rc stuff is run.. > Why... would audio be playing from rc? Bear in mind, it would be set > even before rc.local... I have a radio connected to line in on my sound card. --- 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 PGP signature
Re: it's time...
> > On 09-Aug-99 Brian F. Feldman wrote: > > You guys don't see the point. The point is a single, simple place to put > > default mixer values for any number of devices, and fitting in with the > > current configuration file scenario. rc is the natural place for this, > > because _it_ gets run at startup. I just need to find somewhere to put > > this instead of rc.audio, because jkh vetoes it on that account... > > Sure.. but you still have window of time where the audio is at its default > level before the rc stuff is run.. > > --- > 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 > I didn't really mean to cause all this... I just wanted to have the mixer be at the levels I left it at when I shutdown the machine... I don't think we need all this argument about it. Kenneth Culver To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On Mon, 9 Aug 1999, Alex Zepeda wrote: > One could stuff it into rc.conf, but this means it's harder to > automagically save the state upon shutdown/reboot. But something like: Not really. You could do it with grep, awk, sed, or whatever you want, easily. The only possible problem would be... Getting it actually run at shutdown. > > deviceX_mixerdevice_vol = yy > > might work, and allow for multiple sound card. It's at http://janus.syracuse.net/~green/rc.audio.patch, not vapor :) > > - alex > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On Tue, 10 Aug 1999, Daniel O'Connor wrote: > > On 09-Aug-99 Brian F. Feldman wrote: > > You guys don't see the point. The point is a single, simple place to put > > default mixer values for any number of devices, and fitting in with the > > current configuration file scenario. rc is the natural place for this, > > because _it_ gets run at startup. I just need to find somewhere to put > > this instead of rc.audio, because jkh vetoes it on that account... > > Sure.. but you still have window of time where the audio is at its default > level before the rc stuff is run.. Why... would audio be playing from rc? Bear in mind, it would be set even before rc.local... > > --- > 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 > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
[EMAIL PROTECTED] wrote: >> >> As far as I know, rc.shutdown doesn't get run unless you go to single >> user mode (for example, 'shutdown -h now' will not cause init to run >> rc.shutdown). I think FreeBSD-current was fixed and everytime run rc.shutdown. SEE GNATS DB bin/12093. http://www.freebsd.org/cgi/query-pr.cgi?pr=12093 MIHIRA Sanpei Yoshiro To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On 09-Aug-99 Brian F. Feldman wrote: > You guys don't see the point. The point is a single, simple place to put > default mixer values for any number of devices, and fitting in with the > current configuration file scenario. rc is the natural place for this, > because _it_ gets run at startup. I just need to find somewhere to put > this instead of rc.audio, because jkh vetoes it on that account... Sure.. but you still have window of time where the audio is at its default level before the rc stuff is run.. --- 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 PGP signature
Re: it's time...
On Mon, 9 Aug 1999, Brian F. Feldman wrote: > You guys don't see the point. The point is a single, simple place to put > default mixer values for any number of devices, and fitting in with the > current configuration file scenario. rc is the natural place for this, > because _it_ gets run at startup. I just need to find somewhere to put > this instead of rc.audio, because jkh vetoes it on that account... One could stuff it into rc.conf, but this means it's harder to automagically save the state upon shutdown/reboot. But something like: deviceX_mixerdevice_vol = yy might work, and allow for multiple sound card. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
Daniel O'Connor wrote: > > On 09-Aug-99 Alex Zepeda wrote: > > Actually at shutdown would be cool. So it could save the current > volumes, > > and restore them at startup. Altho, at suspend and resume time > wouldn't > > be a bad idea either. > > You could do it something like the way boot -c stuff or the splash > screen is > done, ie load a 'module' which is just a text file for the sound system > to > parse.. > > Don't know how you'd go unload'ing and load'ing the file though. Wouldn't it be just like a splash screen? kldload volume.conf -t volume_data (or whatever) -- Eric Hodel [EMAIL PROTECTED] "They cook your gonies" -Terry Lambert's uncle on why he doesn't have a microwave To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
Cameron Grant wrote: > > to let newpcm out of the cage so you can all get your grubby little hands on > it. > > http://www.vilnya.demon.co.uk/newpcm+dfrpnp-19990807.diff.gz > > this is a patch against a recent -current. if you have a pci or isapnp > soundcard, you should have pnp0 and pcm0 in your kernel config as > appropriate. isapnp cards should not need any pnp lines in kernel.conf. > > the list of supported cards is as for luigi's driver, with the addition of a > couple more mss-clones, and trident 4dwave. there is a part done aureal > vortex driver which is as yet nonfunctional. mmap() is supported but not > well tested. format conversions are supported. the code seems to be > stable. > > please test it and email me success and failure reports. > > - cameron Hi, First, I'd like to thank Cameron for his great work on the pcm driver. It builds and installs cleanly, and generally looks very impressive. I apologize in advance if the following message is a bit on the long side, but the problem I'm going to describe is very odd. I must also make clear that the sound card works fine under Windoze, and it also worked fine with the old pcm driver, until something got broken around 20 April this year (_after_ the integration of new bus). The sound card settings are changeable in the BIOS; this is what I have (the card is a non-PnP Yamaha): Sound: Enabled (other options are: Disabled and Auto) SB I/O address: 220-22F WSS I/O address:530-538 Adlib I/O address: 388-38F MPU I/O address:300-301 CTRL I/O address: 100 (OPL3 chip control) DMA A: DMA 1 (other options: 0,7) DMA B: DMA 0 (other options: 1,7) IRQ:IRQ 5 In accordance with these settings, I used the following line in the kernel: device pcm0 at isa? port 0x530 irq 5 drq 1 flags 0x10 (Note the order of the DMA channels - 1, then 0) Now this is what happens: the driver successfully detects the card, but fails to register an interrupt: /kernel: mss_detect - chip revision 0x0a /kernel: mss_detect() - Detected CS4231 /kernel: pcm0: at port 0x530-0x53f,0x310-0x311 irq 5 drq 1 flags 0xa210 on isa0 /kernel: pcm: setmap 3, ff00; 0xc7bdd000 -> 3 /kernel: pcm: setmap 4, ff00; 0xc7bed000 -> 4 /kernel: device combination doesn't support shared irq3 /kernel: intr_connect(irq3) failed, result=-1 /kernel: device combination doesn't support shared irq4 /kernel: intr_connect(irq4) failed, result=-1 /kernel: device combination doesn't support shared irq5 /kernel: intr_connect(irq5) failed, result=-1 /kernel: device combination doesn't support shared irq7 /kernel: intr_connect(irq7) failed, result=-1 /kernel: device combination doesn't support shared irq9 /kernel: intr_connect(irq9) failed, result=-1 /kernel: device combination doesn't support shared irq12 /kernel: intr_connect(irq12) failed, result=-1 /kernel: device combination doesn't support shared irq14 /kernel: intr_connect(irq14) failed, result=-1 /kernel: device combination doesn't support shared irq15 /kernel: intr_connect(irq15) failed, result=-1 IRQ 5 is definitely unused, and exactly the same setup worked fine with the old pcm driver. Another strange thing is that cat /dev/sndstat shows: FreeBSD Audio Driver (newpcm) Aug 8 1999 21:55:41 Installed devices: pcm0: at io 0x530 irq 5 drq 1:0 (1/1 channels duplex) as if everything were ok. It also seems that although intr_connect fails, IRQ 5 is marked as being in use, because pcic then chooses the next one available (10): /kernel: PC-Card VLSI 82C146 (5 mem & 2 I/O windows) /kernel: pcic: controller irq 10 Now the VERY odd thing: if I use DMA channels 0 and 1 (as opposed to 1 and 0), change the BIOS settings accordingly, and compile the kernel with device pcm0 at isa? port 0x530 irq 5 drq 0 flags 0x11 I get the following error: /kernel: mss_detect - chip revision 0x0a /kernel: mss_detect() - Detected CS4231 /kernel: pcm0: at port 0x530-0x53f,0x310-0x311 irq 5 flags 0xa211 on isa0 + /kernel: device_probe_and_attach: pcm0 attach returned 6 /kernel: device combination doesn't support shared irq3 /kernel: intr_connect(irq3) failed, result=-1 /kernel: device combination doesn't support shared irq4 /kernel: intr_connect(irq4) failed, result=-1 /kernel: device combination doesn't support shared irq7 /kernel: intr_connect(irq7) failed, result=-1 /kernel: device combination doesn't support shared irq9 /kernel: intr_connect(irq9) failed, result=-1 /kernel: device combination doesn't support shared irq12 /kernel: intr_connect(irq12) failed, result=-1 /kernel: device combination doesn't support shared irq14 /kernel: intr_connect(irq14) failed, result=-1 /kernel: device combination doesn't support shared irq15 /kernel: intr_connect(irq15) failed, result=-1 /kernel: PC-Card VLSI 82C146 (5 mem & 2 I/O windows) + /kernel: pcic: controller irq 5 and cat: /dev/s
Re: it's time...
You guys don't see the point. The point is a single, simple place to put default mixer values for any number of devices, and fitting in with the current configuration file scenario. rc is the natural place for this, because _it_ gets run at startup. I just need to find somewhere to put this instead of rc.audio, because jkh vetoes it on that account... Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
> On Mon, 9 Aug 1999, Daniel O'Connor wrote: > > > You could do it something like the way boot -c stuff or the splash screen is > > done, ie load a 'module' which is just a text file for the sound system to > > parse.. > > > > Don't know how you'd go unload'ing and load'ing the file though. > > Why that complex? Couldn't I just drop in a small script using awk and > sh, to grab the mixer volumes, and drop it in rc.shutdown? Or even a > small C program would suffice if scripting isn't your cup of tea. > > - alex As far as I know, rc.shutdown doesn't get run unless you go to single user mode (for example, 'shutdown -h now' will not cause init to run rc.shutdown). Personally, I put my mixer settings in ~/.mixerrc, and load/save values there by running a script from ~/.xinitrc (load before starting window manager, save after window manager exits). But I never have a real need to use audio when I'm not running X (and no need to have any mixer settings before logon). Daniel ~~ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On Mon, 9 Aug 1999, Daniel O'Connor wrote: > > Why that complex? Couldn't I just drop in a small script using awk and > > sh, to grab the mixer volumes, and drop it in rc.shutdown? Or even a > > small C program would suffice if scripting isn't your cup of tea. > > Hmm.. true.. so have a shell script to write the file on shutdown, then load > the file as a kernel mod on startup using the boot loader? > > That way you don't have that annoying window of time after the card has been > initialised before /etc/rc is run :) Wha? Since neither the kernel nor the startup scripts really frob the sound devices much, another shell script could suffice for this too, no? I mean, I usually have to wait until after I've logged in to turn down the volume anyways. This could even be implemented (perhaps easier) thru the rc.d tree. Perhaps I'll do that tomorrow, and make a port out of it ;) Or am I just oversimplifying things? - alex You better believe that marijuana can cause castration. Just suppose your girlfriend gets the munchies! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On Mon, 9 Aug 1999, Daniel O'Connor wrote: > You could do it something like the way boot -c stuff or the splash screen is > done, ie load a 'module' which is just a text file for the sound system to > parse.. > > Don't know how you'd go unload'ing and load'ing the file though. Why that complex? Couldn't I just drop in a small script using awk and sh, to grab the mixer volumes, and drop it in rc.shutdown? Or even a small C program would suffice if scripting isn't your cup of tea. - alex You better believe that marijuana can cause castration. Just suppose your girlfriend gets the munchies! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On 09-Aug-99 Alex Zepeda wrote: > Why that complex? Couldn't I just drop in a small script using awk and > sh, to grab the mixer volumes, and drop it in rc.shutdown? Or even a > small C program would suffice if scripting isn't your cup of tea. Hmm.. true.. so have a shell script to write the file on shutdown, then load the file as a kernel mod on startup using the boot loader? That way you don't have that annoying window of time after the card has been initialised before /etc/rc is run :) --- 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 PGP signature
Re: it's time...
On Sun, 8 Aug 1999, Mike Smith wrote: > > On Sun, 8 Aug 1999, Brian F. Feldman wrote: > > > > > > It works ok for me, but one nice feature of the sound system would be if > > > > upon shutdown (I don't leave my machine on all the time right now) OS > > > > somehow looked at a config file (call it /etc/soundvol.conf) for mixer > > > > volumes, and set them to that as a default... Just an idea. > > > > > > Don't you mean upon startup? If so, see my recent rc proposition for mixer > > > settings. > > > > Actually at shutdown would be cool. So it could save the current volumes, > > and restore them at startup. Altho, at suspend and resume time wouldn't > > be a bad idea either. > > Gosh, let's see; at shutdown it could edit /etc/rc.conf. Wouldn't that > be handy? And so easy too. 8) Nah, it could store the values in, say, /etc/mixerX.vols, if the knob was enabled in rc.conf. Imagine for a moment one less thing to remember to tweak at boot time. Sure my AWE64 and 32PnP don't need tweaking upon startup if I don't mind waking everyone up when I play an mp3, but there are cards out there that default to a volume of zero. Sure it's nothing monumental, but it's a convience thing. I mean, if the FreeBSD project is opposed to convenience, why have /usr/local/etc/rc.d, or even rc.conf for that matter when one can enter this stuff in by hand each time at startup %) - alex You better believe that marijuana can cause castration. Just suppose your girlfriend gets the munchies! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On 09-Aug-99 Mike Smith wrote: > Gosh, let's see; at shutdown it could edit /etc/rc.conf. Wouldn't that > be handy? And so easy too. 8) Ahh but then you have to put up with the default sound levels until /etc/rc.conf is used :) --- 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 PGP signature
Re: it's time...
On 09-Aug-99 Alex Zepeda wrote: > Actually at shutdown would be cool. So it could save the current volumes, > and restore them at startup. Altho, at suspend and resume time wouldn't > be a bad idea either. You could do it something like the way boot -c stuff or the splash screen is done, ie load a 'module' which is just a text file for the sound system to parse.. Don't know how you'd go unload'ing and load'ing the file though. --- 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 PGP signature
Re: it's time...
> On Sun, 8 Aug 1999, Brian F. Feldman wrote: > > > > It works ok for me, but one nice feature of the sound system would be if > > > upon shutdown (I don't leave my machine on all the time right now) OS > > > somehow looked at a config file (call it /etc/soundvol.conf) for mixer > > > volumes, and set them to that as a default... Just an idea. > > > > Don't you mean upon startup? If so, see my recent rc proposition for mixer > > settings. > > Actually at shutdown would be cool. So it could save the current volumes, > and restore them at startup. Altho, at suspend and resume time wouldn't > be a bad idea either. Gosh, let's see; at shutdown it could edit /etc/rc.conf. Wouldn't that be handy? And so easy too. 8) -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On Sun, 8 Aug 1999, Brian F. Feldman wrote: > > It works ok for me, but one nice feature of the sound system would be if > > upon shutdown (I don't leave my machine on all the time right now) OS > > somehow looked at a config file (call it /etc/soundvol.conf) for mixer > > volumes, and set them to that as a default... Just an idea. > > Don't you mean upon startup? If so, see my recent rc proposition for mixer > settings. Actually at shutdown would be cool. So it could save the current volumes, and restore them at startup. Altho, at suspend and resume time wouldn't be a bad idea either. - alex You better believe that marijuana can cause castration. Just suppose your girlfriend gets the munchies! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
On Sun, 8 Aug 1999, Kenneth Wayne Culver wrote: > It works ok for me, but one nice feature of the sound system would be if > upon shutdown (I don't leave my machine on all the time right now) OS > somehow looked at a config file (call it /etc/soundvol.conf) for mixer > volumes, and set them to that as a default... Just an idea. Don't you mean upon startup? If so, see my recent rc proposition for mixer settings. > > KEnneth Culver > Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
> to let newpcm out of the cage so you can all get your grubby little hands on > it. > > http://www.vilnya.demon.co.uk/newpcm+dfrpnp-19990807.diff.gz > > this is a patch against a recent -current. if you have a pci or isapnp > soundcard, you should have pnp0 and pcm0 in your kernel config as > appropriate. isapnp cards should not need any pnp lines in kernel.conf. > > the list of supported cards is as for luigi's driver, with the addition of a > couple more mss-clones, and trident 4dwave. there is a part done aureal > vortex driver which is as yet nonfunctional. mmap() is supported but not > well tested. format conversions are supported. the code seems to be > stable. > > please test it and email me success and failure reports. > > - cameron > It works ok for me, but one nice feature of the sound system would be if upon shutdown (I don't leave my machine on all the time right now) OS somehow looked at a config file (call it /etc/soundvol.conf) for mixer volumes, and set them to that as a default... Just an idea. KEnneth Culver To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: it's time...
According to Cameron Grant: > the list of supported cards is as for luigi's driver, with the addition of a > couple more mss-clones, and trident 4dwave. there is a part done aureal Can someone with access to a Sony VAIO Z505S(X) laptop try this ? According to Sony it is supposed to be MSS compatible but it is not seen by the current sound code... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 4.0-CURRENT #73: Sat Jul 31 15:36:05 CEST 1999 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
