Re: the ifp to a removed pcmcia ethernet card is left in struct ip_moptions and struct ifmultiaddr
Seigo Tanimura wrote: I have been suffering from this problem for almost 2 months. When I remove a pcmcia ethernet card from my laptop PC, routed(8) announces updated routing information by multicast, leading to a kernel panic. Ejecting an interface configured up will do that. ifconfig the interface `down' and then `delete' before ejecting it. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: the ifp to a removed pcmcia ethernet card is left in struct ip_moptions and struct ifmultiaddr
In message [EMAIL PROTECTED] Wes Peters writes: : Ejecting an interface configured up will do that. ifconfig the interface : `down' and then `delete' before ejecting it. At best this is an unsatisfactory workaround. if_detach should cause the right thing to happen. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: xl driver
On Mon, Sep 04, 2000 at 05:38:11PM +0900, Mitsuru IWASAKI wrote: This happened to me when I turned on ACPI support - infact it thought I had 3 PCI busses when I only had one! I haven't had time to look into it yet though. Hmmm, can I have your full output of dmesg? It seemed to be some combination of the acpi support and Peter's PCI changes. It didn't use ACPI the kernel worked fine and with ACPI support it thought it had 3 PCI busses. I cvsupped a more recent version of the code and now everything works but my ISA network card. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sshd (Re: cvs commit: src/release/sysinstall config.c)
Jordan Hubbard wrote: This will be semi-broken for the next 17 days for US people because sshd won't work out of the box if you have "Protocol 1" defined, which is in the default config (and removing it may surprise people upgrading) Well, it's at least one step closer - all they have to do now (the US people) is install the rsaref port to have the already-running sshd work correctly post-install, correct? Besides, that's what we mean when we say -current is the "bleeding edge". :-) -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] OK, so the solar flares are my fault.. I am sorry, ok?!?! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
problems with aureal soundcard: kernel fault when playing mp3s
[Alexander, I'm Cc:ing you on this just in case you have heard of anyone else having similar problems with Aureal cards with recent -currents] My last good kernel was from aug 14. On a kernel from 09/05, I get a page fault as soon as I try to play mp3s using mpg123. Note that I have an Aureal Vortex 8830, so I have to use the linux drivers to get the device working (http://www.cis.ohio-state.edu/~matey/au88x0/) so this might just be a problem with interactions between the linux .o files and kernel data structures. The soundcard worked fine using the linux drivers on a -current from August 14. I'm wondering if anything changed in the pcm code since then. Here's the page fault in DDB. I have a debug kernel if anyone needs more info. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x101b fault code= supervisor read, page not present instruction pointer = 0x8:0xc016ef23 stack pointer = 0x10:0xd2a4dc98 frame pointer = 0x10:0xd2a4dc98 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 825 (mpg123) interrupt mask= none kernel: type 12 trap, code=0 Stopped at fmtvalid+0xb: cmpl $0,0(%edx) dbtrace fmtvalid(8,101b,c1599000) at fmtvalid+0xb chn_setformat(c1599000,8) at chn_setformat+0x4c chn_reset(c1599000,8,d2a90740,c155f600,d2a4be00) at chn_reset+0x37 dsp_open(c14fe400,0,2,3,0) at dsp_open+0x12b sndopen(c155f600,2,200,d2a4be00,0) at sndopen+0x73 spec_open(d2a4dd94,d2a4dd68,c0264675,d2a4dd94,d2a4de08) at spec_open+0x145 spec_vnoperate(d2a4dd94,d2a4de08,c01cdf6b,d2a4dd94,d2a4df80) at spec_vnoperate+0x15 ufs_vnoperatespec(d2a4dd94,d2a4df80,0,d2a4df80,2) at ufs_vnoperatespec+0x15 vn_open(d2a4de6c,d2a4de38,1,d2a4be00,3) at vn_open+0x333 open(d2a4be00,d2a4df80,bfbffa30,807e8a4,807b4f8) at open+0xcd syscall2(2f,2f,2f,807b4f8,807e8a4) at syscall2+0x1f1 Xint0x80_syscall() at Xint0x80_syscall+0x25 db Here's my dmesg from the kernel that produced the above page fault: Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Tue Sep 5 09:07:19 EDT 2000 root@jabberwock:/home/FreeBSD/src/sys/compile/VORPAL Calibrating clock(s) ... TSC clock: 797903726 Hz, i8254 clock: 1193093 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method Timecounter "TSC" frequency 797966473 Hz CPU: Pentium III/Pentium III Xeon/Celeron (797.97-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,XMM real memory = 402391040 (392960K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x003e3000 - 0x17fb7fff, 398282752 bytes (97237 pages) avail memory = 387465216 (378384K bytes) bios32: Found BIOS32 Service Directory header at 0xc00fda60 bios32: Entry = 0xfda74 (c00fda74) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xda95 pnpbios: Found PnP BIOS data at 0xc00f2c10 pnpbios: Entry = f:24ca Rev = 1.0 Other BIOS signatures found: Preloaded elf kernel "kernel" at 0xc03ca000. nulldev: null device, zero device random: entropy source mem: memory I/O Pentium Pro MTRR support enabled Creating DISK md0 md0: Malloc disk npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard pci0: physical bus=0 found- vendor=0x8086, dev=0x2501, revid=0x04 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[10]: type 3, range 32, base f800, size 26, enabled found- vendor=0x8086, dev=0x250f, revid=0x04 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 subordinatebus=1secondarybus=1 found- vendor=0x8086, dev=0x2418, revid=0x02 bus=0, slot=30, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 subordinatebus=2secondarybus=2 found- vendor=0x8086, dev=0x2410, revid=0x02 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 found- vendor=0x8086, dev=0x2411, revid=0x02 bus=0, slot=31, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[20]: type 4, range 32, base ffa0, size 4, enabled found- vendor=0x8086, dev=0x2412, revid=0x02 bus=0, slot=31, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=d, irq=10 map[20]: type 4, range 32, base ef80, size 5, enabled found- vendor=0x8086, dev=0x2413, revid=0x02
Re: the ifp to a removed pcmcia ethernet card is left in struct ip_moptions and struct ifmultiaddr
Warner Losh wrote: In message [EMAIL PROTECTED] Wes Peters writes: : Ejecting an interface configured up will do that. ifconfig the interface : `down' and then `delete' before ejecting it. At best this is an unsatisfactory workaround. if_detach should cause the right thing to happen. Right, but as we've discussed before, that may not be possible with PCCard and CardBus, or anything else short of CPCI. In the meantime, this is the state the code is in now, and if someone wants it to be better, we await their patches. As always. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problems with aureal soundcard: kernel fault when playing mp3s
At Tue, 5 Sep 2000 10:32:21 -0400 (EDT), Viren R.Shah [EMAIL PROTECTED] wrote:
[Alexander, I'm Cc:ing you on this just in case you have heard of
anyone else having similar problems with Aureal cards with recent
-currents]
My last good kernel was from aug 14. On a kernel from 09/05, I get a
page fault as soon as I try to play mp3s using mpg123.
Note that I have an Aureal Vortex 8830, so I have to use the linux
drivers to get the device working
(http://www.cis.ohio-state.edu/~matey/au88x0/) so this might just be a
problem with interactions between the linux .o files and kernel data
structures. The soundcard worked fine using the linux drivers on a
-current from August 14. I'm wondering if anything changed in the pcm
code since then.
Here's the page fault in DDB. I have a debug kernel if anyone needs
more info.
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x101b
fault code= supervisor read, page not present
The pcm interfaces did change. The following patch fixes the au88x0
driver for me.
Cheers,
-Peter S. Housel- [EMAIL PROTECTED] http://members.home.com/housel/
--- au88x0.cFri May 26 22:12:56 2000
+++ /usr/src/sys/dev/sound/pci/au88x0.c Mon Sep 4 23:17:05 2000
@@ -200,17 +200,23 @@
static int auchan_getptr(void *data);
static pcmchan_caps *auchan_getcaps(void *data);
-static pcmchan_caps au_playcaps = {
- 4000, 48000,
- AFMT_STEREO | AFMT_MU_LAW | AFMT_A_LAW | AFMT_U8 | AFMT_S16_LE,
- AFMT_STEREO | AFMT_S16_LE
+static u_int32_t au_playfmt[] = {
+ AFMT_U8,
+ AFMT_STEREO | AFMT_U8,
+ AFMT_S16_LE,
+ AFMT_STEREO | AFMT_S16_LE,
+ 0
};
+static pcmchan_caps au_playcaps = {4000, 48000, au_playfmt, 0};
-static pcmchan_caps au_reccaps = {
- 4000, 48000,
- AFMT_STEREO | AFMT_MU_LAW | AFMT_A_LAW | AFMT_U8 | AFMT_S16_LE,
- AFMT_STEREO | AFMT_S16_LE
+static u_int32_t au_recfmt[] = {
+ AFMT_U8,
+ AFMT_STEREO | AFMT_U8,
+ AFMT_S16_LE,
+ AFMT_STEREO | AFMT_S16_LE,
+ 0
};
+static pcmchan_caps au_reccaps = {4000, 48000, au_recfmt, 0};
static pcm_channel au_chantemplate = {
auchan_init,
@@ -221,6 +227,14 @@
auchan_trigger,
auchan_getptr,
auchan_getcaps,
+ NULL, /* free */
+ NULL, /* nop1 */
+ NULL, /* nop2 */
+ NULL, /* nop3 */
+ NULL, /* nop4 */
+ NULL, /* nop5 */
+ NULL, /* nop6 */
+ NULL, /* nop7 */
};
@@ -232,6 +246,7 @@
static snd_mixer au_mixtemplate = {
"Aureal Vortex 88x0 mixer",
aumix_init,
+ NULL,
aumix_set,
aumix_setrecsrc,
};
@@ -846,7 +861,7 @@
au_mixer = (snd_mixer *)malloc(sizeof(*au_mixer), M_DEVBUF, M_NOWAIT);
if (au_mixer == NULL) goto bad;
bcopy(au_mixtemplate, au_mixer, sizeof(au_mixtemplate));
- mixer_init(d, au_mixer, au);
+ mixer_init(dev, au_mixer, au);
if (bus_dma_tag_create(/*parent*/NULL, /*alignment*/2, /*boundary*/0,
/*lowaddr*/BUS_SPACE_MAXADDR_32BIT,
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: DPT SmartRAID V, VI, Adaptec SCSI RAID driver committed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 4 Sep 2000, Mike Smith wrote: I'd like to hear a few more success stories first (only one so far) from people using the kit to add the driver to their 4.x systems. With all the breakage in -current's PCI support at the moment, I don't expect to hear too many people there reporting on it just yet. Maybe I missed it... Where is the kit? I would be happy to install and stress test a machine or two with SMP and without, just didn't realize there was a kit ;) must have been when I was reading my e-mail at like 3 am or something Visigoth Damieon Stark Sr. Unix Systems Administrator [EMAIL PROTECTED] PGP Public Key: www.telemere.net/~visigoth/visigoth.asc | M$ -Where do you want to go today? | Linux -Where do you want to go tomorrow?| FreeBSD - The POWER to serve Freebsd -Are you guys coming or what? | http://www.freebsd.org | | - -BEGIN PGP SIGNATURE- Version: PGP 6.5.1i iQA/AwUBObUEmznmC/+RTnGeEQJqLwCgnnbsnbIEW38ATtBTo387XpMf5ZUAnRY5 a7gzxWhBc0xI3JkQyFtweCRI =3TRp -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: the ifp to a removed pcmcia ethernet card is left in struct ip_moptions and struct ifmultiaddr
In message [EMAIL PROTECTED] Wes Peters writes: : state the code is in now, and if someone wants it to be better, we await : their patches. As always. ;^) Tanimura-san did contribute patches. This problem isn't a race at the eject, but rather the network layer incompletely cleaning up after a device has gone away. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FIFOs select: what about our implementation?
Consider this comment comes from screen(1):
/*
* Define this if your system exits select() immediatly if a pipe is
* opened read-only and no writer has opened it.
*/
#define BROKEN_PIPE 1
We have broken(?) pipe, according to this statement. At least, we have
select return code -1 with wrong errno == 0.
I attach the test for it below. The question is: what about our fifo
select (actually poll) implementation? Is it really broken, or is it a
feature? What standards says? If this is a feature, at least errno must be
fixed.
-
#include stdio.h
#include sys/types.h
#include fcntl.h
#include sys/time.h
#include sys/stat.h
char *fin = "/tmp/conftest$$";
main()
{
struct timeval tv;
int r, x;
unlink(fin);
if (mkfifo(fin, 0600))
exit(1);
close(0);
if (open(fin, O_RDONLY|O_NONBLOCK))
exit(1);
r = 1;
tv.tv_sec = 1;
tv.tv_usec = 0;
if (select(1, r, 0, 0, tv)) {
perror("select");
exit(1);
}
exit(0);
}
-
--
Andrey A. Chernov
[EMAIL PROTECTED]
http://ache.pp.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: FIFOs select: what about our implementation?
On Tue, Sep 05, 2000 at 07:50:56PM +0400, Andrey A. Chernov wrote: Consider this comment comes from screen(1): /* * Define this if your system exits select() immediatly if a pipe is * opened read-only and no writer has opened it. */ #define BROKEN_PIPE 1 We have broken(?) pipe, according to this statement. At least, we have select return code -1 with wrong errno == 0. qmail calls this 'named pipe bug 1'. The workaround (which screen probably uses too) is to let the process doing the select() also have one fd opened for writing on the pipe. With that write-open, select() will only return if there is actual data waiting inside the pipe. I have filed a PR (19871) for this I think about 2 months ago, somebody submitted a patch but I never gotten around to testing it. I surely do think this behaviour is broken. http://www.freebsd.org/cgi/query-pr.cgi?pr=19871 Greetz, Peter -- dataloss networks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DPT SmartRAID V, VI, Adaptec SCSI RAID driver committed
I'd like to hear a few more success stories first (only one so far) from people using the kit to add the driver to their 4.x systems. With all the breakage in -current's PCI support at the moment, I don't expect to hear too many people there reporting on it just yet. Maybe I missed it... Where is the kit? I would be happy to install and stress test a machine or two with SMP and without, just didn't realize there was a kit ;) must have been when I was reading my e-mail at like 3 am or something http://people.freebsd.org/~msmith/RAID/index.html#dpt -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: DPT SmartRAID V, VI, Adaptec SCSI RAID driver committed
At 11:25 AM -0700 2000/9/5, Mike Smith wrote: http://people.freebsd.org/~msmith/RAID/index.html#dpt Awesome! Thanks! Now I just have to get FreeBSD 4.2 installed on that ftp server -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, [EMAIL PROTECTED]|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: the ifp to a removed pcmcia ethernet card is left in struct ip_moptions and struct ifmultiaddr
On Tue, 5 Sep 2000, Warner Losh wrote: In message [EMAIL PROTECTED] Wes Peters writes: : Ejecting an interface configured up will do that. ifconfig the interface : `down' and then `delete' before ejecting it. At best this is an unsatisfactory workaround. if_detach should cause the right thing to happen. This is all made harder by the fact that struct mbuf has a struct ifnet pointer in it, so if for any reason there is an outstanding mbuf originating from that interface, it is possible that the struct ifnet * will be dereferenced. For example, if it hits an ipfw rule that dummynets it, then hits an interface-based rule. This has been raised as an issue before, and is a good reason to ifconfig down the interface, and wait a second or two before ejecting. You could imagine code-based solutions, including scanning mbufs (?) for pointers that are undesirable, refcounting the struct ifnet so it isn't freed until all mbufs are free'd, etc. Whatever the case, you want to make sure that locking in the line of fire is avoided (i.e., attempting to lock struct ifnet during packet handling in the interrupt). Robert N M Watson [EMAIL PROTECTED] http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: the ifp to a removed pcmcia ethernet card is left in struct ip_moptions and struct ifmultiaddr
In message [EMAIL PROTECTED] Robert Watson writes: : This is all made harder by the fact that struct mbuf has a struct ifnet : pointer in it, so if for any reason there is an outstanding mbuf : originating from that interface, it is possible that the struct ifnet * : will be dereferenced. For example, if it hits an ipfw rule that dummynets : it, then hits an interface-based rule. Yes. That's true. There's a race. : This has been raised as an issue before, and is a good reason to ifconfig : down the interface, and wait a second or two before ejecting. You could : imagine code-based solutions, including scanning mbufs (?) for pointers : that are undesirable, refcounting the struct ifnet so it isn't freed until : all mbufs are free'd, etc. Whatever the case, you want to make sure that : locking in the line of fire is avoided (i.e., attempting to lock struct : ifnet during packet handling in the interrupt). No body waits :-(. This is made worse by pccard's detaching the device when a suspend happens via acpi or apm. NetBSD has done some interesting things in this area with reference counting and such that I'd love to bring in as soon as I get newcard done. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: the ifp to a removed pcmcia ethernet card is left in struct ip_moptionsand struct ifmultiaddr
This is all made harder by the fact that struct mbuf has a struct ifnet pointer in it, so if for any reason there is an outstanding mbuf ... This has been raised as an issue before, and is a good reason to ifconfig down the interface, and wait a second or two before ejecting. You could and still, the wait is not errorproof as delays can be larger than a second or two. I suppose the correct way to do things when you delete an interface is to to keep the struct ifnet around (in some list) for further reuse when the card is reinserted. One could argue that dummynet with its delayed scheduling of packets is screwing up things, but i would argue that having pointers to volatile objects without reference counts is not such a great design, and SMP might give the same kind of problems. cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FIFOs select: what about our implementation?
On Tue, Sep 05, 2000 at 07:24:58PM +0200, Peter van Dijk wrote: select return code -1 with wrong errno == 0. Sorry, I was wrong about errno, it returns that descriptor is ready for read while there is nothing to read. I surely do think this behaviour is broken. http://www.freebsd.org/cgi/query-pr.cgi?pr=19871 I disagree about Bruce comment on that. If we have nothing to read, select must be timed out. It is not non-blocking read call but select. -- Andrey A. Chernov [EMAIL PROTECTED] http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FIFOs select: what about our implementation?
On Wed, Sep 06, 2000 at 07:35:50AM +1100, Bruce Evans wrote: This behaviour is sort of intentional. Reads on a named pipe with no writers are specified by POSIX.1 to return immediately. 4.4BSD does extra work to break this in some cases. select() on a read descriptor open on such a pipe just follows read(). I think it started giving the behaviour that you don't want when I fixed read(). Please consider that we talk not about reads but about select. 'Select' is used to indicate that data is available while 'read' used to read it, they are two different things and behaviour of one thing not related to other. Currently select indicates that data is available when it really isn't. I don't ask to fix current read implementation, but select is just unusable for FIFOs in its current form. -- Andrey A. Chernov [EMAIL PROTECTED] http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FIFOs select: what about our implementation?
On Wed, Sep 06, 2000 at 12:44:33AM +0400, Andrey A. Chernov wrote: [snip] Please consider that we talk not about reads but about select. 'Select' is used to indicate that data is available while 'read' used to read it, they are two different things and behaviour of one thing not related to other. Currently select indicates that data is available when it really isn't. I don't ask to fix current read implementation, but select is just unusable for FIFOs in its current form. I wouldn't say 'unusable'. It needs a work around. It is broken, in that selecting for readability on a pipe requires you to open that writing fd on it *everytime*. Greetz, Peter -- dataloss networks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
DEVFS patch.
OK, here is the nasty bit of DEVFS: The locking and protection patch: http://phk.freebsd.dk/patch/devfs.patch -- Add support for an overflow table for DEVFS inodes. The static table defaults to 1024 inodes, if that fills, an overflow table of 32k inodes is allocated. Both numbers can be changed at compile time, the size of the overflow table also with the sysctl vfs.devfs.noverflow. Use atomic instructions to barrier between make_dev()/destroy_dev() and the mounts. Add lockmgr() locking of directories for operations accessing or modifying the directory TAILQs. Various nitpicking here and there. The patch to i386/include/atomic.h is taken from SMPng to which I added atomic_cmpset_ptr(). -- With this patch DEVFS has the features and properties it should have with respect to the "main mount". -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci if_dc.c
Hello Bill, I'm sorry about that. Here's some information that I can gather: 1. The Intel 21143 chips is intergrated in NEC VersaPro NoteBook PC. No LED to indicate the network activity are available. 2. It is connected to 10BaseT Hub (HP 28688B) at half duplex. Ok, two more things: - Show me the output of pciconf -l. - Is this supposed to be a 10/100 interface or just 10mbps? -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
** HEADS UP ** kernel changed to /boot/kernel/kernel.ko
I just committed a change to the loader and kernel Makefiles such that the kernel is now named "kernel.ko" and it the modules live in ``/boot/kernel'' (and ``/boot/kernel.old''). After your next world build, the loader will not load ``/kernel'' by default, so you want to make sure you build and install a kernel using sources matching the loader source. Third party modules (ie, those not part of the base FreeBSD) should be placed in ``/boot/modules'' (or ``/modules'') and the FreeBSD build system will not disturb them. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/pci if_dc.c
From: [EMAIL PROTECTED] (Bill Paul) Date: Tue, 5 Sep 2000 15:13:53 -0700 (PDT) :: I'm sorry about that. Here's some information that I can gather: :: 1. The Intel 21143 chips is intergrated in NEC VersaPro NoteBook PC. ::No LED to indicate the network activity are available. :: :: 2. It is connected to 10BaseT Hub (HP 28688B) at half duplex. :: ::Ok, two more things: :: ::- Show me the output of pciconf -l. dc0@pci0:5:0: class=0x02 card=0x80281033 chip=0x00191011 rev=0x41 hdr=0x00 ::- Is this supposed to be a 10/100 interface or just 10mbps? It does handle both 10/100Base, and works great. But for now, it is connected to the HP hub which only does 10. Hope this helps, Haro =-- _ _Munehiro (haro) Matsuda -|- /_\ |_|_| Business Incubation Dept., Kubota Corp. /|\ |_| |_|_| 1-3 Nihonbashi-Muromachi 3-Chome Chuo-ku Tokyo 103-8310, Japan Tel: +81-3-3245-3318 Fax: +81-3-3245-3315 Email: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: SMP code commit iminent
In compliance with the SMP project announcement (archived at http://people.freebsd.org/~jasone/smp/smp_project_announcement.txt), this email is a minimum 24 hour notice that SMP code will be committed to -current. A large patch including major changes to how the kernel works will be checked in sometime after 6 September, 18:00 PST. Also in compliance with the SMP project announcement, a static tag will be created between the above-mentioned time and when the actual commit is done. If you have questions or issues, make sure to first read the original project announcement (URL above) before sending email to the lists. For more extensive information about the SMP project, see the project web page at: http://people.freebsd.org/~jasone/smp/ Let the fun begin! Jason Evans SMP Project Manager To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: SMP code commit iminent
On Tue, Sep 05, 2000 at 05:58:32PM -0700, Jason Evans wrote: this email is a minimum 24 hour notice that SMP code will be committed to -current. What is the status of the Alpha bits? Will we have a working kernel after the commit, or should we site tight for a week while the Alpha bits are tweaked into working status? -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: SMP code commit iminent
On Tue, Sep 05, 2000 at 06:37:38PM -0700, David O'Brien wrote: What is the status of the Alpha bits? Will we have a working kernel after the commit, or should we site tight for a week while the Alpha bits are tweaked into working status? It should work (compile and run), though interrupt threads will not be enabled. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
new zero copy sockets and NFS snapshot
[ -arch and -current BCC'ed for wider coverage, please direct followups to -net and/or me ] I have put a new copy of the zero copy sockets and NFS patches, against -current as of early September 5th, 2000, here: http://people.FreeBSD.ORG/~ken/zero_copy/ Questions, comments and feedback are welcome. Besides being generated against a newer version of -current, the following things have changed in the new patches posted above: - Merged in the new mbuf reference counting code from -current. - Fixed a bug in writev(2) and sendmsg(2) handling noticed by Alan Cox. We weren't incrementing the iov pointer in the uio structure, like uiomove() does. - Fixed another bug in the zero copy code, noticed by Alan Cox. Move the initialization of the cow_send in sosend() (in uipc_socket.c) into the inner while loop. For those of you who missed the previous messages about this code (that went out to -net, -arch and -current), here's a quick list of what is included in the code: - Two sets of zero copy send code, written by Drew Gallatin [EMAIL PROTECTED] and Robert Picco [EMAIL PROTECTED]. - Zero copy receive code, written by Drew Gallatin. - Zero copy NFS code, written by Drew Gallatin. - Header splitting firmware for Alteon's Tigon II boards (written by me), based on version 12.4.11 of their firmware. This is used in combination with the zero copy receive code to guarantee that the payload of TCP or UDP packet is placed into a page-aligned buffer. - Alteon firmware debugging ioctls and supporting routines for the Tigon driver (also written by me). This will help anyone who is doing firmware development under FreeBSD for the Tigon boards. The Alteon header splitting and debugging code was written for Pluto Technologies (www.plutotech.com), which has kindly agreed to let me release the code. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: SMP code commit iminent
Progress will be more rapid with things checked in than not, as long as Jason's statement about "the (alpha) system will run" after the checkin. Jason- I think we'd all appreciate a UTC timestamp suitable for -D that we can all use to checkout stuff prior to the big change. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: SMP code commit iminent
[-smp dropped from cc list.] On Tue, Sep 05, 2000 at 09:57:05PM -0700, Matthew Jacob wrote: Jason- I think we'd all appreciate a UTC timestamp suitable for -D that we can all use to checkout stuff prior to the big change. I initially wrote: Also in compliance with the SMP project announcement, a static tag will be created between the above-mentioned time and when the actual commit is done. Good enough? Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: SMP code commit iminent
On Tue, Sep 05, 2000 at 09:57:05PM -0700, Matthew Jacob wrote: Jason- I think we'd all appreciate a UTC timestamp suitable for -D that we can all use to checkout stuff prior to the big change. There will be a TAG for that to make life easier. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: SMP code commit iminent
Oops- sorry- this is what I get for catching up email after a long day. Thanks. On 5 Sep 2000, Jason Evans wrote: [-smp dropped from cc list.] On Tue, Sep 05, 2000 at 09:57:05PM -0700, Matthew Jacob wrote: Jason- I think we'd all appreciate a UTC timestamp suitable for -D that we can all use to checkout stuff prior to the big change. I initially wrote: Also in compliance with the SMP project announcement, a static tag will be created between the above-mentioned time and when the actual commit is done. Good enough? Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
