Re: Possible problem with rl (Realtek) ethernet card driver in 4.5-STABLE
Does this look like a driver bug, a hardware fault or all of the above? I realise the realtek chips are not the best, but they shouldn't cause a box to fall over :) Here are the details from the core dumps I got, which led me to Hi, I had (in the words of Andrew Lloyd Webber) some Strange Things Mystifying when I was writting a device driver that were very similar. Later I upgraded to version 5.0 PREVIEW and the same code performed flawlessly. I have some deep seated suspicians that the VIA chipset had some problems in the 4.X releases. You might try a newer release (if not 4.5). Cheers Andy To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RFC- Kernel patches for process tracking (read more in body)
Hi hackers,
I had a need to track all processes including daemons that become owned
by init that started from a process for my statistics collection function of
my clustering software.
The basic idea is to add a structure to the 'proc' structure to keep current
and future data in and to be able to set (at least today) the application ID
into this structure via a shell command using a syscall().
Please give me comments on the patches.
*** /usr/src/sys/kern/kern_fork.c.orig Thu May 10 19:54:16 2001
--- /usr/src/sys/kern/kern_fork.c Thu Jan 10 16:50:25 2002
***
*** 362,367
--- 362,369
crhold(p1-p_ucred);
uihold(p1-p_cred-p_uidinfo);
+ bcopy(p1-p_csed, p2-p_csed, sizeof(p2-p_csed));
+
if (p2-p_prison) {
p2-p_prison-pr_ref++;
p2-p_flag |= P_JAILED;
*** /usr/src/sys/sys/proc.h.origThu Jan 10 16:56:13 2002
--- /usr/src/sys/sys/proc.h Thu Jan 10 17:00:22 2002
***
*** 53,58
--- 53,59
#endif
#include sys/ucred.h
#include sys/event.h/* For struct klist */
+ #include sys/cse.h
/*
* One structure allocated per session.
***
*** 144,149
--- 145,151
charp_stat; /* S* process status. */
charp_pad1[3];
+ struct csed p_csed; /* Virtual Application Descriptor */
pid_t p_pid; /* Process identifier. */
LIST_ENTRY(proc) p_hash;/* Hash chain. */
LIST_ENTRY(proc) p_pglist; /* List of processes in pgrp. */
*** /usr/src/sys/conf/files.origThu Jan 10 17:07:21 2002
--- /usr/src/sys/conf/files Thu Jan 10 17:07:35 2002
***
*** 575,580
--- 575,581
kern/subr_scanf.c standard
kern/subr_taskqueue.c standard
kern/subr_xxx.c standard
+ kern/sys_cse.cstandard
kern/sys_generic.cstandard
kern/sys_pipe.c standard
kern/sys_process.cstandard
*** /usr/src/sys/kern/syscalls.master.orig Thu Jan 10 17:10:01 2002
--- /usr/src/sys/kern/syscalls.master Thu Jan 10 17:10:27 2002
***
*** 520,522
--- 520,523
const struct kevent *changelist, int nchanges, \
struct kevent *eventlist, int nevents, \
const struct timespec *timeout); }
+ ZZZ STD BSD { int cse_set_id(int id_num, pid_t pid); }
(NOTE 'ZZZ' changed by install script to be the next available #)
(HERE IS 'sys_cse.c')
#include opt_ktrace.h
#include sys/param.h
#include sys/systm.h
#include sys/sysproto.h
#include sys/proc.h
#include sys/uio.h
#include sys/kernel.h
#include sys/resourcevar.h
#include sys/sysctl.h
#include sys/sysent.h
/*
* CSE system call.
*/
#ifndef _SYS_SYSPROTO_H_
struct cse_set_id_args {
int id_num;
pid_t pid;
};
#endif
int
cse_set_id(p, uap)
struct proc *p;
register struct cse_set_id_args *uap;
{
struct proc *px;
if ((px = pfind(uap-pid)) == NULL) {
return (ESRCH);
}
px-p_csed.cse_c_id = uap-id_num;
return (0);
}
(PATCHES TO 'PS' TO MAKE USE OF THIS)
*** /usr/src/bin/ps/ps.c.orig Wed Aug 1 07:06:23 2001
--- /usr/src/bin/ps/ps.cThu Jan 10 18:34:12 2002
***
*** 103,109
static voidusage __P((void));
static uid_t *getuids(const char *, int *);
! char dfmt[] = pid tt state time command;
char jfmt[] = user pid ppid pgid sess jobc state tt time command;
char lfmt[] = uid pid ppid cpu pri nice vsz rss wchan state tt time
command; char o1[] = pid;
--- 103,109
static voidusage __P((void));
static uid_t *getuids(const char *, int *);
! char dfmt[] = pid tt vapp state time command;
char jfmt[] = user pid ppid pgid sess jobc state tt time command;
char lfmt[] = uid pid ppid cpu pri nice vsz rss wchan state tt time
command; char o1[] = pid;
*** /usr/src/bin/ps/extern.h.orig Sat Aug 28 01:14:50 1999
--- /usr/src/bin/ps/extern.hThu Jan 10 18:34:42 2002
***
*** 59,64
--- 59,65
void maxrss __P((KINFO *, VARENT *));
void nlisterr __P((struct nlist *));
void p_rssize __P((KINFO *, VARENT *));
+ void p_vapp __P((KINFO *, VARENT *));
void pagein __P((KINFO *, VARENT *));
void parsefmt __P((char *));
void pcpu __P((KINFO *, VARENT *));
*** /usr/src/bin/ps/keyword.c.orig Wed Feb 14 19:55:31 2001
--- /usr/src/bin/ps/keyword.c Thu Jan 10 18:33:40 2002
***
*** 185,190
--- 185,191
{upr, UPR, NULL, 0, pvar, NULL, 3, POFF(p_usrpri), CHAR, d},
{user, USER, NULL, LJUST|DSIZ, uname, s_uname, USERLEN},
{usrpri, , upr},
+ {vapp, VAPP, NULL, 0, p_vapp, NULL, 2},
{vsize, , vsz},
{vsz, VSZ, NULL, 0, vsize, NULL, 5},
{wchan, WCHAN, NULL, LJUST, wchan, NULL, 6},
***
RFC (continued -- Forgot a file)
Sorry,
Forgot this one:
(cse.h)
#ifndef _SYS_CSE_H_
#define _SYS_CSE_H_
/*
* One structure allocated per session.
*/
struct csed {
int cse_c_id; /* ID Number of Application */
/* These next fields are not being used yet, but soon... */
int cse_h_node_id; /* Home Node ID of Process */
int cse_c_node_id; /* Current Node ID of process */
int cse_flags; /* Flags used. */
};
#endif /* !_SYS_CSE_H_ */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
UID Limit
Hi, I was wondering if anyone would be able to tell me what the limit is on a UID? Ie what is the highest integer it can go up to. I suppose as well some applications have different values.. or am I completly wrong :) Thanks Jamie To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Possible problem with rl (Realtek) ethernet card driver in 4.5-STABLE
Nigel Roberts writes: #10 0xc0237fbe in rl_rxeof (sc=0xc0b9d200) at ../../pci/if_rl.c:1151 #11 0xc023827a in rl_intr (arg=0xc0b9d200) at ../../pci/if_rl.c:1342 #12 0xc0279c7a in vec3 () #13 0xc01c2196 in ether_output (ifp=0xc0ba4000, m=0xc076af00, dst=0xc0c28770, rt0=0xc0c59d00) at ../../net/if_ethersubr.c:369 #14 0xc01d4663 in ip_output (m0=0xc076af00, opt=0x0, ro=0xc02f9970, flags=1, imo=0x0) at ../../netinet/ip_output.c:822 Was the realtek really at IRQ 3? I'm NOT an x86 hacker, and I don't understand the interrupt code there very well.. Is it possible to have an irq line which is shared between 2 devices which use different interrupt masks? If so, what prevents intr_mux() from being called for a TTY interrupt, and then calling another driver which shares the line but has a NET mask, even when NET interrupts are masked? Does this go away if you remove the serial line driver (sio) from your kernel? Can we see a (non verbose) dmesg from this box? Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
kernel I/O timing statistics
I have a need to record the total physical times spent on I/O requests during some period. My basic idea is to record the start time when the request is issued somewhere in a disk driver and the finish time somewhere in an interrupt routine. Can any one please tell me where are the right places to insert these hooks to collect these timing information for SCSI and IDE disks? I have only a little information about the driver structure in FreeBSD. Maybe this is not a good idea. Thanks for any enlightenment. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: UID Limit
On Wed, May 22, 2002 at 04:27:12PM +0100, Jamie Heckford wrote: Hi, I was wondering if anyone would be able to tell me what the limit is on a UID? Ie what is the highest integer it can go up to. I suppose as well some applications have different values.. or am I completly wrong :) The functions that deal with user ID's take a parameter of type uid_t. The uid_t type is defined in sys/types.h as u_int32_t. Hence, at least theoretically, FreeBSD supports uid's in the range 0 to 4G-1. However, if you decide to go above 64K-1, you may hit various limitations. NFS and NIS (YellowPages), for example, will not be too happy about uid's that big, IIRC. There might be other programs which assume 16-bit uid's, although I cannot think of any at the moment. After 64K-1, the next roadblock is 2G-1, a.k.a. INT_MAX. This will become a problem as soon as some program tries to store an uid_t value into a plain, signed int variable - the value will either turn negative, or be truncated to 2G-1, and much fun will ensue. It is not too common for a program to misuse an uid in this kind, but it is for a gid - there are many programs, including some in the FreeBSD base system, which use 'int' instead of 'gid_t', simply because it's defined that way in gid.h. The 'usual' user creation utilities try to keep the gid the same as the uid, so if you create a user with an uid 2G-1, your gid experience might be.. mm.. interesting. So, to sum it all up - there are no problems, except where there are :) G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If the meanings of 'true' and 'false' were switched, then this sentence wouldn't be false. msg34559/pgp0.pgp Description: PGP signature
sendto syscall
Hello, I am working on a bandwidth measurment tool where I need to send udp packets with fixed interspacing. For this purpose, I am trying to measure the latency of sendto syscall. In one experiment, I set the socket buffer ( both send and receive ) equal to the size of the packet for that experiment ( 512 bytes in that case). Then I do (several) pair of back-to-back sendto and measure their latency using gettimeofday. I repeat the same experiment with a very high value of socket buffer. In first case (socket buffer = pkt size ), I was expecting to see the latecny of second sendto higher relatively to first one since second sendto would block. In the second case , the latency of two sendto should have been of same order. The results of the experiment donot show any trend in the first case nor in the second case. Does anyone have any first thoughts on this ? Does the sendto return after copying the data from user space to kernal space or returns after the packet leaves the interface card ? Thanks, manish http://www.cis.udel.edu/~jain To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: tuning a CPU bound server
On Mon, May 20, 2002 at 12:52:09PM -0700, Terry Lambert wrote: The problem is that as you maintain your patches, and the patch vendor maintains their patches, and DJB maintains his code, you end up with network effects. But DJB does't maintain his code. I don't think it he has touched it in years. He maintains his code quite well. Thing is he only changes something if there is something to change. In the case of qmail-1.03 this means no change since 1998. Why? Simply because qmail-1.03 is essentially bugfree and works perfectly for it's intended purpose. I know because I spend the last five years writing and maintaining the qmail-ldap add-on and know the qmail code inside-out. Actually once you get used to it it's very nice and clean. Otherwise you are of course correct :) -- Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: tuning a CPU bound server
On Wed, May 22, 2002 at 11:31:33PM +0200, Andre Oppermann wrote: But DJB does't maintain his code. I don't think it he has touched it in years. He maintains his code quite well. Thing is he only changes something if there is something to change. In the case of qmail-1.03 this means no change since 1998. Why? Simply because qmail-1.03 is essentially bugfree and works perfectly for it's intended purpose. I know because I spend the last five years writing and maintaining the qmail-ldap add-on and know the qmail code inside-out. Actually once you get used to it it's very nice and clean. Not intended as a slight against DJB ( althought I do realize it looked that way ). I LOVE qmail, look at my headers. But DJB does not introduce any of Terry's network effects. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: tuning a CPU bound server
Christopher Weimann wrote: Not intended as a slight against DJB ( althought I do realize it looked that way ). I LOVE qmail, look at my headers. But DJB does not introduce any of Terry's network effects. Sure he does. By not integrating the patches, he ends up with many patches sitting out there that end up being conflicting, whereas if they had integrated the code, they would not be conflicting. There's really no difference between patches posted to web sites and patches which are posted to usenet. People are in exactly the same boat with qmail as people were with 386BSD, before I wrote the patchkit, and hand-resolved the conflicts between the patches. Of for that matter, the same boat people were in with the UMich LDAP code, until I hand resolved those conflicts, too, and posted my megapatch on FreeBSD.org (if you will check the OpenLDAP CVS repository, you will see that import the FreeBSD patches was the very first thing they did after importing the UMich code at the very start of the project). Actually, people are worse off. At least with NetBSD and FreeBSD, it was possible to derive code from 386BSD, and the same for OpenLDAP being able to derive code from UMich code. With qmail, the license prevents this. The best you can do, without a license change, or active adoption of the patches by DJB, is form an active community, and then run a patchkit-type operation. The more people who use qmail, and need a minor feature tweak that can't be done in the context of configuration data, the larger the conflict domain for the various needs patch sets. I think the qmail user base will never rival the sendmail or postfix user bases because of this. The network shakes apart at a very low level of driving. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: tuning a CPU bound server
I think this has gotten off-topic. I am going to go back and respond to the original posting. When I was doing BEST Internet we had very similar problems with our mail servers. We were constantly cpu-bound. I was constantly fiddling with it (sendmail in this case). For months. For years, in fact. We did things like put sendmail's dns cache in a ramdisk, split the queues, tuned the retry periods, etc. The fiddling ultimately produced incremental gains but in retrospect it was a waste of time. The solution that worked... *REALLY* worked, was two throw more horsepower at the problem. Even more so the solution was to simply add more servers. I created a set of 3 incoming mail servers and a set of 3 outgoing mail servers. The mail servers were load balanced simply with an IN A (DNS) round robin, which worked wonderfully. Separating the incoming from the outgoing servers allowed me to do relatively simple tuning of the incoming servers for incoming traffic, and relatively simple tuning of the outgoing servers for outgoing traffic. One also gets the added perk of being able to turn down individual servers for maintainance without taking down the entire company's mail system in the process. So what I would recommend is that you add another duel-cpu server and load balance the traffic with DNS. It's worth doing some tuning but I would not waste my time at it. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: UID Limit
Peter Pentchev wrote: On Wed, May 22, 2002 at 04:27:12PM +0100, Jamie Heckford wrote: Hi, I was wondering if anyone would be able to tell me what the limit is on a UID? Ie what is the highest integer it can go up to. I suppose as well some applications have different values.. or am I completly wrong :) The functions that deal with user ID's take a parameter of type uid_t. The uid_t type is defined in sys/types.h as u_int32_t. Hence, at least theoretically, FreeBSD supports uid's in the range 0 to 4G-1. It supports them that high, yes, but I believe they wrap at 9. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
