From owner-freebsd-current Thu Aug 30 16:37:47 2001 Delivered-To: freebsd-current@freebsd.org Received: from misha.privatelabs.com (misha.privatelabs.com [66.9.25.166]) by hub.freebsd.org (Postfix) with ESMTP id 499BE37B403; Thu, 30 Aug 2001 16:37:40 -0700 (PDT) (envelope-from mi@aldan.algebra.com) Received: from misha.privatelabs.com (mi@localhost [127.0.0.1]) by misha.privatelabs.com (8.11.3/8.11.1) with ESMTP id f7UNYTk31986; Thu, 30 Aug 2001 19:34:30 -0400 (EDT) (envelope-from mi@aldan.algebra.com) Message-Id: <200108302334.f7UNYTk31986@misha.privatelabs.com> Date: Thu, 30 Aug 2001 19:34:28 -0400 (EDT) From: mi@aldan.algebra.com Reply-To: mi@aldan.algebra.com Subject: Re: another panic (mix ppp and usb to taste) To: n_hibma@FreeBSD.ORG, brian@Awfulhak.org Cc: current@FreeBSD.ORG In-Reply-To: <20010830223344.I618-100000@heather.plazza.uk> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 30 Aug, Nick Hibma wrote: > /usr/sbin/ppp -quiet -direct -nat <> /dev/ugen0.1 > I was confused by the following from ppp's man-page: -direct This is used for receiving incoming connections. ppp ignores the ``set device'' line and uses descriptor 0 as the link. which seems to imply, I don't need to care the descriptor 1 :-) > USB is NOT a serial protocol. It has nothing in common with a serial > port. The reason I tried this, was finding a Linux how-to guide for making the ppp over USB work between a PDA (Palm or Handsrping) and the Linux machine. It mentioned having to install the "Handspring module" or something to work with /dev/ttyUSB (sp?). I figured, I'll try it with a ugen-device... Could we have such a device-module too, BTW? Similar to the serial modems we already have? Or will you just I suggest I write it myself :-)? > P.S.: The reason why it crashes is that it looks for an endpoint > descriptor for endpoint 0 which doesn't exist. I'll fix that. Yeah, but it seems, that just a few lines above the crash, it checks for the sce being non-NULL... Or is it an optimization artifact? Thanks, -mi > On Fri, 24 Aug 2001, Mikhail Teterin wrote: > >> As I was trying to let the Palm Pilot connect to my desktop >> through usb using PPP, I tried to run >> >> /usr/sbin/ppp -quiet -direct -nat < /dev/ugen0 >> >> While, perhaps, not the right way to do what I want (what is? aren't >> serial devices the simplest?), it should not panic (nothing should >> really). But it does, and quite repeatedly (some more comments after >> the trace): >> >> IdlePTD 4984832 >> initial pcb at 3db040 >> panicstr: bwrite: buffer is not busy??? >> panic messages: >> --- >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; lapic.id = 01000000 >> fault virtual address = 0x3 >> fault code = supervisor read, page not present >> instruction pointer = 0x8:0xc01d5a0b >> stack pointer = 0x10:0xce7f1c4c >> frame pointer = 0x10:0xce7f1c58 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 442 (ppp) >> trap number = 12 >> panic: page fault >> cpuid = 0; lapic.id = 01000000 >> boot() called on cpu#0 >> >> syncing disks... panic: bwrite: buffer is not busy??? >> cpuid = 0; lapic.id = 01000000 >> boot() called on cpu#0 >> Uptime: 10m14s >> >> dumping to dev da0b, offset 131200 >> dump ....... 2 1 0 >> --- >> [...] >> #12 0xc030b0bc in trap (frame={tf_fs = -1071644648, tf_es = -830734320, >> tf_ds = 16777232, tf_edi = 64, tf_esi = 0, tf_ebp = -830530472, >> tf_isp = -830530504, tf_ebx = -1049243648, tf_edx = -1049243428, >> tf_ecx = 34, tf_eax = 0, tf_trapno = 12, tf_err = 0, >> tf_eip = -1071818229, tf_cs = 8, tf_eflags = 66178, >> tf_esp = -830530412, tf_ss = -1049288448}) >> at ../../../i386/i386/trap.c:405 >> #13 0xc01d5a0b in ugenpoll (dev=0xc1752100, events=64, p=0xce7abb80) >> at ../../../dev/usb/ugen.c:1369 >> #14 0xc01ed604 in spec_poll (ap=0xce7f1c94) >> at ../../../fs/specfs/spec_vnops.c:333 >> #15 0xc01ed27d in spec_vnoperate (ap=0xce7f1c94) >> at ../../../fs/specfs/spec_vnops.c:119 >> #16 0xc0252333 in vn_poll (fp=0xc17328c0, events=64, cred=0xc1734700, >> p=0xce7abb80) at vnode_if.h:381 >> #17 0xc0228b8b in selscan (p=0xce7abb80, ibits=0xce7f1d48, >> obits=0xce7f1d3c, nfd=1) at ../../../sys/file.h:192 >> #18 0xc02286b5 in select (p=0xce7abb80, uap=0xce7f1f80) >> at ../../../kern/sys_generic.c:772 >> #19 0xc030bf2d in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, >> tf_edi = 134842880, tf_esi = 134842880, tf_ebp = 0, >> tf_isp = -830529580, tf_ebx = 3, tf_edx = 134996480, >> tf_ecx = 134996352, tf_eax = 93, tf_trapno = 12, tf_err = 2, >> tf_eip = 673178596, tf_cs = 31, tf_eflags = 643, >> tf_esp = -1077937708, tf_ss = 47}) at ../../../i386/i386/trap.c:1129 >> (kgdb) up 13 >> #13 0xc01d5a0b in ugenpoll (dev=0xc1752100, events=64, p=0xce7abb80) >> at ../../../dev/usb/ugen.c:1369 >> 1369 switch (sce->edesc->bmAttributes & UE_XFERTYPE) { >> (kgdb) p sce >> $1 = (struct ugen_endpoint *) 0x0 >> (kgdb) l >> 1364 printf("ugenpoll: no pipe\n"); >> 1365 return (EIO); >> 1366 } >> 1367 #endif >> 1368 s = splusb(); >> 1369 switch (sce->edesc->bmAttributes & UE_XFERTYPE) { >> 1370 case UE_INTERRUPT: >> 1371 if (events & (POLLIN | POLLRDNORM)) { >> 1372 if (sce->q.c_cc > 0) >> 1373 revents |= events & (POLLIN | POLLRDNORM); >> (kgdb) p events >> $3 = 64 >> (kgdb) p s >> No symbol "s" in current context. >> (kgdb) p revents >> $5 = 0 >> >> What I don't understand, is -- there is a check, just a few lines >> above: >> if (sce == NULL) >> return (EINVAL); >> >> How come it is not being caught there? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message