Re: multi-channel firewire host adaptors available ?
John Kozubik wrote: > Has anyone seen multi-channel (up to eight) firewire PCI host adaptors ? > We require full 400Mb throughput on each channel, simultaneously. Interesting... 64bit PCI * 66Mhz = 4,429,185,024 bit/S = 4,244 Mbit/S = 528MB/S ...burst rate. Sustained rate is about half that, so the ballpark is: 2,122 Mbit/S = 264 MB/S. Assuming "400Mb" is "400Mbit", you will be at most able to process a total of 5 channels worth of data simultaneously. If that's "400MB", well, expect to get only 2/3 of a single channel, or burst, up to 1 1/3 channels... PS: The most I have seen on a single card is 2... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Problems with Squid on 4.4-RC
Vladimir, I had the same problem and the solution is to compile with the -O switch instead of the -O2. There is a lot of information at the squid site. Gert To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCSH bug...
Steven Ames wrote: > Do you really want to delete all files? [n/y] y [ ... ] > I'm not seeing this problem... This is from -CURRENT from about 2 hours ago. [ ... ] > > Do you really want to delete all files? [n/y] n > > Bus error (core dumped) [ ... ] > > Whazzup? This will always happen, iff you select to not rm * Try saying 'n' instead of 'y'. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCSH bug...
On Mon, Aug 27, 2001 at 09:45:03PM -0500, Jim Bryant wrote: > Someone recently commented in the tcsh/csh thread concerning the fact > that the FreeBSD tcsh is maintained separately from the port, As is all 3rd party contributed software. > and nobody is really sure who is responsible for keeping the FreeBSD > version both in sync, AND, csh compatable when called with the > executable name "csh". We *do* know who that is. This however is a more tcsh-specific issue, and raising it with the tcsh author would probably lead you to faster happiness. Is there some reason you wont email him about this? -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCSH bug...
Charlie & wrote: > On Mon, Aug 27, 2001 at 05:41:21PM -0500, Steven Ames wrote: > >>>-current from saturday... >>> >>>And I've noticed it for a few months, just forgot about it until last >>> >>night... >> >>>Also, you failed to duplicate the test... Try answering "NO" when it >>> >>asks... >> >>OK. Yep. I see the same results. I believe that when you say 'no' tcsh tries >>to >>get clever and remove that command from your command stack (history). The >>relevent code is in tc.func.c starting at line 1238. I don't see anything >>obviously >>silly... I'll do a bit of debugging though. >> > > Hrm... The code all looks good. The offending bit is in tc.func.c > between lines 1245 and 1254 (one block). While removing items from > a doubly linked list tmp->next gets set to an invalid pointer. The > code itself looks good so the list getting passed to it must be flawed. > > That'll take some real effort to track down. Interesting datapoint though... > tcsh from ports doesn't have this problem. Though I don't see any code > changes between the two that could cause this, so it'd have to be in > compile time options or 'config'. > Yeah, I had looked at it, but couldn't really see anything major when I did... That was a few months ago when I first noticed the problem. Someone recently commented in the tcsh/csh thread concerning the fact that the FreeBSD tcsh is maintained separately from the port, and nobody is really sure who is responsible for keeping the FreeBSD version both in sync, AND, csh compatable when called with the executable name "csh". Interesting to note that this has been fixed in the -port though, as opposed to the one that is installed by default. >>>Steven Ames wrote: >>> >>> Under -CURRENT? virtual-voodoo# touch 0 1 2 3 4 5 6 7 8 9 virtual-voodoo# ls 0 1 2 3 4 5 6 7 8 >>9 >> virtual-voodoo# set rmstar virtual-voodoo# rm * Do you really want to delete all files? [n/y] y virtual-voodoo# ls virtual-voodoo# version tcsh 6.10.00 (Astron) 2000-11-19 (i386-intel-FreeBSD) options 8b,nls,dl,al,kan,sm,rh,color,dspm I'm not seeing this problem... This is from -CURRENT from about 2 hours >>ago. >> -Steve - Original Message - From: "Jim Bryant" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, August 27, 2001 4:53 PM Subject: TCSH bug... >Sorry if this doesn't go here... I don't know where else to put it... > > Please forward it to the correct people. >With: > >set rmstar > >in your .cshrc, perform the following operations: > >-- > 4:49:49pm wahoo(49): tcsh > 4:49:51pm wahoo(1): mkdir bs > 4:49:54pm wahoo(2): cd bs > 4:49:56pm wahoo(3): touch 1 2 3 4 5 6 7 8 9 0 > 4:50:02pm wahoo(4): ls >. .. 0 1 2 3 4 5 6 > >>7 >> 8 9 > 4:50:05pm wahoo(5): rm * >Do you really want to delete all files? [n/y] n >Bus error (core dumped) > 4:50:10pm wahoo(50): cd bs > 4:50:19pm wahoo(51): ls >. .. 0 1 2 > > 3 4 5 6 >7 8 9 tcsh.core > 4:50:20pm wahoo(52): >--- > >Whazzup? This will always happen, iff you select to not rm * > >jim >-- >ET has one helluva sense of humor! >He's always anal-probing right-wing schizos! > > >_ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.yahoo.com > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-hackers" in the body of the message > > > >>> >>>-- >>>ET has one helluva sense of humor! >>>He's always anal-probing right-wing schizos! >>> >>> >>>_ >>>Do You Yahoo!? >>>Get your free @yahoo.com address at http://mail.yahoo.com >>> >>> >>> >> >>To Unsubscribe: send mail to [EMAIL PROTECTED] >>with "unsubscribe freebsd-hackers" in the body of the message >> > -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Portability of #warning in /usr/include
> This may not work.
>...
> Some of those compilers
> would NOT let you '#ifdef' out the version that it did not recognize
> (perhaps thinking that '#warn' or '#warning' might be some gross typo
> for '#else' or '#endif', I guess...).
this is true; some compilers seem to require that #ifdef'd out code be syntactically
correct.
while #warning is not available in ISO C, #error is.
it was deliberate to omit #warning; there is nothing in the standard to require #error
to be fatal.
one could easily argue that #warning would have been useful, even if the distinction
between #warning and #error is hazy.
i don't think pragmas offer a solution, in either the "#pragma warning" or "_Pragma"
forms.
i do not think gcc supports a "warning" pragma however (as in #pragma GCC warning
foobar
or _Pragma("GCC warning foobar")), nor is their such a thing in the STDC pragma
namespace.
one sure way to make things work is to move compiler-specific things to
compiler-specific headers,
which would probably be a good idea anyhow. something like including a
"compiler_specific.h"
which would in turn contain stuff like:
#ifdef __GNUC__
#include "gnu_cruft.h"
#elif __TenDRA__ /* don't know if this is what it is called */
#include "tendra_cruft.h"
#else
#error what compiler is this?
#endif
-mda
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: TCSH bug...
On Mon, Aug 27, 2001 at 05:41:21PM -0500, Steven Ames wrote: > > -current from saturday... > > > > And I've noticed it for a few months, just forgot about it until last > night... > > > > Also, you failed to duplicate the test... Try answering "NO" when it > asks... > > OK. Yep. I see the same results. I believe that when you say 'no' tcsh tries > to > get clever and remove that command from your command stack (history). The > relevent code is in tc.func.c starting at line 1238. I don't see anything > obviously > silly... I'll do a bit of debugging though. Hrm... The code all looks good. The offending bit is in tc.func.c between lines 1245 and 1254 (one block). While removing items from a doubly linked list tmp->next gets set to an invalid pointer. The code itself looks good so the list getting passed to it must be flawed. That'll take some real effort to track down. Interesting datapoint though... tcsh from ports doesn't have this problem. Though I don't see any code changes between the two that could cause this, so it'd have to be in compile time options or 'config'. -Steve > > -Steve > > > Steven Ames wrote: > > > > > Under -CURRENT? > > > > > > virtual-voodoo# touch 0 1 2 3 4 5 6 7 8 9 > > > virtual-voodoo# ls > > > 0 1 2 3 4 5 6 7 8 > 9 > > > virtual-voodoo# set rmstar > > > virtual-voodoo# rm * > > > Do you really want to delete all files? [n/y] y > > > virtual-voodoo# ls > > > virtual-voodoo# > > > > > > version tcsh 6.10.00 (Astron) 2000-11-19 (i386-intel-FreeBSD) options > > > 8b,nls,dl,al,kan,sm,rh,color,dspm > > > > > > I'm not seeing this problem... This is from -CURRENT from about 2 hours > ago. > > > > > > -Steve > > > > > > - Original Message - > > > From: "Jim Bryant" <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]> > > > Sent: Monday, August 27, 2001 4:53 PM > > > Subject: TCSH bug... > > > > > > > > > > > >>Sorry if this doesn't go here... I don't know where else to put it... > > >> > > > Please forward it to the correct people. > > > > > >>With: > > >> > > >>set rmstar > > >> > > >>in your .cshrc, perform the following operations: > > >> > > >>-- > > >> 4:49:49pm wahoo(49): tcsh > > >> 4:49:51pm wahoo(1): mkdir bs > > >> 4:49:54pm wahoo(2): cd bs > > >> 4:49:56pm wahoo(3): touch 1 2 3 4 5 6 7 8 9 0 > > >> 4:50:02pm wahoo(4): ls > > >>. .. 0 1 2 3 4 5 6 > 7 > > >> > > > 8 9 > > > > > >> 4:50:05pm wahoo(5): rm * > > >>Do you really want to delete all files? [n/y] n > > >>Bus error (core dumped) > > >> 4:50:10pm wahoo(50): cd bs > > >> 4:50:19pm wahoo(51): ls > > >>. .. 0 1 2 > > >> > > > 3 4 5 6 > > > > > >> 7 8 9 tcsh.core > > >> 4:50:20pm wahoo(52): > > >>--- > > >> > > >>Whazzup? This will always happen, iff you select to not rm * > > >> > > >>jim > > >>-- > > >>ET has one helluva sense of humor! > > >>He's always anal-probing right-wing schizos! > > >> > > >> > > >>_ > > >>Do You Yahoo!? > > >>Get your free @yahoo.com address at http://mail.yahoo.com > > >> > > >> > > >>To Unsubscribe: send mail to [EMAIL PROTECTED] > > >>with "unsubscribe freebsd-hackers" in the body of the message > > >> > > >> > > > > > > > > > -- > > ET has one helluva sense of humor! > > He's always anal-probing right-wing schizos! > > > > > > _ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > 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: multi-channel firewire host adaptors available ?
On Mon, Aug 27, 2001 at 05:50:17PM -0700, John Kozubik wrote: > > Has anyone seen multi-channel (up to eight) firewire PCI host adaptors ? > We require full 400Mb throughput on each channel, simultaneously. > > If not up to eight, how dense have you folks seen a single PCI board ? > > (query not limited to just boards with FreeBSD support...) IIRC the bandwidth of the PCI bus is around 1.2Gbit, so eight devices on one single PCI bus won't really work. This might be better for 66mhz/64bit PCI slots though. Correct me if I'm wrong... Alson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
multi-channel firewire host adaptors available ?
Has anyone seen multi-channel (up to eight) firewire PCI host adaptors ? We require full 400Mb throughput on each channel, simultaneously. If not up to eight, how dense have you folks seen a single PCI board ? (query not limited to just boards with FreeBSD support...) Thanks. - John Kozubik - [EMAIL PROTECTED] - http://www.kozubik.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: To determine if a file has grown?
* Matthew Hagerty <[EMAIL PROTECTED]> [010827 18:28] wrote: > Greetings, > > Is there a fast and/or efficient way to determine if a file size has > changed without reopening the file every time? I'm writing a program that > needs to open a file and watch it to see when data gets written to the file > (from an external source or another part of the same program), then read > the data to process it. I was looking at stat() but I've read that it is a > high overhead function. Any insight would be greatly appreciated. use kqueue. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
To determine if a file has grown?
Greetings, Is there a fast and/or efficient way to determine if a file size has changed without reopening the file every time? I'm writing a program that needs to open a file and watch it to see when data gets written to the file (from an external source or another part of the same program), then read the data to process it. I was looking at stat() but I've read that it is a high overhead function. Any insight would be greatly appreciated. Thanks, Matthew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCSH bug...
Thanks... Steven Ames wrote: >>-current from saturday... >> >>And I've noticed it for a few months, just forgot about it until last >> > night... > >>Also, you failed to duplicate the test... Try answering "NO" when it >> > asks... > > OK. Yep. I see the same results. I believe that when you say 'no' tcsh tries > to > get clever and remove that command from your command stack (history). The > relevent code is in tc.func.c starting at line 1238. I don't see anything > obviously > silly... I'll do a bit of debugging though. > > -Steve > > >>Steven Ames wrote: >> >> >>>Under -CURRENT? >>> >>>virtual-voodoo# touch 0 1 2 3 4 5 6 7 8 9 >>>virtual-voodoo# ls >>>0 1 2 3 4 5 6 7 8 >>> > 9 > >>>virtual-voodoo# set rmstar >>>virtual-voodoo# rm * >>>Do you really want to delete all files? [n/y] y >>>virtual-voodoo# ls >>>virtual-voodoo# >>> >>>version tcsh 6.10.00 (Astron) 2000-11-19 (i386-intel-FreeBSD) options >>>8b,nls,dl,al,kan,sm,rh,color,dspm >>> >>>I'm not seeing this problem... This is from -CURRENT from about 2 hours >>> > ago. > >>>-Steve >>> >>>- Original Message - >>>From: "Jim Bryant" <[EMAIL PROTECTED]> >>>To: <[EMAIL PROTECTED]> >>>Sent: Monday, August 27, 2001 4:53 PM >>>Subject: TCSH bug... >>> >>> >>> >>> Sorry if this doesn't go here... I don't know where else to put it... >>>Please forward it to the correct people. >>> >>> With: set rmstar in your .cshrc, perform the following operations: -- 4:49:49pm wahoo(49): tcsh 4:49:51pm wahoo(1): mkdir bs 4:49:54pm wahoo(2): cd bs 4:49:56pm wahoo(3): touch 1 2 3 4 5 6 7 8 9 0 4:50:02pm wahoo(4): ls . .. 0 1 2 3 4 5 6 > 7 > >>>8 9 >>> >>> 4:50:05pm wahoo(5): rm * Do you really want to delete all files? [n/y] n Bus error (core dumped) 4:50:10pm wahoo(50): cd bs 4:50:19pm wahoo(51): ls . .. 0 1 2 >>>3 4 5 6 >>> >>> 7 8 9 tcsh.core 4:50:20pm wahoo(52): --- Whazzup? This will always happen, iff you select to not rm * jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message >> >>-- >>ET has one helluva sense of humor! >>He's always anal-probing right-wing schizos! >> >> >>_ >>Do You Yahoo!? >>Get your free @yahoo.com address at http://mail.yahoo.com >> >> >> > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > > -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCSH bug...
> -current from saturday... > > And I've noticed it for a few months, just forgot about it until last night... > > Also, you failed to duplicate the test... Try answering "NO" when it asks... OK. Yep. I see the same results. I believe that when you say 'no' tcsh tries to get clever and remove that command from your command stack (history). The relevent code is in tc.func.c starting at line 1238. I don't see anything obviously silly... I'll do a bit of debugging though. -Steve > Steven Ames wrote: > > > Under -CURRENT? > > > > virtual-voodoo# touch 0 1 2 3 4 5 6 7 8 9 > > virtual-voodoo# ls > > 0 1 2 3 4 5 6 7 8 9 > > virtual-voodoo# set rmstar > > virtual-voodoo# rm * > > Do you really want to delete all files? [n/y] y > > virtual-voodoo# ls > > virtual-voodoo# > > > > version tcsh 6.10.00 (Astron) 2000-11-19 (i386-intel-FreeBSD) options > > 8b,nls,dl,al,kan,sm,rh,color,dspm > > > > I'm not seeing this problem... This is from -CURRENT from about 2 hours ago. > > > > -Steve > > > > - Original Message - > > From: "Jim Bryant" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Monday, August 27, 2001 4:53 PM > > Subject: TCSH bug... > > > > > > > >>Sorry if this doesn't go here... I don't know where else to put it... > >> > > Please forward it to the correct people. > > > >>With: > >> > >>set rmstar > >> > >>in your .cshrc, perform the following operations: > >> > >>-- > >> 4:49:49pm wahoo(49): tcsh > >> 4:49:51pm wahoo(1): mkdir bs > >> 4:49:54pm wahoo(2): cd bs > >> 4:49:56pm wahoo(3): touch 1 2 3 4 5 6 7 8 9 0 > >> 4:50:02pm wahoo(4): ls > >>. .. 0 1 2 3 4 5 6 7 > >> > > 8 9 > > > >> 4:50:05pm wahoo(5): rm * > >>Do you really want to delete all files? [n/y] n > >>Bus error (core dumped) > >> 4:50:10pm wahoo(50): cd bs > >> 4:50:19pm wahoo(51): ls > >>. .. 0 1 2 > >> > > 3 4 5 6 > > > >> 7 8 9 tcsh.core > >> 4:50:20pm wahoo(52): > >>--- > >> > >>Whazzup? This will always happen, iff you select to not rm * > >> > >>jim > >>-- > >>ET has one helluva sense of humor! > >>He's always anal-probing right-wing schizos! > >> > >> > >>_ > >>Do You Yahoo!? > >>Get your free @yahoo.com address at http://mail.yahoo.com > >> > >> > >>To Unsubscribe: send mail to [EMAIL PROTECTED] > >>with "unsubscribe freebsd-hackers" in the body of the message > >> > >> > > > > > -- > ET has one helluva sense of humor! > He's always anal-probing right-wing schizos! > > > _ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCSH bug...
-current from saturday... And I've noticed it for a few months, just forgot about it until last night... Also, you failed to duplicate the test... Try answering "NO" when it asks... Steven Ames wrote: > Under -CURRENT? > > virtual-voodoo# touch 0 1 2 3 4 5 6 7 8 9 > virtual-voodoo# ls > 0 1 2 3 4 5 6 7 8 9 > virtual-voodoo# set rmstar > virtual-voodoo# rm * > Do you really want to delete all files? [n/y] y > virtual-voodoo# ls > virtual-voodoo# > > version tcsh 6.10.00 (Astron) 2000-11-19 (i386-intel-FreeBSD) options > 8b,nls,dl,al,kan,sm,rh,color,dspm > > I'm not seeing this problem... This is from -CURRENT from about 2 hours ago. > > -Steve > > - Original Message - > From: "Jim Bryant" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, August 27, 2001 4:53 PM > Subject: TCSH bug... > > > >>Sorry if this doesn't go here... I don't know where else to put it... >> > Please forward it to the correct people. > >>With: >> >>set rmstar >> >>in your .cshrc, perform the following operations: >> >>-- >> 4:49:49pm wahoo(49): tcsh >> 4:49:51pm wahoo(1): mkdir bs >> 4:49:54pm wahoo(2): cd bs >> 4:49:56pm wahoo(3): touch 1 2 3 4 5 6 7 8 9 0 >> 4:50:02pm wahoo(4): ls >>. .. 0 1 2 3 4 5 6 7 >> > 8 9 > >> 4:50:05pm wahoo(5): rm * >>Do you really want to delete all files? [n/y] n >>Bus error (core dumped) >> 4:50:10pm wahoo(50): cd bs >> 4:50:19pm wahoo(51): ls >>. .. 0 1 2 >> > 3 4 5 6 > >> 7 8 9 tcsh.core >> 4:50:20pm wahoo(52): >>--- >> >>Whazzup? This will always happen, iff you select to not rm * >> >>jim >>-- >>ET has one helluva sense of humor! >>He's always anal-probing right-wing schizos! >> >> >>_ >>Do You Yahoo!? >>Get your free @yahoo.com address at http://mail.yahoo.com >> >> >>To Unsubscribe: send mail to [EMAIL PROTECTED] >>with "unsubscribe freebsd-hackers" in the body of the message >> >> > -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCSH bug...
Under -CURRENT? virtual-voodoo# touch 0 1 2 3 4 5 6 7 8 9 virtual-voodoo# ls 0 1 2 3 4 5 6 7 8 9 virtual-voodoo# set rmstar virtual-voodoo# rm * Do you really want to delete all files? [n/y] y virtual-voodoo# ls virtual-voodoo# version tcsh 6.10.00 (Astron) 2000-11-19 (i386-intel-FreeBSD) options 8b,nls,dl,al,kan,sm,rh,color,dspm I'm not seeing this problem... This is from -CURRENT from about 2 hours ago. -Steve - Original Message - From: "Jim Bryant" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, August 27, 2001 4:53 PM Subject: TCSH bug... > Sorry if this doesn't go here... I don't know where else to put it... Please forward it to the correct people. > > With: > > set rmstar > > in your .cshrc, perform the following operations: > > -- > 4:49:49pm wahoo(49): tcsh > 4:49:51pm wahoo(1): mkdir bs > 4:49:54pm wahoo(2): cd bs > 4:49:56pm wahoo(3): touch 1 2 3 4 5 6 7 8 9 0 > 4:50:02pm wahoo(4): ls > . .. 0 1 2 3 4 5 6 7 8 9 > 4:50:05pm wahoo(5): rm * > Do you really want to delete all files? [n/y] n > Bus error (core dumped) > 4:50:10pm wahoo(50): cd bs > 4:50:19pm wahoo(51): ls > . .. 0 1 2 3 4 5 6 > 7 8 9 tcsh.core > 4:50:20pm wahoo(52): > --- > > Whazzup? This will always happen, iff you select to not rm * > > jim > -- > ET has one helluva sense of humor! > He's always anal-probing right-wing schizos! > > > _ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > 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
TCSH bug...
Sorry if this doesn't go here... I don't know where else to put it... Please forward it to the correct people. With: set rmstar in your .cshrc, perform the following operations: -- 4:49:49pm wahoo(49): tcsh 4:49:51pm wahoo(1): mkdir bs 4:49:54pm wahoo(2): cd bs 4:49:56pm wahoo(3): touch 1 2 3 4 5 6 7 8 9 0 4:50:02pm wahoo(4): ls . .. 0 1 2 3 4 5 6 7 8 9 4:50:05pm wahoo(5): rm * Do you really want to delete all files? [n/y] n Bus error (core dumped) 4:50:10pm wahoo(50): cd bs 4:50:19pm wahoo(51): ls . .. 0 1 2 3 4 5 6 7 8 9 tcsh.core 4:50:20pm wahoo(52): --- Whazzup? This will always happen, iff you select to not rm * jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel compiles failing
I found the problem -- in an earlier post to this veryu list options NETSMB #SMB/CIFS requester options NETSMBCRYPTO#encrypted password support options SMBFS #SMB/CIFS filesystem options LIBICONV These 4 options are necessary from what I can tell in order for SMB* to compile into the kernel properly. Im still looking for an answer or some guidance on the pcm issue if anyone wants to take a poke at it John Hildreth MMPS Engineer Allegiance Telecom [EMAIL PROTECTED] Office: 469-259-2612 Cell: 214-914-3112 It has been said: > I hate to say it but I dont have the exact errors -- > I will put my kernel config in here so you can see what Im trying to build > (SMP pIII 550) > > two things are failing about the kernel builds > 1: options SMB and options NETSMB > when those options are in the kernel, the build will fail, > generally with ocnv errors -- if needed I can run another build and paste > the errors this has been an issue since 4.3 (fails on 4.4rc1 as well) > > 2: device pcm > with this option in the kernel, (and the irq/drq options for my isa sound > card) the kernel will successfully build, but the boot will halt once the > kernel tries to config the pcm device -- causing me to have to power off > and boot kernel.old > > are these known issues, and if so is there a fix anywhere? > > any help would be greatly appreciated > > Attached is my kernel config without the pcm/SMB/NETSMB options > (plain text file called SPARKY (my machines hostname) > > John Hildreth > MMPS Engineer > Allegiance Telecom > [EMAIL PROTECTED] > Office: 469-259-2612 > Cell: 214-914-3112 > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: import NetBSD rc system
> Is there anything we need to talk about still, or do we just need an > unemployed guy who understands the problem to bang out a big pile of code. > If we need to hold joint discussions, what are the outstanding issues? Given the lack of any response, I didn't do any further work. My previous work on the NetBSD import is available at http://overtone.org/rc.d/ The version contained in the tarball there requires that you flip rc_new to YES in your rc.conf, else it uses the old stuff. It's not compatible with BOOTP diskless booting out of the box, though it includes the trivial patch to make that work. It includes some minor notes I made for myself while I first worked on the project. There's also a TODO list, noting the items which still need work done (beyond debugging) Everything in the tarball is derived from BSD licensed sources, and it all remains under the BSD license. If anybody decides that they want to fix this up and use it, I'd be more than happy to answer any questions, or accept any flames that you might have. -Kevin Way PGP signature
sysconf() vs sysctl()
Hi
Are there any plans to implement'_SC_NPROCESSORS_CONF' in sysconf() ? I'm
aware of hw.ncpu and the sysctl() call with {CTL_HW,HW_NCPU}, but sysconf is
posix and sysctl is not :) (is it already done in 5.0? I'm using 4.4)
thnx
-Erik <[EMAIL PROTECTED]> [http://math.smsu.edu/~erik]
The opinions expressed by me are not necessarily opinions. In all probability,
they are random rambling, and to be ignored. Failure to ignore may result in
severe boredom or confusion. Shake well before opening. Keep Refrigerated.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Portability of #warning in /usr/include
At 1:47 PM -0500 8/27/01, Alfred Perlstein wrote: >* Charles Randall <[EMAIL PROTECTED]> [010827 12:44] wrote: >> I've noted that several include files in /usr/include use the C preprocessor >> #warning directive. This isn't standard C and prevents some software from >> compiling using a compiler like TenDRA. What's the current opinion on this? > >My opinion is that #warning should be standardized, however since it's >not, diffs to surround them with #ifdef __GNU_C__ (or whatever it is) >will probably be committed. This may not work. I know I had some problem with #warn and #warning with some code I was working on, where some C compilers would only recognize one and other C compilers would only recognize the other. Some of those compilers would NOT let you '#ifdef' out the version that it did not recognize (perhaps thinking that '#warn' or '#warning' might be some gross typo for '#else' or '#endif', I guess...). -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Portability of #warning in /usr/include
* Charles Randall <[EMAIL PROTECTED]> [010827 12:44] wrote: > I've noted that several include files in /usr/include use the C preprocessor > #warning directive. This isn't standard C and prevents some software from > compiling using a compiler like TenDRA. What's the current opinion on this? My opinion is that #warning should be standardized, however since it's not, diffs to surround them with #ifdef __GNU_C__ (or whatever it is) will probably be committed. -- -Alfred Perlstein [[EMAIL PROTECTED]] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: secure Filesystem
On Thu, Aug 16, 2001 at 09:42:58AM -0600, Charles Randall wrote: > > Also note that the version available in ports/packages for FreeBSD 4.x is > CFS v1.4.0b2. CFS v1.4.1 is available on Matt Blaze's site. There's an open PR on this. If you want 1.4.1, apply the patch in the PR at http://www.FreeBSD.org/cgi/query-pr.cgi?pr=29638 > However, the documentation doesn't seem to indicate what may have changed > between these versions. No functional changes, AFAICT. Just build/compatibility improvements for some platforms. cheers, --Scott -- Scott Renfro <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvsup ports always failed
In article <000d01c12d7d$24fb5ea0$0245a8c0@chojin>, Chojin <[EMAIL PROTECTED]> wrote: > > *** > *** runtime error: > ***gc: Could not extend the traced heap > *** Please read the CVSup FAQ at http://www.polstra.com/projects/freeware/CVSup/ There is a question there which directly addresses this problem. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: shared memory models/techniques
Are your processes all created by fork() or are they unrelated? If they're all descendants of the same process, take a look at the GNU mm library (which is loosely based on structure of the mm_malloc library I wrote for my company but couldn't release). http://www.engelschall.com/sw/mm/ If they're unrelated, you'll have to use SysV. Charles -Original Message- From: fergus [mailto:[EMAIL PROTECTED]] Sent: Saturday, August 18, 2001 4:57 AM To: hackers Subject: shared memory models/techniques hope this is an ok place to post this. as far as i can tell there are three ways to share memory between processes - using mmap, ipc shared mem or skip it using threads instead. is this right? basically i have a server process accepting many connections & i was using threads, however, it doesn't really make sense processes would probably be simpler with shared mem. i was going to use IPC but don't like building uncessesary dependancies (i.e. it's a kernel option). is mmap the best way to do this? why would you use ipc instead? . . . and finally (milking the assistance to the last) is there a really simple app using shared mem resources that anyone knows about so i can butcher it? thanks in advance. fergus 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: secure Filesystem
Also note that the version available in ports/packages for FreeBSD 4.x is CFS v1.4.0b2. CFS v1.4.1 is available on Matt Blaze's site. http://www.crypto.com/software/ However, the documentation doesn't seem to indicate what may have changed between these versions. I found this while looking for pointers to compressible file systems (before anyone warms up their flame thrower, they're still of good use for some applications even though disk is real cheap). Any leads there? I couldn't find anything. Charles -Original Message- From: Konstantin Chuguev [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 16, 2001 3:19 AM To: Josef Karthauser Cc: Vladimir Terziev; [EMAIL PROTECTED] Subject: Re: secure Filesystem Josef Karthauser wrote: > >Does FreeBSD support any type of secure (encrypted) filesystem? > > Look at /usr/ports/security/cfs. It's a useland crypto-filesystem that > runs over NFS. > I'd say, it's a daemon pretending to be an NFS server. It's running locally on port other than NFS. Very nice implementation, I use it a lot. A small problem with it is that it seems to support 7-bit file names only. -- * * Konstantin Chuguev Francis House * * Application Engineer 112 Hills Road * Tel: +44 1223 302992 Cambridge CB2 1PQ D A N T E WWW: http://www.dante.netUnited Kingdom 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
Portability of #warning in /usr/include
I've noted that several include files in /usr/include use the C preprocessor #warning directive. This isn't standard C and prevents some software from compiling using a compiler like TenDRA. What's the current opinion on this? Charles To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ata0-master: non aligned DMA transfer attempted
On Mon, 27 Aug 2001, Julian Elischer wrote:
> Zhihui Zhang wrote:
>
> > I believe that message is from ata_dmasetup():
> >
> > if (((uintptr_t)data & scp->alignment) || (count & scp->alignment)) {
> > ata_printf(scp, device, "non aligned DMA transfer attempted\n");
> > return -1;
> > }
> >
> > The user address obtained by static allocation is not 16-byte aligned. The
> > kernel routine physio() grabs a physical buffer to do DMA, but it still
> > uses the user's address. The KVA associated with the buffer is not used.
> >
> > -Zhihui
>
>
> the physical address of a buffer will have the same allignment as the KVA
> address.
But how can you explain the following statement in physio():
bp->b_dev = dev;
bp->b_iodone = physwakeup;
> bp->b_data = uio->uio_iov[i].iov_base;
bp->b_bcount = uio->uio_iov[i].iov_len;
bp->b_offset = uio->uio_offset;
bp->b_saveaddr = sa;
The bp->b_data is set to point to the user address. And later on, it is
passed to the data argument of ata_dmasetup(), where the alignment is
checked.
-Zhihui
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: ata0-master: non aligned DMA transfer attempted
Zhihui Zhang wrote:
> I believe that message is from ata_dmasetup():
>
> if (((uintptr_t)data & scp->alignment) || (count & scp->alignment)) {
> ata_printf(scp, device, "non aligned DMA transfer attempted\n");
> return -1;
> }
>
> The user address obtained by static allocation is not 16-byte aligned. The
> kernel routine physio() grabs a physical buffer to do DMA, but it still
> uses the user's address. The KVA associated with the buffer is not used.
>
> -Zhihui
the physical address of a buffer will have the same allignment as the KVA
address.
--
++ __ _ __
| __--_|\ Julian Elischer | \ U \/ / hard at work in
| / \ [EMAIL PROTECTED] +-->x USA\ a very strange
| ( OZ)\___ ___ | country !
+- X_.---._/presently in San Francisco \_/ \\
v
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
root is limited ? :-o
Hello, I see a strange thing: with bash (or tcsh or any other shell) when I try to modify virtual memory limit with ulimit by ex: ulimit -v unlimited (or any number). When I use limit in tcsh to change virtual memory, I can put anything, it doesn't modify anything. virtual memory (kbytes) 24576 Same thing for data size. It's strange because I've got enough memory: Mem: 61M Active, 270M Inact, 53M Wired, 308K Cache, 73M Buf, 241M Free Swap: 800M Total, 800M Free Anyone has got an idea ? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvsup ports always failed
I found the solution: By default there was # If your network link is a T1 or faster, comment out the following line. *default compress I commented it and now it works :) - Original Message - From: "Rino Mardo" <[EMAIL PROTECTED]> To: "Chojin" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, August 26, 2001 2:48 AM Subject: Re: cvsup ports always failed > > Hello, > > > > I hope someone could help me because I don't know what to do. > > > > I had error in cvsup to update my ports. > > Since this error I putted more memory ( I have 650 Mb now), reinstalled my > > system (cvsup and make world) and recompiled my kernel. > > > > After all done (and rebooted) I do my cvsup > > /usr/share/examples/cvsup/ports-supfile > > Connected to ftp2.fr.FreeBSD.org > > Updating collection ports-all/cvs > > Edit ports/INDEX > > > > > > *** > > *** runtime error: > > ***gc: Could not extend the traced heap > > *** > > > > > have you tried doing cvsup your ports after cvsup your sources? update your > ports before recompiling. > > just my 2cents. > > > _ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
No Subject
Subscribe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ata0-master: non aligned DMA transfer attempted
On Sun, 26 Aug 2001, Julian Elischer wrote:
> Zhihui Zhang wrote:
> >
> > Thanks for your replay. I use gdb to find out that the buffer address is
> > not 16-byte aligned. This leads to a question as to how to align a
> > statically allocated data structure properly. Using union seems to be able
> > to align you on a long boundary (or even long long?), but that is not 16
> > byte aligned.
> >
> > union {
> > my_data_structure_t xyz;
> > long pad;
> > }
> >
> > The natural alignment seems to work only on primitive data types. If you
> > define:
> >
> > unsigned char sector_buf[512];
> >
> > It will not always be aligned on a 512 byte boundary, even 16-byte
> > alignment is not guaranteed. Is there a way to achieve this?
>
> unfortunatly not, except to allocate N+16 bytes, and allign it yourself by
>
> using a 2nd variable..
>
> x = malloc(buffesize + 16)
> y = x + 15 & ~15
> ...
> write (fd, y, buffersize);
> ...
> free (x);
> exit();
>
>
> You may experiment to see what allignment your hardware needs...
> 2?, 4?, 6?, 16?
>
> when does the message happen?
I believe that message is from ata_dmasetup():
if (((uintptr_t)data & scp->alignment) || (count & scp->alignment)) {
ata_printf(scp, device, "non aligned DMA transfer attempted\n");
return -1;
}
The user address obtained by static allocation is not 16-byte aligned. The
kernel routine physio() grabs a physical buffer to do DMA, but it still
uses the user's address. The KVA associated with the buffer is not used.
-Zhihui
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
(no subject)
[EMAIL PROTECTED] to eliminate junk mail. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: problem with unloading device driver
> > Hello, > > > > I have a module which adds new device. It does make_dev() and then simulates > > mknod() syscall, so that /dev/name is always automatically created. > > Also I have a daemon which reads from and writes to this device. The daemon > > opens the device once and then holds it open. When my module unloads, > > it simulates unlink() and then does detsroy_dev(). I just noticed that > > when I unload my module, the first write() by daemon to the fd associated with > > that device causes system to crash. Trace looks like this: > > You're unloading your module while something still has an fd > associated with a device it provides? How do you expect that to work? > The right thing to do would be to keep track of how many times your > device has been opened, and fail to unload (return an error from the > modevent handler) if something still has it open. Oh yes ... but I thought kernel should know that I unloaded the driver and close associated fd's, returning some error code when a program still tries to operate on them. Anyway, I now return EBUSY, and it works fine. Thanks ! Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
syslogd bound to a specific address?
Is there a compelling reason why syslogd doesn't have an option to
make it bind to a specific address? Most daemons have one, but
syslogd does not. I'm asking because jail(8) explicitly mentions that
syslogd doesn't support this, which either means the author knows why
it can't reasonably support it, or doesn't have the time to write it.
The patch attached below seems to work reasonably well for me. Is
there something I'm missing?
Thanks.
Index: syslogd.8
===
RCS file: /home/ncvs/src/usr.sbin/syslogd/syslogd.8,v
retrieving revision 1.40
diff -u -r1.40 syslogd.8
--- syslogd.8 2001/08/27 11:04:09 1.40
+++ syslogd.8 2001/08/27 11:11:10
@@ -42,6 +42,7 @@
.Nm
.Op Fl 46Adknsuv
.Op Fl a Ar allowed_peer
+.Op Fl b Ar bind_address
.Op Fl f Ar config_file
.Op Fl m Ar mark_interval
.Op Fl p Ar log_socket
@@ -151,6 +152,10 @@
options are ignored if the
.Fl s
option is also specified.
+.It Fl b Ar bind_address
+Specify one specific IP address or hostname to bind to.
+If a hostname is specified,
+the IPv4 or IPv6 address which corresponds to it is used.
.It Fl d
Put
.Nm
Index: syslogd.c
===
RCS file: /home/ncvs/src/usr.sbin/syslogd/syslogd.c,v
retrieving revision 1.80
diff -u -r1.80 syslogd.c
--- syslogd.c 2001/07/19 22:04:09 1.80
+++ syslogd.c 2001/08/27 11:11:11
@@ -291,7 +291,7 @@
void die __P((int));
void domark __P((int));
void fprintlog __P((struct filed *, int, char *));
-int* socksetup __P((int));
+int* socksetup __P((int, const char *));
void init __P((int));
void logerror __P((const char *));
void logmsg __P((int, char *, char *, int));
@@ -319,13 +319,15 @@
struct sockaddr_storage frominet;
FILE *fp;
char *p, *hname, line[MAXLINE + 1];
+ const char *bindhostname;
struct timeval tv, *tvp;
struct sigaction sact;
sigset_t mask;
pid_t ppid = 1;
socklen_t len;
- while ((ch = getopt(argc, argv, "46Aa:df:kl:m:np:P:suv")) != -1)
+ bindhostname = NULL;
+ while ((ch = getopt(argc, argv, "46Aa:b:df:kl:m:np:P:suv")) != -1)
switch (ch) {
case '4':
family = PF_INET;
@@ -342,6 +344,9 @@
if (allowaddr(optarg) == -1)
usage();
break;
+ case 'b':
+ bindhostname = optarg;
+ break;
case 'd': /* debug */
Debug++;
break;
@@ -447,7 +452,7 @@
}
}
if (SecureMode <= 1)
- finet = socksetup(family);
+ finet = socksetup(family, bindhostname);
if (finet) {
if (SecureMode) {
@@ -2235,8 +2240,9 @@
}
int *
-socksetup(af)
+socksetup(af, bindhostname)
int af;
+ const char *bindhostname;
{
struct addrinfo hints, *res, *r;
int error, maxs, *s, *socks;
@@ -2245,7 +2251,7 @@
hints.ai_flags = AI_PASSIVE;
hints.ai_family = af;
hints.ai_socktype = SOCK_DGRAM;
- error = getaddrinfo(NULL, "syslog", &hints, &res);
+ error = getaddrinfo(bindhostname, "syslog", &hints, &res);
if (error) {
logerror(gai_strerror(error));
errno = 0;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: problem with unloading device driver
"Eugene L. Vorokov" <[EMAIL PROTECTED]> wrote: > Hello, > > I have a module which adds new device. It does make_dev() and then simulates > mknod() syscall, so that /dev/name is always automatically created. > Also I have a daemon which reads from and writes to this device. The daemon > opens the device once and then holds it open. When my module unloads, > it simulates unlink() and then does detsroy_dev(). I just noticed that > when I unload my module, the first write() by daemon to the fd associated with > that device causes system to crash. Trace looks like this: You're unloading your module while something still has an fd associated with a device it provides? How do you expect that to work? The right thing to do would be to keep track of how many times your device has been opened, and fail to unload (return an error from the modevent handler) if something still has it open. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: problem with unloading device driver
> > Hello, > > > > I have a module which adds new device. It does make_dev() and then simulates > > mknod() syscall, so that /dev/name is always automatically created. > > Also I have a daemon which reads from and writes to this device. The daemon > > opens the device once and then holds it open. When my module unloads, > > it simulates unlink() and then does detsroy_dev(). I just noticed that > > when I unload my module, the first write() by daemon to the fd associated with > > that device causes system to crash. > > Is there really a reason you do not want to keep a persistent device > entry in /dev? Aside from cluttering /dev - this is a problem solved > in -current with a working devfs. True, -stable does not really have > a devfs - the one that was in the tree was removed, because it was > way less functional (and working) than the one in -current; still, > why, really, should you be worried about one (or five) more device > nodes in /dev? The point is that I do not want user to create device node in /dev manually; it's a production module, and the requirement is to have everything added automatically on load and not to have unconfigured entries when module is not loaded. Do you think it will stop crashing if I keep persistent device nodes in /dev ? Regards, Eugene To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: function calls/rets in assembly
Mon, Aug 27, 2001 at 08:11:12, stephen_roome wrote about "Re: function calls/rets in assembly": > One final question... (which may be a gcc question, sorry if it is..) > > why do we have some people proposing the use of "leave". When from the > docs I've read, leave takes longer than a mov and return ? To optimize for some higher than i386, use -mcpu= With -mcpu=i486 and higher, gcc writes movl %ebp,%esp popl %ebp Also consider -march= option. /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: problem with unloading device driver
On Mon, Aug 27, 2001 at 01:43:41PM +0400, Eugene L. Vorokov wrote: > Hello, > > I have a module which adds new device. It does make_dev() and then simulates > mknod() syscall, so that /dev/name is always automatically created. > Also I have a daemon which reads from and writes to this device. The daemon > opens the device once and then holds it open. When my module unloads, > it simulates unlink() and then does detsroy_dev(). I just noticed that > when I unload my module, the first write() by daemon to the fd associated with > that device causes system to crash. Is there really a reason you do not want to keep a persistent device entry in /dev? Aside from cluttering /dev - this is a problem solved in -current with a working devfs. True, -stable does not really have a devfs - the one that was in the tree was removed, because it was way less functional (and working) than the one in -current; still, why, really, should you be worried about one (or five) more device nodes in /dev? G'luck, Peter -- I had to translate this sentence into English because I could not read the original Sanskrit. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
problem with unloading device driver
Hello,
I have a module which adds new device. It does make_dev() and then simulates
mknod() syscall, so that /dev/name is always automatically created.
Also I have a daemon which reads from and writes to this device. The daemon
opens the device once and then holds it open. When my module unloads,
it simulates unlink() and then does detsroy_dev(). I just noticed that
when I unload my module, the first write() by daemon to the fd associated with
that device causes system to crash. Trace looks like this:
(kgdb) bt
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
#1 0xc0177ed7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:330
#2 0xc01782f1 in panic (fmt=0xc0276af8 "bwrite: buffer is not busy???") at
/usr/src/sys/kern/kern_shutdown.c:623
#3 0xc01a4a7b in bwrite (bp=0xc26b2390) at /usr/src/sys/kern/vfs_bio.c:672
#4 0xc01a5d08 in vfs_bio_awrite (bp=0xc26b2390) at /usr/src/sys/kern/vfs_bio.c:1538
#5 0xc01580ac in spec_fsync (ap=0xc7319cec) at /usr/src/sys/fs/specfs/spec_vnops.c:400
#6 0xc0157cb9 in spec_vnoperate (ap=0xc7319cec) at
/usr/src/sys/fs/specfs/spec_vnops.c:119
#7 0xc02161bc in ffs_sync (mp=0xc05ac000, waitfor=2, cred=0xc05b1d00, p=0xc02d3fa0)
at vnode_if.h:441
#8 0xc01b1677 in sync (p=0xc02d3fa0, uap=0x0) at /usr/src/sys/kern/vfs_syscalls.c:622
#9 0xc0177acb in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:239
#10 0xc01782f1 in panic (fmt=0xc0288ffe "%s") at /usr/src/sys/kern/kern_shutdown.c:623
#11 0xc025337b in trap_fatal (frame=0xc7319dec, eva=12) at
/usr/src/sys/i386/i386/trap.c:936
#12 0xc02530c5 in trap_pfault (frame=0xc7319dec, usermode=0, eva=12) at
/usr/src/sys/i386/i386/trap.c:850
#13 0xc0252a44 in trap (frame={tf_fs = -953090024, tf_es = -953090032, tf_ds =
-1071972336, tf_edi = -953049344,
tf_esi = -952992672, tf_ebp = -953049500, tf_isp = -953049576, tf_ebx =
-1053283072, tf_edx = -953049456, tf_ecx = 7,
tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1072332928, tf_cs = 8,
tf_eflags = 66195, tf_esp = -1053283072,
tf_ss = -953049344}) at /usr/src/sys/i386/i386/trap.c:405
#14 0xc0157f80 in spec_write (ap=0xc7319e90) at /usr/src/sys/fs/specfs/spec_vnops.c:289
#15 0xc0157cb9 in spec_vnoperate (ap=0xc7319e90) at
/usr/src/sys/fs/specfs/spec_vnops.c:119
#16 0xc01b6f6b in vn_write (fp=0xc137f280, uio=0xc7319f00, cred=0xc1363800, flags=0,
p=0xc72a5540) at vnode_if.h:303
#17 0xc018fc18 in dofilewrite (p=0xc72a5540, fp=0xc137f280, fd=3, buf=0xbfbffbab,
nbyte=1, offset=-1, flags=0)
at /usr/src/sys/sys/file.h:162
#18 0xc018face in write (p=0xc72a5540, uap=0xc7319f80) at
/usr/src/sys/kern/sys_generic.c:334
#19 0xc02538a5 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi =
-1077937128, tf_esi = -1077937136,
tf_ebp = -1077937220, tf_isp = -953049132, tf_ebx = 1, tf_edx = 0, tf_ecx = 0,
tf_eax = 4, tf_trapno = 12, tf_err = 2,
tf_eip = 671760164, tf_cs = 31, tf_eflags = 663, tf_esp = -1077937280, tf_ss =
47}) at /usr/src/sys/i386/i386/trap.c:1123
#20 0xc024479d in syscall_with_err_pushed ()
#21 0x80486bd in ?? ()
(kgdb) frame 14
#14 0xc0157f80 in spec_write (ap=0xc7319e90) at /usr/src/sys/fs/specfs/spec_vnops.c:289
289 error = (*devsw(dev)->d_write) (dev, uio, ap->a_ioflag);
(kgdb) p *dev
$2 = {si_flags = 0, si_atime = {tv_sec = 998903778, tv_nsec = 2619315}, si_ctime =
{tv_sec = 998903780, tv_nsec = 22640918},
si_mtime = {tv_sec = 998903780, tv_nsec = 22640918}, si_udev = 8448, si_hash =
{le_next = 0xc02bcd38, le_prev = 0xc02bdca4},
si_hlist = {slh_first = 0xc7327c60}, si_children = {lh_first = 0x0}, si_siblings =
{le_next = 0x0, le_prev = 0x0},
si_parent = 0x0, si_snapshots = {tqh_first = 0x0, tqh_last = 0xc1382d3c},
si_copyonwrite = 0, si_inode = 0,
si_name = "paudit\000\000\000\000\000\000\000\000\000", si_drv1 = 0x0, si_drv2 =
0x0, si_devsw = 0x0, si_iosize_max = 65536,
si_uid = 0, si_gid = 0, si_mode = 438, __si_u = {__si_tty = {__sit_tty = 0x0},
__si_disk = {__sid_disk = 0x0,
__sid_mountpoint = 0x0, __sid_bsize_phys = 0, __sid_bsize_best = 0}}}
si_devsw is 0 here, which seems to be a problem.
Is this a bug, or can I do something inside my module to prevent this
from happening ?
Regards,
Eugene
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Can I use DDB within splhigh()/splx() block?
Dear, I ran my system with modified 4.1R kernel, and I hit a problem. System is hanged, and I cannot even use ddb to break on the console. Is that possible kernel is trapped in splhigh()/splx() block? Thanks, -- -- Rex Luo Tel : 886-2-25521814 Ext. 824 Fax : 886-2-25521824 e-mail : [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: secure Filesystem
On Thu, Aug 16, 2001 at 10:18:58AM +0100, Konstantin Chuguev wrote:
>
> I'd say, it's a daemon pretending to be an NFS server. It's running
> locally on port other than NFS.
>
> Very nice implementation, I use it a lot. A small problem with it is
> that it seems to support 7-bit file names only.
I tracked down tonight the one other problem with cfs that has plagued
me repeatedly (although it hasn't prevented me from using it day in and
day out with a couple of shell scripts to fix-up mail files corrupted by
this bug).
There is a rather serious bug in cfs that causes it to throw away writes
when those writes append to the file, are smaller than the blocksize (8
bytes by default), and would otherwise leave the file a multiple of the
blocksize. In this situation, the file needs to be truncated (due to
the padding scheme in use), but cfs doesn't truncate and the file
appears unchanged after the write.
Patches have been sent to [EMAIL PROTECTED] and I submitted a
separate PR[1] to get the patch into ports until a new cfs release hits
the street. I've attached a copy of that patch since the readers of
this thread seem to be using cfs.
cheers,
--Scott
[1] http://www.FreeBSD.org/cgi/query-pr.cgi?pr=30120
--
Scott Renfro <[EMAIL PROTECTED]>
--- cfs_fh.c.orig Mon Aug 27 01:47:52 2001
+++ cfs_fh.cMon Aug 27 01:48:41 2001
@@ -177,6 +177,13 @@
perror("write");
return -1;
}
+ /* due to the way the file is padded we may actually have to
+ truncate it here. This happens when the write is at the end of
+ the file, is shorter than CFSBLOCK and brings the file to a length
+ which is evenly dividable by CFSBLOCK */
+ if (offset+len > dtov(sb.st_size) && vtod(offset+len) < sb.st_size) {
+ ftruncate(fd, vtod(offset+len));
+ }
/* iolen may contain CFSBLOCK extra chars */
return(dtov(iolen)-fronterr);
}
Re: Problems with Squid on 4.4-RC
On Mon, Aug 27, 2001 at 12:05:39PM +0300, Vladimir Terziev wrote: > > Hi hackers, > > I've cvsuped with release tag RELENG_4 and I've considered that I had > FreeBSD 4.4-RC. This is not a problem at all, but I've tried to install and > run Squid-2.4-STABLE1. It has installed sucsessfuly. I've run it, but when a > browser makes a request to it, the child which got the request exits with a > signal 6 (ABRT I think). > > Does anybody have an idea what is the reason? Are you using the www/squid24 port? G'luck, Peter -- If you think this sentence is confusing, then change one pig. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: installation problem
On Sun, Aug 26, 2001 at 11:35:49PM -0700, Rohit Panda wrote: > > hi , > > i was using linux and a great fan of it.Then i heard about this > wonderful OS called FreeBSD and wanted to try it out.i thought to install > it via FTP. My E: drive in my windows machine is the place where i want > to install FreeBSD(i have formatted my E: ,but iam getting the chance > to fdisk because Sysinstall is not running). But iam facing a problem > during installation.i have made the images of the kern.flp and mfsroot.flp > from windows using the utility fdimage.Then i booted from the kernel > image floppy .Everything goes fine and after that when i put the other > floppy and hit enter it says " zf_read:unexpected EOF ". Then it continues > with the kernel configuration.Once i teied to configure and the next time > i skipped,but after that comes the problem.after it probes it says Please wrap lines at 80 or less characters in the future. The problem you are seeing is most probably a corrupted floppy disk, or a corrupted image. Try writing the mfsroot.flp image to another disk, then if this fails, try downloading mfsroot.flp again. Oh, and btw, posting to freebsd-questions would have been *quite* enough :) G'luck, Peter -- This sentence claims to be an Epimenides paradox, but it is lying. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Problems with Squid on 4.4-RC
Hi hackers, I've cvsuped with release tag RELENG_4 and I've considered that I had FreeBSD 4.4-RC. This is not a problem at all, but I've tried to install and run Squid-2.4-STABLE1. It has installed sucsessfuly. I've run it, but when a browser makes a request to it, the child which got the request exits with a signal 6 (ABRT I think). Does anybody have an idea what is the reason? Vladimir To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
