samba problem
i'm not really sure if freebsd-hackers is the right place to ask this, so please feel free to redirect me to the correct place. situation: samba 2.0.6 (installed via /stand/sysinstall) on 3.4-stable smbd and nmbd start fine. testparm doesn't report and error w/ smb.conf. when _any_ kind of access attempt is made against the server, i get the following error in log.smb: [1999/12/24 00:05:44, 0] smbd/oplock.c:open_oplock_ipc(93) open_oplock_ipc: Failed to get local UDP socket for address 17f. Error was Can't assign requested address an smbclient -L SERVERNAME (per the samba troubleshooting docs) results in the following: added interface ip=XXX.XXX.XXX.16 bcast=XXX.XXX.XXX.63 nmask=255.255.255.192 session request to SERVERNAME failed (code 0) session request to *SMBSERVER failed (code 0) i tried removing then reinstalling samba, to no avail. i've searched the samba.org docs and mail archives and didn't find any relevant info. anyone have any suggestions? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: GLIDE for FreeBSD
+[ Theo van Klaveren ]- | | Whew. After two late nights of furious hacking, you | can now download the modified source for Glide 2.46 | (the Voodoo Graphics version) at | | ftp://phoenix.student.utwente.nl/pub/glide Ummm gcc -DPACKAGE=\"glide\" -DVERSION=\"2.46\" -DSTDC_HEADERS=1 -I. -I. -Wall -O6 -fomit-frame-pointer -funroll-loops -fexpensive-optimizations -ffast-math -DPORTIO_DIRECT -DMAPPL_LINUX -I../../lib/fxmisc -g -O2 -c fxlinux.c -o fxlinux.o /dev/null 21 mv -f .libs/fxlinux.lo fxlinux.lo gmake[2]: *** No rule to make target `../../lib/fxmisc/fxdll.h', needed by `fxpci.lo'. Stop. gmake[2]: Leaving directory `/home/users/akm/glide/glide-2.46/lib/fxpci' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/users/akm/glide/glide-2.46/lib' gmake: *** [all-recursive] Error 1 I'm lookin' now... -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Milton The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | ACN: 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: GLIDE for FreeBSD
+[ Theo van Klaveren ]- | On Fri, 24 Dec 1999, Andrew Kenneth Milton wrote: | | +[ Theo van Klaveren ]- | | | | Whew. After two late nights of furious hacking, you | | can now download the modified source for Glide 2.46 | | (the Voodoo Graphics version) at | | | | ftp://phoenix.student.utwente.nl/pub/glide | | Ummm | | Oops... forgot to add that header to the sources, so it didn't get | packages up with 'gmake dist'... | | To fix: Grab the new tarball or copy fxdll.h from the original glide | sources to lib/fxmisc. Will grab new tarball shortly... (at least you know someone's testing it). -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Milton The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | ACN: 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: samba problem
What does your smb.conf file look like? i'm not really sure if freebsd-hackers is the right place to ask this, so please feel free to redirect me to the correct place. situation: samba 2.0.6 (installed via /stand/sysinstall) on 3.4-stable smbd and nmbd start fine. testparm doesn't report and error w/ smb.conf. when _any_ kind of access attempt is made against the server, i get the following error in log.smb: [1999/12/24 00:05:44, 0] smbd/oplock.c:open_oplock_ipc(93) open_oplock_ipc: Failed to get local UDP socket for address 17f. Error was Can't assign requested address an smbclient -L SERVERNAME (per the samba troubleshooting docs) results in the following: added interface ip=XXX.XXX.XXX.16 bcast=XXX.XXX.XXX.63 nmask=255.255.255.192 session request to SERVERNAME failed (code 0) session request to *SMBSERVER failed (code 0) i tried removing then reinstalling samba, to no avail. i've searched the samba.org docs and mail archives and didn't find any relevant info. anyone have any suggestions? 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: samba problem
On Fri, Dec 24, 1999 at 02:08:37AM -0700, Jason Seidel wrote: What does your smb.conf file look like? [global] workgroup = SVJAVA server string = CLIPPER log file = /var/log/log.%m max log size = 50 security = user encrypt passwords = yes socket options = TCP_NODELAY dns proxy = no [homes] comment = Home Directories browseable = no writeable = yes To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SIGFPE on arithmetic overflow
On Fri, 24 Dec 1999 10:37:35 GMT, Ben Smithurst wrote:
Could somebody try this piece of code on a -STABLE machine, just out of
curiosity...?
I did, it gets SIGFPE too.
I think this boils down to my lack of understanding of IEEE floating
point arithmetic standards.
The following code behaves the same on every box I can find to test it
on. Although I'm surprised that the exception is INV instead of OFL, it
seems to be standard behaviour.
Ciao,
Sheldon.
#include ieeefp.h
#include stdio.h
void
do_weird(void)
{
double x;
int i;
printf("double x = 1e19; int i = (int)x\n");
x = 1e19;
i = (int)x;
printf("%d\n", i);
}
int
main(void)
{
printf("clearing fp exception mask\n");
(void)fpsetmask(0);
do_weird();
printf("setting fp exception mask to FP_X_OFL\n");
(void)fpsetmask(FP_X_OFL);
do_weird();
printf("setting fp exception mask to FP_X_INV\n");
(void)fpsetmask(FP_X_INV);
do_weird();
return 0;
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: PCMCIA-ATA/USB support for SanDisk/Digital Cameras
uhub0: 2 ports with 2 removable, self powered ugen0: SanDisk USB CFII, rev 1.00/0.05, addr 2 ugen_set_config: ugen0 to configno 1, sc=0xc0d82000 ugen_set_config: ifaceno 0 ugen_set_config: endptno 0, endpt=0x01(1,1), sce=0xc0d820cc ugen_set_config: endptno 1, endpt=0x02(2,1), sce=0xc0d82144 ugen_set_config: endptno 2, endpt=0x03(3,0), sce=0xc0d82180 Other than the above output, I don't seem to be able to talk to the device. /usr/sbin/usbdevs reports: # usbdevs -v usbdevs: no USB controllers found Hm, you should do a make world. Or a cd /usr/src/*/usbdevs make make install cd /dev/ sh MAKEDEV ugen0 usb0 usb usbdevs -v Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SIGFPE on arithmetic overflow
In [EMAIL PROTECTED], Sheldon Hearn wrote:
On Fri, 24 Dec 1999 10:37:35 GMT, Ben Smithurst wrote:
Could somebody try this piece of code on a -STABLE machine, just out of
curiosity...?
I did, it gets SIGFPE too.
I think this boils down to my lack of understanding of IEEE floating
point arithmetic standards.
The following code behaves the same on every box I can find to test it
on. Although I'm surprised that the exception is INV instead of OFL, it
seems to be standard behaviour.
The cast gets compiled into a fistpl instruction (surrounded by
control word manipulation), which is documented to set "invalid
operation", not "overflow".
Not knowing Intels reason (they may be more twisted), I think this
makes sense:
- The "overflow" execption is thrown for real floaing point overflow,
which - if it was not masked - had a meaningful result - the FPU
infinity value.
- The "invalid" execption is thrown in this case of "too big for
target integer type" because the result is undefined and in fact not
usable in any way. If the FPU would ensure that the result would be
the integer that approaches the former floating point value best
(INT_MAX), it could make sense to thow it into the same basket as
the floating operation (although not really, since that would
require an integer infinity value). Since it doesn't even attempt
to, but sets the result to complete nonsense, it choses to signal a
different kind of error.
This also shows why running such code with execptions enabled is
usually good, not bad. Turn off exceptions only when the code is know
to be aware of the effects.
If you port and fix such a packet, insett a test for INT_MAX before
the cast, don't kill the exceptions. That latter would make it
impossible to find the next occurance of this coding error.
More info on digging follows, partly repeating what you found out
already:
#include stdio.h
#include signal.h
volatile sig_atomic_t code;
void handler_siginfo(int sig, siginfo_t *info, void *nix)
{
code = info-si_code;
}
int
main(void)
{
double x;
int i;
struct sigaction act;
act.sa_sigaction = handler_siginfo;
act.sa_flags |= SA_SIGINFO;
sigemptyset(act.sa_mask);
sigaction(SIGFPE, act, NULL);
code = -1;
x = 1e19;
i = (int)x;
printf("%d\n", i);
if (code != -1)
fprintf(stderr, "Code: %d\n", code);
return 0;
}
Code 7 = "Subscript out of bounds". While this is not the direct error
value from the CPU (but the portable summary), you can tell that it's
not an overflow.
If you run th code with exceptions disabled, you can get the
statusword afterward the cast, you will find that bit one "Invalid
operation" has been set by the FPU. (You can't get the real status
word in a signal handler because you can't access the normal program
flow's state from inside the signal handler for now).
If you look at the code for the cast, it looks like this:
fldl -8(%ebp)
fnstcw -38(%ebp)
movw -38(%ebp),%ax
orw $3072,%ax
movw %ax,-40(%ebp)
fldcw -40(%ebp)
fistpl -12(%ebp) ; causes the exception
fldcw -38(%ebp) ; thowns the delayed exception
Intel documentation implies that fistpl throws "invalid operation",
although the manuals are not clear enough and omit this kind of error
from some tables of exceptions that looked complete.
Martin
--
%
Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/
BSD User Group Hamburg, Germany http://www.bsdhh.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: GLIDE for FreeBSD
+[ Theo van Klaveren ]- | | Whew. After two late nights of furious hacking, you | can now download the modified source for Glide 2.46 | (the Voodoo Graphics version) at Well it's working for me now, good work d8) -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Milton The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | ACN: 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SIGFPE on arithmetic overflow
Just a small addition to this thread: There seems to be a withstanding bug in Mozilla unique for the FreeBSD port, that seems to be quite related to this thread. It's about casting and SIGFPE's. Here's the link: http://bugzilla.mozilla.org/show_bug.cgi?id=9967 I don't know enough about these matters to be able to draw any conclusions, but anyone is of course welcome to take a look at the Mozilla bug, because it needs someone who knows this stuff. Markus On Thu, Dec 23, 1999 at 02:46:27PM -0800, Ronald F. Guilmette wrote: In message [EMAIL PROTECTED], you wrote: On Thu, 23 Dec 1999 17:14:55 GMT, David Malone wrote: Try adding a fpsetmask(fpgetmask()(~FP_X_OFL)); before the calculation and see what happens. It still bombs, although fpsetmask(0) does the trick. I'm really interested in hearing what causes the difference in behaviour. Sorry, I breezed past the first part of this thread too quickly, so I forgot which OS is doing what. However let me say that I do still have a copy of the IEEE floating point standard around here, and if anybody needs me to, I'll be happy to look stuff up in it, and/or to cite chapter and verse. The bottom line, I think, is that the IEEE FP standard talks about two things of interest here... exceptions and traps. An exception is just some condition that probably only arises infrequently (e.g. overflow, divide by zero, and other such stuff). An exception may or may not cause a trap. A trap is one possible response to an exception, and can be thought of as being essentially the same sort of thing as a (non-blocked) UNIX signal. Anyway, to bring this back to the topic at hand, the relevant quote from IEEE Std 754-1985 (Section 7, paragraph 1) is: ``The default response to an exception shall be to proceed without a trap.'' In other words, for a conforming implementation of IEEE 754, unless you explicitly override the default behavior (e.g. with a call to fpsetmask) exceptions (including FP overflow) SHOULD NOT cause a trap. I should say however that back when I was doing compiler testing for a living... a few eons ago... this was something that a lot of implementa- tions did seem to screw up Many compiler/library/OS combinations would invoke main() with one or more of the IEEE FP exceptions set to cause a trap/signal (in violation of IEEE 754). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- Markus Holmberg | Give me UNIX or give me a typewriter. [EMAIL PROTECTED]| http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re:Re: Code
On Wed, 22 Dec 1999, Kip Macy wrote: Typically it refers to moving a process and all its associated attributes from one machine to another. There are a lot of problems with it, to the best of my knowledge the only OS that ever managed to get it right was Berkeley's Elf which was designed with it in mind from the beginning. Osterhout, the professor heading the group, said afterwords that the costs exceeded the gains. Was Elf related to Sprite? Jamie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What's the best accellerated graphics card for XF86?
On Fri, Dec 24, 1999 at 12:58:34AM +0100, Theo van Klaveren wrote: On Thu, 23 Dec 1999 [EMAIL PROTECTED] wrote: On 23 Dec, Joe McGuckin wrote: Now tha GLIDE for FreeBSD is available, what's the best video card for playing quake, etc? Well, since GLIDE only support 3DFX cards, I'd say your choice is pretty limited :) Besides that, the port I've done only supports the (now ancient) Voodoo Graphics based cards. For Voodoo2/3, look at Doug Rabson's patches to the original source code. GLX works pretty good with my g400 max, It get 37.4 fps at 640x480 Normal settings with quake3. And, who is going to build us a FreeBSD Quake 1, now that the source is out! Sorry, I only got as far as the server so far :-) I've built glquake but I still has some bugs to work out. The X11 client built, but there is a bug in Quake's assembly code (methinks) that produces a SIGBUS in memset() ... haven't investigated thourougly(sp?) yet. I'll try and build the GL client, but I haven't got high hopes... If anyone is intersted, I can give you my patches to the QuakeWorld code (it fixes the Linux CDROM code and some other Linux specific thingies). See above, the gl code was actually pretty easy on a first pass sort of thing. (Notice I'm not saying it's usable yet.) Theo van Klaveren [EMAIL PROTECTED] http://phoenix.student.utwente.nl / ICQ #1353681 - Why, oh why didn't I take the _blue_ pill? -Charlie -- Charles Anderson[EMAIL PROTECTED] No quote, no nothin' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
