What is highest connection rate?
What is the highest rate of connections per second people out there have achieved with a FreeBSD machine? Ideally, this would be a server that just accepts and closes connections, using something like a zero byte WebBench client. Thanks, -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw syntax - should this error?
This is the documented behavior.
: With the TCP and UDP protocols, optional ports may be specified
: as:
:
: {port|port-port|port:mask}[,port[,...]]
:
: The `-' notation specifies a range of ports (including bound-
: aries).
:
: The `:' notation specifies a port and a mask, a match is declared
: if the port number in the packet matches the one in the rule,
: limited to the bits which are set in the mask.
:
: Service names (from /etc/services) may be used instead of numeric
: port values. A range may only be specified as the first value,
: and the length of the port list is limited to IP_FW_MAX_PORTS
: ports (as defined in /usr/src/sys/netinet/ip_fw.h).
On Thu, Aug 30, 2001 at 08:31:16PM -0400, David Hill wrote:
The following ipfw commands produce an error.
Could we make this work:
ipfw add allow udp from any to any lowport,higherport1-higherport2
Instead of
ipfw add allow udp from any to any highport1-highport2,lowpot
Could we make this work:
ipfw add allow udp from any to any range1-range2, range3-range4
Instead of having to do
ipfw add allow udp from any to any range1-range2
ipfw add allow udp from any to any range3-range4
fog# uname -a
FreeBSD fog.hill.hom 4.4-RC FreeBSD 4.4-RC #0: Thu Aug 30 15:02:13 EDT 2001
david@fog:/usr/src/sys/compile/FOG i386
Thanks
David
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
On Thu, 30 Aug 2001, Bruce Evans wrote:
I've found acpica as useful as any other disk filling service and hope
it stays that way.
Bruce
Can someone put this in fortunes.dat :)
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Junior Kernel Hacker task: Get rid of NCCD constant.
Poul-Henning Kamp wrote:
Assignment:
There is no reason for the NCCD constant to exist anymore.
The CCD driver already has cloning support but CCDs softc
structure is statically allocated for NCCD devices.
Change the CCD driver to dynamically allocate memory as needed,
the MD driver can be used as example as the overall morphology
of the two drivers are the same.
See attached patch. Due to the fact that statically allocated array was
replaced with queue(9) list, it became big PITA to use kvm in the ccdconfig(8)
utility, so in addition I've replaced kvm with ioctl interface, which
simplifies things and allows to lift sugid bit from it (I bet rwatson and other
trusted folks would like that ;) Also I've converted function prototypes into
single style (deKRified them), because most of them were affected by the my
changes anyway.
I would like to hear comments and suggestions.
Truly yours,
Maxim Jr. Kernel Hacker Sobolev
Index: sys/sys/ccdvar.h
===
RCS file: /home/ncvs/src/sys/sys/ccdvar.h,v
retrieving revision 1.11
diff -d -u -b -B -r1.11 ccdvar.h
--- sys/sys/ccdvar.h2000/01/16 09:25:05 1.11
+++ sys/sys/ccdvar.h2001/08/31 12:06:06
@@ -86,19 +86,6 @@
*/
/*
- * A concatenated disk is described at initialization time by this structure.
- */
-struct ccddevice {
- int ccd_unit; /* logical unit of this ccd */
- int ccd_interleave; /* interleave (DEV_BSIZE blocks) */
- int ccd_flags; /* misc. information */
- int ccd_dk; /* disk number */
- struct vnode**ccd_vpp; /* array of component vnodes */
- char**ccd_cpp; /* array of component pathnames */
- int ccd_ndev; /* number of component devices */
-};
-
-/*
* This structure is used to configure a ccd via ioctl(2).
*/
struct ccd_ioctl {
@@ -110,12 +97,6 @@
size_t ccio_size; /* (returned) size of ccd */
};
-/* ccd_flags */
-#defineCCDF_SWAP 0x01/* interleave should be dmmax */
-#define CCDF_UNIFORM 0x02/* use LCCD of sizes for uniform interleave */
-#define CCDF_MIRROR0x04/* use mirroring */
-#define CCDF_PARITY0x08/* use parity (RAID level 5) */
-
/* Mask of user-settable ccd flags. */
#define CCDF_USERMASK (CCDF_SWAP|CCDF_UNIFORM|CCDF_MIRROR|CCDF_PARITY)
@@ -175,10 +156,13 @@
};
/*
- * A concatenated disk is described after initialization by this structure.
+ * A concatenated disk is described by this structure.
*/
-struct ccd_softc {
+struct ccd_s {
+ LIST_ENTRY(ccd_s) list;
+
int sc_unit; /* logical unit number */
+ struct vnode **sc_vpp; /* array of component vnodes */
int sc_flags; /* flags */
int sc_cflags; /* configuration flags */
size_t sc_size; /* size of ccd */
@@ -195,10 +179,14 @@
};
/* sc_flags */
-#define CCDF_INITED0x01/* unit has been initialized */
-#define CCDF_WLABEL0x02/* label area is writable */
-#define CCDF_LABELLING 0x04/* unit is currently being labelled */
-#define CCDF_WANTED0x40/* someone is waiting to obtain a lock */
+#define CCDF_SWAP 0x01/* interleave should be dmmax */
+#define CCDF_UNIFORM 0x02/* use LCCD of sizes for uniform interleave */
+#define CCDF_MIRROR0x04/* use mirroring */
+#define CCDF_PARITY0x08/* use parity (RAID level 5) */
+#define CCDF_INITED0x10/* unit has been initialized */
+#define CCDF_WLABEL0x20/* label area is writable */
+#define CCDF_LABELLING 0x40/* unit is currently being labelled */
+#define CCDF_WANTED0x60/* someone is waiting to obtain a lock */
#define CCDF_LOCKED0x80/* unit is locked */
/*
@@ -210,3 +198,15 @@
*/
#define CCDIOCSET _IOWR('F', 16, struct ccd_ioctl) /* enable ccd */
#define CCDIOCCLR _IOW('F', 17, struct ccd_ioctl)/* disable ccd */
+
+struct ccdconf {
+ int size; /* sizeof of buffer below */
+ struct ccd_s *buffer; /* pointer to a configuration array */
+};
+#define CCDCONFINFO_IOWR('F', 19, struct ccdconf)/* get config */
+
+struct ccdcpps {
+ int size;
+ char*buffer;
+};
+#define CCDCPPINFO _IOWR('F', 20, struct ccdcpps)/* get components */
Index: sbin/ccdconfig/Makefile
===
RCS file: /home/ncvs/src/sbin/ccdconfig/Makefile,v
retrieving revision 1.5
diff -d -u -b -B -r1.5 Makefile
--- sbin/ccdconfig/Makefile 2001/05/18 13:41:24 1.5
+++ sbin/ccdconfig/Makefile 2001/08/31 12:06:06
@@ -3,9 +3,4 @@
PROG= ccdconfig
MAN= ccdconfig.8
-LDADD+=-lkvm
-DPADD+=${LIBKVM}
-BINGRP=
minor HEADS UP: /etc/defaults/make.conf is gone
Hi! /etc/defaults/make.conf has been removed and is not included by make(1) any more. If you are using BDEFLAGS, add the entry to your local /etc/make.conf. The example file lives in /usr/share/examples/etc/ now. Thank you Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
Bruce Evans [EMAIL PROTECTED] wrote: On Fri, 15 Jun 2001, Steve O'Hara-Smith wrote: On Fri, 15 Jun 2001 06:31:12 -0700 (PDT) David Wolfskill [EMAIL PROTECTED] wrote: DW Indeed: it is my understanding that the path name interpretation is DW an issue at the time of reference, not (necessarily) the time of DW creation. It has, to the best of my knowledge, been valid to create a DW symlink prior to a point when its target exists. It has been on evey platform I have ever used ln -s on. DW One may well argue that this is broken in some way(s). Still, changing DW it at this point could well be considered a POLA violation, at best. I would argue loud and long that changing that *would* be broken. There is never a guarantee (or even an implication) that a symlink points to a valid directory entry (think unmounted filesystems, NFS ...). I find it hard to imagine why creation time should be special in that regard. We are (or at least I am) talking about changing it to prevent links to a string that can _never_ be a valid pathname. Fortunately, in POSIX there is only one such string (the empty string). Here's an example of a standard utility being clueless about symlinks to nothing: $ ln -s '' foo $ cp foo bar cp: foo is a directory (not copied) foo is certainly not a directory. The bug seems to be in fts. No, foo certainly _is_ a directory. It is precisely the same thing as .. cp is also broken for symlinks to valid pathnames for nonexistent files; $ rm -f foo $ ln -s /nonesuch foo $ cp foo bar This duplicates foo as a symlink, but should just fail. Bruce -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE: How often diff'ed ?
Could You give me some guidance as to where to access the p4 repository; I may have missed it on the list. Thanks ! I don't have the capacity to check out the complete CVS repository, by the way. I have only 6 GB, and it is already 80 % full or so. That's why CTM is quite handy for me, hence my question about the diff file. I know this is a lot to ask, but could we have an current KSEified CTM sub- scription ? If not, that's fine, too. Any thoughts on that ? Ciao, derweil, -- Carlo To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ufs ext attr problem...
hi, it seems like there's a problem in ffs_unmount, ffs_vfsops.c:841: if ufs_extattr_stop() returns EOPNOTSUPP, calling ufs_extattr_uepm_destroy two lines later will cause a panic(ufs_extattr_uepm_destroy: not initialized) in ufs_extattr.c:175, at least on my machine. maybe, ufs_extattr_uepm_destroy() should be enclosed in a else statement in ffs_vfsops.c? best, christian -- Sorry, no defects found. Please try a different search [http://www.cisco.com/support/bugtools/bugtool.shtml] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kernel builds failing
Hi... For the last two days, my kernel builds have been failing with: linking kernel.debug ata-all.o: In function `ataioctl': /usr/src/sys/dev/ata/ata-all.c(.text+0x791): undefined reference to `atapi_queue _cmd' *** Error code 1 Stop in /usr/obj/usr/src/sys/CHESHIRE. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Any ideas? thanks -Adam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Kernel Hacker task: Get rid of NCCD constant.
Maxim Sobolev writes: Poul-Henning Kamp wrote: Assignment: There is no reason for the NCCD constant to exist anymore. The CCD driver already has cloning support but CCDs softc structure is statically allocated for NCCD devices. Change the CCD driver to dynamically allocate memory as needed, the MD driver can be used as example as the overall morphology of the two drivers are the same. See attached patch. Due to the fact that statically allocated array was replaced with queue(9) list, it became big PITA to use kvm in the ccdconfig(8) utility, so in addition I've replaced kvm with ioctl interface, which simplifies things and allows to lift sugid bit from it (I bet rwatson and other trusted folks would like that ;) Also I've converted function prototypes into single style (deKRified them), because most of them were affected by the my changes anyway. I would like to hear comments and suggestions. I only have one real suggestion. You added sc_vpp to ccd_s in order to store the vnodes to pass between the ioctl and the init procedures. This is a duplication of resources, since the init procedure merely copies the vnode into the appropriate info structure, and the vpp array is never used again. A better solution might be to simply pass the local vpp array as an extra argument to ccdinit (after cpaths, for instance). Then, after ccdinit is done, simply free the ioctl copy of vpp and you are done. It just seems like a lot of overhead carrying around that malloc'd sc_vpp for no purpose. Unless, of course, you can tell me the purpose for it! Truly yours, Maxim Jr. Kernel Hacker Sobolev /Joe The wanna-be Jr. Kernel Hacker To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Fri, 31 Aug 2001, Brian F. Feldman wrote: Bruce Evans [EMAIL PROTECTED] wrote: Here's an example of a standard utility being clueless about symlinks to nothing: $ ln -s '' foo $ cp foo bar cp: foo is a directory (not copied) foo is certainly not a directory. The bug seems to be in fts. No, foo certainly _is_ a directory. It is precisely the same thing as .. No, the empty pathname has been invalid and not an alias for . since at least the first version of POSIX. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
[Attribution deleted for clarity; see referenced messages in the archives.]
$ ln -s '' foo
$ cp foo bar
cp: foo is a directory (not copied)
No, foo certainly _is_ a directory. It is precisely the same thing as
..
No, the empty pathname has been invalid and not an alias for . since at
least the first version of POSIX.
foo is not the empty pathname. It is also not a directory; it is a
symbolic link. The pathname resolution rules require that references
to foo be indistinguishable from references to . (outside of
those functions which are defined not to follow symbolic links).
XBDd7 says:
# If a symbolic link is encountered during pathname resolution, the
# behavior shall depend on whether the pathname component is at the
# end of the pathname and on the function being performed. If all of
# the following are true, then pathname resolution is complete:
[...]
# 3. The function is required to act on the symbolic link itself, or
#certain arguments direct that the function act on the symbolic
#link itself.
Since this is not true (see below), pathname resolution continues:
# In all other cases, the system shall prefix the remaining pathname,
# if any, with the contents of the symbolic link. If the combined
# length exceeds {PATH_MAX}, and the implementation considers this to
# be an error, errno shall be set to [ENAMETOOLONG] and an error
# indication shall be returned. Otherwise, the resolved pathname shall
# be the resolution of the pathname just created. If the resulting
# pathname does not begin with a slash, the predecessor of the first
# filename of the pathname is taken to be the directory containing the
# symbolic link.
The result of this construction rule is clearly an empty pathname.
The definition of ``pathname'' does not prohibit empty pathnames:
# [A pathname] has an optional beginning slash, followed by zero or
# more filenames separated by slashes. A pathname may optionally
# contain one or more trailing slashes. Multiple successive slashes
# are considered to be the same as one slash.
We seem to be in a region of undefined behavior here.
XCUd7 says (in defining `cp'):
# If source_file is a file of type symbolic link:
# * If neither the -R nor -r options were specified, cp shall take
# actions based on the type and contents of the file referenced by
# the symbolic link, and not by the symbolic link itself.
[...]
# For each source_file, the following steps shall be taken:
# 2. If source_file is of type directory, the following steps shall be
#taken:
# a. If neither the -R or -r options were specified, cp shall write a
#diagnostic message to standard error, do nothing more with
#source_file, and go on to any remaining files.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
Bruce Evans [EMAIL PROTECTED] wrote: On Fri, 31 Aug 2001, Brian F. Feldman wrote: Bruce Evans [EMAIL PROTECTED] wrote: Here's an example of a standard utility being clueless about symlinks to nothing: $ ln -s '' foo $ cp foo bar cp: foo is a directory (not copied) foo is certainly not a directory. The bug seems to be in fts. No, foo certainly _is_ a directory. It is precisely the same thing as .. No, the empty pathname has been invalid and not an alias for . since at least the first version of POSIX. I didn't read the rest of the thread til later ;) The fact remains that FreeBSD interprets it as such in namei(), and is it not an undefined behavior according to POSIX? -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
New source fails probe
The latest sources (yesterday) failed with the following: Copyright (c) 1992-2001 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 #7: Thu Aug 30 22:38:48 AKDT 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/INTAKE Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 901602955 Hz CPU: AMD Athlon(tm) Processor (901.60-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x642 Stepping = 2 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR AMD Features=0xc044b18,AMIE,DSP,3DNow! real memory = 402653184 (393216K bytes) avail memory = 385830912 (376788K bytes) Preloaded elf kernel kernel at 0xc04ae000. Preloaded elf module acpi.ko at 0xc04ae09c. Pentium Pro MTRR support enabled Using $PIR table, 8 entries at 0xc00fa040 npx0: math processor on motherboard npx0: INT 16 interface acpi0: COMPAQ HAWA7K11 on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI frequency 3579545 Hz acpi_timer0: 32-bit timer at 3.579545MHz port 0xee08-0xee0b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu: CLK_VAL field overflows P_CNT register acpi_cpu: CLK_VAL field overlaps THT_EN bit acpi_button0: Power Button on acpi0 acpi_pcib0: Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: PCI bus on acpi_pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at 0.0 (no driver attached) pci0: simple comms at 4.0 (no driver attached) xl0: 3Com 3cSOHO100-TX OfficeConnect irq 5 at device 5.0 on pci0 xl0: couldn't map ports/memory device_probe_and_attach: xl0 attach returned 6 isab0: PCI-ISA bridge at device 20.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686 ATA66 controller port 0x1800-0x180f at device 20.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: VIA 83C572 USB controller port 0x14c0-0x14df irq 11 at device 20.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ukbd0: Logitech USB Receiver, rev 1.10/10.20, addr 2, iclass 3/1 kbd0 at ukbd0 uhid0: Logitech USB Receiver, rev 1.10/10.20, addr 2, iclass 3/0 ums0: Logitech USB Receiver, rev 1.10/9.10, addr 3, iclass 3/1 ums0: 5 buttons and Z dir. uhci1: VIA 83C572 USB controller port 0x14e0-0x14ff irq 11 at device 20.3 on pci0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhid1: American Power Conversion Back-UPS 350 FW: 5.1.D USB FW: c1, rev 1.10/1.00, addr 2, iclass 3/0 pci0: bridge, PCI-unknown at 20.4 (no driver attached) pcm0: VIA VT82C686A port 0x1814-0x1817,0x1810-0x1813,0x1000-0x10ff irq 10 at device 20.5 on pci0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 ppc0 port 0x378-0x37f on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: IEEE1284 device found /NIBBLE Probing for PnP devices on ppbus0: ppbus0: Hewlett-Packard HP LaserJet 6L/0101.01 PRINTER HP ENHANCED PCL5,PJL plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Polled port ppi0: Parallel I/O on ppbus0 ppc1: cannot reserve I/O port range sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A fdc0: NEC 72065B or clone port 0x3f7,0x3f0-0x3f5 irq 6 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc1: cannot reserve I/O port range orm0: Option ROM at iomem 0xc-0xc on isa0 fdc1: cannot reserve I/O port range (6 ports) pmtimer0 on isa0 ppc1: parallel port not found. sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio2: configured irq 3 not in bitmap of probed irqs 0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 ad0: 29311MB Maxtor 53073H6 [59554/16/63] at ata0-master UDMA66 ad1: 38166MB Maxtor 34098H4 [77545/16/63] at ata0-slave UDMA66 acd0: DVD-ROM Compaq DVD-ROM DV-5700B at ata1-master PIO4 acd1: CD-RW CDD4801 CD-R/RW at ata1-slave PIO4 Mounting root from ufs:/dev/ad1s1a Went back to 8-27 for now. Beech -- Micro$oft: Where can we make you go today? --- Beech Rintoul - IT Manager - Instructor - [EMAIL PROTECTED] /\ ASCII Ribbon Campaign | Anchorage Gospel Rescue Mission \ / - NO HTML/RTF in e-mail | P.O. Box 230510 X - NO Word docs in e-mail | Anchorage, AK 99523-0510 / \ - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Junior Kernel Hacker task: Get rid of NCCD constant.
Joe Kelsey writes:
Maxim Sobolev writes:
Poul-Henning Kamp wrote:
Assignment:
There is no reason for the NCCD constant to exist anymore.
The CCD driver already has cloning support but CCDs softc
structure is statically allocated for NCCD devices.
Change the CCD driver to dynamically allocate memory as needed,
the MD driver can be used as example as the overall morphology
of the two drivers are the same.
See attached patch. Due to the fact that statically allocated array
was replaced with queue(9) list, it became big PITA to use kvm in the
ccdconfig(8) utility, so in addition I've replaced kvm with ioctl
interface, which simplifies things and allows to lift sugid bit from
it (I bet rwatson and other trusted folks would like that ;) Also
I've converted function prototypes into single style (deKRified
them), because most of them were affected by the my changes anyway.
I would like to hear comments and suggestions.
I only have one real suggestion. You added sc_vpp to ccd_s in order to
store the vnodes to pass between the ioctl and the init procedures.
This is a duplication of resources, since the init procedure merely
copies the vnode into the appropriate info structure, and the vpp array
is never used again. A better solution might be to simply pass the
local vpp array as an extra argument to ccdinit (after cpaths, for
instance). Then, after ccdinit is done, simply free the ioctl copy of
vpp and you are done. It just seems like a lot of overhead carrying
around that malloc'd sc_vpp for no purpose. Unless, of course, you can
tell me the purpose for it!
After further review, one other thing I would do is store the cdd_s
pointer in the device structure using device_{get,put}_softc. Then,
there is no messing with ccdfind() in the low-level routines just to get
the softc pointer, just use the buffer pointer in strategy to find the
device, or whatever. In ccdiodone, you have to either use obp to get
the original buffer pointer and get the device there, or else change the
ccdbuf structure so that it saves the softc pointer instead of the unit
number, since we can get the unit number directly out of the softc
pointer.
Admittedly, the list of ccd_s is likely to be small, so traversing the
list in ccdfind is also likely to be fast, but storing the softc pointer
in the device structure is generally what most drivers do anyway, so
this would make it look more like most drivers.
/Joe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: minor HEADS UP: /etc/defaults/make.conf is gone
- Original Message - From: Alexander Langer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, August 31, 2001 2:52 PM Subject: minor HEADS UP: /etc/defaults/make.conf is gone Hi! /etc/defaults/make.conf has been removed and is not included by make(1) any more. If you are using BDEFLAGS, add the entry to your local /etc/make.conf. Why introduce this handling of defaults different of other default cfg's: pccard.conf periodic.conf rc.conf The example file lives in /usr/share/examples/etc/ now. It is not an example, it is the vendor defaults Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
My motherboard is a Tyan S1696-DLUA dual P2-333. I am using the latest known bios updates. ACPI is enabled, and APM disabled in the BIOS. This happens regardless if PnP is on or off in the BIOS. [dmesg | grep -i acpi] ACPI debug layer 0x0 debug level 0x0 tbxface-0170: *** Error: AcpiLoadTables: Could not get RSDP, AE_NO_ACPI_TAB LES tbxface-0222: *** Error: AcpiLoadTables: Could not load tables: AE_NO_ACPI_ TABLES ACPI: table load failed: AE_NO_ACPI_TABLES Your ACPI tables, assuming they exist, are somewhere we're not looking for them yet. 8( Can you try: # hexdump /dev/mem | grep RSD PTR and if it finds anything (the string should be left-aligned on the line) send me the line it outputs... (this will take a while). Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
In progress... You aren't joking about it taking a while... Been half an hour now... Mike Smith wrote: My motherboard is a Tyan S1696-DLUA dual P2-333. I am using the latest known bios updates. ACPI is enabled, and APM disabled in the BIOS. This happens regardless if PnP is on or off in the BIOS. [dmesg | grep -i acpi] ACPI debug layer 0x0 debug level 0x0 tbxface-0170: *** Error: AcpiLoadTables: Could not get RSDP, AE_NO_ACPI_TAB LES tbxface-0222: *** Error: AcpiLoadTables: Could not load tables: AE_NO_ACPI_ TABLES ACPI: table load failed: AE_NO_ACPI_TABLES Your ACPI tables, assuming they exist, are somewhere we're not looking for them yet. 8( Can you try: # hexdump /dev/mem | grep RSD PTR and if it finds anything (the string should be left-aligned on the line) send me the line it outputs... (this will take a while). Thanks. jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! POWER TO THE PEOPLE! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
Duh!!! No wonder it was taking so long... Seems we both forgot that would have never come up with anything... doing a: hexdump -C /dev/mem | grep RSD PTR now... Mike Smith wrote: My motherboard is a Tyan S1696-DLUA dual P2-333. I am using the latest known bios updates. ACPI is enabled, and APM disabled in the BIOS. This happens regardless if PnP is on or off in the BIOS. [dmesg | grep -i acpi] ACPI debug layer 0x0 debug level 0x0 tbxface-0170: *** Error: AcpiLoadTables: Could not get RSDP, AE_NO_ACPI_TAB LES tbxface-0222: *** Error: AcpiLoadTables: Could not load tables: AE_NO_ACPI_ TABLES ACPI: table load failed: AE_NO_ACPI_TABLES Your ACPI tables, assuming they exist, are somewhere we're not looking for them yet. 8( Can you try: # hexdump /dev/mem | grep RSD PTR and if it finds anything (the string should be left-aligned on the line) send me the line it outputs... (this will take a while). Thanks. jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! POWER TO THE PEOPLE! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
I would have waited for the re-run of hexdump to finish, but checking right after I sent the last message produced: DING! wahoo(102): hexdump -C /dev/mem | grep RSD PTR 000716d0 67 72 65 70 20 22 52 53 44 20 50 54 52 22 27 00 |grep RSD PTR'.| 000719d0 67 72 65 70 20 22 52 53 44 20 50 54 52 22 27 00 |grep RSD PTR'.| 00369400 52 53 44 20 50 54 52 20 00 54 62 56 61 6c 69 64 |RSD PTR .TbValid| 0036ad00 44 53 44 54 00 52 53 44 20 50 54 52 20 00 52 53 |DSDT.RSD PTR .RS| You did say that what you are looking for would be left-aligned, could it be the bit at 00369400? Mike Smith wrote: My motherboard is a Tyan S1696-DLUA dual P2-333. I am using the latest known bios updates. ACPI is enabled, and APM disabled in the BIOS. This happens regardless if PnP is on or off in the BIOS. [dmesg | grep -i acpi] ACPI debug layer 0x0 debug level 0x0 tbxface-0170: *** Error: AcpiLoadTables: Could not get RSDP, AE_NO_ACPI_TAB LES tbxface-0222: *** Error: AcpiLoadTables: Could not load tables: AE_NO_ACPI_ TABLES ACPI: table load failed: AE_NO_ACPI_TABLES Your ACPI tables, assuming they exist, are somewhere we're not looking for them yet. 8( Can you try: # hexdump /dev/mem | grep RSD PTR and if it finds anything (the string should be left-aligned on the line) send me the line it outputs... (this will take a while). Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! POWER TO THE PEOPLE! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KSE: How often diff'ed ?
John Baldwin wrote: On 31-Aug-01 Peter Wemm wrote: Julian Elischer wrote: The diff file is updated automatically one per hour from the P4 repository that we are working on. it IS possible that yuo might catch it at a time when what is in teh repository may not match what is in -current but generally that should not last to long. (depends on how often one of us does an MFC from -current) I can make a cvsup'able collection and do a live replication of the kse branch into a cvs tree.. I think having a p4 - cvs duplicator up so people can cvsup any of the stuff currently in p4 for testing would be nice. It would also be good practice for the future. *wink* *wink* *nudge* *nudge* Ok. Done. cvsup-master and cvsup10.freebsd.org are carrying a collection called p4-cvs-all. Right now it has the kse sys and lib/libkvm tree in it. To get the cvs ,v tree: *default host=cvsup10.FreeBSD.org *default base=/tmp # change *default prefix=/tmp# change *default release=cvs *default delete use-rel-suffix *default compress p4-cvs-all To get source: *default host=cvsup10.FreeBSD.org *default base=/tmp # change *default prefix=/tmp# change *default release=cvs *default delete use-rel-suffix #*default compress p4-cvs-all tag=. It will check out: projects/kse/lib/libkvm/... and projects/kse/sys/... If you have a committer account on freefall, you can get the truth version by having a look at http://people.freebsd.org/~peter/p4cookbook.txt and running p4newuser on freefall. You can then check out the code directly onto your test machines with none of the replication delays. Incidently, the kse folks may like to keep a copy of the cvs ,v tree on their laptops for extended disconnected sessions so they can easily get logs etc. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
dynamic sysctl problem and hot fix
hi,
i just came across a problem with dynamic sysctls:
when unloading a driver module that used dyn sysctls, my system paniced
with oid too high. that problem is caused by sysctl_ctx_free() in
kern/kern_sysctl.c, that first deregisters all oids in the list to see if
a error occurs. then, all oids are being reregistered and, if there was no
error, they're finally removed.
during the second phase, sysctl_register_oid(e1-entry) is called with
n := e1-entry-oid_number being the old oid number with n
CTL_AUTO_START.
that leads to panic(static sysctl too high) in sysctl_register_oid.
one approach might be to initialize the oid_number field to contain the
value OID_AUTO before calling sysctl_regiser_oid, but i'm unsure about the
side effects of doing that in sysctl_ctx_free().
alternatively, the old oid number could be reused, the following patch
should do, but it's just a workaround.
best,
christian
--
Sorry, no defects found. Please try a different search
[http://www.cisco.com/support/bugtools/bugtool.shtml]
Index: kern_sysctl.c
===
RCS file: /usr/cvs/src/sys/kern/kern_sysctl.c,v
retrieving revision 1.113
diff -r1.113 kern_sysctl.c
83a84,96
static struct sysctl_oid *
sysctl_find_oidnumber(const int number, struct sysctl_oid_list *list)
{
struct sysctl_oid *oidp;
SLIST_FOREACH(oidp, list, oid_link) {
if (oidp-oid_number == number) {
return (oidp);
}
}
return (NULL);
}
125c138,139
panic(static sysctl oid too high: %d, oidp-oid_number);
---
if (sysctl_find_oidnumber(oidp-oid_number, parent))
panic(static sysctl oid too high: %d, oidp-oid_number);
177c191
if (error)
---
if (error)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Broken world (was Re: cvs commit: src/lib/libc/posix1e cap_text.c)
This should now be fixed (actually, as of last night I think). Thanks! Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Fri, 31 Aug 2001, Mike Barcroft wrote: Robert Watson [EMAIL PROTECTED] writes: rwatson 2001/08/30 19:12:00 PDT Modified files: lib/libc/posix1e cap_text.c Log: o Remove definition of CAP_MAX_BUF_LEN since it is defined in sys/capability.h now. Submitted by: tmm Obtained from:TrustedBSD Project Revision ChangesPath 1.4 +5 -2 src/lib/libc/posix1e/cap_text.c This seems to break world on my Alpha. The error is: /usr/src/lib/libc/../libc/posix1e/cap_text.c:293: `CAP_MAX_BUF_LEN' undeclared CAP_MAX_BUF_LEN doesn't seem to be defined in rev 1.8 of capability.h. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ufs ext attr problem...
Could you try the attached patch, which does what you suggest?
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
On Fri, 31 Aug 2001, Christian Carstensen wrote:
hi,
it seems like there's a problem in ffs_unmount, ffs_vfsops.c:841:
if ufs_extattr_stop() returns EOPNOTSUPP, calling ufs_extattr_uepm_destroy
two lines later will cause a panic(ufs_extattr_uepm_destroy: not initialized)
in ufs_extattr.c:175, at least on my machine.
maybe, ufs_extattr_uepm_destroy() should be enclosed in a else statement
in ffs_vfsops.c?
best,
christian
--
Sorry, no defects found. Please try a different search
[http://www.cisco.com/support/bugtools/bugtool.shtml]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Index: ffs_vfsops.c
===
RCS file: /home/ncvs/src/sys/ufs/ffs/ffs_vfsops.c,v
retrieving revision 1.157
diff -u -r1.157 ffs_vfsops.c
--- ffs_vfsops.c2001/06/28 22:21:27 1.157
+++ ffs_vfsops.c2001/09/01 02:22:55
@@ -834,11 +834,13 @@
flags |= FORCECLOSE;
}
#ifdef UFS_EXTATTR
- if ((error = ufs_extattr_stop(mp, p)))
+ if ((error = ufs_extattr_stop(mp, p))) {
if (error != EOPNOTSUPP)
printf(ffs_unmount: ufs_extattr_stop returned %d\n,
error);
- ufs_extattr_uepm_destroy(ump-um_extattr);
+ } else {
+ ufs_extattr_uepm_destroy(ump-um_extattr);
+ }
#endif
if (mp-mnt_flag MNT_SOFTDEP) {
if ((error = softdep_flushfiles(mp, flags, p)) != 0)
MFC request (was Re: symlink(2) [Was: Re: tcsh.cat])
This argument is just rehashing something that came up in June. Man
you people have short memories!
I comitted a fix to -current two months ago. It's still in my -stable
tree... if Jordan gives the O.K., I will MFC it to -stable.
-Matt
Index: vfs_lookup.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_lookup.c,v
retrieving revision 1.38.2.2
diff -u -r1.38.2.2 vfs_lookup.c
--- vfs_lookup.c2001/05/20 12:11:57 1.38.2.2
+++ vfs_lookup.c2001/08/31 18:53:22
@@ -200,6 +200,12 @@
break;
}
linklen = MAXPATHLEN - auio.uio_resid;
+ if (linklen == 0) {
+ if (ndp-ni_pathlen 1)
+ zfree(namei_zone, cp);
+ error = ENOENT;
+ break;
+ }
if (linklen + ndp-ni_pathlen = MAXPATHLEN) {
if (ndp-ni_pathlen 1)
zfree(namei_zone, cp);
:..
: $ cp foo bar
: cp: foo is a directory (not copied)
:
: foo is certainly not a directory. The bug seems to be in fts.
:
: No, foo certainly _is_ a directory. It is precisely the same thing as
: ..
:
: No, the empty pathname has been invalid and not an alias for . since at
: least the first version of POSIX.
:
:I didn't read the rest of the thread til later ;) The fact remains that
:FreeBSD interprets it as such in namei(), and is it not an undefined
:behavior according to POSIX?
:
:--
: Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: testing KSE
Carlo Dapor wrote: The medium I mount is a hard disk partition. /dev/ad0s1 is my win98 boot drive, /dev/ad0s2* my FreeBSD world. It has worked for almost a year, never had a crash or lost a single byte. I can go back to the kse kernel, and remount Win98, with the instructions You just posted. well here's the best procedure.. get newest version try reproduce the crash from single-user-mode but to the dumpon() command first try get a coredump. If you have bith the coredump and a debug kernel in the build environment, I can take them and use them to try locate the problem. (If you get the coredump i can probably find a plac eyou can upload them to, or alternatively, if you have somehere i can download them from) thanks! Ciao, derweil, -- Carlo I can not reproduce this with a memory disk image of an msdos floppy (I do not have a floppy on that machine) can you try accessing the floppy without mounting? e.g. can you try using it as a raw device with TAR or something? Maybe it's the floppy driver rather than tehe filesystem. If you can get a coredump and thus a stack backtrace it could be very helpful. thanks -- ++ __ _ __ | __--_|\ 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-current" in the body of the message
recent acpi-autoloading results in panic during boot on SMP-System
Hello current, the recent changes in current to auoload th acpi.ko module make my system crash in an early state. With a pmap_mapdev: Couldn't alloc kernel virtual memory panic. Without the acpi-module the system works fine. Any hints? Michael This is the output with the panic: ok boot -v |/-\|/-\|/-\|/-\|/boot/kernel/acpi.ko text=0x35d6c |/-\|/-\|/-\|/-\|/-\|/-\|/-\data=0x177c+0x1028 ||/syms=[0x4+0x4b00-\|+0x4+0x6255/-\] |/-\|/-SMAP type=01 base= len= 0009fc00 SMAP type=02 base= 0009fc00 len= 0400 SMAP type=02 base= 000f len= 0001 SMAP type=02 base= fec0 len= 1000 SMAP type=02 base= fee0 len= 1000 SMAP type=02 base= len= 0001 SMAP type=01 base= 0010 len= 3fef SMAP type=03 base= 3fff3000 len= d000 SMAP type=04 base= 3fff len= 3000 Copyright (c) 1992-2001 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: Fri Aug 31 20:44:02 MEST 2001 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/MCSMP2 Calibrating clock(s) ... TSC clock: 998359401 Hz, i8254 clock: 1193183 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 CPU: Pentium III/Pentium III Xeon/Celeron (998.36-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 1073676288 (1048512K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x004ef000 - 0x3ffd, 1068437504 bytes (260849 pages) avail memory = 1040572416 (1016184K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 SMP: CPU0 apic_initialize(): lint0: 0x0700 lint1: 0x00010400 TPR: 0x0010 SVR: 0x01ff FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00178011, at 0xfec0 bios32: Found BIOS32 Service Directory header at 0xc00faed0 bios32: Entry = 0xfb340 (c00fb340) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xb370 pnpbios: Found PnP BIOS data at 0xc00fbd80 pnpbios: Entry = f:bdb0 Rev = 1.0 Other BIOS signatures found: Preloaded elf kernel kernel at 0xc04c6000. Preloaded elf module acpi.ko at 0xc04c60a8. null: null device, zero device random: entropy source mem: memory I/O Pentium Pro MTRR support enabled SMP: CPU0 bsp_apic_configure(): lint0: 0x00010700 lint1: 0x0400 TPR: 0x0010 SVR: 0x01ff pci_open(1):mode 1 addr port (0x0cf8) is 0x80010048 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=06911106) Using $PIR table, 8 entries at 0xc00fdbc0 npx0: math processor on motherboard npx0: INT 16 interface acpi0: VIA694 AWRDACPI on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_button0: Power Button on acpi0 panic: pmap_mapdev: Couldn't alloc kernel virtual memory cpuid = 0; lapic.id = Debugger(panic) Stopped at Debugger+0x46: pushl %ebx db t Debugger(c0345ed9) at Debugger+0x46 panic(c036b500,0,c2d8f300,c2d8e180,c2d8f180) at panic+0xd8 pmap_mapdev(10,3fef,c2d4a0a8,c2d7dd80,c04e7db8) at pmap_mapdev+0x46 nexus_activate_resource(c2d7dd80,c2d8e180,3,7,c2d8f300) at nexus_activate_resource+0x45 bus_generic_activate_resource(c2d7db80,c2d8e180,3,7,c2d8f300) at bus_generic_activate_resource+0x56 bus_activate_resource(c2d8e180,3,7,c2d8f300) at bus_activate_resource+0x5b nexus_alloc_resource(c2d7dd80,c2d8e180,3,c04e7ef8,10) at nexus_alloc_resource+0x109 resource_list_alloc(c205d16c,c2d7db80,c2d8e180,3,c04e7ef8) at resource_list_alloc+0x156 acpi_alloc_resource(c2d7db80,c2d8e180,3,c04e7ef8,0) at acpi_alloc_resource+0x38 bus_alloc_resource(c2d8e180,3,c04e7ef8,0,) at bus_alloc_resource+0x63 acpi_sysresource_attach(c2d8e180,c2d8e180,c2d7db80,c2d7db80,0) at acpi_sysresource_attach+0x3c device_probe_and_attach(c2d8e180) at device_probe_and_attach+0x9a bus_generic_attach(c2d7db80,c2d7db1c,c2d7db00,c2d23ca0,c04e7f5c) at bus_generic_attach+0x16 acpi_probe_children(c2d7db80,c2d6b088,c2d7dd80,c2d7db80,c04e7f7c) at acpi_probe_children+0x64 acpi_attach(c2d7db80,c2d7db80,c2d7dd80,c2d7dd80,1) at acpi_attach+0x1bc device_probe_and_attach(c2d7db80) at device_probe_and_attach+0x9a
Re: symlink(2) [Was: Re: tcsh.cat]
Bruce Evans wrote: No, the empty pathname has been invalid and not an alias for . since at least the first version of POSIX. That's the same time they broke signal restart and file locks, right? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Fri, 31 Aug 2001, Brian F. Feldman wrote: Bruce Evans [EMAIL PROTECTED] wrote: On Fri, 31 Aug 2001, Brian F. Feldman wrote: Bruce Evans [EMAIL PROTECTED] wrote: Here's an example of a standard utility being clueless about symlinks to nothing: $ ln -s '' foo $ cp foo bar cp: foo is a directory (not copied) foo is certainly not a directory. The bug seems to be in fts. No, foo certainly _is_ a directory. It is precisely the same thing as .. No, the empty pathname has been invalid and not an alias for . since at least the first version of POSIX. I didn't read the rest of the thread til later ;) The fact remains that FreeBSD interprets it as such in namei(), and is it not an undefined behavior according to POSIX? See Garrett's reply. The empty pathname is certainly invalid when passed from userland, but POSIX apparently requires it to work when it came from a symlink to . I concluded the rest of the thread that the POSIX spec is natural, what a lot of namei()'s do, and wrong. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: symlink(2) [Was: Re: tcsh.cat]
On Fri, 31 Aug 2001, Terry Lambert wrote: Bruce Evans wrote: No, the empty pathname has been invalid and not an alias for . since at least the first version of POSIX. That's the same time they broke signal restart and file locks, right? Only the file locks :-). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
I'm going to double-check my config against GENERIC, but I've been seeing this since
before the new changes.
Because of that one problem with the missing file the other day, I simply blasted and
re-synched my /usr/src/sys, so I am definitely
running the latest sources.
My motherboard is a Tyan S1696-DLUA dual P2-333. I am using the latest known bios
updates. ACPI is enabled, and APM disabled in
the BIOS. This happens regardless if PnP is on or off in the BIOS.
[dmesg | grep -i acpi]
ACPI debug layer 0x0 debug level 0x0
tbxface-0170: *** Error: AcpiLoadTables: Could not get RSDP, AE_NO_ACPI_TABLES
tbxface-0222: *** Error: AcpiLoadTables: Could not load tables: AE_NO_ACPI_TABLES
ACPI: table load failed: AE_NO_ACPI_TABLES
Andy Farkas wrote:
On Thu, 30 Aug 2001, Bruce Evans wrote:
I've found acpica as useful as any other disk filling service and hope
it stays that way.
Bruce
Can someone put this in fortunes.dat :)
--
:{ [EMAIL PROTECTED]
Andy Farkas
System Administrator
Speednet Communications
http://www.speednet.com.au/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
jim
--
ET has one helluva sense of humor!
He's always anal-probing right-wing schizos!
POWER TO THE PEOPLE!
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
PATCH: if_tap device cloning (final)
Hackers, Attached some patches that implements device cloning (with devfs(5) support) for tap(4). The implementation is based on resource manager (see tun(4) and gif(4)). Brooks Davis ([EMAIL PROTECTED]) took a quick look at the patch and seems has no objection. Please review, test and if there is no objection Brooks Davis will commit it. If there are any problems, please let me know. thanks, max p.s. i'm not on freebsd-net list, so please reply directly p.p.s. Brooks Davis wrote: [...] Looks good. If could post a copy to freebsd-net and give it another 24hrs or so for other responses, I'll commit it if nothing else comes up. diff -ru /usr/src/share/man/man4/tap.4 ./src/share/man/man4/tap.4 --- /usr/src/share/man/man4/tap.4 Thu Aug 30 14:23:44 2001 +++ ./src/share/man/man4/tap.4 Thu Aug 30 15:14:40 2001 @@ -1,4 +1,4 @@ -.\ $FreeBSD: src/share/man/man4/tap.4,v 1.8 2001/08/07 15:48:39 ru Exp $ +.\ $FreeBSD: src/share/man/man4/tap.4,v 1.7 2001/05/01 09:15:13 schweikh Exp $ .\ Based on PR#2411 .\ .Dd July 9, 2000 @@ -36,11 +36,50 @@ interface. .Pp The network interfaces are named -.Sy tap Ns Ar 0 , -.Sy tap Ns Ar 1 , -etc, as many as were made by -.Xr MAKEDEV 8 . -Each one supports the usual Ethernet network-interface +.Dq Li tap0 , +.Dq Li tap1 , +etc., one for each control device that has been opened. +These Ethernet network interfaces persist until +.Pa if_tap.ko +module is unloaded (if +.Nm +is built into your kernel, the network interfaces can not be removed). +.Pp +On older systems without +.Xr devfs 5 +support, +.Xr MAKEDEV 8 +should be used to create the initial control devices and the task +of locating an unused device is left up to the opener (a +.Nm +device is usually obtained by attempting to open +.Pa /dev/tap0 , +and if that fails +.Pa /dev/tap1 +etc., until an +.Va errno +of +.Er EBUSY +is not received). +.Pp +On systems with +.Xr devfs 5 +support, +.Nm +permits opens on the special control device +.Pa /dev/tap . +When this device is opened, +.Nm +will return a handle for the lowest unused +.Nm +device (use +.Xr devname 3 +to determine which). +Control devices (once successfully opened) persist until +.Pa if_tap.ko +is unloaded in the same way that network interfaces persist (see above). +.Pp +Each interface supports the usual Ethernet network interface .Xr ioctl 2 Ns s , such as .Dv SIOCSIFADDR @@ -56,7 +95,7 @@ there); writing an Ethernet frame to the control device generates an input frame on the network interface, as if the -(non-existent) +.Pq non-existent hardware had just received it. .Pp The Ethernet tunnel device, normally @@ -91,15 +130,14 @@ .Fn write . Writes will not block; if the frame cannot be accepted for a transient reason -(e.g., no buffer space available), +.Pq e.g., no buffer space available , it is silently dropped; if the reason is not transient -(e.g., frame too large), +.Pq e.g., frame too large , an error is returned. The following .Xr ioctl 2 calls are supported -(defined in -.Aq Pa net/if_tap.h ) : +.Pq defined in Aq Pa net/if_tap.h Ns : .Bl -tag -width VMIO_SIOCSETMACADDR .It Dv TAPSDEBUG The argument should be a pointer to an @@ -115,7 +153,7 @@ Turn non-blocking I/O for reads off or on, according as the argument .Va int Ns 's value is or isn't zero -(Writes are always nonblocking). +.Pq Writes are always nonblocking . .It Dv FIOASYNC Turn asynchronous I/O for reads (i.e., generation of @@ -172,8 +210,7 @@ .Dq remote side. This command is used by VMware port and expected to be executed on a descriptor, associated with control device -(usually -.Pa /dev/vmnet Ns Sy N ) . +.Pq usually Pa /dev/vmnet Ns Sy N . .El .Pp The control device also supports @@ -199,7 +236,7 @@ and .Nm vmnet devices. VMnet minor numbers begin at -.Va 0x1 +.Va 0x80 + .Va N . Where diff -ru /usr/src/sys/net/if_tap.c ./src/sys/net/if_tap.c --- /usr/src/sys/net/if_tap.c Mon Mar 26 04:41:17 2001 +++ ./src/sys/net/if_tap.c Thu Aug 30 17:51:00 2001 @@ -54,6 +54,9 @@ #include sys/ttycom.h #include sys/uio.h #include sys/vnode.h +#include machine/bus.h /* XXX: Shouldn't really be required! */ +#include sys/rman.h +#include sys/queue.h #include net/bpf.h #include net/ethernet.h @@ -73,7 +76,9 @@ #define TAPtap #define VMNET vmnet -#define VMNET_DEV_MASK 0x0001 +#define TAPMAXUNIT 0x7fff +#define VMNET_DEV_MASK 0x0080 + /* 0x007f00ff */ /* module */ static int tapmodevent __P((module_t, int, void *)); @@ -111,9 +116,12 @@ /* flags */ 0, }; -static int taprefcnt = 0; /* module ref. counter */ -static int taplastunit = -1; /* max. open unit number */ -static int tapdebug = 0; /* debug flag*/ +static int tapdebug = 0;/* debug flag */ +static SLIST_HEAD(, tap_softc) taphead; /* first
