Linux-Development-Sys Digest #285, Volume #8 Fri, 17 Nov 00 07:13:09 EST
Contents:
Kernel Panic after booting recompiled kernel ([EMAIL PROTECTED])
Re: Kernel Panic after booting recompiled kernel (Kaz Kylheku)
Re: injecting keystrokes into virtual console ([EMAIL PROTECTED])
Re: make[3]: *** [ip_masq.o] Error 1 ([EMAIL PROTECTED])
Re: make[3]: *** [ip_masq.o] Error 1 ("Paul D. Smith")
Re: raw packet socket; how to retransmit ("Vadim Model")
Re: raw packet socket; how to retransmit ("Vadim Model")
Re: Kernel Panic after booting recompiled kernel ("Slawek Grajewski")
Re: Pointers, arrays and in_addr! ("Slawek Grajewski")
Re: uaccess question (Arne Driescher)
Re: raw packet socket; how to retransmit (Guy Bolton King)
Re: raw packet socket; how to retransmit (Andi Kleen)
TCP congestion-avoiding slow start mode (Jerome Corre)
RFC POP (Vincent Deverre)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Kernel Panic after booting recompiled kernel
Date: Thu, 16 Nov 2000 21:42:07 GMT
I know that there may have been numerous gripes concerning kernel
panic, but I have not found a similar problem to mine and I have been
unsuccessful in trying the solutions that others have suggested.
The error message that I receive after booting off of my newly
recompiled kernel is:
"Error, Cannot mount root fs on 21:06"
"Kernel Panic ... "
The error messages I have seen others post are usually for when root fs
cannot be mounted at 3:08 or something to the effect. I have tried
redirecting the root mount on the floppy to /mnt/hde6 which is the
mount for my root partition. I have actually even tried compiling the
kernel on another machine in which no changes were made and I still
receive the exact same error. I have even reinstalled everything and
still much to no avail. The two machines have the same board, abit be6.
Any suggestions?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Kernel Panic after booting recompiled kernel
Reply-To: [EMAIL PROTECTED]
Date: Thu, 16 Nov 2000 22:51:54 GMT
On Thu, 16 Nov 2000 21:42:07 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
>The error messages I have seen others post are usually for when root fs
>cannot be mounted at 3:08 or something to the effect. I have tried
>redirecting the root mount on the floppy to /mnt/hde6 which is the
>mount for my root partition.
man rdev
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: injecting keystrokes into virtual console
Date: Fri, 17 Nov 2000 02:32:22 -0000
On Thu, 16 Nov 2000 07:09:47 GMT George MacDonald <[EMAIL PROTECTED]> wrote:
| I don't quite understand what you are trying to do, nor how fast you
| want a solution, nor how widely deployed it will be. I just offered the hardware info
| in case you didn't know about it. It could be used in some circumstances,
| i.e. driving an OS test suite, or for performance testing ...
| I just know about it, but have never tried it myself...
I want one program to feed input into several sessions so that those
sessions get initialized just as if I had spent the time to type it all in
myself. Since it involves about 500 keystrokes into 40 or more sessions, it
would be of great value to have this done for me. Having 40 extra
processes between the real console devices and the ptys seems to me to be a
waste. I'm trying to eliminate it, not change it over to a hardware
solution that involves a converter and another computer, costing at least
another $1000.
| Automating logins seems to be that hardest part, once logged in you can
| run psuedo tty's for most things. X terminal windows ...
That's what I'm trying to eliminate. A lot of these sessions produce some
significant output and I feel the extra pty and process layers are slowing
things down. Since all the process is doing once the session is initialized
is copying data back and forth, it seems to be a waste to even have it
there. Yet, manually setting up the sessions is time consuming and error
prone.
--
| Phil Howard - KA9WGN | My current websites: linuxhomepage.com, ham.org
| phil (at) ipal.net +----------------------------------------------------
| Dallas - Texas - USA | [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: make[3]: *** [ip_masq.o] Error 1
Date: Fri, 17 Nov 2000 02:32:57 GMT
Well, that was a load of horse shit.
That didn't work either.
I eventually installed kgcc (egcs-2.91.66) and noticed that make
bzImage started to use both gcc and kgcc for certain parts.
Same shit happened.
I'll spare Linux, but I'm getting the sense that RedHat sucks shit and
is just using us as quality assurance. I'm glad I didn't buy the piece
of shit- but I'm not sure it was worth the $5 in CDs I burned.
I'm so sick of wasting my fucking time with this bullshit that I'll
send you a check for $50 if your advice can lead me to a successful
kernel build which gets my NE2000 NIC working. It worked on previous
RedHat builds, but past performance is no guarantee for these e-holes.
Thanks
Brian
In article <8uvoq4$i0d$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I found a totally obscure net posting inside a huge text file at some
> site.
>
> Essentially, the solution is to compile IP Masq. as a module and not
> into the kernel.
>
> My machine is currently chugging away at the build...
>
> Brian
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Paul D. Smith" <[EMAIL PROTECTED]>
Subject: Re: make[3]: *** [ip_masq.o] Error 1
Date: 16 Nov 2000 22:47:49 -0500
Reply-To: [EMAIL PROTECTED]
I've said it before, and I'll say it again: anyone who tries to use any
RedHat x.0 release is either a masochist, or has too much time on their
hands. Or both.
RH pushes the envelope with bleeding-edge software _all_ the time.
First all-ELF distro. First libc6 distro. And, they make big mistakes
(bogus version of glibc released; bogus version of gcc in 7.0). It's a
good service to the Linux community to get this stuff out and have
people use it; the "state of the art" in these areas always improves
dramatically, quickly, when that happens.
But, if you're just looking for a stable Linux platform, I would _never_
go with any RedHat x.0 release.
All IMHO, of course. I used RedHat for years; I've switched to Debian
on my personal system a while ago and would never go back, but I still
have RedHat at work.
--
===============================================================================
Paul D. Smith <[EMAIL PROTECTED]> HASMAT--HA Software Methods & Tools
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
===============================================================================
These are my opinions---Nortel Networks takes no responsibility for them.
------------------------------
From: "Vadim Model" <[EMAIL PROTECTED]>
Subject: Re: raw packet socket; how to retransmit
Date: Fri, 17 Nov 2000 10:10:18 +0300
Grant Edwards wrote in message <1sWQ5.8800>
>Agreed -- all of the Ethernet controllers I've seen made that
>information available. The problem is that it's extremely
>difficult (with current stack/driver designs) to get that
>status info back up to the application. At the point where the
>Tx failure status is known, the driver typically doesn't know
>to whom the failed packet belongs.
>
>That information could, in theory, be passed back up to the
>application, but it's a pretty nasty problem. The send() or
>write() syscall returns as soon as the information has been
>queued for transmit. At some point later in time, the Ethernet
>driver notices that a transmit failed. Now there are two
>problems:
>
> 1) The ethernet driver doesn't know who requested the packet
> be sent.
>
> 2) If it did, there isn't a well-defined way (other than a
> signal) to inform an application of an asynchronous error
> like that.
Yes. Actually this is exactly what I see looking into kernel. I know this is
just a design issue of any UNIX. Sometimes I see that UNIX is quite well
designed but there are some solutions which could not be easily implemented
in any UNIX platform. BTW: In the situation we are talking about, Windows
NT/2000 is much more convenient: it associates a request with every packet
sent via similar packet interface, so that you can synchronize execution
with completion of requests processing and obtain status of transmission: OK
or NOT.
And of course I do not want anybody to rewrite the whole Linux kernel. I
just asked if there is something in Linux which I do not see. Looks like
there is no "undocumented" feature which would help me.
>If you just want to query the state of the interface, that's a
>considerably easier problem. Doing a cat on /proc/dev/net
>shows fields for both collisions and carrier-faults (among
>other things).
Yes, and this is what I do now. But the problem is that I have to know when
my packet is processed by hardware. For the moment I just wait for any
change in TX statistics and then I check which counter is changed. But I can
not agree this is a reliable solution. Given the fact that Linux is quite
"liquid" who guarantees that some clever driver writer does not forget to
update TX statistics? If there is no accepted standard interface, there is
no guarantee.
>I don't know if there is a more direct API to get that info,
Loks like there is no one.
>but open() and read() on /proc/net/dev/ should get you that
>info.
>
>--
>Grant Edwards grante Yow! Bo Derek ruined
> at my life!
> visi.com
------------------------------
From: "Vadim Model" <[EMAIL PROTECTED]>
Subject: Re: raw packet socket; how to retransmit
Date: Fri, 17 Nov 2000 10:17:15 +0300
Andi Kleen wrote in message ...
>No you can't. That was the whole point. The linux ethernet layer honours
>the IP internetworking principle that states "packets can be dropped
This is what I suspected but just asked to be sure.
>For an reliable protocol you need at least L3 acknowledgements.
Quite agree.
Regards,
Vadim
------------------------------
From: "Slawek Grajewski" <[EMAIL PROTECTED]>
Subject: Re: Kernel Panic after booting recompiled kernel
Date: Fri, 17 Nov 2000 09:35:59 +0100
>The error message that I receive after booting off of my newly
>recompiled kernel is:
>
>"Error, Cannot mount root fs on 21:06"
>"Kernel Panic ... "
>
This message means that your system can not mount /dev/hde6 as a root. So
you probably don't have valid file system in this locaiton.
------------------------------
From: "Slawek Grajewski" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development
Subject: Re: Pointers, arrays and in_addr!
Date: Fri, 17 Nov 2000 10:28:25 +0100
The below program does what you want (I hope).
The best source for information on C language is Kernighan & Ritchie book on
C language:
"http://s1.amazon.com/exec/varzea/ts/exchange-glance/Y01Y4217460Y0732303/qid
=974453189/sr=1-2/ref=aps_sr_z_2_2/107-6173044-1111761"
Hope this helsp.
Slawek
#include <stdio.h>
#include <stdlib.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
int main(int argc, char **argv)
{
struct in_addr *ip;
struct in_addr **addr_list;
/* allocate table for 1024 pointers to address structures */
addr_list = (struct in_addr **)malloc(1024*sizeof(addr_list[0]));
/* allocate memory for address #1 */
ip = malloc(sizeof(*ip));
inet_aton("192.168.1.1", ip);
addr_list[0] = ip;
/* allocate memory for address #2 */
ip = malloc(sizeof(*ip));
inet_aton("192.168.1.5", ip);
addr_list[1] = ip;
printf("addr_list[0] : %s\n", inet_ntoa(*addr_list[0]));
printf("addr_list[1] : %s\n", inet_ntoa(*addr_list[1]));
free(addr_list[0]);
free(addr_list[1]);
free(addr_list);
return 0;
}
Christoper McClan wrote in message
<8v1e6c$if6$[EMAIL PROTECTED]>...
>A small snipet of code :
>
>#include <all relevant headers>
>int main (int argc, char **argv)
>{
> struct in_addr ip1;
> char **addr_list;
> char *A;
> addr_list = (char **)malloc(1024);
> ip1 = *((struct in_addr *)malloc(1024));
> inet_aton("192.168.1.1",&ip1);
> addr_list[0]=(char *)&ip1;
> inet_aton("192.168.1.5",&ip1);
> addr_list[1]=(char *)&ip1;
> printf("addr_list[0] : %s\n",inet_ntoa(*(struct in_addr
*)addr_list[0]));
> printf("addr_list[1] : %s\n",inet_ntoa(*(struct in_addr
*)addr_list[1]));
>}
>The output is :
>addr_list[0] : 192.168.1.5
>addr_list[1] : 192.168.1.5
>
>I'm not briliant with pointers and referencing etc, does anyone know of a
good
>resource for me to look them up?
>
>Obviously I want to copy the IP addresses into the addr_list array rather
than
>copy a pointer to a in_addr structure (which is what I think is going on!?)
>
>Fairly inexperienced at all this!
>
>Thanks,
>
>Christopher.
------------------------------
From: Arne Driescher <[EMAIL PROTECTED]>
Subject: Re: uaccess question
Date: Fri, 17 Nov 2000 11:44:30 +0100
Thanx for your response.
>
> It is basically if (ptr+size < __PAGE_OFFSET) return -EFAULT; done in lots
> of assembly magic to avoid overflows and make it as fast as possible.
> In 2.2 code you should not use verify_area anymore but only check the return
> value of the *_user() call directly, because it is the one that checks the
> page tables by handling the exceptions properly.
I used verify_area only becaue copy_from_user failed and
copy_from_user calls range_ok and verify_area is only a wrapper for
range_ok. So, range_ok is the function that really fails.
>
> When you pass it a correct address it should not fail though, so you're
> probably passing a wrong one.
I am passing the right address. The call to the ioctl does not change
if the size of the array is increased. I even checked the addresses with
a printk for both cases (both are the same).
Meanwhile a have looked at the output of objdump and tried to figure
out
what is really going on.
000002b0 <ioctl_download_microcode>:
2b0: 55 push %ebp
2b1: 89 e5 mov %esp,%ebp
2b3: 81 ec 1c 40 00 00 sub $0x401c,%esp
2b9: 57 push %edi
2ba: 56 push %esi
2bb: 53 push %ebx
2bc: 8b 75 08 mov 0x8(%ebp),%esi addr->esi
2bf: 85 f6 test %esi,%esi if(addr==NULL)
2c1: 74 3e je 301
<ioctl_download_microcode+0x51>
2c3: b8 00 e0 ff ff mov $0xffffe000,%eax
2c8: 21 e0 and %esp,%eax
2ca: 89 f2 mov %esi,%edx
2cc: 81 c2 08 40 00 00 add $0x4008,%edx add size of struct
to addr
2d2: 19 c9 sbb %ecx,%ecx carry ->ecx
2d4: 39 50 0c cmp %edx,0xc(%eax)
2d7: 83 d9 00 sbb $0x0,%ecx
2da: 89 c8 mov %ecx,%eax
2dc: 31 d2 xor %edx,%edx
2de: 85 c0 test %eax,%eax
2e0: 74 05 je 2e7
<ioctl_download_microcode+0x37>
2e2: ba f2 ff ff ff mov $0xfffffff2,%edx
2e7: 89 d7 mov
%edx,%edi
The interesting part is at 2c8. I don't know much about the internal
memory layout
of the kernel. But this suggested that my esp is not where it should be.
Removing the allocation of the local variable micro_code and replacing
it by
memory obtained via vmalloc resolved the problem. I guess there is some
really small limit to the stack size in kernel space. If anybody
really knows why and how big it is, plz let me know.
-Arne
------------------------------
From: Guy Bolton King <[EMAIL PROTECTED]>
Subject: Re: raw packet socket; how to retransmit
Date: Fri, 17 Nov 2000 09:51:37 +0000
Vadim Model wrote:
>
> Andi Kleen wrote in message ...
> >No you can't. That was the whole point. The linux ethernet layer honours
> >the IP internetworking principle that states "packets can be dropped
>
> This is what I suspected but just asked to be sure.
>
> >For an reliable protocol you need at least L3 acknowledgements.
>
> Quite agree.
>
> Regards,
> Vadim
Vadim,
I recently encountered an equivalent problem, which it probably
wouldn't hurt to be aware of: when injecting packets using the
PF_PACKET socket interface, it is possible for the driver packet queue
to become full, at which point packets queued at the packet scheduling
layer are quietly dropped.
Since the environment I was working could guarantee that only one
process was using the ethernet device at a time, I crufted up a /proc
driver that simply dumped the packet drop statistics from the packet
scheduling layer:
for(pdev = dev_base; pdev && result < MAXFILELEN; pdev = pdev->next){
result += sprintf(page + result, "%s", pdev->name);
if(pdev->qdisc){
result += sprintf(page + result,
"\t%i\n",pdev->qdisc->stats.drops);
}
else{
result += sprintf(page + result, "*\n");
}
}
Whilst this doesn't tell you _which_ packets have been dropped, it at
least lets you know that _some_ have been dropped. It's far from
perfect, but perhaps you could extend your ethernet driver to count
TX failures and do the same sort of thing i.e. tell you that _some_
packets have failed to transmit.
I guess the full solution to your problem would be to implement a char
driver interface to your ethernet card and have non-blocking writes
which would return error on TX failure, bypassing the entire socket
layer. Of course, this may be overkill for your current requirements.
Guy.
------------------------------
From: Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: raw packet socket; how to retransmit
Date: 17 Nov 2000 11:50:25 +0100
[EMAIL PROTECTED] (Grant Edwards) writes:
>
> 1) The ethernet driver doesn't know who requested the packet
> be sent.
Actually it does, otherwise it wouldn't be able to manage the socket
send buffer. It'll just not help the original poster because there is no error state
passed
to the destructor callback.
(but then it is useless anyways, because successfull TX says nothing alltogether
about successfull arrival even at the link layer)
> 2) If it did, there isn't a well-defined way (other than a
> signal) to inform an application of an asynchronous error
> like that.
Linux 2.2 has one. See ip(7), MSG_ERRQUEUE. It is only feed by ICMP messages
currently.
-Andi
------------------------------
From: Jerome Corre <[EMAIL PROTECTED]>
Subject: TCP congestion-avoiding slow start mode
Date: Fri, 17 Nov 2000 11:33:51 GMT
Hi,
Where can I find out more about the TCP protocol and this mode?
Is there a way to know when the slow start is active or inactive during
a transmition? is there a way to force this mode constantly? is there
any other mode?
thanks for any help
Jerome
--
Jerome Corre
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Vincent Deverre <[EMAIL PROTECTED]>
Subject: RFC POP
Date: Fri, 17 Nov 2000 13:00:27 +0100
Quelqu'un pourrait il m'envoyer par mail le fichier RFC correspondant au
protocol POP3
Merci
--
+===========================================+
Vincent Deverre
Mail:[EMAIL PROTECTED]
+===========================================+
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
