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
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 ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
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
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
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
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
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
From: "Randy.Dunlap" <[email protected]>
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
[email protected]