boot messages

boot messages

Post by Andries.Brou.. » Wed, 23 Apr 2003 14:50:10



Comparing my net sources with the vanilla sources showed
a series of differences of which I sent most to you
a moment ago. We still have one point of discussion.

Quote:>> I suppose these can be removed altogether.
>> For now #if 0 ... #endif.
> would it not be preferable to mark these as KERN_DEBUG instead?

I don't think so, but am willing to be convinced by Alan
in the case of lba48 messages. In the other cases these
messages just have to go.

Boot messages must tell us what hardware is detected.
We must not have debugging messages stating how
much memory is allocated for slab cache or so.
One can ask /proc after booting, and unless there are
serious bugs in the code such things do not affect booting.

When disk hardware is detected, I want to see manufacturer,
model, serial number and capacity.
When ethernet hardware is detected, I want to see manufacturer,
model and MAC address. (Possibly also IRQ and ioport.)

You never reacted, so I keep saying this until you either
take this patch or explain why in case of this particular driver
it is a bad idea to reveal the MAC address in the boot messages.

[I have also more general patches making sure that the MAC address
is printed in a uniform way by all drivers, but that comes later.]

Some more or less unrelated stuff below the patch.

Andries

diff -u --recursive --new-file -X /linux/dontdiff a/drivers/net/3c59x.c b/drivers/net/3c59x.c
--- a/drivers/net/3c59x.c       Sun Apr 20 12:59:32 2003

                acpi_set_WOL(dev);
        }
        retval = register_netdev(dev);
-       if (retval == 0)
+       if (retval == 0) {
+               int i;
+               printk("%s: 3c59x, address", dev->name);
+               for (i = 0; i < 6; i++)
+                       printk("%c%2.2x", i ? ':' : ' ', dev->dev_addr[i]);
+               printk("\n");
                return 0;
+       }

 free_ring:
        pci_free_consistent(pdev,
-                                               sizeof(struct boom_rx_desc) * RX_RING_SIZE
-                                                       + sizeof(struct boom_tx_desc) * TX_RING_SIZE,
-                                               vp->rx_ring,
-                                               vp->rx_ring_dma);
+                           sizeof(struct boom_rx_desc) * RX_RING_SIZE
+                           + sizeof(struct boom_tx_desc) * TX_RING_SIZE,
+                           vp->rx_ring, vp->rx_ring_dma);
 free_region:
        if (vp->must_free_region)
                release_region(ioaddr, vci->io_size);

A separate discussion:
Ethernet cards are numbered differently by different kernels.
A bit annoying, and I have tried to fix this a few times,
but probably one just should accept it.
The previous time this came up people answered and said:
use "nameif". OK. So I do, and I explained some SuSE people
my setup - perhaps they will try to make it standard.
But things are really kludgy.
With built-in ethernet cards I cannot use nameif to reshuffle
numbers. The only thing that works is to use entirely fresh
numbers. So if different kernels detect eth0 .. eth3 in
different orders then I can have "nameif eth4 $ADDR0" etc
in a boot script, and use eth4 .. eth7.
I don't know whether this was intended, or should be regarded a bug.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

boot messages

Post by Jeff Garzi » Wed, 23 Apr 2003 15:10:12



> Comparing my net sources with the vanilla sources showed
> a series of differences of which I sent most to you
> a moment ago. We still have one point of discussion.

> >> I suppose these can be removed altogether.
> >> For now #if 0 ... #endif.

> > would it not be preferable to mark these as KERN_DEBUG instead?

> I don't think so, but am willing to be convinced by Alan
> in the case of lba48 messages. In the other cases these
> messages just have to go.

FWIW, we don't like adding ifdefs to the kernel anyway.  Even if
you disagree WRT my KERN_DEBUG point, a tangent objection is also to
the #if's themselves.  I prefer a C if, or looking at the driver and
finding an appropriate existing #ifdef DEBUG construct.

Quote:> Boot messages must tell us what hardware is detected.
> We must not have debugging messages stating how
> much memory is allocated for slab cache or so.
> One can ask /proc after booting, and unless there are
> serious bugs in the code such things do not affect booting.

> When disk hardware is detected, I want to see manufacturer,
> model, serial number and capacity.
> When ethernet hardware is detected, I want to see manufacturer,
> model and MAC address. (Possibly also IRQ and ioport.)

agreed

For ethernet: mmio/pio port, mac addr, irq.  Most PCI net drivers should
already do this, and patches to add missing information are welcome.

Quote:> You never reacted, so I keep saying this until you either
> take this patch or explain why in case of this particular driver
> it is a bad idea to reveal the MAC address in the boot messages.

well, you did the right thing, with resending :)

Quote:> [I have also more general patches making sure that the MAC address
> is printed in a uniform way by all drivers, but that comes later.]

> Some more or less unrelated stuff below the patch.

> Andries

> diff -u --recursive --new-file -X /linux/dontdiff a/drivers/net/3c59x.c b/drivers/net/3c59x.c
> --- a/drivers/net/3c59x.c  Sun Apr 20 12:59:32 2003
> +++ b/drivers/net/3c59x.c  Sun Apr 20 19:07:00 2003

this looks ok to me.

In fact, I am wondering why this code wasn't here before, in fact,
because Donald Becker (original author) is usually pretty good about
printing out the MAC/etc. information for each interface found.

Quote:> A separate discussion:
> Ethernet cards are numbered differently by different kernels.
> A bit annoying, and I have tried to fix this a few times,
> but probably one just should accept it.
> The previous time this came up people answered and said:
> use "nameif".

Two points here:

1) official answer is, "if you want stable ethernet interface naming,
use nameif"

2) I have been told more than once that ethernet device allocation order
changed between 2.4 and 2.5.  I consider this a bug, and welcome patches
to fix it.  Note, though, that the recent PCI probe order fixes that
went in via Andrew Morton may have addressed this issue for some people.

        Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

boot messages

Post by Randy.Dunla » Wed, 23 Apr 2003 16:30:13



| > A separate discussion:
| > Ethernet cards are numbered differently by different kernels.
| > A bit annoying, and I have tried to fix this a few times,
| > but probably one just should accept it.
| > The previous time this came up people answered and said:
| > use "nameif".
|
| Two points here:
|
| 1) official answer is, "if you want stable ethernet interface naming,
| use nameif"

I did a short writeup about this.  See
  http://www.xenotime.net/linux/doc/network-interface-names.txt

| 2) I have been told more than once that ethernet device allocation order
| changed between 2.4 and 2.5.  I consider this a bug, and welcome patches
| to fix it.  Note, though, that the recent PCI probe order fixes that
| went in via Andrew Morton may have addressed this issue for some people.

Patch has already been posted 2 times.

--
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

boot messages

Post by Andries.Brou.. » Wed, 23 Apr 2003 17:20:14


Quote:> I did a short writeup about this.

Thanks!
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

boot messages

Post by Jeff Garzi » Wed, 23 Apr 2003 17:20:14



> | changed between 2.4 and 2.5.  I consider this a bug, and welcome patches
> | to fix it.  Note, though, that the recent PCI probe order fixes that
> | went in via Andrew Morton may have addressed this issue for some people.

> Patch has already been posted 2 times.

Out of sight, out of mind.  :)

I am also wondering how link order and PCI detection order are affecting
things, so re-testing without patches on 2.5.68-bk3 would be useful, for
those having problems.

Re-send the patch against 2.5.68-bk3 if the problem persists...

        Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. Ignoring specific boot messages / boot message redirection??

Hi everyone,

I have written a program that I call from a shell script which is
placed in /etc/rc2.d . This script calls another script which loads a
driver using the add_drv command. This is on Solaris 8.

Thing is, the driver is evaluation only - that's ok I am using it for
a really really basic function - it's just it prints a "please
register/purchase me" to the screen at boot:

"drvr: [ID 513294 kern.notice] Driver: This is an unregistered copy.
The driver will work for the next 60 minutes. To register please
contact..."

I thought in the calling script, I could just redirect output to
/dev/null yet this doesn't work. What is the driver writing to on
load? Is it the standard output? Is there a way to just
ignore/redirect this message so that at boot it is not displayed?

Can I do it by mucking around with syslog.conf? Although I would still
like to log kern.notice messages...

Any help in this matter will be appreciated...

Damien.

2. 250MB ATAPI Zip?

3. Logging boot messages(and crash messages)

4. port bind error....

5. How to captures all boot messages from kernel and daemons from cold boot?

6. smpatch with patch 119107-03 looks good

7. boot message errors

8. Solaris to Solaris ftp through Checkpoint

9. View booting messages after login...

10. Boot Messages - Would like to capture

11. Weird (but non-fatal) boot message with WD7000 SCSI controller

12. boot messages

13. mitsumi boot message