Re: dmesg of 2.5.45 boot on NFS client

Re: dmesg of 2.5.45 boot on NFS client

[Denis Vlasenko]

mii-tool -F 100baseTx-FD eth0

does not work in 2.5 while working fine in 2.4.
What should I do? Fix eth driver?
Use never mii-tool or equivalent?

# mii-tool --version
mii-tool.c 1.9 2000/04/28 00:56:08 (David Hinds)

# lspci
01:08.0 Ethernet controller: Intel Corp. 82820 (ICH2) Chipset Ethernet Controller (rev 03)

On 6 November 2002 18:57, Denis Vlasenko wrote:
> TCP: Hash tables configured (established 4096 bind 5461)
> Sending DHCP requests .fix old protocol handler
> ic_bootp_recv+0x0/0x3a0! .fix old protocol handler
> ic_bootp_recv+0x0/0x3a0!
> ,fix old protocol handler ic_bootp_recv+0x0/0x3a0!
>  OK

Dave, Arnaldo, I can attempt to fix this if you think
it's feasible to receive my possibly buggy newcomer code
instead of fixing it yourself. In this case, feel free
to apply a cluebat as to what should be done / where should
I look for example of 'new protocol handler' ;)

I know that plans are underway to push all this stuff to early
userspace but I need it *now* if I want to test 2.5 at this time.

I suspect you already seen these lines of code,
but here they are (2.5.47):

net/core/dev.c:
static int deliver_to_old_ones(struct packet_type *pt,
                               struct sk_buff *skb, int last)
{
        int ret = NET_RX_DROP;

        if (!last) {
                skb = skb_clone(skb, GFP_ATOMIC);
                if (!skb)
                        goto out;
        }
        if (skb_is_nonlinear(skb) && skb_linearize(skb, GFP_ATOMIC))
                goto out_kfree;

#if CONFIG_SMP
        /* Old protocols did not depened on BHs different of NET_BH and
           TIMER_BH - they need to be fixed for the new assumptions.
         */
        print_symbol("fix old protocol handler %s!\n", (unsigned long)pt->func);
#endif


net/ipv4/ipconfig.c:
...
static int ic_bootp_recv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt);

static struct packet_type bootp_packet_type __initdata = {
        .type = __constant_htons(ETH_P_IP),
        .func = ic_bootp_recv,
};
...
static int __init ic_bootp_recv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt)
{
        struct bootp_pkt *b = (struct bootp_pkt *) skb->nh.iph;
        struct iphdr *h = &b->iph;
        struct ic_device *d;
        int len;

        /* One reply at a time, please. */
        spin_lock(&ic_recv_lock);

        /* If we already have a reply, just drop the packet */
        if (ic_got_reply)
                goto drop;
--
vda

dmesg of 2.5.45 boot on NFS client

[Denis Vlasenko]

Registering system device cpu0
adding '' to cpu class interfaces
      ^^^^

;) What's this?


Serial: 8250/16550 driver $Revision: 1.90 $ IRQ sharing disabled
tts/%d0 at I/O 0x3f8 (irq = 4) is a 16550A
    ^^

;) 

register interface 'mouse' with class 'input

there's no closing '

TCP: Hash tables configured (established 4096 bind 5461)
Sending DHCP requests .fix old protocol handler ic_bootp_recv+0x0/0x3a0!
.fix old protocol handler ic_bootp_recv+0x0/0x3a0!
,fix old protocol handler ic_bootp_recv+0x0/0x3a0!
 OK

Aha... todo for me...

IP-Config: Got DHCP answer from 255.255.255.255, my address is 172.16.42.177
IP-Config: Complete:
      device=eth0, addr=172.16.42.177, mask=255.255.255.0, gw=172.16.42.98,
     host=(none), domain=, nis-domain=(none),
     bootserver=255.255.255.255, rootserver=172.16.42.75, rootpath=
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 172.16.42.75
Looking up port of RPC 100005/1 on 172.16.42.75
VFS: Mounted root (nfs filesystem).
Mounted devfs on /dev
Freeing unused kernel memory: 604k freed

~30 seconds of no apparent activity
I pressed SysRq-P couple of times, they all looked the same:

SysRq : Show Regs

Pid: 0, comm:              swapper
EIP: 0060:[<c01071aa>] CPU: 0
EIP is at default_idle+0x2a/0x50
 EFLAGS: 00000246    Not tainted
EAX: 00000000 EBX: c0466000 ECX: c0447800 EDX: c0466000
ESI: c0107180 EDI: c0466000 EBP: 0008e000 DS: 0068 ES: 0068
CR0: 8005003b CR2: 40001000 CR3: 07d54000 CR4: 000006d0
Call Trace:
 [<c010725a>] cpu_idle+0x3a/0x50
 [<c0105000>] stext+0x0/0x70

No need for ksymoops. Wow.

Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 93M
agpgart: agpgart: Detected an Intel i815 Chipset.
agpgart: AGP aperture is 64M @ 0xf0000000

Re: dmesg of 2.5.45 boot on NFS client

[Russell King]

On Wed, Nov 06, 2002 at 06:57:45PM -0200, Denis Vlasenko wrote:
> Serial: 8250/16550 driver $Revision: 1.90 $ IRQ sharing disabled
> tts/%d0 at I/O 0x3f8 (irq = 4) is a 16550A
>     ^^

Already killed.  I think it went in just after 2.5.46 was released.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: dmesg of 2.5.45 boot on NFS client

[Jeff Garzik]

Denis Vlasenko wrote:

> mii-tool -F 100baseTx-FD eth0
>
> does not work in 2.5 while working fine in 2.4.
> What should I do? Fix eth driver?
> Use never mii-tool or equivalent?
>
> # mii-tool --version
> mii-tool.c 1.9 2000/04/28 00:56:08 (David Hinds)
>
> # lspci
> 01:08.0 Ethernet controller: Intel Corp. 82820 (ICH2) Chipset Ethernet 
> Controller (rev 03)


Addressing only this specific issue, and not the larger $thread issue...

Depends on what driver and version you are using.  It is preferred these 
days to force the media using ethtool.  But that said, if a NIC driver 
allows you to force in 2.4 and not in 2.5, that definitely sounds like 
an eth driver bug.

	Jeff

Re: dmesg of 2.5.45 boot on NFS client

[Randy.Dunlap]

On Wed, 13 Nov 2002, Jeff Garzik wrote:

| Addressing only this specific issue, and not the larger $thread issue...
|
| Depends on what driver and version you are using.  It is preferred these
| days to force the media using ethtool.

That's news to me.  "preferred" by whom?  certainly not by real users ??
It should just work.

| But that said, if a NIC driver
| allows you to force in 2.4 and not in 2.5, that definitely sounds like
| an eth driver bug.

-- 
~Randy
  "I read part of it all the way through." -- Samuel Goldwyn

Re: dmesg of 2.5.45 boot on NFS client

[Jeff Garzik]

Randy.Dunlap wrote:

> On Wed, 13 Nov 2002, Jeff Garzik wrote:
>
> | Addressing only this specific issue, and not the larger $thread issue...
> |
> | Depends on what driver and version you are using.  It is preferred these
> | days to force the media using ethtool.
>
> That's news to me.  "preferred" by whom?  certainly not by real users ??
> It should just work.


You missed quoting the operation he was performing:  forcing the media 
using mii-tool.  He was forcing the media type by hand.  It's impossible 
for that to just-work.

I wasn't talking about setting media in general...

	Jeff

Re: dmesg of 2.5.45 boot on NFS client

[Randy.Dunlap]

On Wed, 13 Nov 2002, Jeff Garzik wrote:

| Randy.Dunlap wrote:
|
| > On Wed, 13 Nov 2002, Jeff Garzik wrote:
| >
| > | Addressing only this specific issue, and not the larger $thread issue...
| > |
| > | Depends on what driver and version you are using.  It is preferred these
| > | days to force the media using ethtool.
| >
| > That's news to me.  "preferred" by whom?  certainly not by real users ??
| > It should just work.
|
|
| You missed quoting the operation he was performing:  forcing the media
| using mii-tool.  He was forcing the media type by hand.  It's impossible
| for that to just-work.
|
| I wasn't talking about setting media in general...

Thanks.  I misread your statement then.

-- 
~Randy
  "I read part of it all the way through." -- Samuel Goldwyn

Re: dmesg of 2.5.45 boot on NFS client

[David S. Miller]

   From: "Randy.Dunlap" <rddunlap@osdl.org>
   Date: Wed, 13 Nov 2002 08:29:13 -0800 (PST)

   On Wed, 13 Nov 2002, Jeff Garzik wrote:
   
   | Addressing only this specific issue, and not the larger $thread issue...
   |
   | Depends on what driver and version you are using.  It is preferred these
   | days to force the media using ethtool.
   
   That's news to me.  "preferred" by whom?  certainly not by real users ??
   It should just work.
   
ethtool is the preferred way to modify any ethernet device parameter
whatsoever.  It is the king of net device APIs for such operations.

Franks a lot,
David S. Miller
davem@redhat.com