Hello, everyone,
The quick question: if I install PPP 2.4.1 in a Linux box w/ kernel 2.2.x,
will I have support to MLPPP??
Now, the explanation for my doubt. I've seen several (actually 3)
different MLPPP implementations for older versions of PPP/pppd (namely
2.3.5 and 2.3.11). I'd like to
Hello, everyone,
The quick question: if I install PPP 2.4.1 in a Linux box w/ kernel 2.2.x,
will I have support to MLPPP??
Now, the explanation for my doubt. I've seen several (actually 3)
different MLPPP implementations for older versions of PPP/pppd (namely
2.3.5 and 2.3.11). I'd like to
On Wed, 28 Mar 2001, Jeff Garzik wrote:
> Ivan Passos wrote:
> > Maybe it's a better idea to have just two ioctl's here (GET and SET), and
> > have "subioctl's" inside the structure passed to the HDLC layer (and
> > defined by the HDLC layer). This would
On 28 Mar 2001, Krzysztof Halasa wrote:
>
> What about a patch like this:
> That would move interface configuration out of private ioctl range,
> making it universal for all types of interfaces (now, we have different
> configuration mechanisms even between different HDLC cards).
Yes! This
On 28 Mar 2001, Krzysztof Halasa wrote:
What about a patch like this:
That would move interface configuration out of private ioctl range,
making it universal for all types of interfaces (now, we have different
configuration mechanisms even between different HDLC cards).
Yes! This would be
On Wed, 28 Mar 2001, Jeff Garzik wrote:
Ivan Passos wrote:
Maybe it's a better idea to have just two ioctl's here (GET and SET), and
have "subioctl's" inside the structure passed to the HDLC layer (and
defined by the HDLC layer). This would allow changes in the HDLC layer
with
On Sun, 11 Mar 2001, Andrey Panin wrote:
>
> this patch removes panic() calls and adds MODULE_DEVICE_TABLE to
> cyclades driver.
Patch looks good. Thanks for the patch, Andrey!
However: Linus, please do not apply this yet. I'll do tests with a new
Cyclades driver version we're about to
On Sun, 11 Mar 2001, Andrey Panin wrote:
this patch removes panic() calls and adds MODULE_DEVICE_TABLE to
cyclades driver.
Patch looks good. Thanks for the patch, Andrey!
However: Linus, please do not apply this yet. I'll do tests with a new
Cyclades driver version we're about to release,
Hello,
A customer has just brought to my attention that when you try to use the
TIOCMIWAIT ioctl with our boards and CLOCAL is enabled, you can't check
changes in the DCD signal. He also mentioned that that is possible with
the regular serial ports.
As I understood, CLOCAL meant disabling DCD
Hello,
A customer has just brought to my attention that when you try to use the
TIOCMIWAIT ioctl with our boards and CLOCAL is enabled, you can't check
changes in the DCD signal. He also mentioned that that is possible with
the regular serial ports.
As I understood, CLOCAL meant disabling DCD
On Fri, 2 Feb 2001, Ivan Passos wrote:
>
> On Fri, 2 Feb 2001, Ion Badulescu wrote:
>
> > On Fri, 2 Feb 2001 15:01:05 -0800 (PST), Ivan Passos <[EMAIL PROTECTED]> wrote:
> >
> > > Sometimes when I reboot the system, as soon as the eepro100 module is
>
On Fri, 2 Feb 2001, Ivan Passos wrote:
On Fri, 2 Feb 2001, Ion Badulescu wrote:
On Fri, 2 Feb 2001 15:01:05 -0800 (PST), Ivan Passos [EMAIL PROTECTED] wrote:
Sometimes when I reboot the system, as soon as the eepro100 module is
loaded, I start to get these msgs on the screen
On Mon, 12 Feb 2001, Scott Laird wrote:
>
> On 12 Feb 2001, H. Peter Anvin wrote:
> >
> > Just checked my own code, and SYSLINUX does indeed support 115200 (I
> > changed this to be a 32-bit register ages ago, apparently.) Still
> > doesn't answer the question "why"... all I think you do is
On Mon, 12 Feb 2001, Ivan Passos wrote:
>
> I'd like to have a LILO version that supports higher serial speeds than
> 9600bps. Questions:
> - Is there a version that already does that?
To answer one of my own questions: my current LILO version does support
speeds up to 38400bps.
Hello,
I'd like to have a LILO version that supports higher serial speeds than
9600bps. Questions:
- Is there a version that already does that?
- If not, do I need to change just LILO to do that, or do I need to change
the kernel as well (I don't think I'd need to do that too, as the serial
Hello,
I'd like to have a LILO version that supports higher serial speeds than
9600bps. Questions:
- Is there a version that already does that?
- If not, do I need to change just LILO to do that, or do I need to change
the kernel as well (I don't think I'd need to do that too, as the serial
On Mon, 12 Feb 2001, Ivan Passos wrote:
I'd like to have a LILO version that supports higher serial speeds than
9600bps. Questions:
- Is there a version that already does that?
To answer one of my own questions: my current LILO version does support
speeds up to 38400bps. I didn't try
On Mon, 12 Feb 2001, Scott Laird wrote:
On 12 Feb 2001, H. Peter Anvin wrote:
Just checked my own code, and SYSLINUX does indeed support 115200 (I
changed this to be a 32-bit register ages ago, apparently.) Still
doesn't answer the question "why"... all I think you do is increase
On Fri, 2 Feb 2001, Ion Badulescu wrote:
> On Fri, 2 Feb 2001 15:01:05 -0800 (PST), Ivan Passos <[EMAIL PROTECTED]> wrote:
>
> > Sometimes when I reboot the system, as soon as the eepro100 module is
> > loaded, I start to get these msgs on the screen:
> >
>
Hello,
The system is as follows:
- Intel CA810EAL motherboard (built-in EtherExpress Pro 10/100)
- 128MB RAM
- 10GB IDE HD (Western Digital WD100)
- Linux kernel 2.2.18
Sometimes when I reboot the system, as soon as the eepro100 module is
loaded, I start to get these msgs on the screen:
eth0:
Hello,
The system is as follows:
- Intel CA810EAL motherboard (built-in EtherExpress Pro 10/100)
- 128MB RAM
- 10GB IDE HD (Western Digital WD100)
- Linux kernel 2.2.18
Sometimes when I reboot the system, as soon as the eepro100 module is
loaded, I start to get these msgs on the screen:
eth0:
Hello,
The system is as follows:
- Intel CA810EAL motherboard (built-in EtherExpress Pro 10/100)
- 128MB RAM
- 10GB IDE HD (Western Digital WD100)
- Linux kernel 2.2.18
Sometimes when I reboot the system, as soon as the eepro100 module is
loaded, I start to get these msgs on the screen:
eth0:
Hello,
The system is as follows:
- Intel CA810EAL motherboard (built-in EtherExpress Pro 10/100)
- 128MB RAM
- 10GB IDE HD (Western Digital WD100)
- Linux kernel 2.2.18
Sometimes when I reboot the system, as soon as the eepro100 module is
loaded, I start to get these msgs on the screen:
eth0:
On Fri, 2 Feb 2001, Ion Badulescu wrote:
On Fri, 2 Feb 2001 15:01:05 -0800 (PST), Ivan Passos [EMAIL PROTECTED] wrote:
Sometimes when I reboot the system, as soon as the eepro100 module is
loaded, I start to get these msgs on the screen:
eth0: card reports no resources.
eth0: card
On Wed, 31 Jan 2001, Alan Cox wrote:
>
> It should be set before netif_rx() is called on the packet. Typically that
> means the driver or its support code sets protocol and nh.raw and if a
> second header is pulled up then they are set again by whichever code does that
> and calls netif_rx
On Wed, 31 Jan 2001, Alan Cox wrote:
> > What I'd like to know is: what exactly causes this msg?? It seems that
> > it's printed when someone sends a packet without properly setting
> > skb->nh.raw first, but who's supposed to set skb->nh.raw?? The HW driver??
> > The data link (HDLC) driver??
On Wed, 31 Jan 2001, Alan Cox wrote:
What I'd like to know is: what exactly causes this msg?? It seems that
it's printed when someone sends a packet without properly setting
skb-nh.raw first, but who's supposed to set skb-nh.raw?? The HW driver??
The data link (HDLC) driver?? The
On Wed, 31 Jan 2001, Alan Cox wrote:
It should be set before netif_rx() is called on the packet. Typically that
means the driver or its support code sets protocol and nh.raw and if a
second header is pulled up then they are set again by whichever code does that
and calls netif_rx again
Hello,
I have a customer who's getting tons of these msgs in his LOGs:
kernel: protocol 0008 is buggy, dev hdlc0
kernel: protocol 0608 is buggy, dev hdlc0
The msg comes from net/core/dev.c, and this device is using the Cisco HDLC
protocol in drivers/net/hdlc.c . However, AFAIK, 0008 and 0608
Hello,
I have a customer who's getting tons of these msgs in his LOGs:
kernel: protocol 0008 is buggy, dev hdlc0
kernel: protocol 0608 is buggy, dev hdlc0
The msg comes from net/core/dev.c, and this device is using the Cisco HDLC
protocol in drivers/net/hdlc.c . However, AFAIK, 0008 and 0608
On Tue, 9 Jan 2001, David Weinehall wrote:
> Everyone laughs, I guess. The 2.0.39final didn't became the final
> release (could've told you so...) The good thing? Well, some bugs were
> found and removed. But this is it. Enjoy!
Well, where is it?? :)
I tried ftp.us.kernel.org, but couldn't
On Tue, 9 Jan 2001, David Weinehall wrote:
Everyone laughs, I guess. The 2.0.39final didn't became the final
release (could've told you so...) The good thing? Well, some bugs were
found and removed. But this is it. Enjoy!
snip
Well, where is it?? :)
I tried ftp.us.kernel.org, but couldn't
On Tue, 5 Dec 2000, Mark Cooke wrote:
>
> struct foo {
> unsigned intcrufty_compatability_number;
> .
> .
> .
> };
>
> ?
The problem is not this, but structure alignment and copy_[to|from]_user
operations. This approach, although it's my preferred one (due to
On Tue, 5 Dec 2000, Matthew G. Marsh wrote:
>
> I would like to note an objection to using ifconfig to carry all of this.
> For example I do not use or even have ifconfig on any of my systems as I
> only use/need/want Alexey's ip utility to perform all of those tasks.
>
> I would rather have
On Tue, 5 Dec 2000, Alan Cox wrote:
>
> I think a new ioctl would be sensible. There is a lot to go in it.
Alan, what's the approach you'd feel more comfortable with:
- One ioctl that passes a pointer to a known structure in ifr.ifr_data as
its argument.
- Several ioctl's, one for each
On Tue, 5 Dec 2000, Francois Romieu wrote:
> Ivan Passos <[EMAIL PROTECTED]> écrit :
> >
> > - Media: V.35, RS-232, X.21, T1, E1
>
> I don't exactly see the point here: do some of your cards supports these
> media at the same time ? I would have believed it to be
On Tue, 5 Dec 2000, Francois Romieu wrote:
Ivan Passos [EMAIL PROTECTED] écrit :
- Media: V.35, RS-232, X.21, T1, E1
I don't exactly see the point here: do some of your cards supports these
media at the same time ? I would have believed it to be set in stone.
Yes. The PC300/RSV
On Tue, 5 Dec 2000, Alan Cox wrote:
I think a new ioctl would be sensible. There is a lot to go in it.
Alan, what's the approach you'd feel more comfortable with:
- One ioctl that passes a pointer to a known structure in ifr.ifr_data as
its argument.
- Several ioctl's, one for each
On Tue, 5 Dec 2000, Matthew G. Marsh wrote:
I would like to note an objection to using ifconfig to carry all of this.
For example I do not use or even have ifconfig on any of my systems as I
only use/need/want Alexey's ip utility to perform all of those tasks.
I would rather have an
On Tue, 5 Dec 2000, Mark Cooke wrote:
struct foo {
unsigned intcrufty_compatability_number;
.
.
.
};
?
The problem is not this, but structure alignment and copy_[to|from]_user
operations. This approach, although it's my preferred one (due to being
Hello,
Thanks to all of you who responded to my first RFC on this subject. The
discussion ended up going in the Ethernet direction, and I frankly don't
know whether that applies to this case, or even if it _should_ apply or
they should really be separate config. subsystems. This is another
Hello,
Thanks to all of you who responded to my first RFC on this subject. The
discussion ended up going in the Ethernet direction, and I frankly don't
know whether that applies to this case, or even if it _should_ apply or
they should really be separate config. subsystems. This is another
Hello,
For synchronous network interfaces, besides configuring network parameters
such as IP address, netmask, MTU, etc., the system should also configure
parameters specific to these sync i/f's, such as media (e.g V.35, X.21,
T1, E1), clock (internal or external, and value if int.), protocol
Hello,
For synchronous network interfaces, besides configuring network parameters
such as IP address, netmask, MTU, etc., the system should also configure
parameters specific to these sync i/f's, such as media (e.g V.35, X.21,
T1, E1), clock (internal or external, and value if int.), protocol
Hello,
Where in the src tree can I find (or what is) the command to generate a
patch file from two Linux kernel src trees, one being the original and the
other being the newly changed one??
I've tried 'diff -ruN', but that does diff's on several files that could
stay out of the comparison
Hello,
Where in the src tree can I find (or what is) the command to generate a
patch file from two Linux kernel src trees, one being the original and the
other being the newly changed one??
I've tried 'diff -ruN', but that does diff's on several files that could
stay out of the comparison
Hello,
I was just checking the driver changes needed to comply with the new PCI
architecture in 2.4.x, and then I got into a problem. I noticed that all
drivers that use this architecture (or at least the ones I found, such as
the Tulip, EEPro100, 3c59x ...) support boards with only one
Hello,
I was just checking the driver changes needed to comply with the new PCI
architecture in 2.4.x, and then I got into a problem. I noticed that all
drivers that use this architecture (or at least the ones I found, such as
the Tulip, EEPro100, 3c59x ...) support boards with only one
On Thu, 28 Sep 2000, Ivan Passos wrote:
>
> In order to get the configuration of a board, I have to send, from
> userspace, an ioctl to the driver and wait for the board to complete its
> action. The way this is implemented is as follows:
> - In the ioctl, the driver
On Thu, 28 Sep 2000, Ivan Passos wrote:
In order to get the configuration of a board, I have to send, from
userspace, an ioctl to the driver and wait for the board to complete its
action. The way this is implemented is as follows:
- In the ioctl, the driver sends a command to the board
Hello,
I have a customer who's getting tons of this msg in his LOGs:
kernel: protocol 0008 is buggy, dev hdlc0
The msg comes from net/core/dev.c, and this device is using the Frame
Relay protocol in drivers/net/hdlc.c .
What I'd like to know is:
- What exactly causes this msg?? It seems that
Hello,
I have a customer who's getting tons of this msg in his LOGs:
kernel: protocol 0008 is buggy, dev hdlc0
The msg comes from net/core/dev.c, and this device is using the Frame
Relay protocol in drivers/net/hdlc.c .
What I'd like to know is:
- What exactly causes this msg?? It seems that
Hello,
In order to get the configuration of a board, I have to send, from
userspace, an ioctl to the driver and wait for the board to complete its
action. The way this is implemented is as follows:
- In the ioctl, the driver sends a command to the board and then goes to
sleep
Hello,
In order to get the configuration of a board, I have to send, from
userspace, an ioctl to the driver and wait for the board to complete its
action. The way this is implemented is as follows:
- In the ioctl, the driver sends a command to the board and then goes to
sleep
On Wed, 27 Sep 2000, Hen, Shmulik wrote:
>
> Is there a good source of information that describes the changes in network
> driver interface between 2.2.x and 2.4.x kernels ?
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0002.1/0408.html
On Wed, 27 Sep 2000, Hen, Shmulik wrote:
Is there a good source of information that describes the changes in network
driver interface between 2.2.x and 2.4.x kernels ?
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0002.1/0408.html
On Thu, 31 Aug 2000, Andi Kleen wrote:
>
> Most of your questions should be answered in packet(7)
You mean packet(4)?? BTW, very nice piece of documentation!!
> In future please try to consult the available documentation before asking
> user questions on the kernel list.
Actually my question
On Thu, 31 Aug 2000, Alan Cox wrote:
> > What I still don't understand is how the network layer will pass the
> > request directly to the driver _without_ goind through the INET (IP)
> > layer ... Do you know of any src code that I could use as a reference??
> > Src code that does the "request
On Thu, 31 Aug 2000, Alan Cox wrote:
> > BSD sockets in the kernel?? I'm trying to learn how to implement a
> > "raw" network point-to-point interface (i.e. no protocols, just data), but
> > I'm having trouble understanding what I need to change or do.
>
> Implement just the hardware driver.
Hello,
Quick question: does anybody here know of a good _online_ reference for
BSD sockets in the kernel?? I'm trying to learn how to implement a
"raw" network point-to-point interface (i.e. no protocols, just data), but
I'm having trouble understanding what I need to change or do.
I already
Hello,
Quick question: does anybody here know of a good _online_ reference for
BSD sockets in the kernel?? I'm trying to learn how to implement a
"raw" network point-to-point interface (i.e. no protocols, just data), but
I'm having trouble understanding what I need to change or do.
I already
61 matches
Mail list logo
