Re: getting interface MAC addr from C
Mario Lobo wrote:
Hi;
Would anyone have a tip on how to get the MAC from a C program?
I tried:
struct ifreq ifreq;
unsigned char *hw;
strcpy(ifreq.ifr_name, rl0);
ioctl(fd, SIOCGIFMAC, ifreq);
hw = ifreq.ifr_ifru.ifru_data;
This is probably very far from what you want. MAC stands here for MAC(4)
- e.g. security related stuff as opposed to something network (did you
read MAC as Media Access Control?).
I don't know it that is the easiest/right way to get this information
but you can use getifaddrs(3). Attached find a simple program which
prints out the interfaces and their MAC addresses using getifaddrs().
The code for getting the printable address is taken from function
fmt_sockaddr() from src/usr.bin/netstat/route.c.
You can also probably use SIOCGIFADDR with the right socket passed in as
fd or with sysctl(3) (int mib[] = { CTL_NET, AF_ROUTE, 0, AF_LINK,
NET_RT_IFLIST, 0}).
but i don't know if this is right or, if it is, where to get the MAC from the
structure. I doesn't issue any error compiling or running though.
In linux i used:
struct ifreq ifreq;
unsigned char *hw;
strcpy(ifreq.ifr_name, rl0);
ioctl(fd, SIOCGIFHWADDR, ifreq);
hw = ifreq.ifr_hwaddr.sa_data;
Thanks,
Mario
HTH
Michal
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVIDIA FreeBSD kernel feature requests
Miguel Mendez wrote: On Thu, 29 Jun 2006 13:12:31 +0200 Christian Zander [EMAIL PROTECTED] wrote: Hi, I just saw an article on OSNews about this, seems I missed it. NVIDIA has been looking at ways to improve its graphics driver for the FreeBSD i386 platform, as well as investigating the possibility of adding support for the FreeBSD amd64 platform, and identified a number of obstacles. Some progress has been made to resolve them, and NVIDIA would Yes, I'll tell you what the obstacle is: Lack of documentation. If you guys released the specs of your hardware this wouldn't be a problem. I think that this reaction wasn't called for. Modern GPUs are extraordinarily complex HW and to write a decent driver will take appropriate effort. I understand that open source infected people (like me) prefer having the detailed HW documentation but we shouldn't refuse the vendor's efforts to provide good driver to us. I haven't understood much of Mr. Zander's questions but I am pretty sure some readers did and probably have been talking to him off-list. I also tend to believe that his requests for features were based on good understanding of FreeBSD kernel internals (better that mine and probably also yours) and if we add the features or help him effectively use what's there everyone will benefit. Maybe not for the latest GPUs but I'm sure a lot people would be happy if they could use not-so-new NVidia hardware on FreeBSD/amd64. I built and AMD64 box from scratch with the sole purpose of running FreeBSD/amd64 on it. When it came time to choose the gfx card the choice was obvious: Ati Radeon 9250. I know that a lot of FreeBSDers are more than happy to have proprietary drivers which I personlly won't touch with the proverbial 10 foot pole :) So please, do tell, is there any _real_ problem with releasing a register spec doc for last year's hardware so amd64 users can hope to have more than a framebuffer some day? How about the proprietary nforce4 chipset? They well may have reasons not to disclose everything. There is probably lot of their market success hidden in the full specs. I bet that Mr. Zanders can't answer the question (and definitely can't decide to give the specs) anyway. And - again - it will probably take a couple of very skilled programmers' years' time to write good driver from scratch. Cheers. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ordering of ports on Promise PDC40718 SATA300 controller
Rick C. Petty wrote: What determines the probing order of the ports/channels on the PDC40718 (Promise TX4 SATA300 controller)? The SATA ports are labeled Port 1 through Port 4. I have a total of four of these cards, and all of them repeatably probe out of order: label reported in FreeBSD ----- Port 1ATA channel 3 Port 2ATA channel 1 Port 3ATA channel 0 Port 4ATA channel 2 Has anyone else noticed this with these cards? What can I do to fix it? I'm running both 6.0-RELEASE and RELENG_6_1 as of 2006-May-07. I see that too but I don't care as long as it works :-). Michal ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nagios and pthreads
Jeremie Le Hen wrote: Hi Christophe, a quick glance at the archives whould have helped you. I also experienced the problem and read the thread. I don't believe anybody found and shared a way to solve it. The conclusion of the thread was that the problem is more in the application then in FreeBSD - the application does things not well defined in POSIX threading environment. The right fix is probably a non trivial change to Nagios. i know that we add already discuss about this problem, but is there any solution for this problem ? --- What's section on nagios website FreeBSD and threads. On FreeBSD there's a native user-level implementation of threads called 'pthread' and there's also an optional ports collection 'linuxthreads' that uses kernel hooks. Some folks from Yahoo! have reported that using the pthread library causes Nagios to pause under heavy I/O load, causing some service check results to be lost. Switching to linuxthreads seems to help this problem, but not fix it. The lock happens in liblthread's __pthread_acquire() - it can't ever acquire the spinlock. It happens when the main thread forks to execute an active check. On the second fork to create the grandchild, the grandchild is created by fork, but never returns from liblthread's fork wrapper, because it's stuck in __pthread_acquire(). Maybe some FreeBSD users can help out with this problem. --- I have just upgraded to 5.4-STABLE but i encountered again the problem. Sometimes, there is a nagios forked child process which consume 100% of CPU. i have heard that there was perhaps a problem with libc_r reported by Luigi Rizzo on this list 06/22/2005, but no news since this date... My workaround is to have a cron job which run every hour and check if there is a bad nagios process and kill it... i know it's very ugly... Do you any solution or what could i do to get more trace when it happen ? sorry, but i am not familiar with ktrace like tools... If someone could help me to help nagios community on freebsd ;-) ? Thanks in advance. This thread should countain some answers : http://lists.freebsd.org/pipermail/freebsd-hackers/2005-June/012435.html Regards, ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Nagios and threads
On Wed, 22 Jun 2005, I wrote: Daniel Eischen wrote: On Tue, 21 Jun 2005, Michal Mertl wrote: Dag-Erling Smrgrav wrote: Charles Sprickman [EMAIL PROTECTED] writes: 1. FreeBSD and threads. On FreeBSD there's a native user-level implementation of threads called 'pthread' and there's also an optional ports collection 'linuxthreads' that uses kernel hooks. This is only the case for FreeBSD 4. FreeBSD 5 has native threads. Yes, the description on Nagios page is not precise but unfortunately Nagios still has some problems even on 5.4. I wasn't able to find out what was wrong and the problem dissappeared when I had to replace the computer with single-processor one. The symptoms I observed were that every several days one Nagios process was consuming all the CPU doing hundreds of thousands of syscalls per second. It got always stuck around the time when the the daily cron job run. I did a ktrace on the stuck process and tried to abort it to have the core but I've lost the ktrace output and it never saved the core :-(. I'll install it on another machine and try to diagnose the problem some more. You gotta try it on -stable. OK. I installed Nagios on a SMP computer with fresh -stable. I tried to stress the disk but until now Nagios hasn't hung. Michal Just FYI - I really wasn't able to provoke the hang. I've no idea if the reason is my upgrade to STABLE or something else. I can only confirm what went on this thread - Nagios seems to have lots of short lived children (for the tests) which are probably created with fork and the main process is multithreaded. Michal ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Nagios and threads
Daniel Eischen wrote: On Tue, 21 Jun 2005, Michal Mertl wrote: Dag-Erling Smrgrav wrote: Charles Sprickman [EMAIL PROTECTED] writes: 1. FreeBSD and threads. On FreeBSD there's a native user-level implementation of threads called 'pthread' and there's also an optional ports collection 'linuxthreads' that uses kernel hooks. This is only the case for FreeBSD 4. FreeBSD 5 has native threads. Yes, the description on Nagios page is not precise but unfortunately Nagios still has some problems even on 5.4. I wasn't able to find out what was wrong and the problem dissappeared when I had to replace the computer with single-processor one. The symptoms I observed were that every several days one Nagios process was consuming all the CPU doing hundreds of thousands of syscalls per second. It got always stuck around the time when the the daily cron job run. I did a ktrace on the stuck process and tried to abort it to have the core but I've lost the ktrace output and it never saved the core :-(. I'll install it on another machine and try to diagnose the problem some more. You gotta try it on -stable. OK. I installed Nagios on a SMP computer with fresh -stable. I tried to stress the disk but until now Nagios hasn't hung. Michal ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Nagios and threads
Dag-Erling Smørgrav wrote: Charles Sprickman [EMAIL PROTECTED] writes: 1. FreeBSD and threads. On FreeBSD there's a native user-level implementation of threads called 'pthread' and there's also an optional ports collection 'linuxthreads' that uses kernel hooks. This is only the case for FreeBSD 4. FreeBSD 5 has native threads. Yes, the description on Nagios page is not precise but unfortunately Nagios still has some problems even on 5.4. I wasn't able to find out what was wrong and the problem dissappeared when I had to replace the computer with single-processor one. The symptoms I observed were that every several days one Nagios process was consuming all the CPU doing hundreds of thousands of syscalls per second. It got always stuck around the time when the the daily cron job run. I did a ktrace on the stuck process and tried to abort it to have the core but I've lost the ktrace output and it never saved the core :-(. I'll install it on another machine and try to diagnose the problem some more. Michal ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
max number of tcp cons on STABLE (bug?)
I like to run stupid benchmarks (http_load) and found the same problem
lots of other people complained about on the lists - no buffer space
available and similar on the requests generating machine.
I wanted to let the http_load run for long time so that the number of
Apache processes stabilizes for high load.
But no matter what I configured to kern.maxusers,
net.inet.tcp.{send,recv}space, kern.ipc.somaxconn, kern.ipc.maxsockets,
kern.ipc.nmbclusters, kern.maxfiles, client always starts to fail after
having net.inet.tcp.pcbcount about ~4000 (close to the number of sockets
seen with 'netstat -anf inet'). Output of 'netstat -m' isn't anywhere
close to mbuf exhaustion.
My main observation:
From the names of OIDs I thought the high limit on net.inet.tcp.pcbcount
could be somehow controlled by kern.ipc.maxsockets. That seems to be true
on CURRENT but not on STABLE.
I understand that it's not very common to have more than ~4000 sockets but
I think it should be possible. It can be the reason of others' failures I
guess.
--
Michal Mertl
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: stack alignment issues
Greg Shenaut wrote: In message [EMAIL PROTECTED], Dan Nelson cleopede: In the last episode (Feb 03), Alfred Perlstein said: * Michal Mertl [EMAIL PROTECTED] [020203 08:17] wrote: Not really sure what to make of this, anyone else know how we ought to fix this? This has actually been an issue for ages, most commonly seen with doubles. take a look at the thread at Has any real world program ever been significantly affected by this problem? I don't know any such program but I suppose they exist. The problem is probably generaly unnoticed by the people running the program. FWIW OpenBSD 2.6 has the same problem but Linux (kernel 2.0 and 2.4) is unaffected. Did you look at the patch by Bruce at http://groups.yahoo.com/group/freebsd-current/message/39605 ? Bruce, is it still fresh in your memory? Can you comment on the patch - can it be commited in some form? -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
unbelievable benchmark output
I wrote a simple program which does this:
gettimeofday
something (takes several seconds)
gettimeofday
print time elapsed
Several runs of the program take about the same time but the time
changes wildly when the executable is called differently.
---
./xx/xxx
5 s
xx/xxx
9 s
and similar. It holds true on vastly different machines with current and
stable.
The only thing which I can think of that can be causing this is some
memory alignment issue.
It makes me a bit scared - if the filename or argv[0] make program load
to different address than it can probaly mean that even normal programs
can suffer significatnly from this. Alignment, which does gcc would
probably be mostly useless than. Does the system care where is loads the
program image at all?
Compile the code below with gcc -O -march=pentiumpro and save the
program to /tmp/x (1x) and /tmp/xxx (11x). cd /tmp; ./x shows me
0.490495 (with slight variations amongst runs) and ./xxx 1.016591.
The real results depend on hw but they occur always with different
differences in speed and the length of name of fast/slow programs.
BTW: The program doesn't have to contain assembly it seems but with the
program below the results are most visible.
-- 8
#include sys/types.h
#include sys/time.h
#include stdio.h
#include stdlib.h
#define NUMTESTS 1000
static inline void
atomic_add_64(volatile u_int64_t *p, u_int64_t v)
{
__asm __volatile (
movl (%0),%%eax ;
movl 4(%0),%%edx ;
1:movl (%1),%%ebx ;
movl 4(%1),%%ecx ;
addl %%eax,%%ebx ;
adcl %%edx,%%ecx ;
cmpxchg8b (%0) ;
jnz 1b ;
#atomic_add_64
:
: S (p), /* 0 */
D (v) /* 1 */
: eax, ebx, ecx, edx, memory );
}
void
difftimeval(struct timeval start, struct timeval *end)
{
if (end-tv_usec start.tv_usec) {
end-tv_usec += (100 - start.tv_usec);
end-tv_sec--;
} else
end-tv_usec -= start.tv_usec;
end-tv_sec -= start.tv_sec;
}
int
main()
{
u_int64_t i, j;
int k;
struct timeval st, en;
i = 0;
j = 10;
gettimeofday(st, NULL);
for (k = 0; k NUMTESTS; k++) {
atomic_add_64(i, j);
}
gettimeofday(en, NULL);
difftimeval(st, en);
printf(%lu.%06lu\n, en.tv_sec, en.tv_usec);
return (EXIT_SUCCESS);
}
- 8
--
Michal Mertl
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
patch for network counter implementation (64bit/atomic)
After rather long discussion on arch with no apparent result I have my
patch for STABLE ready.
Sorry to repeat what has been already talked about but there may be people
on hackers who don't read arch.
I've posted 2 patches on
http://home.eunet.cz/mime/syscntr.diff.20020120.gz
and http://home.eunet.cz/mime/netstat.diff.gz (only modifies netstat to be
able to show 64 bit values).
The first one modifies lots of sources in kernel but I believe that most
changes are totally harmless. It modifies all network device driver
sources to use newly defined API for accessing counters (packets, bytes,
errors...). It also modifies some files in /sys/net* to use the same API.
The counters are defined in /sys/net/if.h and
/sys/netinet/{ip|tcp|udp|igmp|icmp}_var.h and their type is changed from
u_long to syscntr_t. The new API is defined in /sys/i386/include/syscntr.h
but is 99% MI - no problem should occur with Alpha and other ports. By
default the syscntr_t is u_int32_t and is accessed non-atomically. This is
probably incorrect but it's the same way it's been done for ages so no new
problem is created. Change of 2 defines in the file makes counters either
64 bit and/or atomic. Other API feature which may end up useless is that
the different counters can be accessed by different type of operation (the
size is always either 32 or 64 bit) - maybe even something not yet
implemented - per cpu.
Other change there is adding support for 64 bit atomic ops to X86 -
unfortunatelly the instruction required for this operation is only or
=586. So atomic 64 bit operation is possible only on these computers -
but that's maybe also only on SMP machines (=586) where the atomicity is
strictly needed.
As discussed to death on arch atomicity and 64 bit both add to cost of
accessing the counters. The most common operation is addition - on p3
non-atomic 32 bit cost about 2 clocks, atomic 32 bit 20 clocks, non-atomic
64 bit 7 clocks and atomic 64 bit 50 clocks. For each tcp packet we have
at least 5 counter updates.
The code is perfectly usable on CURRENT too. If there's single request
I'll make sure it fits there 100%.
There's one problem I'm aware of - NETGRAPH. It has some counters
defined in code too and I think it will benefit from the change too. But I
don't now if it's possible to change the types in there (are there NG
drivers not it tree?).
PS: After changing kernel counters from 32 to 64 bit, some of world has to
be rebuild too (to notice the change in structs which contain the
counters). Namely ifconfig, netstat, systat and probably others.
--
Michal Mertl
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
