kernel debugging, console and GDB_REMOTE_CHAT option
Hi, kernel option GDB_REMOTE_CHAT allowed to share the same serial line for console and remote gdb. Looking at the following commit message for src/sys/conf/NOTES, it says that GDB_REMOTE_CHAT has been removed, but it is not clear to me how to obain the equivalent of that option. Could somebody explain? Also, the man page for gdb(4) is outdated, since it contains references to GDB_REMOTE_CHAT. thanks marco Revision 1.1244, Sun Jul 11 01:44:07 2004 UTC (5 weeks, 4 days ago) by marcel Branch: MAIN Changes since 1.1243: +18 -25 lines Diff to previous 1.1243 (colored) Update for the KDB framework: o Rename WITNESS_DDB to WITNESS_KDB. In the new world order KDB is the acronym to use for debugging related code. The DDB option is used to enable the DDB debugger backend only. o Likewise, rename DDB_TRACE to KDB_TRACE, rename DDB_UNATTENDED to KDB_UNATTENDED and rename SC_HISTORY_DDBKEY to SC_HISTORY_KDBKEY. o Remove DDB_NOKLDSYM. The new DDB backend supports pre-linker symbol lookups as well as KLD symbol lookups at the same time. o Remove GDB_REMOTE_CHAT. The GDB protocol hacks to allow this are FreeBSD specific. At the same time, the GDB protocol has packets for console output. -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
too late null checks
Bugs found with Coverity's automated analysis. In each case, either the NULL check is unnecessary, or it's too late because the variable was already deref'd. dev/firewire/fwohci.c:dump_db (debugging function) pp can not be null (crash if it is) dev/mpt/mpt_pci.c:mpt_detach a null mpt won't survive mpt_prt netinet/tcp_subr.c:tcp_mtudisc tp has already been dereferenced to obtain isipv6 result usb/dev/urio.c:urio_attach if uaa-device can be null, usbd_devinfo already used it. cam/cam_xpt.c:xptplistperiphfunc check at line 2532 looks wrong. perhaps should be *pdrv == NULL? dev/twe/twe.c:twe_ioctl if you make it to line 552, tr is definitely not null. kern/vfs_subr.c:reassignbufs (4.10) 1408 while (tbp tbp-b_lblkno 0) 1409 tdp = TAILQ_PREV(tbp, buflists, b_vnbufs); 1410 TAILQ_INSERT_AFTER(listheadp, tbp, bp, b_vnbufs); if the first while() test fails, tailq insert will crash. i'm not sure where this code went in current. some other bugs of a similar nature have already been fixed or the code removed in current, let me know if you are still interested in 4.10 results. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What mouse? (was: Samsung Cordless Mouse)
On Tuesday, 17 August 2004 at 20:18:42 -0500, Sean Farley wrote: On Wed, 18 Aug 2004, Greg 'groggy' Lehey wrote: On Tuesday, 17 August 2004 at 11:13:17 -0500, Sean Farley wrote: On Tue, 17 Aug 2004, Greg 'groggy' Lehey wrote: This mouse has five buttons: the normal three on top, and one on each side. I can't find a way to get the side buttons to work, and looking on the web hasn't shown anything of interest. I assume you mean in X as opposed to moused although moused appears to support at least five buttons according to its man page. No, this is with moused. It still needs to initialize the mouse. Will you be using moused on the console? No. It is not needed to run X. I know. Without a reason to change, I won't. - Preferably cordless. Cord mice tend to wander a little when you let go of them, and that's a real nuisance on a high-resolution display. Maybe you can find a cord-to-cordless converter--there is bound to be an engineer that has done this :)--if you find a mouse you like that just happens to have a tail. That would defeat the purpose of it being cordless. Greg -- Note: I discard all HTML mail unseen. Finger [EMAIL PROTECTED] for PGP public key. See complete headers for address and phone numbers. pgpPsTnUu8Ica.pgp Description: PGP signature
RE: What mouse? (was: Samsung Cordless Mouse)
From: Greg 'groggy' Lehey Can anybody recommend a good mouse? My criteria are: - Middle button easy to use. The current crop of mice has the middle button integrated with the roller, and that makes the middle button either heavy or easy to confuse with the roller. - Preferably cordless. Cord mice tend to wander a little when you let go of them, and that's a real nuisance on a high-resolution display. I have a Logitech MX700. Very solid mouse, excellent performance and rechargable battery life. It can also run on standard alkalines (though you can't charge them). The mouse is heavier than most, but this seems to help with making smooth movements. The weight makes some of the more fervid in-game mouse maneuvers a bit tiresome on the wrist, though. It does integrate the middle button with the wheel. But there is hope! The force needed to press the wheel-button isn't much more than that of the right and left buttons. The return spring on the wheel housing can be easily removed. Doing so makes the return tension the same as the left and right buttons without affecting the wheel's functionality. It also has five additional buttons which are presented as separate buttons (6 through 10, in xf86config). They could be mapped to the middle button if you don't want to do surgery on your mouse. I've used the MX700 in 5.1 with XF86 4.3.x with great success. The only thing I couldn't get to work was the AppSwitch button, but I ended up never needing to use it anyway. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel debugging, console and GDB_REMOTE_CHAT option
Replying to myself: On Thu, 19 Aug 2004 Marco Molteni [EMAIL PROTECTED] wrote: kernel option GDB_REMOTE_CHAT allowed to share the same serial line for console and remote gdb. Looking at the following commit message for src/sys/conf/NOTES, it says that GDB_REMOTE_CHAT has been removed, but it is not clear to me how to obain the equivalent of that option. Could somebody explain? [..] I tested and it just works: sharing of serial line between console and gdb is enabled by default. marco ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
remote kernel gdb: break, continue: fatal trap 12
Hi, I am playing around with remote gdb on a -current cvsupped 2 days ago. In gdb I set a breakpoint on ums_open (USB mouse driver, as a module), in the console I execute cat /dev/ums0, the breakpoint triggers, in gdb I issue a continue and I get a Fatal trap 12: page fault while in kernel mode, as detailed below. Any ideas why? thanks marco (gdb) tr0 (gdb) getsyms [..] (gdb) b ums_open Breakpoint 1 at 0xc072eedf: file /home/usr.src/sys/modules/ums/../../dev/usb/ums.c, line 594. (gdb) c = cat /dev/ums0 = [New Thread 100057] [Switching to Thread 100057] Breakpoint 1, ums_open (dev=0xc064ef6c, flag=0x1, fmt=0x2000, p=0xc10242c0) at /home/usr.src/sys/modules/ums/../../dev/usb/ums.c:594 (gdb) c Program received signal SIGSEGV, Segmentation fault. cdevsw_rel (csw=0x0) at /home/usr.src/sys/kern/kern_conf.c:124 /home/usr.src/sys/kern/kern_conf.c:124:3280:beg:0xc0489e14 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x48 fault code = supervisor write, page not present instruction pointer = 0x8:0xc0489e14 stack pointer = 0x10:0xcbf6e9c0 frame pointer = 0x10:0xcbf6e9c4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 559 (cat) -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: too late null checks
Ted Unangst wrote: Bugs found with Coverity's automated analysis. In each case, either the NULL check is unnecessary, or it's too late because the variable was already deref'd. ... netinet/tcp_subr.c:tcp_mtudisc tp has already been dereferenced to obtain isipv6 result Thanks, fixed. Did you run your entire tool on the FreeBSD tree or is this subset of the available tests and checks? -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
How can I fake a device ?
Hi, I want to know is there a way to call *_probe (for device driver) with fake (PCI) device that does not exists in the system ? First of all a cant find how struct device is declared (i've searched even the compile/ dir) and second I think that I'll need to intercept pci_get_vendor and pci_get_device funcs with my own which should detect the fake device and thus will return vandor/device that I need to fake. I realy don't need anything else except _probe ... regards. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How can I fake a device ?
In message [EMAIL PROTECTED], Iasen Kostov wrote: Hi, I want to know is there a way to call *_probe (for device driver) with fake (PCI) device that does not exists in the system ? First of all a cant find how struct device is declared (i've searched even the compile/ dir) and second I think that I'll need to intercept pci_get_vendor and pci_get_device funcs with my own which should detect the fake device and thus will return vandor/device that I need to fake. I realy don't need anything else except _probe ... I have never tried such but grimpsed the PCI framework, I propose the following, though I don't imagine why you want to do so: Your driver have to contain DEVICE_IDENTIFY method that calls device_add_child to allocate device_t object. Then you allocate 'struct pci_devinfo' and initialize pci_devinfo as you like. And you have to make your driver as a module. Then a device object will show up on the device tree on your system. You may want to have a look at pci_add_children@/sys/dev/pci/pci.c ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
