Daniel Phillips wrote:
>
> > because then you would be allocating the size of a pointer, not the size
> > of a structure
>
> Whoops Jeff, you didn't have your coffee yet:
Whoops yourself. The following patch brings your example into line with
the driver code. mpuout is a pointer to a structure
Hi,
Bill Pringlemeir wrote:
>
> I have been looking at the emu10k1 driver and I had a few questions
> about general idioms used there.
Warning I've not looked at that particular driver and would concider
myself a Linux kernel newbie. 20 years kernel hacking but only 9
months Linux with two
Hi,
Bill Pringlemeir wrote:
I have been looking at the emu10k1 driver and I had a few questions
about general idioms used there.
Warning I've not looked at that particular driver and would concider
myself a Linux kernel newbie. 20 years kernel hacking but only 9
months Linux with two
Daniel Phillips wrote:
because then you would be allocating the size of a pointer, not the size
of a structure
Whoops Jeff, you didn't have your coffee yet:
Whoops yourself. The following patch brings your example into line with
the driver code. mpuout is a pointer to a structure not
Paul Fulghum wrote:
>
> RFC1661 state table shows a transition to req-sent
> from opened when a (properly formated with
> correct sequence ID) cfg-ack is received.
>
> Syncppp does not do this (from sppp_lcp_input):
...
> Maybe adding:
>
> case LCP_STATE_OPENED:
>sppp_lcp_open (sp);
>
Paul Fulghum wrote:
> >
> > Thanks but I've already tried that. You get a slightly different pattern
> > to the loop but it still loops.
>
> What does the loop look like when the cfg-req is sent 1st?
Thanks for making me go back and look at it again guys. The reordering of
REQ and ACK does
Paul Fulghum wrote:
Thanks but I've already tried that. You get a slightly different pattern
to the loop but it still loops.
What does the loop look like when the cfg-req is sent 1st?
Thanks for making me go back and look at it again guys. The reordering of
REQ and ACK does work to
Paul Fulghum wrote:
RFC1661 state table shows a transition to req-sent
from opened when a (properly formated with
correct sequence ID) cfg-ack is received.
Syncppp does not do this (from sppp_lcp_input):
...
Maybe adding:
case LCP_STATE_OPENED:
sppp_lcp_open (sp);
Paul Mackerras wrote:
>
> [EMAIL PROTECTED] writes:
> > I've hit a problem with the syncPPP module within Linux.
>
> Seems to me that when you get the conf-request in opened state, you
> should send your conf-request before sending the conf-ack to the
> peer's conf-request. I think this would
I've hit a problem with the syncPPP module within Linux.
Under certain conditions (hard to quantify exactly, but try several 8Mbps
streams hitting a relatively slow, say 200MHz processor) the LCP/IPCP
negotiation hits the following loop.
A side state Packet B side
I've hit a problem with the syncPPP module within Linux.
Under certain conditions (hard to quantify exactly, but try several 8Mbps
streams hitting a relatively slow, say 200MHz processor) the LCP/IPCP
negotiation hits the following loop.
A side state Packet B side
Paul Mackerras wrote:
[EMAIL PROTECTED] writes:
I've hit a problem with the syncPPP module within Linux.
Seems to me that when you get the conf-request in opened state, you
should send your conf-request before sending the conf-ack to the
peer's conf-request. I think this would
Hi,
How can I determine if the build my device driver is being compiled under is
a standard kernel.org one or a Red Hat one ?
The problem is I have a driver that includes syncppp.h which in the releases
from kernel.org is in linux/drivers/net/wan/ up to and including 2.4.2 after
which it moves
Hi,
I've just completed the first draft of a new device driver for the FarSite
Communications, FarSync T2P and T4P cards. These cards are intelligent
synchronous serial cards supporting 2 or 4 ports running at up to 8Mbps with
X.21, V.35 or V.24 signalling.
This mail is basically a call for
Hi,
I've just completed the first draft of a new device driver for the FarSite
Communications, FarSync T2P and T4P cards. These cards are intelligent
synchronous serial cards supporting 2 or 4 ports running at up to 8Mbps with
X.21, V.35 or V.24 signalling.
This mail is basically a call for
Stuart MacDonald wrote:
>
> It seems to me this might be an opportunity...
Or a trap. I'm not about to go anywhere near this and won't even look at
the licience but I bet the M$ argument will go something like:
You've looked at the code.
You now know things that are propriatary to M$.
Stuart MacDonald wrote:
It seems to me this might be an opportunity...
Or a trap. I'm not about to go anywhere near this and won't even look at
the licience but I bet the M$ argument will go something like:
You've looked at the code.
You now know things that are propriatary to M$.
Dennis wrote:
...
> objective, arent we?
Nope. Are you claiming to be?
> For example, if there were six different companies that marketed ethernet
> drivers for the eepro100, you'd have a choice of which one to buy..perhaps
... Rant deleted
I had a problem with eepro100.
It was fixed same
Dennis wrote:
...
objective, arent we?
Nope. Are you claiming to be?
For example, if there were six different companies that marketed ethernet
drivers for the eepro100, you'd have a choice of which one to buy..perhaps
... Rant deleted
I had a problem with eepro100.
It was fixed same night
19 matches
Mail list logo
