Re: Pcmcia support
> Why can't the PAO changes be committed to the main source tree? It would > be nice if I could just install the latest version of FreeBSD from > the Walnut Creek CD-ROM as is and have PCMCIA and APM support on my Yes, it would be nice. To make a long story short (and emotionless) there are integration problems which prevent this and I think that's about as much summary information as I need to state here. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Pcmcia support
Why can't the PAO changes be committed to the main source tree? It would be nice if I could just install the latest version of FreeBSD from the Walnut Creek CD-ROM as is and have PCMCIA and APM support on my laptop without always having to wait for Hosokawa. I asked about this previously and received a disappointingly emotional and uninformative response. On Sat, 29 May 1999, Doug White wrote: > On Sat, 29 May 1999, Forrest Aldrich wrote: > > > I'm still at 3.2; however, I wonder what plans there are (if any) to have > > pcmcia > > support in 4.x (like the 3com 3c574, etc). Might be a good idea to include > > a pcmcia floppy in the installation media (like Linux already has). > > Someone has never discovered PAO, apparently. > > Doug White > Internet: dwh...@resnet.uoregon.edu| FreeBSD: The Power to Serve > http://gladstone.uoregon.edu/~dwhite| www.freebsd.org > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Pcmcia support
On Sat, 29 May 1999, Forrest Aldrich wrote: > I'm still at 3.2; however, I wonder what plans there are (if any) to have > pcmcia > support in 4.x (like the 3com 3c574, etc). Might be a good idea to include > a pcmcia floppy in the installation media (like Linux already has). Someone has never discovered PAO, apparently. Doug White Internet: dwh...@resnet.uoregon.edu| FreeBSD: The Power to Serve http://gladstone.uoregon.edu/~dwhite| www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Pcmcia support
I'm still at 3.2; however, I wonder what plans there are (if any) to have pcmcia support in 4.x (like the 3com 3c574, etc). Might be a good idea to include a pcmcia floppy in the installation media (like Linux already has). Thanks. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: libgcc
On Sat, 29 May 1999, John Polstra wrote: > In article , > Chuck Robey wrote: > > > I thought libgcc was being deprecated, isn't that so? That only > > libstdc++ was going to be needed? > > No, I think you're confusing libgcc with libg++. Yeah, guess you're right, I was. OK, thanks. > > John > -- > John Polstra j...@polstra.com > John D. Polstra & Co., Inc.Seattle, Washington USA > "Self-interest is the aphrodisiac of belief." -- James V. DeLong > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: libgcc
In article , Chuck Robey wrote: > I thought libgcc was being deprecated, isn't that so? That only > libstdc++ was going to be needed? No, I think you're confusing libgcc with libg++. John -- John Polstra j...@polstra.com John D. Polstra & Co., Inc.Seattle, Washington USA "Self-interest is the aphrodisiac of belief." -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
libgcc
I've got an egcs related question here. If it wasn't for the linking, this would be a ports question, but bear with me, you'll see. Anyhow, I was trying to get sp to work, as I continue checking into xml and xsl, so I used the /usr/ports/textproc/sp port. It dies in several places, because it's unable to find the symbol "set_new_handler". This guy is defined in new.h (which points towards "new", which has the very simple code for it). The problem is, the code for it is stuffed into libgcc.a. I thought libgcc was being deprecated, isn't that so? That only libstdc++ was going to be needed? This is a pretty well needed function, so I'm somewhat confused, and hope that some other C++ expert can explain what's happening under egcs these days, with respect to libgcc. +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Announcing a new cvsup server - cvsup6.freebsd.org
On Fri, May 28, 1999 at 02:44:58PM -0700, Jordan K. Hubbard wrote: > A florida ISP recently donated a T3 connection and a beefy SMP box to > us, so I took advantage of this to create another cvsup mirror which > allows up to 32 connections. Folks are encouraged to use this site > in preference to some of our more loaded cvsup servers (like cvsup1 > and cvsup2) and it updates from freefall once an hour, so the > bits are nice and fresh. :) FYI.. cvsup5.freebsd.org (2xXeon, also wearing the hat of cvsup4) is also still not at capacity and welcomes anyone in need of CVSup services, updates are also hourly from freefall. Cheers, Chris -- Christian Kuhtz, Sr. Network ArchitectBellSouth Corporation -wk, -hmAdvanced Data Services "Affiliation given for identification, not representation." Atlanta, GA, U.S. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: pcm for SB 128 PCI in -current is broken...
On 29-May-99 Osokin Sergey wrote: > > Hello! > pcm driver for SB 128 PCI in -current is broken... ># dmesg | more > . > es0: irq 5 at device 11.0 on pci0 > pcm0: using I/O space register mapping at 0xe800 > > > play, waveplay, wmsound dont' work correct. > Does someone have any idea? > And when it fixed? That's odd, working here! I just built world and the kernel about an hour ago. A few random thoughts.. did you set the mixer volumes? do you have the right entries in /dev (snd0 in current)? when was this last working? are there any error messages? *Happily playing a wav with waveplay* --- Chris PiazzaAbbotsford, BC, Canada cpia...@home.net finger n...@norn.ca.eu.org for PGP key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: NFS diskless on -current
Mark Newton writes:
| I tried to upgrade my diskless router this afternoon to -current as
| cvsupped last night.
|
| I can't make it boot, though.
|
| It now panics with "Can't mount root" when I boot it. And yes, I have
| updated the kernel config for new-bus.
|
| I noticed the BOOTP stuff in LINT, but that's been there for a while and
| I've never needed to use it before. I turned it on anyway just to see
| what happens, but tcpdump doesn't show it sending any bootp requests.
I have a fix for you based on the MFS mount root problem! Note it is
a best guess and works for me. It seems rootdev needs to be defined
or it ignores trying to mount it. I ran into this a couple of days
ago.
Doug A.
Index: bootp_subr.c
===
RCS file: /cvs/freebsd/src/sys/nfs/bootp_subr.c,v
retrieving revision 1.19
diff -c -r1.19 bootp_subr.c
*** bootp_subr.c1999/01/27 23:45:39 1.19
--- bootp_subr.c1999/05/29 16:52:14
***
*** 1043,1048
--- 1043,1049
panic("nfs_boot: lookup swap, error=%d", error);
}
nfs_diskless_valid = 3;
+ rootdev = makedev(255,0);
}
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
pcm for SB 128 PCI in -current is broken...
Hello! pcm driver for SB 128 PCI in -current is broken... # dmesg | more . es0: irq 5 at device 11.0 on pci0 pcm0: using I/O space register mapping at 0xe800 play, waveplay, wmsound dont' work correct. Does someone have any idea? And when it fixed? Rgdz, Osokin Sergey aka oZZ, o...@etrust.ru To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FP exceptions broken (Re: Interesting bogons from last night's 4.0 snapshot.)
>>> JFYI - don't want us getting *too* complacent with -current now, do we? :-) >> >>Floating point exceptions are also broken, they always behave like >>masked, even if you unmask some explicitly with fpsetmask(). >> >>Even worse, a wrong result is returned if an exception had to be >>thrown, while the result is right for masked exceptions. > >This seems to have fixed itself: > >May 23 kernel: fails >May 24 kernel: works >May 28 kernel: works Actually, it works on a Celeron but fails on a P5. This is caused by the following bug suite (in approximately historical order): 1) IRQ13 interface was broken as designed. 2) Intel F00F bug. 3) Probe for (1) is not very well implemented. It hacks on the idt[] global to context switch some IDT entries. 4) Fix for (2) is not very well implemented. It moves the IDT without hiding idt[] from (3). 5) Rev.1.55 of disturbed the probe order so that (4) is done before (3). This breaks the IDT context switching if the F00F fix gets installed. npx traps and interrupts end up being serviced by the dummy probe routines. The easiest fix is to change the probe order. The F00F fix should never have been attached to proc0 initialisation. Bruce To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: splash screen broken??
Dag-Erling Smorgrav writes: > ENODEV from splash_bmp can also mean that no image is loaded, or that > the image is invalid. Specifically, splash_bmp will return ENODEV if one of the following holds: - no image is loaded - the image data has a negative length (!) - the first two bytes are not 0x4d42 - the compression format is not RGB, RLE4 or RLE8 - the image size and / or color depth does not match any supported mode (320x200, 640x480, 800x600 or 1024x768 in 8-bit color) DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: savecore too (Re: kvm_getswapinfo is broken)
In message <199905291221.waa28...@godzilla.zeta.org.au>, Bruce Evans writes: >>Just found that savecore is broken in the same way. What is proper >>procedure to fix it? I.e. is it must be fixed in the kernel, leaving >>userland programs as is or in userland, leaving kernel as is? > >The kernel needs to maintain (or create as necessary for return by >sysctl()) udev_t versions of most (all?) device numbers that are accessed >in userland. I think the proper way to do this will be to maintain a >udev_t for each dev_t in the kernel too. udev_t should be named dev_t, >the current dev_t should be named something like kdev_t and should be >a pointer to a struct containing the (user) dev_t. The kernel needs >something like this for fast conversions in old interfaces like stat(2). ... But since renaming dev_t in the kernel will totally hose all device driver writers, we don't rename it, but suffer the trouble of the overloaded name. The structure thing will happen RSN. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: kldload (module parameters ??)
On Sat, 29 May 1999, Nicolai Petri wrote: > Would it be possible and wise to implement a way to pass parameters to > modules when they are loaded ?? Like "kldload if_olp -recv_debug" ? Use sysctl for this. -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | win...@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FP exceptions broken (Re: Interesting bogons from last night's 4.0 snapshot.)
>> JFYI - don't want us getting *too* complacent with -current now, do we? :-) > >Floating point exceptions are also broken, they always behave like >masked, even if you unmask some explicitly with fpsetmask(). > >Even worse, a wrong result is returned if an exception had to be >thrown, while the result is right for masked exceptions. This seems to have fixed itself: May 23 kernel: fails May 24 kernel: works May 28 kernel: works For the failing case, the FPU seems to be working properly but no CPU exception 16 is received for the unmasked FPU exception, and CR0_TS is in an unusualy state (not set) at the end of another test program. Bruce To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: savecore too (Re: kvm_getswapinfo is broken)
>Just found that savecore is broken in the same way. What is proper >procedure to fix it? I.e. is it must be fixed in the kernel, leaving >userland programs as is or in userland, leaving kernel as is? The kernel needs to maintain (or create as necessary for return by sysctl()) udev_t versions of most (all?) device numbers that are accessed in userland. I think the proper way to do this will be to maintain a udev_t for each dev_t in the kernel too. udev_t should be named dev_t, the current dev_t should be named something like kdev_t and should be a pointer to a struct containing the (user) dev_t. The kernel needs something like this for fast conversions in old interfaces like stat(2). Bruce To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
FP exceptions broken (Re: Interesting bogons from last night's 4.0 snapshot.)
In <17751.927941...@zippy.cdrom.com>, Jordan K. Hubbard wrote:
[...]
> JFYI - don't want us getting *too* complacent with -current now, do we? :-)
Floating point exceptions are also broken, they always behave like
masked, even if you unmask some explicitly with fpsetmask().
Even worse, a wrong result is returned if an exception had to be
thrown, while the result is right for masked exceptions.
#include
#include
#include
int main(void)
{
fpsetmask(0);
fprintf(stderr, "I want no exception, but an exception value\n");
fprintf(stderr, "res: %g\n", atof("1.0") / atof("0.0"));
fpsetmask(FP_X_INV|FP_X_DNML|FP_X_DZ|FP_X_OFL|FP_X_UFL);
fprintf(stderr, "I want an exception. Or at least an exceptional value\n");
fprintf(stderr, "res: %g\n", atof("1.0") / atof("0.0"));
fprintf(stderr, "I didn't get one!\n");
return 0;
}
output on -current:
I want no exception, but an exception value
res: Inf
I want an exception. Or at least an exception value
res: 1
I didn't get one!
output on anything else:
I want no exception, but an exception value
res: Inf
I want an exception. Or at least an exception value
Floating point exception (core dumped)
Martin
--
%
Martin Cracauer http://www.cons.org/cracauer/
Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: NFS diskless on -current
>I'm obviously missing something really stupid. Would anyone care to >educate me about changes to diskless booting with NFS root filesystems >since February 24? rootdev is now correctly initialised to NODEV, but vfs_mountrootfs() still uses NODEV to terminate the list of root devices to try. Bruce To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FTP passive mode - a new default?
"Jordan K. Hubbard" writes:
> My only point was that you should make sure something is a certain way
> before you offer advice for dealing with its *current* behavior since,
> otherwise, that's just confusing to everyone. Either way, I don't
> think that *any* of the current sources, from libfetch to libftpio,
> are currently doing anything "right" with FTP_PASSIVE_MODE and hence
> this debate is also 100% academic for the time being. :-)
So let's *make* them Do The Right Thing. That's what commit privs are
for, after all.
d...@des ~$ stable FTP_PASSIVE_MODE
src/lib/libfetch/ftp.c: #define FTP_PASSIVE_MODE227
src/lib/libfetch/ftp.c: if ((e = _ftp_cmd(cf, "PASV" ENDL)) !=
FTP_PASSIVE_MODE)
src/lib/libftpio/ftpio.3: .Bl -tag -width FTP_PASSIVE_MODE -offset 123
src/lib/libftpio/ftpio.3: .It Ev FTP_PASSIVE_MODE
src/lib/libftpio/ftpio.c: if (getenv("FTP_PASSIVE_MODE"))
src/usr.bin/fetch/fetch.1: .Bl -tag -width FTP_PASSIVE_MODE -offset indent
src/usr.bin/fetch/fetch.1: .It Ev FTP_PASSIVE_MODE
src/usr.bin/ftp/ftp.1: .Bl -tag -width "FTP_PASSIVE_MODE"
src/usr.bin/ftp/ftp.1: .It Ev FTP_PASSIVE_MODE
src/usr.bin/ftp/main.c: if (getenv("FTP_PASSIVE_MODE") || strcmp(cp,
"pftp") == 0)
src/usr.sbin/pkg_install/add/pkg_add.1: FTP_PASSIVE_MODE
Looks like ftpio(3) and ftp(1) both Do The Wrong Thing. Should be
trivial to fix, but I have a train to catch right now :)
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: FTP passive mode - a new default?
Ollivier Robert writes: > According to Dag-Erling Smorgrav: > > FTP servers which do not accept passive mode are, IMHO, broken. Their > They're broken with respect to RFC-959, not only to your opinion :-) No. Allowable responses to the PASV command include 227 (Entering passive mode), 500 (Unrecognized command), 501 (Invalid parameters), 502 (Command not implemented), 421 (Service not available), and 530 (Not logged in). A server which does not wish to allow passive mode can thus choose to acknowledge the command but refuse to obey it (502), or to reject the command altogether (500). DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: splash screen broken??
Mike Smith writes: > > module_register_init: MOD_LOAD (splash_bmp, c028162c, 0) error 19 > That's what we needed to see. Error 19 is ENODEV; this means you > either don't have VESA support compiled in, haven't loaded the VESA > module, or your VESA BIOS doesn't support a mode that allows > a 300x200x8 image to be displayed. 320x200x8 has nothing to do with VESA. If no VESA modes are available, splash_bmp falls back to M_VGA_CG320, which should be available on all VGA compatible frame buffers. ENODEV from splash_bmp can also mean that no image is loaded, or that the image is invalid. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: kvm_getswapinfo is broken
"Andrey A. Chernov" writes: > Just check 'swapinfo' in recent -current, it shows "/dev/(null)" as swap > device, it means that devinfo() call in kvm_getswapinfo() returns NULL, > i.e. called with wrong argument which is swinfo.sw_dev Other interesting swapinfo(8) behaviour: root(yeshs-3)--# uname -a FreeBSD yeshs-3.yes.no 3.1-19990505-STABLE FreeBSD 3.1-19990505-STABLE #1: Wed May 19 01:13:59 CEST 1999 r...@yeshs-3.yes.no:/usr/src/sys/compile/YESHS i386 root(yeshs-3)--# swapinfo Device 1K-blocks UsedAvail Capacity Type /dev/od0b 5242880 524160 0%Interleaved /dev/da1b 5242880 524160 0%Interleaved /dev/da2b 5242880 524160 0%Interleaved Total 15724800 1572480 0% (before you ask - no, this machine does *not* swap to a magneto- optiocal disk, and magneto-optical devices aren't named od any more) DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
kldload (module parameters ??)
Would it be possible and wise to implement a way to pass parameters to modules when they are loaded ?? Like "kldload if_olp -recv_debug" ? - Nicolai Petri n...@swamp.dk To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
