Re: Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1
On 08/16/06 20:37 Pyun YongHyeon said the following: If the media is set to 'none' you couldn't send anything from re(4) as recent changes checks whether the link is present(Receiver should work). ifconfig re0 media 10baset or 100baset always returns error, so there doesn't seem to be anyway of forcing the media type. Does old(working) version also show 'none' for media? Do you use manual media configuration instead of 'auto'? i never got re(4) working, and the patch i'm currently using forces the use of rl(4) instead of using re(4). using rl(4) still shows media as none, but it works the way it should with packets going in and out. i've yet to try dag-erling's suggestion of disabling rx and tx checksums. i'll also try with the patch you sent it to see if that works. -- Regards, /\_/\ All dogs go to heaven. [EMAIL PROTECTED](0 0) http://www.openmalaysiablog.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo The opinions here in no way reflect the opinions of my $a $b. | | done; done | +=+ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1
On Thu, Aug 17, 2006 at 02:05:48PM +0800, Dinesh Nair wrote: On 08/16/06 20:37 Pyun YongHyeon said the following: If the media is set to 'none' you couldn't send anything from re(4) as recent changes checks whether the link is present(Receiver should work). ifconfig re0 media 10baset or 100baset always returns error, so there doesn't seem to be anyway of forcing the media type. Does old(working) version also show 'none' for media? Do you use manual media configuration instead of 'auto'? i never got re(4) working, and the patch i'm currently using forces the use of rl(4) instead of using re(4). using rl(4) still shows media as none, but it works the way it should with packets going in and out. i've yet to try dag-erling's suggestion of disabling rx and tx checksums. i'll also try I think disabling checksum offload wouldn't help either. re(4)/rlphy(4) should be taught to detect link status. with the patch you sent it to see if that works. -- Regards, Pyun YongHyeon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: struct dirent question
On Wed, 2006-Aug-16 15:54:25 -0700, Micah wrote:
I think you could fake it as follows:
struct dirent {
__uint32_t d_fileno;/* file number of entry */
__uint16_t d_reclen;/* length of this record */
__uint8_t d_type; /* file type, see below */
__uint8_t d_namlen;/* length of string in d_name */
#define MAXNAMLEN 255
chard_name[MAXNAMLEN + 1]; /* name must be no longer than
this */
#if !__BSD_VISIBLE
#undef MAXNAMLEN
#endif
};
Macro definitions don't nest so this isn't safe. Consider some code that
does:
#define MAXNAMLEN 1024
...
#include sys/dirent.h
...
charmybuffer[MAXNAMLEN];
--
Peter Jeremy
pgp9G71sqx9ME.pgp
Description: PGP signature
6-STABLE snapshot (background fsck) lock-up
I've seen this several times now, but this time I got a dump. Basically, the system comes up after unclean shutdown, throws a bunch of filesystems into the background fsck list, and begins 60 seconds later. After some amount of time, the system will lock up, presumably hung waiting on locks. Here's some info: lock type bufwait: EXCL (count 1) by thread 0xff0128812980 (pid 804) lock type getblk: EXCL (count 1) by thread 0xff0128812980 (pid 804)Locked vnodes 0xff01c5c9f000: tag ufs, type VREG usecount 1, writecount 0, refcount 13656 mountedhere 0 flags (VV_SYSTEM) v_object 0xff01b09542a0 ref 0 pages 1691637 lock type snaplk: EXCL (count 1) by thread 0xff0128812980 (pid 804) ino 4, on dev label/vol4 How can I use kgdb to get more debugging information from this? Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to get RealTek 8139C+ to work with re(4) under FreeBSD 6.1
Dinesh Nair [EMAIL PROTECTED] writes: i never got re(4) working, and the patch i'm currently using forces the use of rl(4) instead of using re(4). using rl(4) still shows media as none, but it works the way it should with packets going in and out. i've yet to try dag-erling's suggestion of disabling rx and tx checksums. i'll also try with the patch you sent it to see if that works. If you can receive but not transmit (as I understood from other posts in the thread, though you never answered my question about tcpdump), disabling tx checksum offloading should be the *first* thing to try, especially as there is a known bug in some RealTek chipsets which will cause tx checksums to be computed incorrectly for short packets (such as ICMP echo replies, or TCP handshake frames). DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6-STABLE snapshot (background fsck) lock-up
On Thu, Aug 17, 2006 at 07:08:31AM -0500, Eric Anderson wrote: I've seen this several times now, but this time I got a dump. Basically, the system comes up after unclean shutdown, throws a bunch of filesystems into the background fsck list, and begins 60 seconds later. After some amount of time, the system will lock up, presumably hung waiting on locks. Here's some info: lock type bufwait: EXCL (count 1) by thread 0xff0128812980 (pid 804) lock type getblk: EXCL (count 1) by thread 0xff0128812980 (pid 804)Locked vnodes 0xff01c5c9f000: tag ufs, type VREG usecount 1, writecount 0, refcount 13656 mountedhere 0 flags (VV_SYSTEM) v_object 0xff01b09542a0 ref 0 pages 1691637 lock type snaplk: EXCL (count 1) by thread 0xff0128812980 (pid 804) ino 4, on dev label/vol4 How can I use kgdb to get more debugging information from this? Look at the http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html for instructions for ddb. What is the date of the system checkout ? pgpHtWHCTyns5.pgp Description: PGP signature
Re: 6-STABLE snapshot (background fsck) lock-up
On 08/17/06 07:25, Kostik Belousov wrote: On Thu, Aug 17, 2006 at 07:08:31AM -0500, Eric Anderson wrote: I've seen this several times now, but this time I got a dump. Basically, the system comes up after unclean shutdown, throws a bunch of filesystems into the background fsck list, and begins 60 seconds later. After some amount of time, the system will lock up, presumably hung waiting on locks. Here's some info: lock type bufwait: EXCL (count 1) by thread 0xff0128812980 (pid 804) lock type getblk: EXCL (count 1) by thread 0xff0128812980 (pid 804)Locked vnodes 0xff01c5c9f000: tag ufs, type VREG usecount 1, writecount 0, refcount 13656 mountedhere 0 flags (VV_SYSTEM) v_object 0xff01b09542a0 ref 0 pages 1691637 lock type snaplk: EXCL (count 1) by thread 0xff0128812980 (pid 804) ino 4, on dev label/vol4 How can I use kgdb to get more debugging information from this? Look at the http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html for instructions for ddb. What is the date of the system checkout ? 6-STABLE from ~8/12/06. So there's not much that can be done with the vmcore? I'll add the options to my kernel config (I was missing a few), and I suppose wait for another deadlock. Thanks! Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Is it possible to trace the routing socket messages going from the kernel to a particular daemon
Is it possible that we can add some loadable module into the kernel to get a pid of a daemon-process and then somehow trace routing socket messages coming in / going out from the kernel to that particular daemon ? The thing why I am in need of this is that there are two daemons , one daemon is responsible for configuring the interfaces ...and the second is actually awaiting the updates from the kernel ( that it should send in case it sees that there is a change in the ifstate for the interface ---IFD update) ... any resources / material would be of great help.Thanks and regards. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Is it possible to trace the routing socket messages going from the kernel to a particular daemon
get a pid of a daemon-process and then somehow trace routing socket messages coming in / going out from the kernel to that particular daemon ? `ktrace -p DAEMON-PID` might be what you want. -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6-STABLE snapshot (background fsck) lock-up
On 08/17/06 07:30, Eric Anderson wrote: On 08/17/06 07:25, Kostik Belousov wrote: On Thu, Aug 17, 2006 at 07:08:31AM -0500, Eric Anderson wrote: I've seen this several times now, but this time I got a dump. Basically, the system comes up after unclean shutdown, throws a bunch of filesystems into the background fsck list, and begins 60 seconds later. After some amount of time, the system will lock up, presumably hung waiting on locks. Here's some info: lock type bufwait: EXCL (count 1) by thread 0xff0128812980 (pid 804) lock type getblk: EXCL (count 1) by thread 0xff0128812980 (pid 804)Locked vnodes 0xff01c5c9f000: tag ufs, type VREG usecount 1, writecount 0, refcount 13656 mountedhere 0 flags (VV_SYSTEM) v_object 0xff01b09542a0 ref 0 pages 1691637 lock type snaplk: EXCL (count 1) by thread 0xff0128812980 (pid 804) ino 4, on dev label/vol4 How can I use kgdb to get more debugging information from this? Look at the http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html for instructions for ddb. What is the date of the system checkout ? 6-STABLE from ~8/12/06. So there's not much that can be done with the vmcore? I'll add the options to my kernel config (I was missing a few), and I suppose wait for another deadlock. Ok, had another one. Here are screenshots: http://www.googlebit.com/freebsd/snapshots/ Is it the sysctl that is triggering it? Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6-STABLE snapshot (background fsck) lock-up
On Thu, Aug 17, 2006 at 09:53:28AM -0500, Eric Anderson wrote: On 08/17/06 07:30, Eric Anderson wrote: On 08/17/06 07:25, Kostik Belousov wrote: On Thu, Aug 17, 2006 at 07:08:31AM -0500, Eric Anderson wrote: I've seen this several times now, but this time I got a dump. Basically, the system comes up after unclean shutdown, throws a bunch of filesystems into the background fsck list, and begins 60 seconds later. After some amount of time, the system will lock up, presumably hung waiting on locks. Here's some info: lock type bufwait: EXCL (count 1) by thread 0xff0128812980 (pid 804) lock type getblk: EXCL (count 1) by thread 0xff0128812980 (pid 804)Locked vnodes 0xff01c5c9f000: tag ufs, type VREG usecount 1, writecount 0, refcount 13656 mountedhere 0 flags (VV_SYSTEM) v_object 0xff01b09542a0 ref 0 pages 1691637 lock type snaplk: EXCL (count 1) by thread 0xff0128812980 (pid 804) ino 4, on dev label/vol4 How can I use kgdb to get more debugging information from this? Look at the http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html for instructions for ddb. What is the date of the system checkout ? 6-STABLE from ~8/12/06. So there's not much that can be done with the vmcore? I'll add the options to my kernel config (I was missing a few), and I suppose wait for another deadlock. Ok, had another one. Here are screenshots: http://www.googlebit.com/freebsd/snapshots/ Is it the sysctl that is triggering it? Hmm, unbelievable. It would be much simpler for you to set up serial console. Anyway, you use g_journal, and the problem seems to be related to some geom locking. pjd@ is the right person to contact. I added him to the Cc:. pgpihylf7MQ3E.pgp Description: PGP signature
Re: 6-STABLE snapshot (background fsck) lock-up
On 08/17/06 10:04, Kostik Belousov wrote: On Thu, Aug 17, 2006 at 09:53:28AM -0500, Eric Anderson wrote: On 08/17/06 07:30, Eric Anderson wrote: On 08/17/06 07:25, Kostik Belousov wrote: On Thu, Aug 17, 2006 at 07:08:31AM -0500, Eric Anderson wrote: I've seen this several times now, but this time I got a dump. Basically, the system comes up after unclean shutdown, throws a bunch of filesystems into the background fsck list, and begins 60 seconds later. After some amount of time, the system will lock up, presumably hung waiting on locks. Here's some info: lock type bufwait: EXCL (count 1) by thread 0xff0128812980 (pid 804) lock type getblk: EXCL (count 1) by thread 0xff0128812980 (pid 804)Locked vnodes 0xff01c5c9f000: tag ufs, type VREG usecount 1, writecount 0, refcount 13656 mountedhere 0 flags (VV_SYSTEM) v_object 0xff01b09542a0 ref 0 pages 1691637 lock type snaplk: EXCL (count 1) by thread 0xff0128812980 (pid 804) ino 4, on dev label/vol4 How can I use kgdb to get more debugging information from this? Look at the http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html for instructions for ddb. What is the date of the system checkout ? 6-STABLE from ~8/12/06. So there's not much that can be done with the vmcore? I'll add the options to my kernel config (I was missing a few), and I suppose wait for another deadlock. Ok, had another one. Here are screenshots: http://www.googlebit.com/freebsd/snapshots/ Is it the sysctl that is triggering it? Hmm, unbelievable. It would be much simpler for you to set up serial console. Not really, at least right now. I'm doing this remotely, so it'll be some time before I can do that. Anyway, you use g_journal, and the problem seems to be related to some geom locking. pjd@ is the right person to contact. I added him to the Cc:. Ahah. Ok. Thank you! Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Is it possible to trace the routing socket messages going from the kernel to a particular daemon
On Thu, 17 Aug 2006, Shriek wrote: Is it possible that we can add some loadable module into the kernel to get a pid of a daemon-process and then somehow trace routing socket messages coming in / going out from the kernel to that particular daemon ? The thing why I am in need of this is that there are two daemons , one daemon is responsible for configuring the interfaces ...and the second is actually awaiting the updates from the kernel ( that it should send in case it sees that there is a change in the ifstate for the interface ---IFD update) ... any resources / material would be of great help.Thanks and regards. This won't give you exactly what you want, but if you don't know about it already, you probably will find it useful. route monitor monitors routing socket messages generated by the kernel, and includes the pid of the process they are destined for. It doesn't include messages sent to the kernel. As an exampl: TTY 1: peppercorn# route monitor got message of size 200 on Thu Aug 17 20:03:20 2006 RTM_GET: Report Metrics: len 200, pid: 784, seq 1, errno 0, flags:UP,GATEWAY,DONE,STATIC locks: inits: sockaddrs: DST,GATEWAY,NETMASK,IFP,IFA default 192.168.100.1 default fxp0:0.3.47.d3.46.47 192.168.100.198 TTY 2 after running route monitor on the first tty: peppercorn:~ route -n get www.watson.org route to: 209.31.154.41 destination: default mask: default gateway: 192.168.100.1 interface: fxp0 flags: UP,GATEWAY,DONE,STATIC recvpipe sendpipe ssthresh rtt,msecrttvar hopcount mtu expire 0 0 0 0 0 0 1500 0 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Minidumps in FreeBSD 4
Hi all, I'm sort of curious as to how many people might be interested in this. I'm aware that there are still other companies who also have embedded products / appliances based on FreeBSD 4, and I suppose that's probably the only interest for such a patch. It's available at: http://databits.net/~dho/minidumps.patch.bz2 It's ~100KB uncompressed; 26KB otherwise. There are some dump-related changes that were made to e.g. disk drivers -- so there may be some bugs. Please let me know if you're able to use it successfully, if there are other things you'd like to see it do, and whatnot. It's pretty much a straight backport from Peter Wemm's minidumps which were recently MFCed to FreeBSD 6. I only had to make a couple changes to a few things, and figure out how to get gdb to read things correctly (which was basically a couple lines of obvious code and bringing some extra bits from the libkvm changes over, since gdb in 4.x doesn't use libkvm for kernel debugging). If there's any significant interest, maybe somebody can be convinced to commit it to RELENG_4 (ha ha ha). Huge thanks to Peter who helped me out with understanding some of the more hairy things towards the end. --Devon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
