Send buglog mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openmoko.org/mailman/listinfo/buglog
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of buglog digest..."
Today's Topics:
1. Re: Openmoko Bug #2212: pppd: page allocation failure.
order:4, mode:0x4d0 (Openmoko Public Trac)
2. Re: Openmoko Bug #2212: pppd: page allocation failure.
order:4, mode:0x4d0 (Openmoko Public Trac)
--- Begin Message ---
#2212: pppd: page allocation failure. order:4, mode:0x4d0
-----------------------------+----------------------------------------------
Reporter: lindi | Owner: openmoko-kernel
Type: defect | Status: new
Priority: normal | Milestone:
Component: System Software | Version: unspecified
Severity: normal | Keywords:
Haspatch: 1 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Changes (by werner):
* haspatch: 0 => 1
Comment:
This is nasty :-( It's z_decomp_alloc trying to allocate a chunk of
64kB of contiguous kernel memory for its 'struct inflate_workspace',
defined in lib/zlib_inflate/infutil.h (MAX_WBITS is 15.)
Such large allocations are generally bad practice and it's a bit
disconcerting to find one here. Fortunately, there may be an easy
fix by just using vmalloc. I've attached an untested patch.
I'm not sure if the problem is very reproducible and if you're
actually using PPP compression. If the answer to at least one of
these items is yes, then could you please give it a try ?
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2212#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2212: pppd: page allocation failure. order:4, mode:0x4d0
-----------------------------+----------------------------------------------
Reporter: lindi | Owner: openmoko-kernel
Type: defect | Status: new
Priority: normal | Milestone:
Component: System Software | Version: unspecified
Severity: normal | Keywords:
Haspatch: 1 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Comment(by lindi):
I do not know a way to reproduce the problem. I do not know if I am really
using compression:
{{{
/usr/sbin/pppd /dev/pts/12 connect /var/tmp/ogsmd/gprs-connect-chat
disconnect /var/tmp/ogsmd/gprs-disconnect-chat 115200 nodetach crtscts
defaultroute debug hide-password holdoff 3 ipcp-accept-local ktune lcp-
echo-failure 10 lcp-echo-interval 20 ipcp-max-configure 4 lock noauth
noipdefault novj novjccomp proxyarp replacedefaultroute usepeerdns user x
}}}
does not mention any compression but
{{{
Jan 20 22:58:10 ginger local2.notice pppd[28779]: Connect: ppp0 <-->
/dev/pts/12
Jan 20 22:58:11 ginger local2.warn pppd[28779]: Warning - secret file
/etc/ppp/pap-secrets has world and/or group access
Jan 20 22:58:11 ginger local2.debug pppd[28779]: sent [LCP ConfReq id=0x1
<asyncmap 0x0> <magic 0x59062554> <pcomp> <accomp>]
Jan 20 22:58:11 ginger local2.debug pppd[28779]: rcvd [LCP ConfRej id=0x1
<magic 0x59062554>]
Jan 20 22:58:11 ginger local2.debug pppd[28779]: sent [LCP ConfReq id=0x2
<asyncmap 0x0> <pcomp> <accomp>]
Jan 20 22:58:11 ginger local2.debug pppd[28779]: rcvd [LCP ConfAck id=0x2
<asyncmap 0x0> <pcomp> <accomp>]
Jan 20 22:58:12 ginger local2.debug pppd[28779]: rcvd [LCP ConfReq id=0x1
<asyncmap 0x0> <auth chap MD5> <pcomp> <accomp>]
Jan 20 22:58:12 ginger local2.debug pppd[28779]: sent [LCP ConfAck id=0x1
<asyncmap 0x0> <auth chap MD5> <pcomp> <accomp>]
Jan 20 22:58:12 ginger local2.debug pppd[28779]: sent [LCP EchoReq id=0x0
magic=0x0]
Jan 20 22:58:12 ginger local2.debug pppd[28779]: rcvd [CHAP Challenge
id=0x1
<1c48e86d81593b59610ab90eb6f316af62b989b092081333ef4e8f268b3c7e1986fd90e08434f2eccfb85b6a4b0fd4191dab4a>,
name = ""]
Jan 20 22:58:12 ginger local2.warn pppd[28779]: Warning - secret file
/etc/ppp/chap-secrets has world and/or group access
Jan 20 22:58:12 ginger local2.debug pppd[28779]: sent [CHAP Response
id=0x1 <8c1674df4f25333bdd88f9a5804dadd0>, name = "x"]
Jan 20 22:58:12 ginger local2.debug pppd[28779]: rcvd [LCP EchoRep id=0x0
magic=0x0]
Jan 20 22:58:12 ginger local2.debug pppd[28779]: rcvd [CHAP Success id=0x1
""]
Jan 20 22:58:12 ginger local2.info pppd[28779]: CHAP authentication
succeeded
Jan 20 22:58:12 ginger local2.notice pppd[28779]: CHAP authentication
succeeded
Jan 20 22:58:12 ginger local2.debug pppd[28779]: sent [CCP ConfReq id=0x1
<deflate 15> <deflate(old#) 15> <bsd v1 15>]
Jan 20 22:58:12 ginger local2.debug pppd[28779]: sent [IPCP ConfReq id=0x1
<addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Jan 20 22:58:12 ginger local2.debug pppd[28779]: rcvd [LCP ProtRej id=0x1
80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
Jan 20 22:58:12 ginger local2.debug pppd[28779]: Protocol-Reject for
'Compression Control Protocol' (0x80fd) received
Jan 20 22:58:13 ginger user.info kernel: [152171.845000]
fbcon_event_notify action=9, data=c7b3de08
Jan 20 22:58:13 ginger user.info kernel: [152171.845000] jbt6k74 spi2.0:
**** jbt6k74 hsync suspend
Jan 20 22:58:15 ginger local2.debug pppd[28779]: sent [IPCP ConfReq id=0x1
<addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Jan 20 22:58:16 ginger local2.debug pppd[28779]: rcvd [IPCP ConfReq
id=0x1]
Jan 20 22:58:16 ginger local2.debug pppd[28779]: sent [IPCP ConfNak id=0x1
<addr 0.0.0.0>]
Jan 20 22:58:16 ginger local2.debug pppd[28779]: rcvd [IPCP ConfNak id=0x1
<addr 85.77.208.13> <ms-dns1 195.197.54.100> <ms-dns3 195.74.0.47>]
Jan 20 22:58:16 ginger local2.debug pppd[28779]: sent [IPCP ConfReq id=0x2
<addr 85.77.208.13> <ms-dns1 195.197.54.100> <ms-dns3 195.74.0.47>]
Jan 20 22:58:16 ginger local2.debug pppd[28779]: rcvd [IPCP ConfReq
id=0x2]
Jan 20 22:58:16 ginger local2.debug pppd[28779]: sent [IPCP ConfAck
id=0x2]
Jan 20 22:58:16 ginger local2.debug pppd[28779]: rcvd [IPCP ConfAck id=0x2
<addr 85.77.208.13> <ms-dns1 195.197.54.100> <ms-dns3 195.74.0.47>]
Jan 20 22:58:16 ginger local2.warn pppd[28779]: Could not determine remote
IP address: defaulting to 10.64.64.64
Jan 20 22:58:16 ginger local2.notice pppd[28779]: replacing old default
route to usb0 [192.168.4.200]
Jan 20 22:58:16 ginger local2.err pppd[28779]: Cannot determine ethernet
address for proxy ARP
Jan 20 22:58:16 ginger local2.notice pppd[28779]: local IP address
85.77.208.13
Jan 20 22:58:16 ginger local2.notice pppd[28779]: remote IP address
10.64.64.64
Jan 20 22:58:16 ginger local2.notice pppd[28779]: primary DNS address
195.197.54.100
Jan 20 22:58:16 ginger local2.notice pppd[28779]: secondary DNS address
195.74.0.47
}}}
seems to at least try to negotiate deflate compression? Downloading a file
with zeroes over HTTP seems to happen at the same bandwidth as downloading
a file that has random data so I don't think any real compression is in
use.
In any case I'm waiting for the kernel to build with the patch and check
that ppp works after it.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2212#comment:2>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
