MLPPP in kernels 2.2.x w/ PPP v2.4.1
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 know if once I install PPP 2.4.1 in a system w/ kernel 2.2.x, I kill my need for these kind of patches in order to support MLPPP. Or would I still need some kind of patch, even for PPP 2.4.1, to have MLPPP support in kernels 2.2.x?? I know that for kernels 2.4.x these patches are not needed. Thanks in advance for your help! Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: configuring net interfaces
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 > > without having to change sockios.h (you'd still have to change HDLC's > > code and definitions, but this would be more self-contained). Again, this > > may be better, or maybe not. What do you think? > > That's essentially what's happening with ethtool > (include/linux/ethtool.h in 2.4.3-pre8) Then maybe it's really a better idea, after all. ;) Krzysztof, please let us know what you think. Regards, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: configuring net interfaces
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 great.
> +struct hdlc_physical /* 10 bytes */
> +{
> + unsigned int interface;
> + unsigned int clock_rate;
> + unsigned short clock_type;
> +};
I guess 'interface' means media type (e.g. V.35, RS-232, X.21, etc.).
Maybe it would be more intuitive to call it 'media'. What do you think?
Also, for synchronous cards that have built-in DSU/CSU's (such as the
Cylades-PC300/TE), it's also necessary to configure T1/E1 parameters
(e.g. line code, frame mode, active channels, etc.). Should we make these
parameters also available here or keep them in the driver realm?? I think
we should have them here too, but maybe you see some problem with this
that I don't. Please advice.
> +struct hdlc_protocol /* 4 bytes */
> +{
> + unsigned int proto;
> +};
What are the possible protocols to be set here?? I imagine PPP, Cisco
HDLC, Raw HDLC, Frame Relay, X.25, and ... ?? Is that it??
> +struct fr_protocol /* 12 bytes */
> +{
> + unsigned short lmi_type;
> + unsigned short t391;
> + unsigned short t392;
> + unsigned short n391;
> + unsigned short n392;
> + unsigned short n393;
> +};
So we would have hdlc_protocol->proto set to PROTO_FR, and then the
details about Frame Relay would be set in this separate structure. Is that
what you have in mind??
> --- linux-2.4.orig/include/linux/sockios.hSun Nov 12 04:02:40 2000
> +++ linux-2.4/include/linux/sockios.h Wed Mar 28 16:35:23 2001
> @@ -76,6 +76,12 @@
> #define SIOCSIFDIVERT0x8945 /* Set frame diversion options */
>
> #define SIOCETHTOOL 0x8946 /* Ethtool interface*/
> +#define SIOCSHDLC_PHY0x8947 /* set physical HDLC iface */
> +#define SIOCGHDLC_PHY0x8948 /* get physical HDLC iface */
> +#define SIOCSHDLC_PROTO 0x8949 /* set HDLC protocol*/
> +#define SIOCGHDLC_PROTO 0x894A /* get HDLC protocol*/
> +#define SIOCSFR_PROTO0x894B /* set Frame-Relay protocol */
> +#define SIOCGFR_PROTO0x894C /* get Frame-Relay protocol */
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
without having to change sockios.h (you'd still have to change HDLC's
code and definitions, but this would be more self-contained). Again, this
may be better, or maybe not. What do you think?
Regards,
Ivan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] /drivers/char/cyclades.c: panic() call removal
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, and then I'll submit patches to the Cyclades driver once the tests are done (and they'll include Andrey's patch). Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CLOCAL and TIOCMIWAIT
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 sensitivity, so if CLOCAL is disabled, no changes in DCD will be passed from hardware driver to the kernel or userspace. The way the serial driver is implemented, this is not true (i.e. even with CLOCAL enabled, you can still see DCD changes through the TIOCMIWAIT command). My question is: what's the correct interpretation of CLOCAL?? If the serial driver's interpretation is the correct one, I'll be more than happy to change the Cyclades' driver to comply with that, I just want to make sure that this is the expected behavior before I patch the driver. Thanks in advance for your comments. Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18: weird eepro100 msgs
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: > > > > > > eth0: card reports no resources. > > > eth0: card reports no RX buffers. > > > eth0: card reports no resources. > > > eth0: card reports no RX buffers. > > > eth0: card reports no resources. > > > eth0: card reports no RX buffers. > > > (...) > > > > Does the following patch, taken from 2.4.1, help? > > I'm currently testing. I'll get back to you soon (have to reboot the > system a lot to make sure it's really solved ... :)). Yes, the patch did solve the problem. Alan, could you please include this patch on your 2.2.19pre series (if it's not already included)?? Ion, thanks again for your help!! Later, Ivan --- linux-2.2.18/drivers/net/eepro100-old.c Fri Feb 2 15:30:23 2001 +++ linux-2.2.18/drivers/net/eepro100.c Fri Feb 2 15:33:19 2001 @@ -751,6 +751,7 @@ This takes less than 10usec and will easily finish before the next action. */ outl(PortReset, ioaddr + SCBPort); + inl(ioaddr + SCBPort); /* Honor PortReset timing. */ udelay(10); @@ -839,6 +840,7 @@ #endif /* kernel_bloat */ outl(PortReset, ioaddr + SCBPort); + inl(ioaddr + SCBPort); /* Honor PortReset timing. */ udelay(10); @@ -1062,6 +1064,9 @@ /* Set the segment registers to '0'. */ wait_for_cmd_done(ioaddr + SCBCmd); outl(0, ioaddr + SCBPointer); + /* impose a delay to avoid a bug */ + inl(ioaddr + SCBPointer); + udelay(10); outb(RxAddrLoad, ioaddr + SCBCmd); wait_for_cmd_done(ioaddr + SCBCmd); outb(CUCmdBase, ioaddr + SCBCmd); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LILO and serial speeds over 9600
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 > > the risk for FIFO overrun and lost characters (flow control on a boot > > loader console is vestigial at the best.) > > It's simple -- we want the kernel to have its serial console running at > 115200, and we don't want to have to change speeds to talk to the > bootloader. Exactly. Then HPA may ask: but why do you want to run the serial console at 115200?? The answer is simple: because we can (or more precisely, because the HW can ;). If the hardware is supposed to support 115.2Kbps, why can't / shouldn't we use it?? Remember, this is not a modem connection, there is no compression involved, both sides are running 115.2Kbps, so there should NOT be a risk for FIFO overruns (unless you have buggy hardware). And in this case, you can then decrease your baud rate. But at least you have the _option_! :) > Some boot processes, particularaly fsck, can be *REALLY* > verbose on screwed up systems. I've seen systems take hours to run fsck, > even on small filesystems, simply because they were blocking on a 9600 bps > console. This is true!! Another one (not as critical as the fsck though): when compiling the kernel, sometimes the kernel compilation is done, but the console output isn't finished yet (I'm serious). Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://vger.kernel.org/lkml/
Re: LILO and serial speeds over 9600
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 it before because the _man page_ said it supported up to 9600 (and I believed in it :), but after checking LILO's Changelog, I found that support for speeds up to 38400 is available for a long time now. I tested it running at 38400 and it works. Since I still want to add support for speeds up to 115200, the other two questions are still up (see below): > - 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 > console kernel code does support up to 115.2Kbps, but it doesn't hurt to > ask ... ;) ?? > - Does another bootloader (e.g. GRUB) support serial speeds higher than > 9600bps?? If so, which one(s)?? I'd really appreciate any help. Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://vger.kernel.org/lkml/
LILO and serial speeds over 9600
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 console kernel code does support up to 115.2Kbps, but it doesn't hurt to ask ... ;) ?? - Does another bootloader (e.g. GRUB) support serial speeds higher than 9600bps?? If so, which one(s)?? TIA for your help!! Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://vger.kernel.org/lkml/
Re: 2.2.18: weird eepro100 msgs
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 reports no RX buffers. > > eth0: card reports no resources. > > eth0: card reports no RX buffers. > > eth0: card reports no resources. > > eth0: card reports no RX buffers. > > (...) > > Does the following patch, taken from 2.4.1, help? I'm currently testing. I'll get back to you soon (have to reboot the system a lot to make sure it's really solved ... :)). Thanks for the quick response!! Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.2.18: weird eepro100 msgs
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: card reports no resources. eth0: card reports no RX buffers. eth0: card reports no resources. eth0: card reports no RX buffers. eth0: card reports no resources. eth0: card reports no RX buffers. (...) They go on forever, and the box becomes inoperational (I can see the msgs on the screen, but I can't login, type anything ...). If I reboot the system, the msgs do NOT show up anymore, and then I can use the system again. Could anyone _please_ shed a light on this one for me?!?! How could I solve it?? What kind of additional info you need?? Please let me know. Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.2.17: weird eepro100 msgs
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: card reports no resources. eth0: card reports no RX buffers. eth0: card reports no resources. eth0: card reports no RX buffers. eth0: card reports no resources. eth0: card reports no RX buffers. (...) They go on forever, and the box becomes inoperational (I can see the msgs on the screen, but I can't login, type anything ...). If I reboot the system, the msgs do NOT show up anymore, and then I can use the system again. Could anyone _please_ shed a light on this one for me?!?! How could I solve it?? What kind of additional info you need?? Please let me know. Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.2.18: Protocol 0008 is buggy
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 Another question. The function that prints the "buggy protocol" msg is dev_queue_xmit_nit(), which is called by dev_queue_xmit(). Isn't that a Tx function?? What would it have to do with netif_rx() (which from what I understand is called to send Rx packets upstream, not used in the Tx datapath)?? Thanks again! Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.2.18: Protocol 0008 is buggy
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 kernel protocol drivers? How should I go > > about fixing this problem, where should I start?? > > 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 Alan, Could you please tell me where I can find an example of this?? I searched the whole drivers/net directory, and couldn't find any occurrence. Is this really supposed to be done in the HW driver / support code level, or is it supposed to be done in the protocol (IP / ARP) level?? Thanks for the reply!! Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Kernel 2.2.18: Protocol 0008 is buggy
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 represent IP and ARP (respectively), not Cisco HDLC. So ... 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 kernel protocol drivers? How should I go about fixing this problem, where should I start?? I'm at a total loss here. Any help would be really appreciated. Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Announcement] linux-kernel v2.0.39
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 find it. Maybe it hasn't propagated thru the mirrors yet ... Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC-2] Configuring Synchronous Interfaces in Linux
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
self-contained), requires synchronization between kernel and utility, and
this sometimes is not always true.
Anyhow, I still prefer this approach over the "tons of different ioctl's"
one. I'd like to get the opinion of the community though (especially
Alan).
Later,
Ivan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC-2] Configuring Synchronous Interfaces in Linux
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 independant utility that could set and check the > settings of all of these variables for whatever classes of networking > connections existed. This would provide a cleaner split between the > protocol configuration (IPv4, IPv6, IPX, ...) and the device (V.##, > 10/100, 4/16/100, etc) parameters. > > Such a split should make for a cleaner configuration structure WRT virtual > devices as well which for the most part deal with the protocol config and > do not need much device config. > > FWIW: Alexey's ip has replaced both ifconfig and route on my systems. > Something that could now replace having several different card config > utils around with one binary would be fantastic. Very good point IMHO. I'll have a look at ip to see if I can get ideas from it. Thanks for the info!! Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC-2] Configuring Synchronous Interfaces in Linux
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 parameter, that pass only the specific parameter new value as the argument. The former is good because it relies on a _single_ ioctl. However, every time you change the ioctl structure you may lose backward compatibility. The latter is good because new implementations / features won't affect previous working features. However, it'd create a huge list of ioctl's. Please let me know whatcha think. Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC-2] Configuring Synchronous Interfaces in Linux
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 supports RS-232 and V.35, software selectable. The PC300/TE supports T1 and E1, also software selectable. > > - Protocol: Frame Relay, (Cisco)-HDLC, PPP, X.25 (not sure whether that is > > already supported by the 'hw' option) > > + Transparent HDLC ? As I said, for sure there will be parameters left out, but this would be my _initial_ set of parameters. Subsequent patches would add more and more parameters. > > - T1/E1 only: > > - Line code: > > - Frame mode: > > - LBO (T1 only): line-build-out > > - Rx Sensitivity: short-haul or long-haul > > - Active channels: mask that represents the possible 24/32 > >channels (timeslots) on a T1/E1 line > > May I ask what kind of protocol support you have in mind here ? Same protocols as before: Frame Relay, X.25, PPP, HDLC ... Did I misunderstood your question?? > We can pass (media/clock) through his "media" parameter but I won't claim it > to be sexy. So far, I don't see how we may avoid some tool to do all the > required ioctl. The point is not to prevent the tool from doing ioctl's, is having _one single_ tool that generates _the same_ ioctl to all sync drivers. That would mean that a user wouldn't care if his sync card is from X, Y or Z manufacturer, the command syntax to set a specific link configuration would be the same for all of them. How to translate this standard command to the hardware, that's a device driver problem (no news here). > > - where I should create the new ioctl's to handle these new parameters. > > drivers/net/wan/sbni.[ch] uses the SIOCDEVPRIVATE range for different things. > The x25 protocol uses the SIOCPROTOPRIVATE. I'd rather avoid both. That's what everybody does currently, but each driver uses their _own_ set of ioctl's. Having one unified set of ioctl's for all drivers would ease the user's life a lot. Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[RFC-2] Configuring Synchronous Interfaces in Linux
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 thing that you may wanna throw your opinions on. Anyhow, the parameters we currently need to configure on our board (the PC300) are as follows: - Media: V.35, RS-232, X.21, T1, E1 - Protocol: Frame Relay, (Cisco)-HDLC, PPP, X.25 (not sure whether that is already supported by the 'hw' option) - Clock: 'ext' (or 0, which implies external clock) or some numeric value > 0 (which implies internal clock); setting it to 'int' would set it to some fixed numeric value > 0 (useful for T1/E1 links, just to indicate master clock as opposed to slave or 'ext' clock) - Frame Relay only: - End type: DCE or DTE (maybe this applies to other interface types as well) - DLCI: DLC number for the interface - T1/E1 only: - Line code: - Frame mode: - LBO (T1 only): line-build-out - Rx Sensitivity: short-haul or long-haul - Active channels: mask that represents the possible 24/32 channels (timeslots) on a T1/E1 line I'm sure that _all_ the other sync cards need to configure the _same_ parameters (or a subset of them), and there may be cards that need even more parameters (but we have to start somewhere ... ;). So having a unified interface and making the drivers compliant to it is not that hard and surely would help users to dump the currently ridiculous set of individual config. tools for these cards (yes, we currently have our own pc300cfg, along with the -- not absolute -- "standard" sethdlc utility). I'm willing to go for this implementation, but I wanted to know first: - whether ifconfig is the right place to do it; - where I should create the new ioctl's to handle these new parameters. Suggestions / comments are more than welcome. Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[RFC] Configuring synchronous interfaces in Linux
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 (e.g PPP, HDLC, Frame Relay), etc. What I noticed was that each synchronous board in Linux provides a different way of doing this, and it would be good for users to have a single, standard interface (such as ifconfig) to do this type of configuration. Maybe even patch ifconfig itself, I don't know ... Questions: - Is there any existing _standard_ interface to do that?? - If not, is there any existing _standard_ infrastructure (e.g. ioctls and structures) so that I can write an application to do that over this standard structure? - If not, where would be the right place in the kernel to change in order to implement such infrastructure? I'm interested in implementing this, but I don't want to reinvent the wheel (if such wheel exists ...). Thanks in advance for your comments. Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Patch generation
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 (such as the files in include/config, .files, etc.). Thanks in advance for your help. Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Question on new PCI architecture (2.4.x)
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 net_device per board. What about boards with more than one net_device?? In my case, the driver supports one- and two-channel boards, and I don't know how to remove a board that has two net_devices (since pdev->driver_data can't contain two pointers!! ;). Also, if anyone could give me pointers to documentation on this new PCI architecture (sample src code would be great, real documentation, even better!!), I'd really appreciate it. Thanks in advance! Regards, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Interrupt/Sleep deadlock
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 and then goes to > sleep (interruptible_sleep_on(&info->config_wait)); > - The board receives the command, handles it and answers back with an > interrupt; > - The driver's interrupt handler schedules a bottom-half action. > - The bottom-half calls wake_up_interuptible(&info->config_wait). > - The ioctl returns and the userspace application has the board > configuration. > > Now, the problem: the board is so fast that it interrupts back _before_ > the driver goes to sleep, i.e.: > - Driver sends command to board; > - Driver goes to sl... interrupt back from board!! > - Interrupt handler schedules bottom-half. > - Bottom-half calls wake_up. > - Ioctl continues, and _then_ goes to sleep. System locked. > > I can't disable interrupts before going to sleep, because the event that > wakes me up is an interrupt. However, if I don't protect it from the > interrupts, the system locks ... > > Is there any other way in Linux to implement this?!?!?! This e-mail is to thank everybody who answered, and to let you know that the solution I'm using is the one suggested by Nigel Gamble <[EMAIL PROTECTED]>: "You could use a semaphore for this. Initialize it to 0, then call down() from the ioctl, and up() from the interrupt handler. If the up() happens before the down(), the down() won't go to sleep." Initializing it to 0 means: cfg_sem = MUTEX_LOCKED; It's the simplest to understand, and it works great!! Does anybody see a problem with this implementation?? Thanks again!! Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Protocol 0008 is buggy
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 it's printed when someone sends a packet without the skb->nh.raw correctly set, but I couldn't find any driver under drivers/net that sets this. - How can / should I solve this?? Should it be solved in the hdlc.c driver or somewhere else in an upper level?? Thanks in advance for your help. Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Interrupt/Sleep deadlock
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 (interruptible_sleep_on(&info->config_wait)); - The board receives the command, handles it and answers back with an interrupt; - The driver's interrupt handler schedules a bottom-half action. - The bottom-half calls wake_up_interuptible(&info->config_wait). - The ioctl returns and the userspace application has the board configuration. Now, the problem: the board is so fast that it interrupts back _before_ the driver goes to sleep, i.e.: - Driver sends command to board; - Driver goes to sl... interrupt back from board!! - Interrupt handler schedules bottom-half. - Bottom-half calls wake_up. - Ioctl continues, and _then_ goes to sleep. System locked. I can't disable interrupts before going to sleep, because the event that wakes me up is an interrupt. However, if I don't protect it from the interrupts, the system locks ... Is there any other way in Linux to implement this?!?!?! Thanks in advance for any help. Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Q: network drivers interface changes
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 http://www.uwsg.indiana.edu/hypermail/linux/kernel/0002.1/0461.html Hope this helps. :) Regards, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Any good _online_ kernel BSD sockets reference out there??
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 was whether I should change the _kernel_ device driver in order to support that. I guess this _is_ a kernel question ... In the end, it was solved from userspace, but I didn't know that was possible. But ok, your advice was taken (believe me, I'm serious). I'll try and look for docs more thoroughly before dropping a note here. Thanks. Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Any good _online_ kernel BSD sockets reference out there??
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 passing" would be good too ... :) > > AF_PACKET sockets allocate an sk_buff, copy the data into it and call > dev_queue_xmit() to hand the packet as is to the driver Ok, so please comment on the description below: - Userspace: sd = socket(AF_PACKET, SOCK_RAW, 0); (Is this correct??) bind(how do I bind this socket to the interface, if I don't have an address?? Can I just make one up??); send(sd, data, len); - Kernel: "send" makes kernel call dev_queue_xmit(), which will call the driver's hard_start_xmit function. Questions: - Do I need to bring the interface up with ifconfig before being able to do this?? My question is because ifconfig doesn't have a "raw mode" address family ... - Who opens the interface, if not ifconfig?? Sorry for my dumb questions, and thanks for your help!! Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Any good _online_ kernel BSD sockets reference out there??
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. Open an AF_PACKET socket to it 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 passing" would be good too ... :) TIA!! Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Any good _online_ kernel BSD sockets reference out there??
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 have a driver that works with AF_INET (IP), and now I'd like to be able to configure it so that a user can open a socket and write raw data to it. Any pointers are highly appreciated. Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
