Re: Boot messages

[Dag-Erling Smorgrav]

Garrett Wollman <[EMAIL PROTECTED]> writes:
> The ``can't assign resources'' messages indicate that the devices are
> legacy ISA devices for which a non-PnP-aware driver is compiled into
> the kernel.

Wrong.

> If it didn't say ``can't assign resources'', then *and only then* is
> the device in question not configured in the kernel.

Wrong (well, it depends on your definition of "configured").

>   AIUI such
> messages are currently disabled unless one boots in verbose mode.

Wrong.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

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

Re: Boot messages

[Warner Losh]

In message <[EMAIL PROTECTED]> Garrett Wollman writes:
: < said:
: 
: > Actually, it is a bug.  The drivers in the tree should grok these pnp
: > ids.
: 
: Actually, no, it is not a bug.  The FreeBSD drivers for these devices
: manage their resources differently from the way the Windows drivers
: do, and the result is not unexpected if you look closely at the dump
: in verbose mode.

Ummm, I have to disagree here.  The PNP ids aren't for keyboards and
the like.  They are for floppy disks, serial ports and the like.  The
things that we already have a driver for in the tree.  That's why the
can't allocate messages happen.  Someone else, who doesn't handle PNP
stuff, has already grabbed the resource.

Warner

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

Re: Boot messages

[Mike Smith]

> < said:
> 
> > Actually, it is a bug.  The drivers in the tree should grok these pnp
> > ids.
> 
> Actually, no, it is not a bug.  The FreeBSD drivers for these devices
> manage their resources differently from the way the Windows drivers
> do, and the result is not unexpected if you look closely at the dump
> in verbose mode.

I'll say this for the seventeenth time, it is a bug; it's in the way that 
a) hints are handled, and b) the way that the console code currently 
works.

It's also not really dangerous, so most people ignore it.  There are much 
bigger problems to worry about. 8)

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
   V I C T O R Y   N O T   V E N G E A N C E



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

Re: Boot messages

[Garrett Wollman]

< said:

> Actually, it is a bug.  The drivers in the tree should grok these pnp
> ids.

Actually, no, it is not a bug.  The FreeBSD drivers for these devices
manage their resources differently from the way the Windows drivers
do, and the result is not unexpected if you look closely at the dump
in verbose mode.

-GAWollman


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

Re: Boot messages

[Mike Smith]

> < said:
> 
> > This is not a bug.  This is an FAQ.  So much that it's actually
> > documented in (*gasp!*) the FAQ:
> 
> Unfortunately, the A in the FAQ is wrong.
> 
> The ``can't assign resources'' messages indicate that the devices are
> legacy ISA devices for which a non-PnP-aware driver is compiled into
> the kernel.

Actually, this isn't true; these drivers are for the most part PnP-aware, 
the problem is that the hints are processed before the PnP data, so when 
hints for these drivers are present, the devices instantiated by the PnP 
data can't get at their resources (because they're already taken).

> These include devices such as keyboard controllers, the
> programmable interrupt controller chip, and several other bits of
> standard infrastructure.  The resources can't be assigned because
> there is already a driver using those addresses.

The only devices which can't correctly be handled using PnP data right 
now are console devices, due to our need to have console support before 
the device subsystem is initialised.  (Keyboard, mouse, video).

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
   V I C T O R Y   N O T   V E N G E A N C E



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

Re: Boot messages

[Warner Losh]

In message <[EMAIL PROTECTED]> John Baldwin writes:
: 
: On 25-Apr-01 Warner Losh wrote:
: > In message <[EMAIL PROTECTED]> Dima Dorfman
: > writes:
: >: Riccardo Torrini <[EMAIL PROTECTED]> writes:
: >: >   pca1:  at port 0x61 on isa0
: >: >   WARNING: Driver mistake: repeat make_dev("pcaudio")
: >: >   WARNING: Driver mistake: repeat make_dev("pcaudioctl")
: >: 
: >: As it says, this is a driver mistake.  It's a bug.  I don't know if
: >: it's new or not since I don't have any computers with a sound card
: >: (and thus have no need for pcaudio*).
: >: 
: >: >   unknown:  can't assign resources
: >: >   unknown:  can't assign resources
: >: >   unknown:  can't assign resources
: >: 
: >: This is not a bug.  This is an FAQ.  So much that it's actually
: >: documented in (*gasp!*) the FAQ:
: > 
: > Actually, it is a bug.  The drivers in the tree should grok these pnp
: > ids.  Also, the bios pnp devices should be probed first rather than
: > last because those are hard wired pnp devices, as opposed to the ISA
: > PNP devices, which have the potential to be moved and can be
: > disabled.
: 
: Well, yes, but that breaks console probing atm since we only support
: hints-based devices for the kernel console.  You'll want to fix that first.

Right.  Last time I tried to push changes like this through, there
were some other minor obejctions that I can't recall at the moment as
well.  I think it was on the par of this one.

Warner

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

Re: Boot messages

[John Baldwin]

On 25-Apr-01 Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Dima Dorfman
> writes:
>: Riccardo Torrini <[EMAIL PROTECTED]> writes:
>: >   pca1:  at port 0x61 on isa0
>: >   WARNING: Driver mistake: repeat make_dev("pcaudio")
>: >   WARNING: Driver mistake: repeat make_dev("pcaudioctl")
>: 
>: As it says, this is a driver mistake.  It's a bug.  I don't know if
>: it's new or not since I don't have any computers with a sound card
>: (and thus have no need for pcaudio*).
>: 
>: >   unknown:  can't assign resources
>: >   unknown:  can't assign resources
>: >   unknown:  can't assign resources
>: 
>: This is not a bug.  This is an FAQ.  So much that it's actually
>: documented in (*gasp!*) the FAQ:
> 
> Actually, it is a bug.  The drivers in the tree should grok these pnp
> ids.  Also, the bios pnp devices should be probed first rather than
> last because those are hard wired pnp devices, as opposed to the ISA
> PNP devices, which have the potential to be moved and can be
> disabled.

Well, yes, but that breaks console probing atm since we only support
hints-based devices for the kernel console.  You'll want to fix that first.

> Note well: ISA PNP and BIOS PNP are different things.
> 
> Warner

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use 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: Boot messages

[Warner Losh]

In message <[EMAIL PROTECTED]> Dima Dorfman writes:
: Riccardo Torrini <[EMAIL PROTECTED]> writes:
: >   pca1:  at port 0x61 on isa0
: >   WARNING: Driver mistake: repeat make_dev("pcaudio")
: >   WARNING: Driver mistake: repeat make_dev("pcaudioctl")
: 
: As it says, this is a driver mistake.  It's a bug.  I don't know if
: it's new or not since I don't have any computers with a sound card
: (and thus have no need for pcaudio*).
: 
: >   unknown:  can't assign resources
: >   unknown:  can't assign resources
: >   unknown:  can't assign resources
: 
: This is not a bug.  This is an FAQ.  So much that it's actually
: documented in (*gasp!*) the FAQ:

Actually, it is a bug.  The drivers in the tree should grok these pnp
ids.  Also, the bios pnp devices should be probed first rather than
last because those are hard wired pnp devices, as opposed to the ISA
PNP devices, which have the potential to be moved and can be
disabled. 

Note well: ISA PNP and BIOS PNP are different things.

Warner

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

Re: Boot messages

[Garrett Wollman]

< 
said:

> This means that I can remove this lines?  Sure?

> device  atkbdc  1

No, I said nothing of the sort.

-GAWollman


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

Re: Boot messages

[Riccardo Torrini]

On 25-Apr-01 (01:31:59/GMT) Garrett Wollman wrote:

> The ``can't assign resources'' messages indicate that the
> devices are legacy ISA devices for which a non-PnP-aware
> driver is compiled into the kernel.  These include devices
> such as keyboard...

This means that I can remove this lines?  Sure?

-8<-[ /usr/src/sys/i386/conf/TRUDY ]-8<-
# atkbdc0 controls both the keyboard and the PS/2 mouse
device  atkbdc  1
device  atkbd
device  psm

# Floppy drives
device  fdc

# Serial (COM) ports
device  sio 1

# pca: PCM audio through your PC speaker
device  pca


> AIUI such messages are currently disabled unless one boots in
> verbose mode.

Under -CURRENT boot is supposed to be 'extra_verbose' (IMHO).


Ciao,
Riccardo.

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

Re: Boot messages

[Garrett Wollman]

[Followups to -questions, please.]

< 
said:

> unknown:  can't assign resources

Keyboard controller.

> unknown:  can't assign resources

PS/2 mouse port.

> unknown:  can't assign resources

Serial port whose settings conflict with one of your configured serial
ports.

> unknown:  can't assign resources

Floppy disk controller.

See .

-GAWollman


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

Re: Boot messages

[Garrett Wollman]

< said:

> This is not a bug.  This is an FAQ.  So much that it's actually
> documented in (*gasp!*) the FAQ:

Unfortunately, the A in the FAQ is wrong.

The ``can't assign resources'' messages indicate that the devices are
legacy ISA devices for which a non-PnP-aware driver is compiled into
the kernel.  These include devices such as keyboard controllers, the
programmable interrupt controller chip, and several other bits of
standard infrastructure.  The resources can't be assigned because
there is already a driver using those addresses.

If it didn't say ``can't assign resources'', then *and only then* is
the device in question not configured in the kernel.  AIUI such
messages are currently disabled unless one boots in verbose mode.

-GAWollman



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

Re: Boot messages

[Riccardo Torrini]

On 24-Apr-01 (23:19:59/GMT) Dima Dorfman wrote:

>>   WARNING: Driver mistake: repeat make_dev("pcaudio")
>>   WARNING: Driver mistake: repeat make_dev("pcaudioctl")

> As it says, this is a driver mistake.  It's a bug.

Ok.  It happens from first days of devfs.  I'm looking into
gnats but there isn't any reference to it.  Must send a PR?


>>   unknown:  can't assign resources...

> This is not a bug.  This is an FAQ.

Yes.  I know.  I'll try to explain better: where can I find a
list of unsupported PnP devices?  I only have an ethernet isa
card (ex0) and a sound isa card (AWE64).  Where all that PnP
devices come from?  Here is my dmesg:

[...]
pca0 at port 0x40 on isa0
ex0:  at port 0x300-0x30f irq 10 on isa0
ex0: Manual config, 16-bit bus, board id 0x006, stepping 0x0
ex0: Ethernet address 00:aa:00:ad:44:7c
sbc0:  at port 0x220-0x22f,0x330-0x331,0x388-0x38b
   irq 5 drq 1,5 on isa0
pcm1:  on sbc0
midi0:  on sbc0
midi1:  on sbc0
joy0:  at port 0x200-0x207 on isa0
midi2:  at port
   0x620-0x623,0xa20-0xa23,0xe20-0xe23 on isa0
emu2: DRAM size = 512KB
unknown:  can't assign resources
pca1:  at port 0x61 on isa0
WARNING: Driver mistake: repeat make_dev("pcaudio")
WARNING: Driver mistake: repeat make_dev("pcaudioctl")
unknown:  can't assign resources
unknown:  can't assign resources
unknown:  can't assign resources
[...]


And this?   What is it?  isa0: unexpected small tag 14


Thanks in advance,
Riccardo.

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

Re: Boot messages

[Dima Dorfman]

Riccardo Torrini <[EMAIL PROTECTED]> writes:
>   pca1:  at port 0x61 on isa0
>   WARNING: Driver mistake: repeat make_dev("pcaudio")
>   WARNING: Driver mistake: repeat make_dev("pcaudioctl")

As it says, this is a driver mistake.  It's a bug.  I don't know if
it's new or not since I don't have any computers with a sound card
(and thus have no need for pcaudio*).

>   unknown:  can't assign resources
>   unknown:  can't assign resources
>   unknown:  can't assign resources

This is not a bug.  This is an FAQ.  So much that it's actually
documented in (*gasp!*) the FAQ:

http://www.freebsd.org/doc/en_US.ISO_8859-1/books/faq/admin.html#PNP-RESOURCES

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

Re: boot messages for pci devices...

[Jeroen Ruigrok/Asmodai]

-On [2119 08:00], Warner Losh ([EMAIL PROTECTED]) wrote:
>In message <[EMAIL PROTECTED]> Chris Piazza writes:
>: I *thought* I noticed it was different.  I actually find this pretty
>: annoying because it wraps almost all of the lines and makes it difficult
>: to read dmesg.
>
>I don't mind them, but wouldn't object to a generic wrapping
>mechanism.

Ditto,

I like the current verbosity, and the really bootverbose stuff is WAY
much more verbose than this.

For me, at least, this allows easy debugging without going full verbose.

That wrapping issue seems very useful indeed.  At least it would
structure the information a bit more orderly.

-- 
Jeroen Ruigrok vd W/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org]
Documentation nutter/B-rated Coder BSD: Technical excellence at its best  
The BSD Programmer's Documentation Project 
Peace with honour...


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

Re: boot messages for pci devices...

[Mike Smith]

> On Wed, Jan 19, 2000 at 12:28:09AM +0100, Poul-Henning Kamp wrote:
> > fxp0:  port 0xc400-0xc43f mem 
>0xefe0-0xefef,0xe000-0xefff irq 9 at device 14.0 on pci0
> 
> Agreed.  For a PCI card all I want to know is what it is, and what IRQ it
> was assigned.  A single line should be suffient.

The IRQ number is actually pretty redundant as well.

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\  [EMAIL PROTECTED]




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

Re: boot messages for pci devices...

[Andrzej Bialecki]

On Wed, 19 Jan 2000, David Scheidt wrote:

> On Wed, 19 Jan 2000, Andrzej Bialecki wrote:
> 
> > 
> > I did some hacks a while ago on a tool which could be called "devinfo". It
> > simply traversed the dev/bus tree and displayed tons of info about each
> > node.
> > 
> > Perhaps something like that could be useful instead of full-blown FS?
> 
> 
> This is something like HP-UX's ioscan(1M)?  This would be very handy, even
> it only gave info on the hardware the kernel knows about, as opposed to
> actually rescanning the busses.  

No, the code that I wrote doesn't do re-scan. It simply displays the bus
info in formatted way. I would have to dust it off and rewrite it in order
for it to be usable... Or I can send you the code "as is" and you can
finish it. :-)

Andrzej Bialecki

//  <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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

Re: boot messages for pci devices...

[David Scheidt]

On Wed, 19 Jan 2000, Andrzej Bialecki wrote:

> 
> I did some hacks a while ago on a tool which could be called "devinfo". It
> simply traversed the dev/bus tree and displayed tons of info about each
> node.
> 
> Perhaps something like that could be useful instead of full-blown FS?


This is something like HP-UX's ioscan(1M)?  This would be very handy, even
it only gave info on the hardware the kernel knows about, as opposed to
actually rescanning the busses.  


David Scheidt




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

Re: boot messages for pci devices...

[Andrzej Bialecki]

On Tue, 18 Jan 2000, Matthew N. Dodd wrote:

> On Wed, 19 Jan 2000, Poul-Henning Kamp wrote:
> > fxp0:  port 0xc400-0xc43f mem 
>0xefe0-0xefef,0xe000-0xefff irq 9 at device 14.0 on pci0
> > 
> > Is this level of verbosity really helping anybody ?
> 
> Its consistant, but I need to unify all the resource printing stuff since
> theres about 5 different ways that are being used to print the stuff right
> now.  I'll do this after 4.0R.
> 
> > I thought we printed out the port/mem stuff for ISA because it is
> > usually jumpered by the admin, but for dynamic allocation
> > busses/devices I think this should be "bootverbose" material.
> 
> Humm...  Thats possible.  There was talk a while ago about making multiple
> levels of verbosity in the bootup messages.  I'll explore this when I fix
> the line wrapping issues.
> 
> It would really be nice if we could have busfs; this would make it much
> easier to allow access to this sort of information.

I did some hacks a while ago on a tool which could be called "devinfo". It
simply traversed the dev/bus tree and displayed tons of info about each
node.

Perhaps something like that could be useful instead of full-blown FS?

Andrzej Bialecki

//  <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com)
// ---
// -- FreeBSD: The Power to Serve. http://www.freebsd.org 
// --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 




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

Re: boot messages for pci devices...

[Matthew Jacob]

> The IRQ is useful to me at least, since the ISA/PCI irq distribution is
> rather hackish and non-trivial to get right at times.

Note that I'm not saying that IRQ is not useful - I'm just asking whether it's
important to see when bootverbose == 0.




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

Re: boot messages for pci devices...

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Matthew
 Jacob writes:
>
>
>> On Wed, Jan 19, 2000 at 12:28:09AM +0100, Poul-Henning Kamp wrote:
>> > fxp0:  port 0xc400-0xc43f mem 
>0xefe0-0xefef,0xe000-0xefff irq 9 at device 14.0 on pci0
>> 
>> Agreed.  For a PCI card all I want to know is what it is, and what IRQ it
>> was assigned.  A single line should be suffient.
>
>Do you even need to know what IRQ it was assigned? It seems to me that IRQ,
>like IO-PORT, is only needed if you're either interested in such stuff or to
>catch conflicts (both are under bootverbose)

The IRQ is useful to me at least, since the ISA/PCI irq distribution is
rather hackish and non-trivial to get right at times.

--
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: boot messages for pci devices...

[Warner Losh]

In message <[EMAIL PROTECTED]> Chris Piazza writes:
: I *thought* I noticed it was different.  I actually find this pretty
: annoying because it wraps almost all of the lines and makes it difficult
: to read dmesg.

I don't mind them, but wouldn't object to a generic wrapping
mechanism.

Warner


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

Re: boot messages for pci devices...

[Matthew Jacob]

On Tue, 18 Jan 2000, David O'Brien wrote:

> On Tue, Jan 18, 2000 at 06:10:00PM -0800, Matthew Jacob wrote:
> > > Agreed.  For a PCI card all I want to know is what it is, and what IRQ it
> > > was assigned.  A single line should be suffient.
> > 
> > Do you even need to know what IRQ it was assigned? It seems to me that IRQ,
> 
> 
> With wacky PC hardware being what it is, I would say yes.  Especially on
> laptops.  Having to tell everyone to boot verbose besides posting
> /var/run/dmesg.boot would be yet one more thing to get over when pulling
> teeth [read details] from people.

Hmm? Haven't we argued over this before [ default grep output ]]?




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

Re: boot messages for pci devices...

[Matthew Jacob]

> 
> What would be nice would be to have the normal version displayed and
> the verbose stuff go to a seperate buffer and logged seperatly..
> 
> ie so you don't clutter your boot screen with junk, but if you have a
> problem you can get at the verbose info :)
> 
> .. and no I don't have any patches :)

>From tne cmn_err(9f) man page for solaris:

 The first character in format affects where the message will
 be written:

 !the message goes only to the system buffer.

 ^the message goes only to the console.

 ?If level is also CE_CONT, the message is always sent to
  the  system  buffer, but is only written to the console
  when the system has been booted in verbose  mode.   See
  kernel(1M).   If  neither  condition  is  met,  the '?'
  character has no effect and is simply ignored.





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

Re: boot messages for pci devices...

[David O'Brien]

On Tue, Jan 18, 2000 at 06:10:00PM -0800, Matthew Jacob wrote:
> > Agreed.  For a PCI card all I want to know is what it is, and what IRQ it
> > was assigned.  A single line should be suffient.
> 
> Do you even need to know what IRQ it was assigned? It seems to me that IRQ,


With wacky PC hardware being what it is, I would say yes.  Especially on
laptops.  Having to tell everyone to boot verbose besides posting
/var/run/dmesg.boot would be yet one more thing to get over when pulling
teeth [read details] from people.

-- 
-- David([EMAIL PROTECTED])


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

Re: boot messages for pci devices...

[Daniel O'Connor]

On 19-Jan-00 Matthew Jacob wrote:
>  Do you even need to know what IRQ it was assigned? It seems to me
>  that IRQ,
>  like IO-PORT, is only needed if you're either interested in such
>  stuff or to
>  catch conflicts (both are under bootverbose)

What would be nice would be to have the normal version displayed and
the verbose stuff go to a seperate buffer and logged seperatly..

ie so you don't clutter your boot screen with junk, but if you have a
problem you can get at the verbose info :)

.. and no I don't have any patches :)

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


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

Re: boot messages for pci devices...

[Matthew Jacob]

> On Wed, Jan 19, 2000 at 12:28:09AM +0100, Poul-Henning Kamp wrote:
> > fxp0:  port 0xc400-0xc43f mem 
>0xefe0-0xefef,0xe000-0xefff irq 9 at device 14.0 on pci0
> 
> Agreed.  For a PCI card all I want to know is what it is, and what IRQ it
> was assigned.  A single line should be suffient.

Do you even need to know what IRQ it was assigned? It seems to me that IRQ,
like IO-PORT, is only needed if you're either interested in such stuff or to
catch conflicts (both are under bootverbose)




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

Re: boot messages for pci devices...

[David O'Brien]

On Wed, Jan 19, 2000 at 12:28:09AM +0100, Poul-Henning Kamp wrote:
> fxp0:  port 0xc400-0xc43f mem 
>0xefe0-0xefef,0xe000-0xefff irq 9 at device 14.0 on pci0

Agreed.  For a PCI card all I want to know is what it is, and what IRQ it
was assigned.  A single line should be suffient.
 
-- 
-- David([EMAIL PROTECTED])


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

Re: boot messages for pci devices...

[Amancio Hasty]

> 
> fxp0:  port 0xc400-0xc43f mem 
>0xefe0-0xefef,0xe000-0xefff irq 9 at device 14.0 on pci0
> 
> Is this level of verbosity really helping anybody ?
> 
> I thought we printed out the port/mem stuff for ISA because it is
> usually jumpered by the admin, but for dynamic allocation busses/devices
> I think this should be "bootverbose" material.
> 
> Or maybe we should always make the resource allocations bootverbose stuff
> now ?
> 
I think that the pci info should be displayed onlly in verbose mode .
Some of the pci devices specially the newer graphic cards have tons
of memory map registers and it is of virtually no use to users.





-- 
 Amancio Hasty
 [EMAIL PROTECTED]




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

Re: boot messages for pci devices...

[Chris Piazza]

On Wed, Jan 19, 2000 at 12:28:09AM +0100, Poul-Henning Kamp wrote:
> 
> fxp0:  port 0xc400-0xc43f mem 
>0xefe0-0xefef,0xe000-0xefff irq 9 at device 14.0 on pci0
> 
> Is this level of verbosity really helping anybody ?

I *thought* I noticed it was different.  I actually find this pretty
annoying because it wraps almost all of the lines and makes it difficult
to read dmesg.

-Chris
-- 
[EMAIL PROTECTED]   [EMAIL PROTECTED]
Abbotsford, BC, Canada


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

Re: boot messages for pci devices...

[Matthew N. Dodd]

On Wed, 19 Jan 2000, Poul-Henning Kamp wrote:
> fxp0:  port 0xc400-0xc43f mem 
>0xefe0-0xefef,0xe000-0xefff irq 9 at device 14.0 on pci0
> 
> Is this level of verbosity really helping anybody ?

Its consistant, but I need to unify all the resource printing stuff since
theres about 5 different ways that are being used to print the stuff right
now.  I'll do this after 4.0R.

> I thought we printed out the port/mem stuff for ISA because it is
> usually jumpered by the admin, but for dynamic allocation
> busses/devices I think this should be "bootverbose" material.

Humm...  Thats possible.  There was talk a while ago about making multiple
levels of verbosity in the bootup messages.  I'll explore this when I fix
the line wrapping issues.

It would really be nice if we could have busfs; this would make it much
easier to allow access to this sort of information.

-- 
| 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