Date: Mon, 08 Apr 2002 04:25:59 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Josef Karthauser <joe@tao.org.uk> Cc: current@freebsd.org Subject: Re: Kernel debugging - what's the procedure? Message-ID: <3CB17E47.753ACB6@mindspring.com> References: <20020407091335.GA697@genius.tao.org.uk> <3CB01F95.ACCDAA82@mindspring.com> <20020407105959.GA14407@genius.tao.org.uk> <3CB0B1F0.F2D701F7@mindspring.com> <20020408093021.GA54610@genius.tao.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Josef Karthauser wrote: > > On Sun, Apr 07, 2002 at 01:54:08PM -0700, Terry Lambert wrote: > > Josef Karthauser wrote: > > > > You use another machine, and connect the serial ports together. > > > > See the handbook for details. > > > > > > I'd love to ;) but no additional machine is available at the moment. > > > > Then you install vmware, and Julian's back-to-back serial > > driver, and then run the kernel to be debuged in the vmware > > session. This lets you debug the kernel on a virtual > > machine (single CPU only). > > Yes I do have vmware, but it's not going to help me debug the usb stack > is it? (I know vmware3 does usb, but not if the underlying usb stack on > the host machine is also hosed). It's my understanding that you can assign resources to the vmware machine, which it can then permit to be accessed natively. Thus, if you gave your USB ports to the vmware virtual machine entirely, this would resolve the problem. The vmware3 support for usb appears (to me) to be a tunnel driver, like the standard network driver interface (e.g. it pretends to be hardware, and uses a host driver to contact the real hardware, so that its use can be multiplexed and thus the device accessed by etiher the real or the virtual machine). > > Well, since this is the -current list... have you updated > > recently? There were some recent changes by PHK to the dump > > format that may have broken/fixed things, if your answer to > > that question is yes/no, respectively. > > Yes, that's what I implied by the above paragraph. I was up-to-date > with sources yesterday. This is probably your problem. If you can back up to when the problem first appeared, or back out the kernel dump fule generation modifications, this would probably fix your problems. If you look at the -current list archives, you will see a number of posts which identify the files which have changed, and are probably what is breaking you [ comments on policy related to commits of kernel changes without corresponding commits to user space utilities elided ]. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CB17E47.753ACB6>