From: Paul Mackerras <[EMAIL PROTECTED]>
Date: Sun, 15 Apr 2007 11:05:53 +1000
> I wrote:
>
> > So this doesn't change process_input_packet(), which treats the case
> > where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is
> > 0x03 (PPP_UI) as indicating a packet with a PPP protoc
Herbert Xu <[EMAIL PROTECTED]> wrote:
>
> Paul Mackerras <[EMAIL PROTECTED]> wrote:
>>
>> So this doesn't change process_input_packet(), which treats the case
>> where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is
>> 0x03 (PPP_UI) as indicating a packet with a PPP protocol numbe
Your fix is probably needed too. However, I think the issue that Patrick
was trying to fix is the case where p[0] != PPP_ALLSTATIONS and therefore
we'd still have a problem there.
I tested Paul's patch for last few days and I think everything seems
ok. The system is stable.
Regards
Bartek
-
To
Hi Paul:
Paul Mackerras <[EMAIL PROTECTED]> wrote:
>
> So this doesn't change process_input_packet(), which treats the case
> where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is
> 0x03 (PPP_UI) as indicating a packet with a PPP protocol number of
> 0xff. Arguably that's wrong s
Hi,
I didn't analyse this bug report but probably it
is nearly connected with one of the bugs visible in
a log from this submit:
http://bugzilla.kernel.org/show_bug.cgi?id=8132
On 15-04-2007 02:50, Paul Mackerras wrote:
> David Miller writes:
>
>> Here is Patrick McHardy's patch:
>
> So this d
Bartek wrote:
> 2007/4/14, David Miller <[EMAIL PROTECTED]>:
>
>> From: Patrick McHardy <[EMAIL PROTECTED]>
>> Date: Thu, 12 Apr 2007 07:43:39 +0200
>>
>> > It seems we fail to reserve enough headroom for the case
>> > buf[0] == PPP_ALLSTATIONS and buf[1] != PPP_UI.
>> >
>> > Can you try this patc
2007/4/14, David Miller <[EMAIL PROTECTED]>:
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Thu, 12 Apr 2007 07:43:39 +0200
> It seems we fail to reserve enough headroom for the case
> buf[0] == PPP_ALLSTATIONS and buf[1] != PPP_UI.
>
> Can you try this patch please?
Any confirmation of this f
I wrote:
> So this doesn't change process_input_packet(), which treats the case
> where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is
> 0x03 (PPP_UI) as indicating a packet with a PPP protocol number of
I meant "the second byte is NOT 0x03", of course.
Paul.
-
To unsubscribe fr
David Miller writes:
> Here is Patrick McHardy's patch:
So this doesn't change process_input_packet(), which treats the case
where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is
0x03 (PPP_UI) as indicating a packet with a PPP protocol number of
0xff. Arguably that's wrong since
David Miller wrote:
> From: Paul Mackerras <[EMAIL PROTECTED]>
> Date: Sun, 15 Apr 2007 02:49:28 +1000
>
>
>>I didn't see the patch (the message that this is a reply to is the
>>first one that I have seen in this thread), so I can't comment on it.
>
>
> Here is Patrick McHardy's patch:
>
> [..
From: Paul Mackerras <[EMAIL PROTECTED]>
Date: Sun, 15 Apr 2007 02:49:28 +1000
> I didn't see the patch (the message that this is a reply to is the
> first one that I have seen in this thread), so I can't comment on it.
Here is Patrick McHardy's patch:
diff --git a/drivers/net/ppp_async.c b/driv
David Miller writes:
> > It seems we fail to reserve enough headroom for the case
> > buf[0] == PPP_ALLSTATIONS and buf[1] != PPP_UI.
> >
> > Can you try this patch please?
>
> Any confirmation of this fix yet?
Indeed, ppp_async doesn't handle that case correctly.
RFC 1662 says:
The Con
David Miller <[EMAIL PROTECTED]> wrote:
>
>> It seems we fail to reserve enough headroom for the case
>> buf[0] == PPP_ALLSTATIONS and buf[1] != PPP_UI.
>>
>> Can you try this patch please?
>
> Any confirmation of this fix yet?
FWIW the fix definitely looks correct (the bug has been there for
ye
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Thu, 12 Apr 2007 07:43:39 +0200
> Bartek wrote:
> > Hopefully, this time it my bug report should be ok :):
> >
> > Apr 11 23:53:38 localhost pppd[31289]: rcvd [proto=0x7689] e1 cd 33 f6
> > fd f7 52 e6 58 c9 73 98 bc ff ad d5 b5 a3 e5 d9 1e 77 76 0a
Bartek wrote:
> Hopefully, this time it my bug report should be ok :):
>
> Apr 11 23:53:38 localhost pppd[31289]: rcvd [proto=0x7689] e1 cd 33 f6
> fd f7 52 e6 58 c9 73 98 bc ff ad d5 b5 a3 e5 d9 1e 77 76 0a 1c 87 59
> bf 44 cc ac 3b ...
> Apr 11 23:53:38 localhost pppd[31289]: Unsupported protoco
It is not enough to unload proprietary modules. As long as they have
ever been loaded at all the kernel is tainted.
You need to ensure that the proprietary modules never get loaded at
all. I guess you probably already worked that out, just wanted to
point it out just in case :-)
Hopefully, this
On 10/04/07, Bartek <[EMAIL PROTECTED]> wrote:
> Apr 8 21:47:22 localhost kernel: EIP:0060:[]
> Tainted: P VLI
Someone in private took me a noticed of a still tainted kernel. I
didn't noticed that, I am sorry for that. I was sure that unloaded
proprietary modules should resolve the p
Apr 8 21:47:22 localhost kernel: EIP:0060:[]
Tainted: P VLI
Someone in private took me a noticed of a still tainted kernel. I
didn't noticed that, I am sorry for that. I was sure that unloaded
proprietary modules should resolve the problem. My fault. I will try
to reproduce the crash
Please reproduce and provide a new crash dump without the nvidia
binary-only module loaded.
Hi again,
Here is a new crash dump (I also removed vmnet and vmmon properitary
modules), this time I also included a lspci output:
Apr 8 21:47:21 localhost pppd[2114]: rcvd [proto=0xfc3b] bc d4 80 eb
4
From: Bartek <[EMAIL PROTECTED]>
Date: Sat, 7 Apr 2007 20:11:13 +0200
> I have problem with a Linux kernel oops. It mostly appears when I
> download files using bittorrent or other large file. I have a phone
> modem based Internet access using Home Internet Solution
> (http://en.wikipedia.org/wiki
Hallo
I have problem with a Linux kernel oops. It mostly appears when I
download files using bittorrent or other large file. I have a phone
modem based Internet access using Home Internet Solution
(http://en.wikipedia.org/wiki/Home_internet_Solution). I use Debian
testing, Linux vanilla version:
21 matches
Mail list logo
