Re: remote debugging question
On Tue, 28 Sep 2004 16:22:29 -0700 Jerry Toung [EMAIL PROTECTED] wrote: Hi Greg, thank you for all the feedback. The set remotebaud 1 thing in my previous email was a typo, I usually enter 9600. So you're saying that I may have a communication problem. I would like to point out that I can use cu -l cuaa0 -s 9600 on both side and all is well. What do you think could cause this communication issue? I will run another cvsup soon. May be a bug in 6.0current for kgdb. [..] Note also that you need a -current after 15 sept 2004 to be able to properly set breakpoints and obtain a backtrace without crashing the kernel. (See the commit log for src/sys/i386/i386/gdb_machdep.c for details). marco -- panic(The moon has moved again.); ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fixes for ipfw and pf lock ordering issues
On Fri, Sep 24, 2004 at 10:37:54PM +, Christian S.J. Peron wrote:
Good day folks, we need some beta testers
Hi, as an author of LOR reports I feel obliged to test this patch. I was
running it for a 2 days and intended to report, that for me everything works
ok, when an panic occured. Regretably, I do not have actual panic message, but
the trace looks as follows:
pf_socket_lookup(cbb24958,cbb2495c,2,cbb24a0c,c15275a0) at
pf_socket_lookup+0x22
pf_test_tcp(cbb249c0,cbb249bc,2,c14d6200,c139e500) at pf_test_tcp+0x648
pf_test(2,c14b8014,cbb24aa8,c15275a0,c15661c0) at pf_test+0x53d
pf_check_out(0,cbb24aa8,c14b8014,2,c15275a0) at pf_check_out+0x6d
pfil_run_hooks(c066da00,cbb24b1c,c14b8014,2,c15275a0) at pfil_run_hooks+0xeb
ip_output(c139e500,0,cbb24ae8,0,0) at ip_output+0x630
tcp_twrespond(c18709a0,10,c0607304,69c,1) at tcp_twrespond+0x1ed
tcp_twstart(c186b380,0,c0606ba2,96f,0) at tcp_twstart+0x1d3
tcp_input(c139d800,14,c14b8014,1,0) at tcp_input+0x2c39
ip_input(c139d800,0,c06053ae,e7,c066d098) at ip_input+0x5b0
netisr_processqueue(c066d098,c0642940,1,c05fb4da,c10d62c0) at
netisr_processqueu
e+0x8e
swi_net(0,0,c05f9b18,269,0) at swi_net+0xe9
ithread_loop(c10de480,cbb24d48,c05f990f,31f,100) at ithread_loop+0x172
fork_exit(c04a6520,c10de480,cbb24d48) at fork_exit+0xc6
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xcbb24d7c, ebp = 0 ---
db
db show locks
exclusive sleep mutex inp (tcpinp) r = 0 (0xc1527630) locked @
/usr/src/sys/neti
net/tcp_input.c:737
exclusive sleep mutex tcp r = 0 (0xc066de6c) locked @
/usr/src/sys/netinet/tcp_i
nput.c:611
db
(gdb) l *pf_socket_lookup+0x22
0xc043a2d2 is in pf_socket_lookup (/usr/src/sys/contrib/pf/net/pf.c:2414).
2409#endif
2410struct inpcb*inp;
2411
2412#ifdef __FreeBSD__
2413if (inp_arg != NULL) {
2414*uid = inp_arg-inp_socket-so_cred-cr_uid;
2415*gid = inp_arg-inp_socket-so_cred-cr_groups[0];
2416return (1);
2417}
2418#endif
(gdb) l *pf_test_tcp+0x648
0xc043aef8 is in pf_test_tcp (/usr/src/sys/contrib/pf/net/pf.c:2781).
2776r = TAILQ_NEXT(r, entries);
2777else if (r-rule_flag PFRULE_FRAGMENT)
2778r = TAILQ_NEXT(r, entries);
2779else if ((r-flagset th-th_flags) != r-flags)
2780r = TAILQ_NEXT(r, entries);
2781else if (r-uid.op (lookup != -1 || (lookup =
2782#ifdef __FreeBSD__
2783pf_socket_lookup(uid, gid, direction, pd, inp),
1))
2784#else
2785pf_socket_lookup(uid, gid, direction, pd), 1))
If there is anything more I may provide, please tell me. I can't get my kernel
dumps on, although I have KDB_UNATTENDED option in kernel, it gaves me prompt
on panics, and when I call panic from debugger I get hangs :S If you know any
other way to get the panic message, I'd appreciate.
My comments for the patch alone:
Before the patch, I got the LOR's and rather rare panics due to this problem.
They were happening mainly when changing PF rules, sometimes on shutdown.
After the patch, I do not have any LOR messages, I tried to load PF rules in a
loop for a few minutes. After that I just left the system for it own, while
there was some activity on network (and particularly on rules with uid
matching). Till today I was quite happy with that.
If there is anything I can debug more, to help you solve the problem, please
ask.
Cheers,
Wiktor Niesiobedzki
PS. Just for the record - I tired it only with PF. I'm also planning to give
it a shot with my old IPFW rules.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 4.10 system stops responding
Hello, World! Opening a remote HTTP URL in raplayer (old a.out program) makes my FreeBSD 4.10-RELEASE box completely frozen. The system does not respond on PINGs. The same happens when I run raplayer in a remote X session. It looks like the trouble happens in the beginning of the prebuffering, before start of the playback. What is quite interesting is that when I entered tuss raplayer /dev/console the system did not get frozen. Can this be something timing/buffering related? Is there any way to investigate the problem without using NMI? Igor. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Device probe issue with an em(4) compatible device
I have a somewhat limited knowledge of FreeBSD's device system, so forgive (and correct) me if I get any of this wrong. I am writing a network driver for a em(4) compatible chip. I know the specific subvendor id and subdevice id, but the em(4) driver seems to attach to the device before my driver can. Is this because the em_probe is occurring before my probe AND because the em_probe is allowing for PCI_ANY_ID for subvendor subdevice ids (the vendor and device ids of my card are identical to an actual Intel card)? If so the solution then would be to have the em driver return a number less than zero in em_probe and my driver's probe to return a number greater than the em_probes's return? On a side not, would it also not be more correct for FreeBSD drivers in the tree to return a negative number for _any_ device that accepts a PCI_ANY_ID value? Thanks in advance for the clarification/help. -- Brenden C. Grace Intelli7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Device probe issue with an em(4) compatible device
If its compatible with em why not just alter the em to support the additional id's? Steve - Original Message - From: Brenden Grace [EMAIL PROTECTED] I am writing a network driver for a em(4) compatible chip. I know the specific subvendor id and subdevice id, but the em(4) driver seems to attach to the device before my driver can. Is this because the em_probe is occurring before my probe AND because the em_probe is allowing for PCI_ANY_ID for subvendor subdevice ids (the vendor and device ids of my card are identical to an actual Intel card)? If so the solution then would be to have the em driver return a number less than zero in em_probe and my driver's probe to return a number greater than the em_probes's return? On a side not, would it also not be more correct for FreeBSD drivers in the tree to return a negative number for _any_ device that accepts a PCI_ANY_ID value? This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Device probe issue with an em(4) compatible device
On Wed, 2004-09-29 at 13:00, Steven Hartland wrote: If its compatible with em why not just alter the em to support the additional id's? Because I don't need to ... Me: but the em(4) driver seems to attach to the device before my driver can. This card works fine with the em driver, but I want my driver to support the device not the em driver. -- Brenden C. Grace Intelli7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Device probe issue with an em(4) compatible device
On Wed, 2004-09-29 at 13:37, Peter Buckingham wrote: why compile the em driver in at all? it won't probe the device if it doesn't exist ;-) because I need it ... otherwise, just add some code to the em's probe routine to check for your subvendor, subdevice pair and exit without attaching. Well sure (though ugly), but I think having it just return a negative number would be a better fix than that. I was more interested in why the em driver (and others) returns 0 and ends the probing of a device that it could possibly only partially support (based on its matching of PCI_ANY_ID). If I understand DEVICE_PROBE(9) correctly it seems that the whole reason for the negative return scale is to avoid this very issue. -- Brenden C. Grace Intelli7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Serial Console / GDB Port
Is it possible to use the same serial line as the console and GDB port? I currently have console=comconsole in my loader.conf and am able to break to the debugger in tip. (I'm Ssh'ing into a box connected via serial line to the dev box.) I tried setting up gdb on that serial link. Broke into the debugger in one screen, opened gdb -k kernel.debug in another screen, when I typed in the target remote /dev/cuaa0 line in gdb though the garbage printed onto the serial line (beginning of the gdb protocol session I'm assuming) ended up crashing ddb and panicing the kernel and I'm unable to access the box over the serial line (and currently don't have physical access to the box). Now, I don't think I added the 0x80 flag onto the serial port. Will adding that flag fix this? Or is there something more I need to do to be able to enable gdb and a console on the same serial line? -- Ryan Sommers [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Device probe issue with an em(4) compatible device
On Wed, 2004-09-29 at 15:32, Peter Buckingham wrote: experience then just not compiling in the em driver or an ugly like i describe (or you suggest) should be fine. I wasn't trying to be rude, but DEVICE_PROBE(9) seems to describe how conflicts like this should be handled. I was wondering if I am in fact correct that devices that attempt to be generic enough for wide support (accepting PCI_ANY_ID) should also properly pass the probing (by returning some negative) so that a driver that may better fit the exact device can attach. If you are doing it for the later reason why aren't you just extending the em driver to support your device? I _really_ am only interested in answers to the above question. -- Brenden C. Grace Intelli7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Device probe issue with an em(4) compatible device
In message: [EMAIL PROTECTED] Brenden Grace [EMAIL PROTECTED] writes: : I am writing a network driver for a em(4) compatible chip. I know the : specific subvendor id and subdevice id, but the em(4) driver seems to : attach to the device before my driver can. Is this because the em_probe : is occurring before my probe AND because the em_probe is allowing for : PCI_ANY_ID for subvendor subdevice ids (the vendor and device ids of my : card are identical to an actual Intel card)? If so the solution then : would be to have the em driver return a number less than zero in : em_probe and my driver's probe to return a number greater than the : em_probes's return? Ths solution is to have em's probe return a small negative number, and your probe return a larger negative number (eg, -10 for the em probe and -5 for yours). However, is there any reason you're writing a driver for a device that's compatible with em? why not use em? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Device probe issue with an em(4) compatible device
In message: [EMAIL PROTECTED] Brenden Grace [EMAIL PROTECTED] writes: : On Wed, 2004-09-29 at 13:37, Peter Buckingham wrote: : why compile the em driver in at all? it won't probe the device if it : doesn't exist ;-) : : because I need it ... As opposed to just hacking the em driver? : otherwise, just add some code to the em's probe routine to check for : your subvendor, subdevice pair and exit without attaching. : : Well sure (though ugly), but I think having it just return a negative : number would be a better fix than that. I was more interested in why the : em driver (and others) returns 0 and ends the probing of a device that : it could possibly only partially support (based on its matching of : PCI_ANY_ID). If I understand DEVICE_PROBE(9) correctly it seems that the : whole reason for the negative return scale is to avoid this very issue. That's correct. PCI_ANY_ID has nothing to do with it. If em_probe returns 0, it trumps all other drivers for that device that haven't had a chance to bid (as well as the potential drivers that bid a negative number). Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Device probe issue with an em(4) compatible device
In message: [EMAIL PROTECTED] Brenden Grace [EMAIL PROTECTED] writes: : On Wed, 2004-09-29 at 15:32, Peter Buckingham wrote: : experience then just not compiling in the em driver or an ugly like i : describe (or you suggest) should be fine. : : I wasn't trying to be rude, but DEVICE_PROBE(9) seems to describe how : conflicts like this should be handled. I was wondering if I am in fact : correct that devices that attempt to be generic enough for wide support : (accepting PCI_ANY_ID) should also properly pass the probing (by : returning some negative) so that a driver that may better fit the exact : device can attach. Well, it does match on the VENDOR ID and DEVICE, so it isn't that generic. The subvendor field is generally a don't care field for drivers in FreeBSD, so it is just following existing practices. Maybe that practice should be revisited, but that's why em_probe does things the way it does. If you need em to not attach, you'll have to hack em in your tree to return some small negative number. Chances are excellent that FreeBSD 6 will have facilities to address these issues (they are needed both for 'vendor supplied updated drivers' as well as 'please load me when you see this sort of card'). Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
