Re: Need help for kernel crash dump analysis
Thank you for your answer,
OK, let's make it a bit clearer !
I use a private scheme to interact with the 'ipintr' isr. The two following
routines are expected to be called either by our modified version of 'ip_input'
at network SWI level or at user level.
int my_global_ipl=0;
void my_enter() {
int s=splnet();
/* We do not expect this routine to be reentrant, thus the following sanity check. */
ASSERT(my_global_ipl==0);
my_global_ipl=s;
}
void my_exit() {
int s=my_global_ipl;
my_global_ipl=0;
splx(s);
}
The crashes I got are always due to the assertion failure occuring in the
'ipintr' isr. This *seems* to indicate that 'my_enter' is called at the network
SWI level after another execution flow has called 'my_enter' itself and has
*NOT* called 'my_exit' yet ! This actually seems strange due to the 'splnet',
and the only explanation I have found is that the first execution flow has
fallen asleep somewhere in the kernel (while this is not expected, of course
!).
Now, if you've read my first mail, I was actually asking for help onhow to
dump the stack of an interrupted process with GDB when the kernelcrash occurs
in the context of an isr. Actually, I would like to know how I could dump
the stack of *any* process at the time of the crash. This way, I would be
able to see where my user-land daemon was lying in the kernel when the interrupt
occurs.
Anyway, without this information, I am reduced to add some traps on the track
of the execution of my process within my kernel code. This brought me to
surround calls to MALLOC with counters as follows:
somewhere_else() {
...
my_enter(); /* handle competition with network isr (especially ipintr) */
...
some_counter++;
MALLOC(buf,cast,size,M_DEVBUF,M_NOWAIT);
some_other_counter++;
...
my_exit();
...
}
Then, all crashes I got show the following equation at the time of crash:
( some_counter - some_other_counter == 1 )
which *seems* to indicate that that my process has been somehow preempted during the call to MALLOC.
My belief is that the FreeBSD kernel is (currently) a monolithic non-preemptive non-threaded UNIX kernel, thus implying that :
system-scope scheduling is still done at process level (no kernel thread yet)
any process executing in the kernel cannot be preempted for execution
by another process unless it either returns to user code or falls explicitely
asleep.
the only interlocking that must be done is with interrupts (when relevant), using the 'spl' management routine set.
Is that correct ?
Well, I am obviously tracking a bug in my own code, but I would greatly appreciate
to get help either on my GDB usage question or through technical hints on
where I should look at to progress in my investigation.
Thank you very much for your attention,
Rgds,
Xavier
Alfred Perlstein wrote:
[EMAIL PROTECTED]">* Xavier Galleri [EMAIL PROTECTED] [010111 11:27] wrote:
Hi everybody,I have reached a point where I am wondering if a call to 'malloc' with the M_NOWAIT flag is not falling asleep !
M_NOWAIT shouldn't sleep.
In fact, I suspect that the interrupted context is somewhere during a call to 'malloc' (I increment a counter just before calling malloc and increment another just after and the difference is one !) while I have called 'splnet' beforehand, thus normally preventing competing with any network isr. I assume that this shouldnever occur unless the code is somewhere calling 'sleep' and provoke acontext switch.
if you add 1 to a variable the difference is expected to be one.
Is there anybody who can help on this ?
I'm not sure, you need to be more specific/clear.
Re: Need help for kernel crash dump analysis
Thank you for your answer,
OK, let's make it a bit clearer !
I use a private scheme to interact with the 'ipintr' isr. The two following
routines are expected to be called either by our modified version of 'ip_input'
at network SWI level or at user level.
int my_global_ipl=0;
void my_enter() {
int s=splnet();
/* We do not expect this routine to be reentrant, thus the following sanity check. */
ASSERT(my_global_ipl==0);
my_global_ipl=s;
}
void my_exit() {
int s=my_global_ipl;
my_global_ipl=0;
splx(s);
}
The crashes I got are always due to the assertion failure occuring in the
'ipintr' isr. This *seems* to indicate that 'my_enter' is called at the network
SWI level after another execution flow has called 'my_enter' itself and has
*NOT* called 'my_exit' yet ! This actually seems strange due to the 'splnet',
and the only explanation I have found is that the first execution flow has
fallen asleep somewhere in the kernel (while this is not expected, of course
!).
Now, if you've read my first mail, I was actually asking for help onhow to
dump the stack of an interrupted process with GDB when the kernelcrash occurs
in the context of an isr. Actually, I would like to know how I could dump
the stack of *any* process at the time of the crash. This way, I would be
able to see where my user-land daemon was lying in the kernel when the interrupt
occurs.
Anyway, without this information, I am reduced to add some traps on the track
of the execution of my process within my kernel code. This brought me to
surround calls to MALLOC with counters as follows:
somewhere_else() {
...
my_enter(); /* handle competition with network isr (especially ipintr) */
...
some_counter++;
MALLOC(buf,cast,size,M_DEVBUF,M_NOWAIT);
some_other_counter++;
...
my_exit();
...
}
Then, all crashes I got show the following equation at the time of crash:
( some_counter - some_other_counter == 1 )
which *seems* to indicate that that my process has been somehow preempted during the call to MALLOC.
My belief is that the FreeBSD kernel is (currently) a monolithic non-preemptive non-threaded UNIX kernel, thus implying that :
system-scope scheduling is still done at process level (no kernel thread yet)any process executing in the kernel cannot be preempted for execution
by another process unless it either returns to user code or falls explicitely
asleep.the only interlocking that must be done is with interrupts (when relevant), using the 'spl' management routine set.
Is that correct ?
Well, I am obviously tracking a bug in my own code, but I would greatly appreciate
to get help either on my GDB usage question or through technical hints on
where I should look at to progress in my investigation.
Thank you very much for your attention,
Rgds,
Xavier
Alfred Perlstein wrote:
[EMAIL PROTECTED]">* Xavier Galleri [EMAIL PROTECTED] [010111 11:27] wrote:Hi everybody,I have reached a point where I am wondering if a call to 'malloc' with the M_NOWAIT flag is not falling asleep !M_NOWAIT shouldn't sleep.In fact, I suspect that the interrupted context is somewhere during a call to 'malloc' (I increment a counter just before calling malloc and increment another just after and the difference is one !) while I have called 'splnet' beforehand, thus normally preventing competing with any network isr. I assume that this shouldnever occur unless the code is somewhere calling 'sleep' and provoke acontext switch.if you add 1 to a variable the difference is expected to be one.Is there anybody who can help on this ?I'm not sure, you need to be more specific/clear.
Re: pppd mkdir diff
Alfred Perlstein wrote: 1. a pppd patch which sends the pppd messages to stderr. not sure about this one, I would open a PR about it. I'm not sure either :) Maybe everyone else uses gui frontend which reads pppd's syslog messages or starts pppd as root? Ok, I may be misreading this, but this doesn't fix it really: mkdir /tmp/a/b/c/d/e/f/s perhaps if you called "stat" in a loop to on each patch component until it failed you'd be able to trim off the directory paths one by one. I don't think it's useful for mkdir to check which exact part of the path of the parent directory does exist. The fix just makes mkdir say the parent directory doesn't exist (instead of the previously wierd "the dir you wanted me to create doesn't exist" type of error message :). Regards, Wouter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Image Communications Inc..
Title: Untitled Document
how to write custom init
Hi ,
What are the points to be observed while writing custom init
I am currently doing something like :
/*
1. never exit
2. open fd 0,1 2
3. link statically */
int main( int argc, char **argv )
{
int fd ;
char cmd[128] = {0};
fd = open( "/dev/console", O_RDWR );
dup(fd);
dup(fd);
while( 1 ) {
printf( "comm" ); fflush( stdout );
fgets( cmd, sizeof(cmd ), stdin );
if( memcmp( "init", cmd , 4 ) == 0 )
{ close(0); close(1);close(2); execv("/init/sbin", argv ); }
if( memcmp( "quit", cmd, 4) == 0 ) reboot( RB_AUTOBOOT );
} /* while */
/* should not reach here */
return 0 ;
}
Am I missing something ?
Thanx Regards
soumen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Broken-by-design USB device?
First of all, you are not wasting my time (I _asked_ for the info, right?). More probably it is the other way around with you having to crash you machine all the time ... :-) Second the info your supplying is good quality. Thanks for that. I'll have a look after the weekend (I'll try and not be a sad person while on holiday) ... oh hell ... I have enough space on my laptop for a usr/src/sys tree of STABLE ... sigh, they'll hate me now... Thanks. Nick On Thu, 11 Jan 2001, Jon Simola wrote: On Mon, 8 Jan 2001, Nick Hibma wrote: Just as a note on the side, the fact that the attach of the generic driver fails (while setting config 0, which is a sort of a soft reset) could indicate that there is something fishy going on with respect to fetching the report descriptor. I seems to freeze. I'd still bet on the hardware being suspect. It's got all the prime labelling of a quality product: "PS-PC USB Converter" "Full Colors" "Special Design, Extra Stable Highly Compatibility" And now back to your scheduled 'panic' demolition: It still bombs in the middle of DEVOPMETH in: device_probe_t *m = (device_probe_t *) DEVOPMETH(dev, device_probe); which is #define DEVOPMETH(DEV, OP) \ ((DEVOPDESC(OP)-offset = DEVOPS(DEV)-maxoffset) \ ? DEVOPDESC(OP)-deflt \ : DEVOPS(DEV)-methods[DEVOPDESC(OP)-offset]) while executing 56: 3b 02 cmp(%edx),%eax with edx == dev-ops and eax == device_probe_ops-offset (don't you hate i386 assembler syntax?) and edx apparently being 0. Which as far as I can see is impossible in the subr_bus.c code. So that leaves 'memory spamming' as the only option :-( Apart from that, I have no clue which driver tries to attach after the ugen driver is finished. Because that is the last driver that makes an attempt. Could you do the following: Boot the machine and when it panics type the following commands: show registers db show registers cs 0x8 ds 0xc0a20010 es 0xc0150010 await+0xe4 fs 0xc0300010 ss0x10 eax0x9 ecx 0xc0d32400 edx 0 ebx0x6 esp 0xc030b920 ebp 0xc030b920 esi 0xc0a227b0 edi 0xc0d32400 eip 0xc011d58a DEVICE_PROBE+0xe efl0x90282 x/x $ecx,0x20 db x/x $ecx,0x20 0xc0d32400: 0 0 0 0 0xc0d32410: 0 0 0 c0d2ac40 0xc0d32420: 0 c0a220400 0 0xc0d32430: 0 0 0 0 0xc0d32440: 0 0 0 0 0xc0d32450: 0 0 0 0 0xc0d32460: 0 0 0 0 0xc0d32470: 0 0 0 0 x/c *($ecx+0x24),0x10 db x/c *($ecx+0x24),0x10 0xc0a22040: uhid0\000\000\000\000\000\000\000\000\000\000\000 which will print three things: the contents of all registers (show registers), then the 32 longs at address $ecx (x/x $ecx,20), basically the contents of the struct device in DEVICE_PROBE, in which the 6th element (at +0x14) should be zero. And then the string that is pointed to by the nameunit element in the struct device. This last one should give us a hint at which device is failing. Never mind if the last one gives you a page fault. nameunit might be zero. I really am at a loss what this could be :( If I'm following you, the info above will just prove that something is too broken to figure out. If I can find another one of these things I'll just mail it to you. Other than that, I'll stop wasting your time :) Thank you very much for the help. --- Jon Simola [EMAIL PROTECTED] | "In the near future - corporate networks Systems Administrator | reach out to the stars, electrons and light ABC Communications | flow throughout the universe." -- GITS -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: scsi and PS2 mode parallel port programming
You've been speaking to Nicolas Souchu, right? He has written the current driver and seems to know a fair bit about this topic. Nick | I'll put this on my pile of things to and dig through the CAM changes to | find it. There weren't that many in the past year. I finally heard from the guy who noticed the change, and asked if he could help localize it. | I don't know much about the PS2 mode nor the parallel port driver | (allthough I've had my fingers in there, as you know). A parallel port in ECP mode should support PS2 without any problem, correct? And if I recall, it worked under 3.x, so that *should* rule out a buggy BIOS or hardware anomaly. I *hate* when problems only afflict my machine. jcm -- o-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-o | Jonathon McKitrick ~ | | "I prefer the term 'Artificial Person' myself." | o-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-o -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to write custom init
You may want to check out sysinstalls initialization, it is used to
run as /sbin/init when you boot from installation media
Poul-Henning
In message 001201c07c8d$4276f8a0$[EMAIL PROTECTED], "Soumen Biswas" writ
es:
Hi ,
What are the points to be observed while writing custom init
I am currently doing something like :
/*
1. never exit
2. open fd 0,1 2
3. link statically */
int main( int argc, char **argv )
{
int fd ;
char cmd[128] = {0};
fd = open( "/dev/console", O_RDWR );
dup(fd);
dup(fd);
while( 1 ) {
printf( "comm" ); fflush( stdout );
fgets( cmd, sizeof(cmd ), stdin );
if( memcmp( "init", cmd , 4 ) == 0 )
{ close(0); close(1);close(2); execv("/init/sbin", argv ); }
if( memcmp( "quit", cmd, 4) == 0 ) reboot( RB_AUTOBOOT );
} /* while */
/* should not reach here */
return 0 ;
}
Am I missing something ?
Thanx Regards
soumen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Broken-by-design USB device?
Oh, and another thing: a kernel panicing is unacceptable, even with bad hardware (except possibly for hardware faults. There is not a lot you can do about those). We've found one non-trivial bug, and I have the feeling that we are looking at another one (possibly a stack or device list corruption bug), which I'm determined to find. If you could send me the make and model (basically all the numbers (including the FCC one) on the label on the device, that would be appreciated. I'll have a look around to see whether I can find another one. We have a PlayStation 2 Developer's Kit in the office, so I'm interested to see the controllers work. We develop a game for PlayStation 2 and Windows (but it runs on FreeBSD as well :-), so being able to use the gamepad converter on FreeBSD would be a laugh. Hm, is it one of these? http://www.psxshop.com/shownews.asp?NewsID=1870 http://www.allusb.com/products/P10227.html http://www.angelcd.com/angelcd/psxusbcon.html http://www.baysoftgames.com/baysoftgames/pssmartjoy2.html http://www.dcs.com.hk/misc/mc_joybox.htm http://www.goldenshop.com.hk/AI-trad/pc/pc_psxn64usb.htm http://www.smartjoy.com/ or was it a do-it-your-self adapater http://www.users.globalnet.co.uk/~snandhe/usbpads.htm There is quite a few of those it seems. Or I have loads of duplicates ... That could be as well :) Cheers, Nick If I'm following you, the info above will just prove that something is too broken to figure out. If I can find another one of these things I'll just mail it to you. Other than that, I'll stop wasting your time :) Thank you very much for the help. --- Jon Simola [EMAIL PROTECTED] | "In the near future - corporate networks Systems Administrator | reach out to the stars, electrons and light ABC Communications | flow throughout the universe." -- GITS -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to write custom init
On Fri, 12 Jan 2001, Soumen Biswas wrote:
Hi ,
What are the points to be observed while writing custom init
I am currently doing something like :
/*
1. never exit
2. open fd 0,1 2
3. link statically */
int main( int argc, char **argv )
{
int fd ;
char cmd[128] = {0};
fd = open( "/dev/console", O_RDWR );
dup(fd);
dup(fd);
while( 1 ) {
printf( "comm" ); fflush( stdout );
fgets( cmd, sizeof(cmd ), stdin );
if( memcmp( "init", cmd , 4 ) == 0 )
{ close(0); close(1);close(2); execv("/init/sbin", argv ); }
Why /init/sbin ??
if( memcmp( "quit", cmd, 4) == 0 ) reboot( RB_AUTOBOOT );
} /* while */
/* should not reach here */
return 0 ;
}
Am I missing something ?
Thanx Regards
soumen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Question about 'open' files....
Actually, I finally found it. One of the function calls I pulled from a
library someone else wrote used mkstemps(), and didn't bother to discard the
descriptor when it was done.
I had originally thought the problem to be in my code, but, it wasn't. I fixed
the other code, and the problem was solved.
-Brian
Don't know if this is part of the error checking you glossed over,
but I recently had some extremely weird problems with file IO that went away
when I added the third mode argument that open() needs when it is passed the
O_CREAT flag.
On Thu, Jan 11, 2001 at 03:05:29PM -0500, Brian J. McGovern wrote:
I'm doing some tests for Greg on vinum (trying to crash it), and I've run
across a problem that is not particular to vinum. I'm hoping someone can
explain it to me and/or tell me how to work around it.
Using the code fragment (note: The code I'm using is actually more complex
,
and checks for errors in opening, writing, etc, but I'm keeping it basic
for the discussion):
for (counter = 0; counter 2; counter++)
{
x = open(filename,O_CREAT | O_WRONLY);
write(x, buffer, size);
close(x);
}
I will run anywhere between 1-5 instances of the code loop above. After th
ere
are about 2050 files on the disk (it _appears_ to be variations of 2048, p
lus
files already on the disk, . and .., etc.), the programs crash with "too m
any
open files".
The problem, in my mind, is that the files are _closed_ (not open). I'm cu
rious
if this is some type of accounting error on a per-login basis, or whether
there is some type of garbage collection not happening. Typically, after a
ll
of the applications die with this error, if I immediately restart, they
die pretty quickly. If I wait like 10+ seconds, they can run again, and
generate the 2048+/- files again before dying, which leads me to believe i
ts
something to do with per-user accounting/garbage collection.
I would be curious to understand this, and its impact, as this does not
appear to be 'good' (tm) behavior, particularly if one wishes to run a pro
gram
that opens and closes a lot of small files.
I welcome any thoughts.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Need help for kernel crash dump analysis
On Fri, 12 Jan 2001, Xavier Galleri wrote: OK, let's make it a bit clearer ! ... [skiped] Now, if you've read my first mail, I was actually asking for help onhow to dump the stack of an interrupted process with GDB when the kernelcrash occurs in the context of an isr. Actually, I would like to know how I could dump the stack of *any* process at the time of the crash. This way, I would be able to see where my user-land daemon was lying in the kernel when the interrupt occurs. To dump stack of *any* (all) process you may write a little kld wich will: 1) go through a process list, 2) get tf_eip, tf_esp, tf_ebp of a process 3) get p-p_vmspace 4) read process stack frames and all you need by manually written routine based on procfs_rwmem and old good 'pread' (which dosn't work now) Another way is to go through proc list and coredump all the processes for future manual analisys. I like such way. Can anybody point me to some difficults wich can appear while implementing this? [skiped] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need help for kernel crash dump analysis
Thank you for your answer, It's difficult to believe that nothing more intuitive and immediate can be done to get the kernel stack of any process from a GDB session on a kernel crash dump. Does it mean that this is something that nobody ever need until now ? Also, is there a mean to ask GDB to dump the kernel stack of the 'curproc' that has been interrupted at the time of kernel panic ? Regards, Xavier diman wrote: [EMAIL PROTECTED]">On Fri, 12 Jan 2001, Xavier Galleri wrote: OK, let's make it a bit clearer ! [skiped] Now, if you've read my first mail, I was actually asking for help onhow to dump the stack of an interrupted process with GDB when the kernelcrash occurs in the context of an isr. Actually, I would like to know how I could dump the stack of *any* process at the time of the crash. This way, I would be able to see where my user-land daemon was lying in the kernel when the interrupt occurs. To dump stack of *any* (all) process you may write a little kld wich will:1) go through a process list,2) get tf_eip, tf_esp, tf_ebp of a process3) get p-p_vmspace 4) read process stack frames and all you need by manually written routine based on procfs_rwmem and old good 'pread' (which dosn't work now)Another way is to go through proc list and coredump all theprocesses for future manual analisys.I like such way. Can anybody point me to some difficults wich can appear whileimplementing this? [skiped]
Re: FreeBSD boot manager, where is latest version?
Bob Willcox wrote: Well, ob-bs didn't work either. I went to the referenced site for XOSL and it certainly looked interesting...but was way more than I was looking for at this time (I was happy with the default FreeBSD installed boot manager before W98 trashed it and I certainly didn't want to create partion for it...which seemed to be required). On the XOSL web site I found a refernence to the "Ranish Partition Manager" which I wound up installing and it worked for me. :-) Good to hear. BTW, xosl will also install on your Win98 partition, so you don't have to make a special partition just for it. -- _ __ ___ ___ __ / \/ \ | ||_ _|| _ \|___| | Jason Andresen -- [EMAIL PROTECTED] / /\/\ \ | | | | | |/ /|_|_ | Views expressed may not reflect those /_/\_\|_| |_| |_|\_\|___| | of the Mitre Corporation. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pppd mkdir diff
* W.H.Scholten [EMAIL PROTECTED] [010112 03:13] wrote: Alfred Perlstein wrote: 1. a pppd patch which sends the pppd messages to stderr. not sure about this one, I would open a PR about it. I'm not sure either :) Maybe everyone else uses gui frontend which reads pppd's syslog messages or starts pppd as root? Open a PR, someone will get to it. :) Ok, I may be misreading this, but this doesn't fix it really: mkdir /tmp/a/b/c/d/e/f/s perhaps if you called "stat" in a loop to on each patch component until it failed you'd be able to trim off the directory paths one by one. I don't think it's useful for mkdir to check which exact part of the path of the parent directory does exist. The fix just makes mkdir say the parent directory doesn't exist (instead of the previously wierd "the dir you wanted me to create doesn't exist" type of error message :). Good point, I'll commit the patch shortly. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Setting default hostname to localhost
In message [EMAIL PROTECTED] Robert Watson writes: : Unless there are some really good reasons : not to (which there may be), I'd like to commit changes to -CURRENT's : /etc/default/rc.conf to change the default hostname to "localhost". We have localhost.com as one of our domains here in the Village. So long as this change doesn't generate traffic to us in any way, shape, or form, I'd say go for it. Sniff your network for traffic to/from 204.144.255.150 to see if it does or not. There have been bugs in the past that would cause this to be the case. There have also been bugs in the past where machines (not necessarily FreeBSD machines) whose hostname was foo.com (for all values of foo) would try to use localhost.com as the loopback address. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CFR: Generalized power-management interface
Hi, I've update the patch based on some comments so far and added wmpm (actually ACPI support for wmapm which is utility for WindowMaker) ports files as a example. http://people.freebsd.org/~iwasaki/acpi/power-20010113.tar.gz http://people.freebsd.org/~iwasaki/acpi/wmpm-20010113.tar.gz Note that ioctl number for power device have been changed, so rebuilding your kernel and recompiling lib/libpower/ and usr.sbin/power/ are needed. Added API is; u_intpower_get_pm_type(void); I'll get device major number for /dev/power and commit them within a few days if no objection. Thanks I've created new common framework on generalized power-management interface for userland utilities. http://people.freebsd.org/~iwasaki/acpi/power-20001229.tar.gz This provides some PM APIs to APM applications, such as wmapm, so that these applications can be ported smoothly to use ACPI (power management portion). Currently following APIs are implemented; intpower_get_syspm_info(struct power_syspm_info *); intpower_get_batt_info(u_int, struct power_batt_info *); intpower_standby(void); intpower_suspend(void); intpower_hibernate(void); And PM event notification mechanism is suggested to be implemented so far. Sample application is included in usr.sbin/power/ which is very similar to apm(8) but supports ACPI as well. usr.sbin/acpi/acpibatt/ is for displaying acpi_cmbat (ACPI Control Method Battery), can be used to verify that generalized power-management interface is working correctly. Note that many ACPI BIOS give us unknown battery remaining time when ac-line is plugged in. MIB 'hw.battery.full_charge_time' can be used to specify the full charged remaining time of batteries in minutes, like sysctl -w hw.battery.full_charge_time=60,60 for multiple number of batteries, or sysctl -w hw.battery.full_charge_time=120 for a battery installed. To test them, /dev/power is required as a device control file. % ls -l /dev/power crw-r--r-- 1 root wheel 210, 0 12/19 04:51 /dev/power I'll commit them at sometime early in coming century. Any comments would be appreciated. Thanks! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
wicontrol: password - hex digits
I'm trying to debug my interactions with a WAP. Could someone quickly explain the algorithm in wicontrol for converting a text key to a hex key, and vice-versa? Yes, I could go scrounge though the source, but I have my hands full... And, while I'm at it, how does 'wicontrol -i wi0' know when to dump out the keys in text vs hex? -- Brian 'you Bastard' Reichert[EMAIL PROTECTED] 37 Crystal Ave. #303Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Mutexs: checking for initialization
On 12-Jan-01 Jason Smethers wrote: I've got some kernel code that passes untrusted data containing mutic. I'd like to be able to check if the mutic have been initialized and return an error if they haven't. As of now I don't see a standard way of checking for initialization. I'd like to do it this way to abstract out the way things are locked, and in FreeBSD's case the mutex's description. I known I can do this other ways, but it'd be nice if there was a standard way to check for this. Just a thought, or else I'd have a diff =O. Umm, well, you could write a function that walked the all_mtx list and checked if the mutex was in that list. However, I think that you are using the wrong tool for your problem here. :) I'm not sure validating mutexes is the way to validate all the data you are receiving. Thanks - Jason -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CFR: Generalized power-management interface
On 12-Jan-01 Mitsuru IWASAKI wrote: Hi, I've update the patch based on some comments so far and added wmpm (actually ACPI support for wmapm which is utility for WindowMaker) ports files as a example. http://people.freebsd.org/~iwasaki/acpi/power-20010113.tar.gz http://people.freebsd.org/~iwasaki/acpi/wmpm-20010113.tar.gz Note that ioctl number for power device have been changed, so rebuilding your kernel and recompiling lib/libpower/ and usr.sbin/power/ are needed. Added API is; u_intpower_get_pm_type(void); I'll get device major number for /dev/power and commit them within a few days if no objection. One thing that I was talking about with Mike Smith is that perhaps instead of having a /dev/power just for power management stuff we should be a bit more generic and have a /dev/health used for anything related to the machine's "health"? This could include power management, thermal zones, etc. BTW, the battery status doesn't work on my laptop unfortunately, but that is because I have to have the Super IO (and thus all GPIO) disabled to get ACPI to boot. :( Thanks -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: wicontrol: password - hex digits
On Fri, Jan 12, 2001 at 12:54:46PM -0500, Brian Reichert wrote: I'm trying to debug my interactions with a WAP. Could someone quickly explain the algorithm in wicontrol for converting a text key to a hex key, and vice-versa? Yes, I could go scrounge though the source, but I have my hands full... The hex version is just the literal ASCII string. IMNSHO it's a really bad idea to generate a key by converting an ASCII string as you limit your key space tremendously by doing so. If you really want to do this you can use: echo "password" | hexdump -C Just ignore the trailing 0x0a. My recommended key generation method is actually: dd count=13 bs=1 if=/dev/random of=/dev/stdout | hexdump -C And, while I'm at it, how does 'wicontrol -i wi0' know when to dump out the keys in text vs hex? It checks to see if all the characters are printable with isprint() and if they are it prints the string in ASCII, otherwise it prints it out in hex. I implemented this feature because it pretty much does what the user would expect, but it's pretty stupid because it encourages people to use ASCII keys. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CFR: Generalized power-management interface
Hi, I'll get device major number for /dev/power and commit them within a few days if no objection. One thing that I was talking about with Mike Smith is that perhaps instead of having a /dev/power just for power management stuff we should be a bit more generic and have a /dev/health used for anything related to the machine's "health"? This could include power management, thermal zones, etc. BTW, the I'm not sure if /dev/health is better but I think having common API for the machine's health is good thing. How about having /dev/power, /dev/thermal or whatever related with machine's health as abstracted layers, and creating API libraries for each subsystems like libpower, then providing libhealth as full-set API for the applications? battery status doesn't work on my laptop unfortunately, but that is because I have to have the Super IO (and thus all GPIO) disabled to get ACPI to boot. :( Is that related with embedded controller too? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Kernel time drifting -0.3% to -50% from H/W clock.
HI, I sent a message about this to questions to no avail. So sorry if this is an inappropreate place but here is the problem. Dec 3 Upgared machine to FreeBSD 4.2 (i386) Dec 6 - Jan 2 away from machine. I logged in to find that the value of date was way out (-6 Days), at this point the machie was not running any type of time peering it was essentually stand-alone. I corrected the time manually using date. The next day I noticed the time was wrong again, and decided to run ntp to track the time on our master. It tried very hard to keep time but finally gave up and syslogged me that a manual time change would be necessary. This moring I find that the drift is -50% . I don't know much about how kernel time relates to bios time but I guess that there's a pashe locked loop in the software that is not getting feedback from the HW clock, but I'm just guessing. Can anybody explain what is happening? Thanks. Tom Brown To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CFR: Generalized power-management interface
On 12-Jan-01 Mitsuru IWASAKI wrote: Hi, I'll get device major number for /dev/power and commit them within a few days if no objection. One thing that I was talking about with Mike Smith is that perhaps instead of having a /dev/power just for power management stuff we should be a bit more generic and have a /dev/health used for anything related to the machine's "health"? This could include power management, thermal zones, etc. BTW, the I'm not sure if /dev/health is better but I think having common API for the machine's health is good thing. How about having /dev/power, /dev/thermal or whatever related with machine's health as abstracted layers, and creating API libraries for each subsystems like libpower, then providing libhealth as full-set API for the applications? It was just an idea to think about is all. :) However you do it will probably be fine. I'm not really working on this code enough to make too many suggestions right now. :) battery status doesn't work on my laptop unfortunately, but that is because I have to have the Super IO (and thus all GPIO) disabled to get ACPI to boot. :( Is that related with embedded controller too? Yes. I need to figure out how ACPI_DEBUG works so I can dimp debugging info and find out where it hangs when I don't disable the SIO_ controller. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: wicontrol: password - hex digits
On Fri, Jan 12, 2001 at 10:34:21AM -0800, Brooks Davis wrote: It checks to see if all the characters are printable with isprint() and if they are it prints the string in ASCII, otherwise it prints it out in hex. I implemented this feature because it pretty much does what the user would expect, but it's pretty stupid because it encourages people to use ASCII keys. Thanks for the answers, and the advice. My only comment WRT hex keys: there's a greater chance of transcription error, which can be a hassle in provisioning. But I certianly agree with you WRT the keyspace issues... -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. -- Brian 'you Bastard' Reichert[EMAIL PROTECTED] 37 Crystal Ave. #303Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CFR: Generalized power-management interface
If we're going to talk about 'health' for a machine and it's components, it should tie in with the SES/SAF-TE driver (for SCSI/FibreChannel). On 12-Jan-01 Mitsuru IWASAKI wrote: Hi, I'll get device major number for /dev/power and commit them within a few days if no objection. One thing that I was talking about with Mike Smith is that perhaps instead of having a /dev/power just for power management stuff we should be a bit more generic and have a /dev/health used for anything related to the machine's "health"? This could include power management, thermal zones, etc. BTW, the I'm not sure if /dev/health is better but I think having common API for the machine's health is good thing. How about having /dev/power, /dev/thermal or whatever related with machine's health as abstracted layers, and creating API libraries for each subsystems like libpower, then providing libhealth as full-set API for the applications? It was just an idea to think about is all. :) However you do it will probably be fine. I'm not really working on this code enough to make too many suggestions right now. :) battery status doesn't work on my laptop unfortunately, but that is because I have to have the Super IO (and thus all GPIO) disabled to get ACPI to boot. :( Is that related with embedded controller too? Yes. I need to figure out how ACPI_DEBUG works so I can dimp debugging info and find out where it hangs when I don't disable the SIO_ controller. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mutexs: checking for initialization
From: "John Baldwin" [EMAIL PROTECTED] Umm, well, you could write a function that walked the all_mtx list and checked if the mutex was in that list. However, I think that you are using the wrong tool for your problem here. :) I'm not sure validating mutexes is the way to validate all the data you are receiving. We'll, I'm not validating ALL the data with the mutic, just the mutic itself. Anyway, after sleep and a shower I come back and have a 'Duh' moment. What am I trying to do and what am I doing? If I can't trust the data being passed, how can I trust the memory it's in. Time to change the model to a one time memory copy hit. =) Thanks - Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Setting default hostname to localhost
Warner Losh writes: : Unless there are some really good reasons : not to (which there may be), I'd like to commit changes to -CURRENT's : /etc/default/rc.conf to change the default hostname to "localhost". We have localhost.com as one of our domains here in the Village. So long as this change doesn't generate traffic to us in any way, shape, or form, I'd say go for it. Sniff your network for traffic to/from 204.144.255.150 to see if it does or not. There have been bugs in the past that would cause this to be the case. There have also been bugs in the past where machines (not necessarily FreeBSD machines) whose hostname was foo.com (for all values of foo) would try to use localhost.com as the loopback address. There is an RFC that specifies a "private use" top level domain, analogous to 192.168.0.0/16, 10.0.0.0/8, etc. The domain is ".local" so any default ending in ".local" should not conflict. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel time drifting -0.3% to -50% from H/W clock.
In the last episode (Jan 12), tomb said: The next day I noticed the time was wrong again, and decided to run ntp to track the time on our master. It tried very hard to keep time but finally gave up and syslogged me that a manual time change would be necessary. This moring I find that the drift is -50% . I don't know much about how kernel time relates to bios time but I guess that there's a pashe locked loop in the software that is not getting feedback from the HW clock, but I'm just guessing. Can anybody explain what is happening? Try adding the following kernel options and rebuilding: options CLK_USE_I8254_CALIBRATION options CLK_USE_TSC_CALIBRATION That should help some, if the clock the kernel decided to pick really drifts that badly. You can see which clock the kernel is using with "sysctl kern.timecounter.hardware", and view the current timing values for each clock with "sysctl machdep | grep freq". -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Setting default hostname to localhost
In message [EMAIL PROTECTED] Archie Cobbs writes: : There is an RFC that specifies a "private use" top level domain, : analogous to 192.168.0.0/16, 10.0.0.0/8, etc. : : The domain is ".local" so any default ending in ".local" should : not conflict. RFC 2606 states: To safely satisfy these needs, four domain names are reserved as listed and described below. .test .example .invalid .localhost ".test" is recommended for use in testing of current or new DNS related code. ".example" is recommended for use in documentation or as examples. ".invalid" is intended for use in online construction of domain names that are sure to be invalid and which it is obvious at a glance are invalid. The ".localhost" TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use. But RFC 2964 and 2965 (which relate to http things) both say The IESG notes that this mechanism makes use of the .local top-level domain (TLD) internally when handling host names that don't contain any dots, and that this mechanism might not work in the expected way should an actual .local TLD ever be registered. So it looks like the more porper choice is 'host.invalid' rather than 'localhost'. I think that would, in the end, cause fewer problems. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: synchronous IO
On Thu, Jan 11, 2001 at 09:44:49PM -0600, Dan Nelson wrote: # I don't think you really mean synchronous IO; All you need is some # buffering. If the toggling you're talking about is direct wave # generation (i.e. you have to do something for each byte in the sample), # your time restrictions are probably tight enough that you'll want # multiple buffers, filled by one process and drained by another one. # You mmap() some shared buffer space, fork your process into two, and # send buffer status messages over a pipe connecting the two. Process 1: # read a block of data from input file, fill an empty buffer, send the # buffer address over the pipe, repeat. Process 2: read a full buffer, # toggle buffer through the serial port, send the address of the buffer # back over the pipe for reuse. This ensures that the only operations P2 # does apart from waveform generation are a select, two reads, and a # write every sizeof(buffer). You could even toss the pipe and use # another bit of shared memory to keep track of buffer usage. # # If, on the other hand, the toggling merely tells the controller to play # a sample that you have already stored in the device's memory, then you # presumably have looser timing requirements and can get away with having # one process drain and fill the buffers as appropriate. This is similar # to how the kernel's soundcard drivers work; most soundcards read system # memory directly and signal the kernel via interrupts when its buffers # are getting empty. Thanks for the info. I don't think I was very clear in my first explanation. I have an RF transmitter that I control via a serial port on a FreeBSD box. I also have a sound card in that same computer connected to the transmitter. I'm sending commands to the transmitter in a sequence that looks like this. DIGITAL_BURST (commands sent via serial port) AUDIO (.wav files being played by the computer) TEXT_ECHO (text to display on the radio) I use DTR and RTS to control a set of relays in the transmitter to select which source of data to broadcast to the radios. I set the bits appropriately and I send the digital burst via the serial port. I need to make sure all of these bits have made it to the controller before I reset the bits to tell the transmitter to start sending the WAV file I'm playing on the computer. In the same respect I need to know when all of the sound data is completely sent so that I can put the controller back in serial IO mode and transmit the text to display on the radio. I don't have control over the message format nor can I change anything inside the transmitter. I only have control over the software that runs on the computer. This is why I believe I need something like synchronous IO. How would I otherwise know when all the data from one phase has been transmitted and I can go on to the next step? Currently the code is riddled with a bunch of nanosleeps that do their best to estimate how long it takes to transmit the data. This is kludgy at best and not very accurate because it depends on the load of the box and a bunch of other factors. I end up having to pad the times a bunch to try and cover all the possible things that could cause my rough-order transmission times to be missed. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: synchronous IO
Thanks for the info. I don't think I was very clear in my first explanation. I have an RF transmitter that I control via a serial port on a FreeBSD box. I also have a sound card in that same computer connected to the transmitter. I'm sending commands to the transmitter in a sequence that looks like this. DIGITAL_BURST (commands sent via serial port) AUDIO (.wav files being played by the computer) TEXT_ECHO (text to display on the radio) I use DTR and RTS to control a set of relays in the transmitter to select which source of data to broadcast to the radios. I set the bits appropriately and I send the digital burst via the serial port. I need to make sure all of these bits have made it to the controller before I reset the bits to tell the transmitter to start sending the WAV file I'm playing on the computer. In the same respect I need to know when all of the sound data is completely sent so that I can put the controller back in serial IO mode and transmit the text to display on the radio. You can ensure the serial output is drained with tcdrain(). There's is probably an interface for checking the status of the sound buffer. Looking in sys/soundcard.h, I would suggest calling SNDCTL_DSP_GETOSPACE while the card is idle to determine the total amount of output space, then poll while you're waiting for the sample play to end until it returns to the "empty" level. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: synchronous IO
On Fri, Jan 12, 2001 at 12:18:20PM -0800, Mike Smith wrote: # # You can ensure the serial output is drained with tcdrain(). There's is # probably an interface for checking the status of the sound buffer. Yes, this appears to have done the trick. # Looking in sys/soundcard.h, I would suggest calling SNDCTL_DSP_GETOSPACE # while the card is idle to determine the total amount of output space, # then poll while you're waiting for the sample play to end until it # returns to the "empty" level. I'll give this one a shot shortly. Thanks Mike. :) -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
FWIW, I'm against changing cron. Ted Faber said it best: If someone wants to change cron's behavior to make DST (and other timezone shenanigans) behave intuitively, add a flag to make cron work exclusively in UTC as someone else suggested. It's simple to explain which means less user confusion, and covers all the cases (even crossing the International Date line with a mobile laptop) which reduces code bloat. Finally it's conceptually simpler and more elegant. I think that's ^^ worth something. -- Tim Jackson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
new documentaion
Hello everyone, I have started a thread on freebsd-newbies freebsd-advocacy. The main purpose of this thread is to create new and up to date documentation for freebsd, as well as extend the number of tutorials as a whole. I have decent number of contributers from the above mentioned lists and we are going to be going to work soon, organizing it all through E-mail etc... here is my reason for posting this: While i am sure me and the few people i have gathered will have no time writing up to date tutorials on topics such as UNIX basics, configuring ppp, setting up a cable modem, using some development tools etc, I know there will be some advanced subjects that we will need some assistance on from you guys. I know this is a busy bunch, and if you have things you are doing (for the project or otherwise) that are more important, disregard this message, I am simply looking for some people who are willing to write some tutorials whenever they have the time. If you would like to participate just send me an E-mail with the E-mail address you would like to discuss the docs with, and any other information you feel to be of relevence, Biggest thanks, Arthur To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
bus_alloc_resource and RF_SHARABLE
Hello, Hackers.
I'm on FreeBSD 4.1.1 and when I attempt multiple calls to
bus_alloc_resource on a PCI device for the same BAR, I run afoul of code
in resource_list_alloc:
rle = resource_list_find(rl, type, *rid);
if (!rle)
return 0; /* no resource of that type/rid */
if (rle-res)
panic("resource_list_alloc: resource entry is busy");
Even though I'm calling it with RF_SHARABLE, this code doesn't seem
to take that into account. It finds the existing list and therefore
panics. Am I doing something wrong or does this really work?
Yes, I can rig things up such that there is only one bus_alloc_resource
call per BAR but I'd rather not.
Thanx,
RJL
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Off topic but worth it.. Things to Say When You're Losing a Technical Argument
Maybe we could declare a thread closed when these turn up? http://www.pigdog.org/auto/mr_bads_list/shortcolumn/1914.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Off topic but worth it.. Things to Say When You're Losing aTechnical Argument
On Fri, 12 Jan 2001, Julian Elischer wrote: Maybe we could declare a thread closed when these turn up? http://www.pigdog.org/auto/mr_bads_list/shortcolumn/1914.html I like your idea. Why don't you write up a white paper and we'll review it at the next staff meeting? Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
