RE: ARLA 0.35.11 on FreeBSD 5.0-RC1
Now that I'm having much better luck with -current, I haven't had the time to go back and look into arla. Also, since that time there has been a fair amount of progress with openafs support for freebsd, and for my own purposes that would be an easier sell to my managers anyway. [not that I have openafs working on -current either, but I do hope to get to that soon...] I don't actually care about whether it's arla or openafs (we are running openafs on linux boxes and it's running OK) but I need to have AFS client (and even better a server) working. I've noticed some rather sporadic mails on freebsd port openafs mailing list but I felt like it's not under heavy development. BTW: how about commiting openafs to the ports tree to have at least some common place for patches that can be tested... If I can help with getting one (or both) of these ported to -CURRENT I'd be happy to do so (e.g. testing of current patches etc.) Petr Petr Holub CESNET z.s.p.o. Supercomputing Center Brno Zikova 4 Institute of Compt. Science 160 00 Praha 6, CZMasaryk University Czech Republic Botanicka 68a, 60200 Brno, CZ e-mail: [EMAIL PROTECTED] phone: +420-5-41512213 e-mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sshd only allows connections per public key since this week
this is almost the complete report, i get the on this list already mentioned error message fatal: ssh_msg_send: write when i try to use password (pam?) authentication to my current box (same effect from anywhere). As the title says, public_key authentication works. This effect started to show up over the weekend. Greetings -- Fritz Heinrichmeyer mailto:[EMAIL PROTECTED] FernUniversitaet Hagen, LG ES, 58084 Hagen (Germany) tel:+49 2331/987-1166 fax:987-355 http://www-es.fernuni-hagen.de/~jfh To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ARLA 0.35.11 on FreeBSD 5.0-RC1
On Mon, Dec 16, 2002 at 01:34:35PM -0500, Garance A Drosihn wrote: When I was looking into this, I was talking with Andrea Campi about some changes he had for arla on -current. He was also very busy at the time, but maybe he still has that around. (I'm in the middle I used to have patches that allowed me to compile arla, yes - but that was a long time ago, I haven't updated them for more recent versions of Arla. More interesting, I had patches to put the xfs layer in the kernel, and I was able to run with them linked in or as a module. Locking however was very primitive, and I'm not sure it still compiles cleanly. However, my company has since dropped its AFS project, so I don't have any test lab available anymore. If anybody would want to take over the project, I might be able to help - but not much more than that. Bye, Andrea -- Failure is not an option. It comes bundled with your Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
How to update UFS1 to UFS2?
Have an existing partition with UFS1 on it. How can i update/convert it to UFS2? It is safe make it that way: dump -0 -f /store/arch.usr /usr shutdown now umount -a /usr mount / mount /store newfs -O2 /dev/ad0s2e restore -f /store/arch.usr /store is fat32 partition. Is there another way? -- Vitaly Markitantov mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ARLA 0.35.11 on FreeBSD 5.0-RC1
Andrea Campi [EMAIL PROTECTED] writes: On Mon, Dec 16, 2002 at 01:34:35PM -0500, Garance A Drosihn wrote: When I was looking into this, I was talking with Andrea Campi about some changes he had for arla on -current. He was also very busy at the time, but maybe he still has that around. (I'm in the middle I used to have patches that allowed me to compile arla, yes - but that was a long time ago, I haven't updated them for more recent versions of Arla. More interesting, I had patches to put the xfs layer in the kernel, and I was able to run with them linked in or as a module. Locking however was very primitive, and I'm not sure it still compiles cleanly. I added most off the Andrea's patches into current arla, so there is better hope of getting that working with FreeBSD 5.0 current. I just downloaded the RC1 images and will see if I can get it working later today. Love To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Lock GEOM topology not exclusively locked
I've updated today's -current (HEAD). I got this messages after rebooting. Is it OK? Lock GEOM topology not exclusively locked @ ../../../geom/geom_mbr.c:118 Lock GEOM topology not exclusively locked @ ../../../geom/geom_slice.c:298 Lock GEOM topology not exclusively locked @ ../../../geom/geom_slice.c:298 Lock GEOM topology not exclusively locked @ ../../../geom/geom_slice.c:298 Lock GEOM topology not exclusively locked @ ../../../geom/geom_slice.c:298 Lock GEOM topology not exclusively locked @ ../../../geom/geom_slice.c:298 Lock GEOM topology not exclusively locked @ ../../../geom/geom_subr.c:176 Lock GEOM topology not exclusively locked @ ../../../geom/geom_event.c:279 Lock GEOM topology not exclusively locked @ ../../../geom/geom_slice.c:298 Lock GEOM topology not exclusively locked @ ../../../geom/geom_slice.c:298 Lock GEOM topology not exclusively locked @ ../../../geom/geom_slice.c:298 -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Lock GEOM topology not exclusively locked
In message [EMAIL PROTECTED], Jun Kuriyama writes: I've updated today's -current (HEAD). I got this messages after rebooting. Is it OK? No, it's not, but your system is almost certainly unharmed. Fixed a second a go. Thanks! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | 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: 5.0 performance (was: 80386 out of GENERIC)
When I put KDE 3.0.5 on my 5.0-RC1 box it took just about 20 hours (600mhz with 384MB PC100... backup box ;)) but it runs faster (as compared to KDE on a 4.7-RELEASE). Im willing to give up a bit more comiple time to get better performance out of my apps. =) -Nick Harm Hale - Original Message - From: Cliff L. Biffle [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 17, 2002 1:29 AM Subject: Re: 5.0 performance (was: 80386 out of GENERIC) On Tuesday 17 December 2002 12:19 am, Garance A Drosihn wrote: At 5:58 AM +0100 12/17/02, Cliff Sarginson wrote: Also didn't someone mention that GCC has got slower anyway ? gcc is slower at compiling things. This is very noticeable when you're doing a buildworld. The code which gcc 3.2.1 produces does not seem any slower than the code produced by gcc 2.95.4 (the version in freebsd-stable). Actually, in my benchmarks here, the same code tends to yield much faster executables under gcc3, particularly in C++. But these are limited benchmarks (primarily of KDE and my own applications). I'm willing to trade some time on the compile (which, with any luck, happens only once) in exchange for speed in the application (which I may use every day)! :-) -Cliff L. Biffle 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: How to update UFS1 to UFS2?
On Tue, Dec 17, 2002 at 11:29:05AM +0200, Vitaly Markitantov wrote: Have an existing partition with UFS1 on it. How can i update/convert it to UFS2? It is safe make it that way: dump -0 -f /store/arch.usr /usr shutdown now umount -a /usr mount / mount /store newfs -O2 /dev/ad0s2e restore -f /store/arch.usr About right, but I'd do it just a little differently: shutdown now umount /usr dump 0af /store/arch.usr /dev/ad0s2e newfs -O 2 -U /dev/ad0s2e mount /usr cd /usr restore rf /store/arch.usr -- Ray Kohler [EMAIL PROTECTED] As Zeus said to Narcissus, Watch yourself. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ata driver
The current ata driver on pc98 has a problem. I think that the
following patch solves the problem. Please review it. This change
must be in RELENG_5_0 branch.
Index: sys/dev/ata/ata-disk.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-disk.c,v
retrieving revision 1.137
diff -u -r1.137 ata-disk.c
--- sys/dev/ata/ata-disk.c 3 Dec 2002 20:19:37 - 1.137
+++ sys/dev/ata/ata-disk.c 8 Dec 2002 08:50:01 -
@@ -123,6 +123,14 @@
adp-heads = atadev-param-heads;
adp-sectors = atadev-param-sectors;
adp-total_secs = atadev-param-cylinders * adp-heads * adp-sectors;
+#ifdef PC98
+if (adp-total_secs 17 * 8 * 65536) {
+ /* convert PC98 geometry */
+ adp-sectors = 17;
+ adp-heads = 8;
+ atadev-param-cylinders = adp-total_secs / (17 * 8);
+}
+#endif
adp-max_iosize = 256 * DEV_BSIZE;
bioq_init(adp-queue);
Index: sys/geom/geom_pc98.c
===
RCS file: /home/ncvs/src/sys/geom/geom_pc98.c,v
retrieving revision 1.20
diff -u -r1.20 geom_pc98.c
--- sys/geom/geom_pc98.c3 Dec 2002 20:18:35 - 1.20
+++ sys/geom/geom_pc98.c8 Dec 2002 04:47:43 -
@@ -190,10 +190,6 @@
sectorsize = cp-provider-sectorsize;
if (sectorsize 512)
break;
- if (cp-provider-mediasize / sectorsize 17 * 8 * 65536) {
- fwsectors = 17;
- fwheads = 8;
- }
gsp-frontstuff = sectorsize * fwsectors;
spercyl = (off_t)fwsectors * fwheads * sectorsize;
buf = g_read_data(cp, 0,
---
TAKAHASHI Yoshihiro [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
sio and ed woes
Hi I have a problem getting CURRENT to find my ISA SMC Ultra ethernet card. No matter what I do I can't stop the kernel finding a third sio device on top of the memory and interrupt that the ed card occupies. The kernel correctly registers its surprise at finding the third sio device since no hints for it exist: sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio2: configured irq 10 not in bitmap of probed irqs 0 sio2: port may not be enabled sio2 port 0x2e8-0x2ef irq 10 on acpi0 sio2: type 16550A I've tried setting hint.sio.2.disabled=1. I've tried leaving it out. I can't not have sio because this server is my router and is permanently connected to a modem. The SMC Ultra card exists on 0x280 irq 10 0xd8000. Has current dropped ISA support (which was hinted at in the GENERIC/80386 thread)? Any ideas? Kernel config, device.hints, dmesg.boot follows. Ian Copyright (c) 1992-2002 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 #2: Tue Dec 17 14:17:13 SAST 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/BRANE-DEAD Preloaded elf kernel /boot/kernel/kernel at 0xc0455000. Timecounter i8254 frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (267.27-MHz 686-class CPU) Origin = GenuineIntel Id = 0x634 Stepping = 4 Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,MMX real memory = 201261056 (191 MB) avail memory = 190504960 (181 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 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: 0x00170011, at 0xfec0 Initializing GEOMetry subsystem Pentium Pro MTRR support enabled acpi0: GBTAWRDACPI on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 Using $PIR table, 8 entries at 0xc00fdc60 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-safe frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 acpi_cpu0: CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0x5000-0x500f,0x4000-0x4041,0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 IOAPIC #0 intpin 16 - irq 2 agp0: Intel 82443LX (440 LX) host to PCI bridge mem 0xe000-0xe3ff at device 0.0 on pci0 pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xe000-0xe01f irq 12 at device 7.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered Timecounter PIIX frequency 3579545 Hz pci0: bridge, PCI-unknown at device 7.3 (no driver attached) xl0: 3Com 3c905-TX Fast Etherlink XL port 0xe400-0xe43f irq 2 at device 8.0 on pci0 xl0: Ethernet address: 00:60:08:0b:2e:c8 miibus0: MII bus on xl0 nsphy0: DP83840 10/100 media interface on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ahc0: Adaptec aic7880 Ultra SCSI adapter port 0xe800-0xe8ff mem 0xe900-0xe9000fff irq 2 at device 12.0 on pci0 ahc0: Using left over BIOS settings aic7880: Ultra Single Channel A, SCSI Id=7, 16/253 SCBs fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio2: configured irq 10 not in bitmap of probed irqs 0 sio2: port may not be enabled sio2 port 0x2e8-0x2ef irq 10 on acpi0 sio2: type 16550A ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 npx0: math processor on motherboard npx0: INT 16 interface orm0: Option ROMs at iomem 0xc8000-0xc87ff,0xc-0xc7fff on isa0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 Timecounters tick every 10.000 msec acpi_cpu: CPU throttling enabled, 8 steps from 100% to 12.5% ad0: 4103MB ST34342A [8894/15/63] at ata0-master UDMA33 Waiting 15 seconds for SCSI
Re: ata driver
I really wish somebody could tell us conclusively when to use
the compat geometry and when not ?
Is it only for ATA/IDE disks ?
Does it depend on the size of the disks ?
Does it also affect SCSI disks ?
Poul-Henning
In message [EMAIL PROTECTED], Takahashi Yoshihiro
writes:
The current ata driver on pc98 has a problem. I think that the
following patch solves the problem. Please review it. This change
must be in RELENG_5_0 branch.
Index: sys/dev/ata/ata-disk.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-disk.c,v
retrieving revision 1.137
diff -u -r1.137 ata-disk.c
--- sys/dev/ata/ata-disk.c 3 Dec 2002 20:19:37 - 1.137
+++ sys/dev/ata/ata-disk.c 8 Dec 2002 08:50:01 -
@@ -123,6 +123,14 @@
adp-heads = atadev-param-heads;
adp-sectors = atadev-param-sectors;
adp-total_secs = atadev-param-cylinders * adp-heads * adp-sectors;
+#ifdef PC98
+if (adp-total_secs 17 * 8 * 65536) {
+ /* convert PC98 geometry */
+ adp-sectors = 17;
+ adp-heads = 8;
+ atadev-param-cylinders = adp-total_secs / (17 * 8);
+}
+#endif
adp-max_iosize = 256 * DEV_BSIZE;
bioq_init(adp-queue);
Index: sys/geom/geom_pc98.c
===
RCS file: /home/ncvs/src/sys/geom/geom_pc98.c,v
retrieving revision 1.20
diff -u -r1.20 geom_pc98.c
--- sys/geom/geom_pc98.c 3 Dec 2002 20:18:35 - 1.20
+++ sys/geom/geom_pc98.c 8 Dec 2002 04:47:43 -
@@ -190,10 +190,6 @@
sectorsize = cp-provider-sectorsize;
if (sectorsize 512)
break;
- if (cp-provider-mediasize / sectorsize 17 * 8 * 65536) {
- fwsectors = 17;
- fwheads = 8;
- }
gsp-frontstuff = sectorsize * fwsectors;
spercyl = (off_t)fwsectors * fwheads * sectorsize;
buf = g_read_data(cp, 0,
---
TAKAHASHI Yoshihiro [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | 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: ata driver
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: Is it only for ATA/IDE disks ? Does it depend on the size of the disks ? Only for the internal IDE controller. The internal IDE controller on pc98 uses the fixed geometry which is 8 heads and 17 sectors. If the size of the disk is larger than 4.2GB (65535C x 8H x 17S x 512B), a different geometry depend on the disk is used. Does it also affect SCSI disks ? No. --- TAKAHASHI Yoshihiro [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ata driver
In message [EMAIL PROTECTED], Takahashi Yoshihiro
writes:
In article [EMAIL PROTECTED]
[EMAIL PROTECTED] writes:
Is it only for ATA/IDE disks ?
Does it depend on the size of the disks ?
Only for the internal IDE controller. The internal IDE controller on
pc98 uses the fixed geometry which is 8 heads and 17 sectors. If the
size of the disk is larger than 4.2GB (65535C x 8H x 17S x 512B), a
different geometry depend on the disk is used.
I guess the correct pseudocode then is:
if (disk is ata
unit 4
size 65535C x 8H x 17S x 512B) {
use 8/17 geometry
}
Is this correctly understood ?
So this would not affect an IDE controller in a PCI slot ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | 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: ata driver
It seems Takahashi Yoshihiro wrote:
In article [EMAIL PROTECTED]
[EMAIL PROTECTED] writes:
Is it only for ATA/IDE disks ?
Does it depend on the size of the disks ?
Only for the internal IDE controller. The internal IDE controller on
pc98 uses the fixed geometry which is 8 heads and 17 sectors. If the
size of the disk is larger than 4.2GB (65535C x 8H x 17S x 512B), a
different geometry depend on the disk is used.
OK, could you try this patch then (and probably still rip out the
stuff in GEOM)...
Index: ata-all.h
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-all.h,v
retrieving revision 1.55
diff -u -r1.55 ata-all.h
--- ata-all.h 3 Dec 2002 20:19:37 - 1.55
+++ ata-all.h 17 Dec 2002 14:29:12 -
@@ -213,9 +213,10 @@
intflags; /* controller flags */
#defineATA_NO_SLAVE0x01
#defineATA_USE_16BIT 0x02
-#defineATA_ATAPI_DMA_RO0x04
-#defineATA_QUEUED 0x08
-#defineATA_DMA_ACTIVE 0x10
+#defineATA_USE_PC98GEOM0x04
+#defineATA_ATAPI_DMA_RO0x08
+#defineATA_QUEUED 0x10
+#defineATA_DMA_ACTIVE 0x20
struct ata_device device[2]; /* devices on this channel */
#defineMASTER 0x00
Index: ata-cbus.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-cbus.c,v
retrieving revision 1.1
diff -u -r1.1 ata-cbus.c
--- ata-cbus.c 3 Dec 2002 20:19:37 - 1.1
+++ ata-cbus.c 17 Dec 2002 14:28:21 -
@@ -239,7 +239,7 @@
ch-unit = i;
}
free(children, M_TEMP);
-ch-flags |= ATA_USE_16BIT;
+ch-flags |= ATA_USE_16BIT | ATA_USE_PC98GEOM;
ch-intr_func = ata_cbus_intr;
ch-lock_func = ata_cbus_banking;
return ata_probe(dev);
Index: ata-disk.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-disk.c,v
retrieving revision 1.138
diff -u -r1.138 ata-disk.c
--- ata-disk.c 6 Dec 2002 19:29:53 - 1.138
+++ ata-disk.c 17 Dec 2002 14:34:27 -
@@ -124,6 +124,11 @@
adp-sectors = atadev-param-sectors;
adp-total_secs = atadev-param-cylinders * adp-heads * adp-sectors;
adp-max_iosize = 256 * DEV_BSIZE;
+if (adp-device-channel-flags ATA_USE_PC98GEOM
+ adp-total_secs 17 * 8 * 65536) {
+ adp-sectors = 17;
+ adp-heads = 8;
+}
bioq_init(adp-queue);
lbasize = (u_int32_t)atadev-param-lba_size_1 |
-Søren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ata driver
In article [EMAIL PROTECTED]
[EMAIL PROTECTED] writes:
I guess the correct pseudocode then is:
if (disk is ata
unit 4
size 65535C x 8H x 17S x 512B) {
use 8/17 geometry
}
Is this correctly understood ?
So this would not affect an IDE controller in a PCI slot ?
Oh, I think that an IDE controller on PCI bus is also so. Therefore,
the above condition is
if (disk is ata size 65535C x 8H x 17S x 512B) {
...
}
In article [EMAIL PROTECTED]
Soeren Schmidt [EMAIL PROTECTED] writes:
OK, could you try this patch then (and probably still rip out the
stuff in GEOM)...
This patch has no problem. I have succeeded in using all disks on my
pc98.
Thank you.
---
TAKAHASHI Yoshihiro [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: 5.0 performance (was: 80386 out of GENERIC)
On 2002-12-16 23:24, Gary Stanley [EMAIL PROTECTED] wrote: At 03:45 AM 12/17/2002 +0200, Giorgos Keramidas wrote: I still have the Pentium 133 with 64 MB or memory that I used to run 5.0-CURRENT until a few weeks ago. I haven't got any real numbers, but the general `feel' of the system was pretty good. [...] Read the top of /usr/src/UPDATING Explains most of the slow problems. You got me backwards there. Removing all sort of debugging from current actually results in a fairly stable and fast system. It's the build of it all that is slow on an old machine (for obvious reasons, since FreeBSD is now a big system with a lot of tools). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: How to update UFS1 to UFS2?
On a related topic... how do you tell which of your filesystems are mounted UFS1 -vs- UFS2? 'mount -v' just says ufs. -Steve - Original Message - From: Ray Kohler [EMAIL PROTECTED] To: Vitaly Markitantov [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, December 17, 2002 6:54 AM Subject: Re: How to update UFS1 to UFS2? On Tue, Dec 17, 2002 at 11:29:05AM +0200, Vitaly Markitantov wrote: Have an existing partition with UFS1 on it. How can i update/convert it to UFS2? It is safe make it that way: dump -0 -f /store/arch.usr /usr shutdown now umount -a /usr mount / mount /store newfs -O2 /dev/ad0s2e restore -f /store/arch.usr About right, but I'd do it just a little differently: shutdown now umount /usr dump 0af /store/arch.usr /dev/ad0s2e newfs -O 2 -U /dev/ad0s2e mount /usr cd /usr restore rf /store/arch.usr -- Ray Kohler [EMAIL PROTECTED] As Zeus said to Narcissus, Watch yourself. 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: How to update UFS1 to UFS2?
On Tue, Dec 17, 2002 at 11:47:23AM -0500, Steven Ames wrote: On a related topic... how do you tell which of your filesystems are mounted UFS1 -vs- UFS2? 'mount -v' just says ufs. -Steve Maybe dumpfs(8) will help you. -- Aurelien msg48915/pgp0.pgp Description: PGP signature
C64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/tinderbox/c64/obj/home/tinderbox/c64/src/c64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sun Dec 15 10:07:13 PST 2002 -- === xe /home/tinderbox/c64/src/sys/contrib/dev/acpica/hwregs.c: In function `AcpiGetSleepTypeData': /home/tinderbox/c64/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards qualifiers from pointer target type /home/tinderbox/c64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetRegionName': /home/tinderbox/c64/src/sys/contrib/dev/acpica/utglobal.c:482: warning: cast discards qualifiers from pointer target type /home/tinderbox/c64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetEventName': /home/tinderbox/c64/src/sys/contrib/dev/acpica/utglobal.c:520: warning: cast discards qualifiers from pointer target type /home/tinderbox/c64/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetTypeName': /home/tinderbox/c64/src/sys/contrib/dev/acpica/utglobal.c:590: warning: cast discards qualifiers from pointer target type /home/tinderbox/c64/src/sys/contrib/dev/acpica/utglobal.c:593: warning: cast discards qualifiers from pointer target type /home/tinderbox/c64/src/sys/dev/acpica/acpi_powerres.c:272: warning: `acpi_pwr_deregister_consumer' defined but not used /home/tinderbox/c64/src/sys/dev/acpica/acpi_powerres.c:210: warning: `acpi_pwr_deregister_resource' defined but not used cc1: warnings being treated as errors /home/tinderbox/c64/src/sys/ufs/ffs/ffs_snapshot.c: In function `ffs_snapshot': /home/tinderbox/c64/src/sys/ufs/ffs/ffs_snapshot.c:542: warning: cast to pointer from integer of different size /home/tinderbox/c64/src/sys/ufs/ffs/ffs_snapshot.c:557: warning: cast to pointer from integer of different size /home/tinderbox/c64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs1': /home/tinderbox/c64/src/sys/ufs/ffs/ffs_snapshot.c:1002: warning: cast to pointer from integer of different size /home/tinderbox/c64/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs2': /home/tinderbox/c64/src/sys/ufs/ffs/ffs_snapshot.c:1278: warning: cast to pointer from integer of different size *** Error code 1 Stop in /home/tinderbox/c64/obj/home/tinderbox/c64/src/sys/GENERIC. *** Error code 1 Stop in /home/tinderbox/c64/src. *** Error code 1 Stop in /home/tinderbox/c64/src. _ For the best comics, toys, movies, and more, please visit http://www.tfaw.com/?qt=wmf To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Amiga 500 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/tinderbox/a500/obj/home/tinderbox/a500/src/a500/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sun Dec 15 10:07:13 PST 2002 -- === xe /home/tinderbox/a500/src/sys/contrib/dev/acpica/hwregs.c: In function `AcpiGetSleepTypeData': /home/tinderbox/a500/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards qualifiers from pointer target type /home/tinderbox/a500/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetRegionName': /home/tinderbox/a500/src/sys/contrib/dev/acpica/utglobal.c:482: warning: cast discards qualifiers from pointer target type /home/tinderbox/a500/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetEventName': /home/tinderbox/a500/src/sys/contrib/dev/acpica/utglobal.c:520: warning: cast discards qualifiers from pointer target type /home/tinderbox/a500/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetTypeName': /home/tinderbox/a500/src/sys/contrib/dev/acpica/utglobal.c:590: warning: cast discards qualifiers from pointer target type /home/tinderbox/a500/src/sys/contrib/dev/acpica/utglobal.c:593: warning: cast discards qualifiers from pointer target type /home/tinderbox/a500/src/sys/dev/acpica/acpi_powerres.c:272: warning: `acpi_pwr_deregister_consumer' defined but not used /home/tinderbox/a500/src/sys/dev/acpica/acpi_powerres.c:210: warning: `acpi_pwr_deregister_resource' defined but not used cc1: warnings being treated as errors /home/tinderbox/a500/src/sys/ufs/ffs/ffs_snapshot.c: In function `ffs_snapshot': /home/tinderbox/a500/src/sys/ufs/ffs/ffs_snapshot.c:542: warning: cast to pointer from integer of different size /home/tinderbox/a500/src/sys/ufs/ffs/ffs_snapshot.c:557: warning: cast to pointer from integer of different size /home/tinderbox/a500/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs1': /home/tinderbox/a500/src/sys/ufs/ffs/ffs_snapshot.c:1002: warning: cast to pointer from integer of different size /home/tinderbox/a500/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs2': /home/tinderbox/a500/src/sys/ufs/ffs/ffs_snapshot.c:1278: warning: cast to pointer from integer of different size *** Error code 1 Stop in /home/tinderbox/a500/obj/home/tinderbox/a500/src/sys/GENERIC. *** Error code 1 Stop in /home/tinderbox/a500/src. *** Error code 1 Stop in /home/tinderbox/a500/src. _ For the best comics, toys, movies, and more, please visit http://www.tfaw.com/?qt=wmf To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
pdp11 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/tinderbox/pdp11/obj/home/tinderbox/pdp11/src/pdp11/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sun Dec 15 10:07:13 PST 2002 -- === xe /home/tinderbox/pdp11/src/sys/contrib/dev/acpica/hwregs.c: In function `AcpiGetSleepTypeData': /home/tinderbox/pdp11/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards qualifiers from pointer target type /home/tinderbox/pdp11/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetRegionName': /home/tinderbox/pdp11/src/sys/contrib/dev/acpica/utglobal.c:482: warning: cast discards qualifiers from pointer target type /home/tinderbox/pdp11/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetEventName': /home/tinderbox/pdp11/src/sys/contrib/dev/acpica/utglobal.c:520: warning: cast discards qualifiers from pointer target type /home/tinderbox/pdp11/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetTypeName': /home/tinderbox/pdp11/src/sys/contrib/dev/acpica/utglobal.c:590: warning: cast discards qualifiers from pointer target type /home/tinderbox/pdp11/src/sys/contrib/dev/acpica/utglobal.c:593: warning: cast discards qualifiers from pointer target type /home/tinderbox/pdp11/src/sys/dev/acpica/acpi_powerres.c:272: warning: `acpi_pwr_deregister_consumer' defined but not used /home/tinderbox/pdp11/src/sys/dev/acpica/acpi_powerres.c:210: warning: `acpi_pwr_deregister_resource' defined but not used cc1: warnings being treated as errors /home/tinderbox/pdp11/src/sys/ufs/ffs/ffs_snapshot.c: In function `ffs_snapshot': /home/tinderbox/pdp11/src/sys/ufs/ffs/ffs_snapshot.c:542: warning: cast to pointer from integer of different size /home/tinderbox/pdp11/src/sys/ufs/ffs/ffs_snapshot.c:557: warning: cast to pointer from integer of different size /home/tinderbox/pdp11/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs1': /home/tinderbox/pdp11/src/sys/ufs/ffs/ffs_snapshot.c:1002: warning: cast to pointer from integer of different size /home/tinderbox/pdp11/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs2': /home/tinderbox/pdp11/src/sys/ufs/ffs/ffs_snapshot.c:1278: warning: cast to pointer from integer of different size *** Error code 1 Stop in /home/tinderbox/pdp11/obj/home/tinderbox/pdp11/src/sys/GENERIC. *** Error code 1 Stop in /home/tinderbox/pdp11/src. *** Error code 1 Stop in /home/tinderbox/pdp11/src. _ For the best comics, toys, movies, and more, please visit http://www.tfaw.com/?qt=wmf To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pdp11 tinderbox failure
Great I was waiting for this for too long. I'm going to install this on my 11/70 emulator as soon as it compiles again :-) How about a HP-65 port? harti On Tue, 17 Dec 2002, Matt Dillon wrote: MD MD-- MD Rebuilding the temporary build tree MD-- MD stage 1: bootstrap tools MD-- MD stage 2: cleaning up the object tree MD-- MD stage 2: rebuilding the object tree MD-- MD stage 2: build tools MD-- MD stage 3: cross tools MD-- MD stage 4: populating /home/tinderbox/pdp11/obj/home/tinderbox/pdp11/src/pdp11/usr/include MD-- MD stage 4: building libraries MD-- MD stage 4: make dependencies MD-- MD stage 4: building everything.. MD-- MD Kernel build for GENERIC started on Sun Dec 15 10:07:13 PST 2002 MD-- MD=== xe MD/home/tinderbox/pdp11/src/sys/contrib/dev/acpica/hwregs.c: MDIn function `AcpiGetSleepTypeData': MD/home/tinderbox/pdp11/src/sys/contrib/dev/acpica/hwregs.c:242: MDwarning: cast discards qualifiers from pointer target type MD/home/tinderbox/pdp11/src/sys/contrib/dev/acpica/utglobal.c: MDIn function `AcpiUtGetRegionName': MD/home/tinderbox/pdp11/src/sys/contrib/dev/acpica/utglobal.c:482: MDwarning: cast discards qualifiers from pointer target type MD/home/tinderbox/pdp11/src/sys/contrib/dev/acpica/utglobal.c: MDIn function `AcpiUtGetEventName': MD/home/tinderbox/pdp11/src/sys/contrib/dev/acpica/utglobal.c:520: MDwarning: cast discards qualifiers from pointer target type MD/home/tinderbox/pdp11/src/sys/contrib/dev/acpica/utglobal.c: MDIn function `AcpiUtGetTypeName': MD/home/tinderbox/pdp11/src/sys/contrib/dev/acpica/utglobal.c:590: MDwarning: cast discards qualifiers from pointer target type MD/home/tinderbox/pdp11/src/sys/contrib/dev/acpica/utglobal.c:593: MDwarning: cast discards qualifiers from pointer target type MD/home/tinderbox/pdp11/src/sys/dev/acpica/acpi_powerres.c:272: MDwarning: `acpi_pwr_deregister_consumer' defined but not MDused MD/home/tinderbox/pdp11/src/sys/dev/acpica/acpi_powerres.c:210: MDwarning: `acpi_pwr_deregister_resource' defined but not MDused MDcc1: warnings being treated as errors MD/home/tinderbox/pdp11/src/sys/ufs/ffs/ffs_snapshot.c: In MDfunction `ffs_snapshot': MD/home/tinderbox/pdp11/src/sys/ufs/ffs/ffs_snapshot.c:542: MDwarning: cast to pointer from integer of different size MD/home/tinderbox/pdp11/src/sys/ufs/ffs/ffs_snapshot.c:557: MDwarning: cast to pointer from integer of different size MD/home/tinderbox/pdp11/src/sys/ufs/ffs/ffs_snapshot.c: In MDfunction `mapacct_ufs1': MD/home/tinderbox/pdp11/src/sys/ufs/ffs/ffs_snapshot.c:1002: MDwarning: cast to pointer from integer of different size MD/home/tinderbox/pdp11/src/sys/ufs/ffs/ffs_snapshot.c: In MDfunction `mapacct_ufs2': MD/home/tinderbox/pdp11/src/sys/ufs/ffs/ffs_snapshot.c:1278: MDwarning: cast to pointer from integer of different size MD*** Error code 1 MD MDStop in MD/home/tinderbox/pdp11/obj/home/tinderbox/pdp11/src/sys/GENERIC. MD*** Error code 1 MD MDStop in /home/tinderbox/pdp11/src. MD*** Error code 1 MD MDStop in /home/tinderbox/pdp11/src. MD MD_ MDFor the best comics, toys, movies, and more, MDplease visit http://www.tfaw.com/?qt=wmf MD MD MDTo Unsubscribe: send mail to [EMAIL PROTECTED] MDwith unsubscribe freebsd-current in the body of the message MD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
VAX tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/tinderbox/vax/obj/home/tinderbox/vax/src/vax/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sun Dec 15 10:07:13 PST 2002 -- === xe /home/tinderbox/vax/src/sys/contrib/dev/acpica/hwregs.c: In function `AcpiGetSleepTypeData': /home/tinderbox/vax/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards qualifiers from pointer target type /home/tinderbox/vax/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetRegionName': /home/tinderbox/vax/src/sys/contrib/dev/acpica/utglobal.c:482: warning: cast discards qualifiers from pointer target type /home/tinderbox/vax/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetEventName': /home/tinderbox/vax/src/sys/contrib/dev/acpica/utglobal.c:520: warning: cast discards qualifiers from pointer target type /home/tinderbox/vax/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetTypeName': /home/tinderbox/vax/src/sys/contrib/dev/acpica/utglobal.c:590: warning: cast discards qualifiers from pointer target type /home/tinderbox/vax/src/sys/contrib/dev/acpica/utglobal.c:593: warning: cast discards qualifiers from pointer target type /home/tinderbox/vax/src/sys/dev/acpica/acpi_powerres.c:272: warning: `acpi_pwr_deregister_consumer' defined but not used /home/tinderbox/vax/src/sys/dev/acpica/acpi_powerres.c:210: warning: `acpi_pwr_deregister_resource' defined but not used cc1: warnings being treated as errors /home/tinderbox/vax/src/sys/ufs/ffs/ffs_snapshot.c: In function `ffs_snapshot': /home/tinderbox/vax/src/sys/ufs/ffs/ffs_snapshot.c:542: warning: cast to pointer from integer of different size /home/tinderbox/vax/src/sys/ufs/ffs/ffs_snapshot.c:557: warning: cast to pointer from integer of different size /home/tinderbox/vax/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs1': /home/tinderbox/vax/src/sys/ufs/ffs/ffs_snapshot.c:1002: warning: cast to pointer from integer of different size /home/tinderbox/vax/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs2': /home/tinderbox/vax/src/sys/ufs/ffs/ffs_snapshot.c:1278: warning: cast to pointer from integer of different size *** Error code 1 Stop in /home/tinderbox/vax/obj/home/tinderbox/vax/src/sys/GENERIC. *** Error code 1 Stop in /home/tinderbox/vax/src. *** Error code 1 Stop in /home/tinderbox/vax/src. _ For the best comics, toys, movies, and more, please visit http://www.tfaw.com/?qt=wmf To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
I'm leaving the project
Thanks to my dear friend Warner Losh. I've decided to leave FreeBSD and flame in another project. Maybe I could join OpenBSD, the seem to share my views on how to deal with other people. I hereby give maintainership of all my code to Warner, or, whoever wants it, for that matter. Thank you, Matthew _ For the best comics, toys, movies, and more, please visit http://www.tfaw.com/?qt=wmf To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VAX tinderbox failure
This is cross-compiled, isn't it? Or you guys have too much patience otherwise. On Tue, Dec 17, 2002 at 09:47:52AM -0800, Matt Dillon [EMAIL PROTECTED] wrote: -- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/tinderbox/vax/obj/home/tinderbox/vax/src/vax/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sun Dec 15 10:07:13 PST 2002 -- === xe /home/tinderbox/vax/src/sys/contrib/dev/acpica/hwregs.c: In function `AcpiGetSleepTypeData': /home/tinderbox/vax/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards qualifiers from pointer target type /home/tinderbox/vax/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetRegionName': /home/tinderbox/vax/src/sys/contrib/dev/acpica/utglobal.c:482: warning: cast discards qualifiers from pointer target type /home/tinderbox/vax/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetEventName': /home/tinderbox/vax/src/sys/contrib/dev/acpica/utglobal.c:520: warning: cast discards qualifiers from pointer target type /home/tinderbox/vax/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetTypeName': /home/tinderbox/vax/src/sys/contrib/dev/acpica/utglobal.c:590: warning: cast discards qualifiers from pointer target type /home/tinderbox/vax/src/sys/contrib/dev/acpica/utglobal.c:593: warning: cast discards qualifiers from pointer target type /home/tinderbox/vax/src/sys/dev/acpica/acpi_powerres.c:272: warning: `acpi_pwr_deregister_consumer' defined but not used /home/tinderbox/vax/src/sys/dev/acpica/acpi_powerres.c:210: warning: `acpi_pwr_deregister_resource' defined but not used cc1: warnings being treated as errors /home/tinderbox/vax/src/sys/ufs/ffs/ffs_snapshot.c: In function `ffs_snapshot': /home/tinderbox/vax/src/sys/ufs/ffs/ffs_snapshot.c:542: warning: cast to pointer from integer of different size /home/tinderbox/vax/src/sys/ufs/ffs/ffs_snapshot.c:557: warning: cast to pointer from integer of different size /home/tinderbox/vax/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs1': /home/tinderbox/vax/src/sys/ufs/ffs/ffs_snapshot.c:1002: warning: cast to pointer from integer of different size /home/tinderbox/vax/src/sys/ufs/ffs/ffs_snapshot.c: In function `mapacct_ufs2': /home/tinderbox/vax/src/sys/ufs/ffs/ffs_snapshot.c:1278: warning: cast to pointer from integer of different size *** Error code 1 Stop in /home/tinderbox/vax/obj/home/tinderbox/vax/src/sys/GENERIC. *** Error code 1 Stop in /home/tinderbox/vax/src. *** Error code 1 Stop in /home/tinderbox/vax/src. _ For the best comics, toys, movies, and more, please visit http://www.tfaw.com/?qt=wmf To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kernel Panic in runq_check
I have a CURRENT system that is panicing on me every couple of days. I have enabled crash dumps in the rc.conf file, but when the system is rebooted, savecore doesn't find any core files on the swap partition. The system has 128M RAM installed, and the swap partion is ~512M. I am using a GENERIC kernel with SMP options enabled (see diff at bottom of message). Is there anything I need to add to the kernel config file to enable dumping of core files? Can I force a core dump when it panics? How? Current# ls /usr/obj/usr/src/srcC/sys/GENERIC-SMP/kernel* /usr/obj/usr/src/srcC/sys/GENERIC-SMP/kernel /usr/obj/usr/src/srcC/sys/GENERIC-SMP/kernel.debug The system was built from sources cvsuped on Dec 4th. I was trying to compile soureces cvsuped from yesterday when the panic occured. FreeBSD Current.westbend.net 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Thu Dec 5 19:11:47 CST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/srcC/sys/GENERIC-SMP i386 cpuid=0; lapic.id= instruction pointer = 0x8:0xc02f3d21 stack pointer = 0x10:0xc8678cdc frame pointer = 0x10:0xc8678cdc code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, Pres 1, def32 1, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = 12 (idle: cpu 0) kernel: type 30 trap, code = 0 stopped at runq_check+0x21: cmpl $0x1, %eax nm -n /boot/kernel_smp/kernel | grep c02f3d c02f3d00 T runq_check c02f3d30 T runq_choose c02f3dc0 T runq_remove Current# grep dump /etc/rc.conf dumpdev=/dev/da0s1b # Device name to crashdump to (or NO). dumpdir=/var/crash# Directory where crash dumps are to be stored savecore_flags= # Used if dumpdev is enabled above, and present. Current# df Filesystem1K-blocksUsed Avail Capacity Mounted on /dev/da0s1a 516062 121330 35344826% / devfs 1 1 0 100% /dev /dev/da0s1f 5160623232 471546 1% /tmp /dev/da0s1g 2310684 576178 154965227% /usr /dev/da0s1e 516062 123158 35162026% /var Current# disklabel -r /dev/da0s1 # /dev/da0s1: type: SCSI disk: da0s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 553 sectors/unit: 924 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 104857604.2BSD 2048 1638489 # (Cyl.0 - 65*) b: 1048576 1048576 swap# (Cyl. 65*- 130*) c: 9240unused0 0 # (Cyl.0 - 553*) e: 1048576 20971524.2BSD 2048 1638489 # (Cyl. 130*- 195*) f: 1048576 31457284.2BSD 2048 1638489 # (Cyl. 195*- 261*) g: 4694620 41943044.2BSD 2048 1638489 # (Cyl. 261*- 553*) Current# dmesg Copyright (c) 1992-2002 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 #1: Thu Dec 5 19:11:47 CST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/srcC/sys/GENERIC-SMP Preloaded elf kernel /boot/kernel_smp/kernel at 0xc067d000. Timecounter i8254 frequency 1193182 Hz CPU: Pentium/P54C (200.46-MHz 586-class CPU) Origin = GenuineIntel Id = 0x52c Stepping = 12 Features=0x3bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,APIC real memory = 134217728 (128 MB) avail memory = 123412480 (117 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 IOAPIC #0 intpin 17 - irq 10 IOAPIC #0 intpin 18 - irq 12 IOAPIC #0 intpin 19 - irq 11 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00030010, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00030010, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Intel Pentium detected, installing workaround for F00F bug Initializing GEOMetry subsystem npx0: math processor on motherboard npx0: INT 16 interface Using $PIR table, 6 entries at 0xc00fcdd0 pcib0: Host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX3 ATA controller port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: display, VGA at device 9.0 (no driver attached) fxp0: Intel Pro 10/100B/100+ Ethernet port 0xe400-0xe41f mem 0xd400-0xd40f,0xd410-0xd4100fff irq 12 at device 10.0 on pci0 fxp0: Ethernet address 00:a0:c9:85:b5:ed inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ahc0: Adaptec aic7880 Ultra SCSI adapter port 0xe800-0xe8ff mem
Re: ipfw userland breaks again.
Huh. Interesting. The IP_FW_ADD test threw me but now that I
look at the code more closely it is only there because IP_FW_ADD
is a valid SOPT_GET op as well as a SOPT_SET op. But FLUSH and friends
are SOPT_SET only. Now I see how it works :-)
-Matt
:..
:: rule that, say, prevents spoofing is as bad as adding a rule that
:: allows everything through :-(
:
:This comment got me thinking. The thinking lead to a lot of looking
:at code between compiles today, and more this evening. It would
:appear that the test that was there was sufficient to deal with the
:cases that I was worried about. Revisiting the change:
:
:- if (sopt-sopt_name == IP_FW_ADD ||
:+ if (sopt-sopt_name == IP_FW_ADD || sopt-sopt_name == IP_FW_UNBREAK ||
: (sopt-sopt_dir == SOPT_SET sopt-sopt_name != IP_FW_RESETLOG)) {
:
:Earlier, we only allow IP_FW_{ADD,UNBREAK,RESETLOG,FLUSH,DELETE} for
:SOPT_SET requests and IP_FW_ADD (and a few others) for SOPT_GET
:requests. Since GET + ADD is only case that isn't a SET that changes
:things, the == SOPT_SET takes care of the case that you added.
:
:For a while I thought one could do nasty things based on GET + FLUSH,
:say, but in raw_ip.c, we do the proper checks before calling
:ip_fw_ctl_ptr().
:
:So it looks like this code is subtle enough to have fooled both of
:us. This one change isn't needed for this patch.
:
:Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: I'm leaving the project
* Matt Dillon ([EMAIL PROTECTED]) wrote: Thanks to my dear friend Warner Losh. I've decided to leave FreeBSD and flame in another project. Maybe I could join OpenBSD, the seem to share my views on how to deal with other people. Damn, isn't it a little early for april fool? Cheers, Emiel -- 'I generally avoid temptation unless I can't resist it. -- Mae West To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
50% off All Lists: Publicity - Libraries - Bookstores - Film Producers - Art Galleries - Record Stores - Custom (more)
***LIMITED TIME SALE - ALL LISTS 50% OFF MUST MENTION SALE WHEN ORDERING*** -- UNLIMITED USE LISTS . . .DOWNLOAD WITHIN MINUTES. -- NEW LISTS: TRAVEL MEDIA, SCIENCE PROFESSORS, SCIENCE CLUBS, PASTORS CHURCHES, BIBLE COLLEGE SEMINARY PROFESSORS, PET MEDIA, POLITICAL MEDIA, NEW AGE MEDIA, SCIENTIFIC JOURNALS, -- IF WE DO NOT HAVE THE LIST YOU NEED, WE WILL COMPILE A CUSTOM LIST ACCORDING TO YOUR SPECIFICATIONS -- Call to place your order or for more information. US CANADA TOLL-FREE NUMBER: 888 330 4919 (24/7) If you would like more information via email, please write us at [EMAIL PROTECTED] - Thank you. -- LIBRARIES (BOOKSTORES, MEDIA AND OTHER LISTS BELOW . . .) LISTS INCLUDE: Name, Address, phone, fax and email address (when available). AVAILABLE FORMATS: Excel Spreadsheet Text Database 1,200 U.S. Public Libraries WITH EMAIL ADDRESSES - $109 - NOW $54.50 1,200 U.S. Public Libraries - $89 - NOW $44.50 1,000 U.S. University Libraries WITH EMAIL ADDRESSES - $89 - NOW $44.50 1,000 U.S. University Libraries - $69 - NOW $34.50 400+ Community College Libraries WITH EMAIL ADDRESSES - $59 - NOW $29.50 400+ Community College Libraries - $49 - NOW $24.50 1,093 U.S. K-12 Private School Libraries WITH EMAIL ADDRESSES - $109 - NOW $54.50 1,093 U.S. K-12 Private School Libraries - $89 - NOW $44.50 200 U.K. Public Libraries WITH EMAIL ADDRESSES - $49 - NOW $24.50 200 U.K. Public Libraries - $39 - NOW $19.50 250 U.K. University Libraries WITH EMAIL ADDRESSES - $49 - NOW $24.50 250 U.K. University Libraries - $39 - NOW $19.50 528 Australian Public Libraries WITH EMAIL ADDRESSES - $79 - NOW $39.50 528 Australian Public Libraries - $69 - NOW $34.50 279 Australian College Univ. Libraries WITH EMAIL ADDRESSES - $49 - NOW $24.50 279 Australian College Univ. Libraries - $39 - NOW $19.50 200 Canadian Libraries WITH EMAIL ADDRESSES - $49 - NOW $24.50 200 Canadian Libraries - $39 - NOW $19.50 100 New Zealand Libraries WITH EMAIL ADDRESSES - $39 - NOW $19.50 100 New Zealand Libraries - $29 - NOW $14.50 1,000 U.S. Medical Libraries - $79 - NOW $34.50 313 U.S. Law Libraries - $49 - NOW $24.50 193 U.S. Religious Libraries - $39 - NOW $19.50 -- BOOKSTORES LIST INCLUDES: Name, Address, phone, fax and email address (when available). AVAILABLE FORMATS: Excel Spreadsheets Text Databases 1,900+ Independent Bookstores WITH EMAIL ADDRESSES - $149 - NOW $74.50 1,900+ Independent Bookstores - $129 - NOW $64.50 1,900+ College Bookstores WITH EMAIL ADDRESSES - $149 - NOW $74.50 1,900+ College Bookstores - $129 - NOW $64.50 3,000+ Christian Bookstores WITH EMAIL ADDRESSES - $169 - NOW $84.50 3,000+ Christian Bookstores - $149 - NOW $74.50 2,200+ Chain Bookstores - $129 - NOW $64.50 575+ Book Distributors Chain HQs - WITH EMAIL ADDRESSES - $59 - NOW $29.50 575+ Book Distributors Chain HQs - $49 - NOW $24.50 675 Canadian General Bookstores WITH EMAIL ADDRESSES - $69 - NOW $34.50 675 Canadian General Bookstores - $59 - NOW $29.50 175 Canadian University Bookstores - WITH EMAIL ADDRESSES - $39 175 Canadian University Bookstores - $29 - NOW $14.50 550+ New Age Bookstores - WITH EMAIL ADDRESSES - $59 - NOW $29.50 550+ New Age Bookstores - $49 - NOW $24.50 125 African-American Bookstores - $29 - NOW $14.50 You will be able to download your lists WITHIN MINUTES. --- MEDIA LISTS LISTS INCLUDE: Contact Name, Title/Position, Company, Address, Phone, Fax and Email Address (when available) AVAILABLE FORMATS: Excel Spreadsheet and Microsoft Word U.S. National Media List (1000+ Contacts) - $99 - NOW $49.50 Includes national business, consumer, and entertainment magazine contacts, syndicated talk shows, Newswire contacts, network news, cable news and entertainment programs. Australian National Media LisT (360+ Contacts) - $99 - NOW $49.50 Australia's finest newspapers, magazines and television news and entertainment contacts are included in this list. Canadian National Media (590+ Contacts) - $99 - NOW $49.50 Provides quality contacts from diverse Canadian TV, Magazine, and Newspaper outlets. UK Media List(500 Contacts)- $99 - NOW $49.50 Contact reporters, editors, writers and producers from the UK's best media outlets. PBS Stations (800+ Contacts) - $99 - NOW $49.50 Local and national contacts are featured in this extensive public television database. National Public Radio - NPR (265 Contacts)- $99 - NOW $49.50 Features program directors and producers at local public radio stations as well as contacts at national syndicated shows including Diane Rehm and Fresh Air with Terry Gross. Drive Time Radio - Top 100
Re: ipfw userland breaks again.
On Tue, Dec 17, 2002 at 10:23:15AM -0800, Matthew Dillon wrote: Huh. Interesting. The IP_FW_ADD test threw me but now that I look at the code more closely it is only there because IP_FW_ADD is a valid SOPT_GET op as well as a SOPT_SET op. But FLUSH and friends are SOPT_SET only. Now I see how it works :-) ``cvs log -r1.145 -r1.147 ip_fw.c'' for more details. Cheers, -- Ruslan Ermilov Sysadmin and 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 msg48927/pgp0.pgp Description: PGP signature
Re: I'm leaving the project
Emiel Kollof wrote: * Matt Dillon ([EMAIL PROTECTED]) wrote: Thanks to my dear friend Warner Losh. I've decided to leave FreeBSD and flame in another project. Maybe I could join OpenBSD, the seem to share my views on how to deal with other people. Damn, isn't it a little early for april fool? Cheers, Emiel I think it's now time to let it be. It's gone and we've all read it and had our fun (more or less). It's over and we should stop that and care 'bout our own crap. Jens To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: I'm leaving the project
Emiel Kollof wrote: Someone claiming to be Matt Dillon ([EMAIL PROTECTED]) wrote: Thanks to my dear friend Warner Losh. I've decided to leave FreeBSD and flame in another project. Maybe I could join OpenBSD, the seem to share my views on how to deal with other people. Damn, isn't it a little early for april fool? This kind of fool is a fool all year 'round, I'm afraid. (And no, I don't mean the real Matt Dillon, if it wasn't obvious.) -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SCSI Bios complaints and Disk Slices
On Tue, 17 Dec 2002, Cliff Sarginson wrote: Windows .. fine, I installed Linux .. fine. Then I installed FreeBSD...fine *but* the SCSI BIOS on bootup complains that the disk geometry is all cockeyed, and it looks that way from what it says. It warns any non-DOS O/S may have problems using it. Well I have had no problems, and fdisk makes no complaints. What has happened to upset the SCSI BIOS ? The thing it seems to hate is that it is getting 63 heads reported instead of 64. It is a Tekram 390 U/W controller, with an IBM 18MB U160 disk. There have never been any other complaints about the 1st SCSI disk. Diagnostics show no problems. One thing to check is that you should have 1GB drive support enabled. This needs to be done before installing. See the archives for freebsd-scsi list. I am not familiar with trm(4) so perhaps Oliver can fill in more. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: I'm leaving the project
Matt Dillon wrote: Thanks to my dear friend Warner Losh. I've decided to leave FreeBSD and flame in another project. Maybe I could join OpenBSD, the seem to share my views on how to deal with other people. I hereby give maintainership of all my code to Warner, or, whoever wants it, for that matter. Does anyone know why this person is trying to (poorly) impersonate MD? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
INTR_MPSAFE to network device drivers
Is it okay to add INTR_MPSAFE for all INTR_TYPE_NET drivers? mbuf and bpf routines are all mp-safe, so it seems that it is safe to make network device drivers out of Giant lock. Or is there any unresolved related issues? -- Kyunghwan Kim [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: writing to mbr under GEOM
On Mon, 16 Dec 2002, Ray Kohler wrote: What's the status of the issue where devices with open partitions can't have their boot sectors written to? I know phk@ was working on it a while back but it's something I'd like to see fixed soon, maybe before release? I've been using the following: ftp://ftp.jurai.net/users/winter/patches/geom-foot.patch Set the sysctl 'kern.geom.allow_foot_shooting' to 1 and cross your fingers. Most of the time accessing an already open device is harmless but I've encountered panics a few times. YMMV -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
perl from with XF4 port
I just did a fresh install of RC1+ onto my workstation machine and proceeded to build X. A previous package install had installed the perl package. Unfortunately, during the build of the X fonts, it stopped and said that /usr/X11R6/bin/mkhtmlindex could not be found. Sure enough the file was there, but the contents started with #!/usr/bin/perl So it looks like yet more damage caused by the perl wrapper removal. I also noted that installing the XF4 library package produces the same error. This probably needs to be fixed in some fashion for 5.0-R Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: INTR_MPSAFE to network device drivers
Kyunghwan Kim writes: Is it okay to add INTR_MPSAFE for all INTR_TYPE_NET drivers? NO! mbuf and bpf routines are all mp-safe, so it seems that it is safe to make network device drivers out of Giant lock. Or is there any unresolved related issues? Yes, the mbuf allocator must occasionally call kmem_malloc(), which requires Giant.This means no net driver can be made INTR_MPSAFE, or it will eventually panic when kmem_malloc is called. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: I'm leaving the project
: :Matt Dillon wrote: : Thanks to my dear friend Warner Losh. I've decided to leave FreeBSD and : flame in another project. Maybe I could join OpenBSD, the seem to share : my views on how to deal with other people. : : I hereby give maintainership of all my code to Warner, or, whoever wants : it, for that matter. : :Does anyone know why this person is trying to (poorly) impersonate MD? Probably because I lambast him mercilessly for being such a whimp. It's kinda sad, actually. He's probably not making any friends with the people running the blind proxies he abuses to post, either. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: perl from with XF4 port
On 17-Dec-2002 Long, Scott wrote: I just did a fresh install of RC1+ onto my workstation machine and proceeded to build X. A previous package install had installed the perl package. Unfortunately, during the build of the X fonts, it stopped and said that /usr/X11R6/bin/mkhtmlindex could not be found. Sure enough the file was there, but the contents started with #!/usr/bin/perl So it looks like yet more damage caused by the perl wrapper removal. I also noted that installing the XF4 library package produces the same error. This probably needs to be fixed in some fashion for 5.0-R The current version of the perl package should do a 'use.perl port' automatically which should have fixed this case. If you installed the port a while ago you need to do 'use.perl port' manually. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: perl from with XF4 port
John Baldwin wrote: On 17-Dec-2002 Long, Scott wrote: I just did a fresh install of RC1+ onto my workstation machine and proceeded to build X. A previous package install had installed the perl package. Unfortunately, during the build of the X fonts, it stopped and said that /usr/X11R6/bin/mkhtmlindex could not be found. Sure enough the file was there, but the contents started with #!/usr/bin/perl So it looks like yet more damage caused by the perl wrapper removal. I also noted that installing the XF4 library package produces the same error. This probably needs to be fixed in some fashion for 5.0-R The current version of the perl package should do a 'use.perl port' automatically which should have fixed this case. If you installed the port a while ago you need to do 'use.perl port' manually. As I mentioend at the beginning, this was a *fresh* install of the OS. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: INTR_MPSAFE to network device drivers
On Tue, Dec 17, 2002 at 02:31:31PM -0500, Andrew Gallatin wrote: mbuf and bpf routines are all mp-safe, so it seems that it is safe to make network device drivers out of Giant lock. Or is there any unresolved related issues? Yes, the mbuf allocator must occasionally call kmem_malloc(), which requires Giant.This means no net driver can be made INTR_MPSAFE, or it will eventually panic when kmem_malloc is called. I found and read the thread that you and Alan had discussed about this problem just before. Then what about making updated version of mb_pop_cont() that accepts occasionally acquiring Giant? -- Kyunghwan Kim [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Data corruption in soft updates?
On Mon, 9 Dec 2002, Kirk McKusick wrote: It appears that you are getting all those errors (BAD block) because fsck thinks that your filesystem is smaller than it really is. If you do a dumpfs on the filesystem and check the size (about line 5), I expect that you will find that all those bad blocks exceed that size. It might be interesting to check one or more of the alternate blocks to see if they have a different size. If so, using an alternate should help. If not, then the question is why all those out of range blocks were allocated. I booted an older kernel (Dec. 4) and ran fsck_ffs -b 32. It repaired a few simple errors (summary info bad). I then copied the alt sblock to the default location with dd. I reran fsck to make sure the sblock was copied correctly and it came up clean. Everything was fine. I rebooted into multiuser with the old kernel and everything worked fine. I did a full buildkernel with srcs as of yesterday at 5 pm without any bad block messages. But after rebooting with that new kernel, it tried to correct the sblockloc again and my system started having the same problem again. uname and dmesg is below. -Nate FreeBSD 5.0-CURRENT #1: Mon Dec 16 18:05:56 PST 2002 /: correcting fs_sblockloc from 4 to 8192 bad block 1553167, ino 386832 /usr: optimization changed from TIME to SPACE bad block 1553152, ino 387421 pid 42 (syncer), uid 0 inumber 387421 on /usr: bad block bad block 1551181, ino 383169 pid 42 (syncer), uid 0 inumber 383169 on /usr: bad block bad block 1632087, ino 383281 pid 42 (syncer), uid 0 inumber 383281 on /usr: bad block bad block 1616355, ino 383200 pid 42 (syncer), uid 0 inumber 383200 on /usr: bad block bad block 1623472, ino 383200 pid 42 (syncer), uid 0 inumber 383200 on /usr: bad block bad block 1551227, ino 383200 pid 42 (syncer), uid 0 inumber 383200 on /usr: bad block bad block 1552592, ino 383200 pid 42 (syncer), uid 0 inumber 383200 on /usr: bad block bad block 1555160, ino 383200 pid 42 (syncer), uid 0 inumber 383200 on /usr: bad block bad block 1555208, ino 383200 pid 42 (syncer), uid 0 inumber 383200 on /usr: bad block bad block 1550776, ino 383200 pid 42 (syncer), uid 0 inumber 383200 on /usr: bad block bad block 1551208, ino 383198 pid 42 (syncer), uid 0 inumber 383198 on /usr: bad block bad block 1551209, ino 383241 pid 42 (syncer), uid 0 inumber 383241 on /usr: bad block bad block 1553153, ino 387219 pid 42 (syncer), uid 0 inumber 387219 on /usr: bad block bad block 1552704, ino 389415 pid 42 (syncer), uid 0 inumber 389415 on /usr: bad block bad block 1552707, ino 390100 pid 42 (syncer), uid 0 inumber 390100 on /usr: bad block bad block 1639665, ino 391119 pid 42 (syncer), uid 0 inumber 391119 on /usr: bad block bad block 1553170, ino 39 pid 42 (syncer), uid 0 inumber 39 on /usr: bad block bad block 1553431, ino 391118 pid 42 (syncer), uid 0 inumber 391118 on /usr: bad block bad block 1553405, ino 391122 pid 42 (syncer), uid 0 inumber 391122 on /usr: bad block To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: perl from with XF4 port
On 17-Dec-2002 Scott Long wrote: John Baldwin wrote: On 17-Dec-2002 Long, Scott wrote: I just did a fresh install of RC1+ onto my workstation machine and proceeded to build X. A previous package install had installed the perl package. Unfortunately, during the build of the X fonts, it stopped and said that /usr/X11R6/bin/mkhtmlindex could not be found. Sure enough the file was there, but the contents started with #!/usr/bin/perl So it looks like yet more damage caused by the perl wrapper removal. I also noted that installing the XF4 library package produces the same error. This probably needs to be fixed in some fashion for 5.0-R The current version of the perl package should do a 'use.perl port' automatically which should have fixed this case. If you installed the port a while ago you need to do 'use.perl port' manually. As I mentioend at the beginning, this was a *fresh* install of the OS. The perl package on RC1 wasn't that fresh. It has since been updated to do the automatic use.perl port thing post-RC1 IIRC. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: INTR_MPSAFE to network device drivers
On Wed, Dec 18, 2002 at 04:53:00AM +0900, Kyunghwan Kim wrote: On Tue, Dec 17, 2002 at 02:31:31PM -0500, Andrew Gallatin wrote: mbuf and bpf routines are all mp-safe, so it seems that it is safe to make network device drivers out of Giant lock. Or is there any unresolved related issues? Yes, the mbuf allocator must occasionally call kmem_malloc(), which requires Giant.This means no net driver can be made INTR_MPSAFE, or it will eventually panic when kmem_malloc is called. I found and read the thread that you and Alan had discussed about this problem just before. Then what about making updated version of mb_pop_cont() that accepts occasionally acquiring Giant? Oh, sorry. Conclusion of the thread was preallocation. But it doesn't seem that preallocation is the correct way. -- Kyunghwan Kim [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Data corruption in soft updates?
Please send me a `dumpfs /usr | head -50' output of the filesystem under the current system. Then clean it up with fsck and run the same command again. Finally, boot up under the old kernel and get the output both before and after fsck cleaning. What I am looking for is changes in the reported size of the filesystem because that getting out of sync is what is causing these problems. The basic deal is that the old UFS1 superblock stored the filesystem size in a 32-bit field. The new UFS1 superblock stores the filesystem size in a new (previously unused) 64-bit field. When you mount a UFS1 filesystem on a new kernel, it copies the 32-bit size field to the 64-bit field. At that point the filesystem size is in both places and should work equally well on old or new kernels. However, it does not update the 64-bit size field on any of the alternate superblocks. So, somehow, your using and copying an alternate into the standard location is losing the update done for the size field. I am not sure how that is happening, but I am hoping to catch where in all your messing around with alternates that is happening so I can cover that hole. Kirk McKusick =-=-=-=-=-= Date: Tue, 17 Dec 2002 12:14:12 -0800 (PST) From: Nate Lawson [EMAIL PROTECTED] To: Kirk McKusick [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: Re: Data corruption in soft updates? In-Reply-To: [EMAIL PROTECTED] X-ASK-Info: Whitelist match On Mon, 9 Dec 2002, Kirk McKusick wrote: It appears that you are getting all those errors (BAD block) because fsck thinks that your filesystem is smaller than it really is. If you do a dumpfs on the filesystem and check the size (about line 5), I expect that you will find that all those bad blocks exceed that size. It might be interesting to check one or more of the alternate blocks to see if they have a different size. If so, using an alternate should help. If not, then the question is why all those out of range blocks were allocated. I booted an older kernel (Dec. 4) and ran fsck_ffs -b 32. It repaired a few simple errors (summary info bad). I then copied the alt sblock to the default location with dd. I reran fsck to make sure the sblock was copied correctly and it came up clean. Everything was fine. I rebooted into multiuser with the old kernel and everything worked fine. I did a full buildkernel with srcs as of yesterday at 5 pm without any bad block messages. But after rebooting with that new kernel, it tried to correct the sblockloc again and my system started having the same problem again. uname and dmesg is below. -Nate FreeBSD 5.0-CURRENT #1: Mon Dec 16 18:05:56 PST 2002 /: correcting fs_sblockloc from 4 to 8192 bad block 1553167, ino 386832 /usr: optimization changed from TIME to SPACE bad block 1553152, ino 387421 pid 42 (syncer), uid 0 inumber 387421 on /usr: bad block bad block 1551181, ino 383169 pid 42 (syncer), uid 0 inumber 383169 on /usr: bad block bad block 1632087, ino 383281 pid 42 (syncer), uid 0 inumber 383281 on /usr: bad block bad block 1616355, ino 383200 pid 42 (syncer), uid 0 inumber 383200 on /usr: bad block bad block 1623472, ino 383200 pid 42 (syncer), uid 0 inumber 383200 on /usr: bad block bad block 1551227, ino 383200 pid 42 (syncer), uid 0 inumber 383200 on /usr: bad block bad block 1552592, ino 383200 pid 42 (syncer), uid 0 inumber 383200 on /usr: bad block bad block 1555160, ino 383200 pid 42 (syncer), uid 0 inumber 383200 on /usr: bad block bad block 1555208, ino 383200 pid 42 (syncer), uid 0 inumber 383200 on /usr: bad block bad block 1550776, ino 383200 pid 42 (syncer), uid 0 inumber 383200 on /usr: bad block bad block 1551208, ino 383198 pid 42 (syncer), uid 0 inumber 383198 on /usr: bad block bad block 1551209, ino 383241 pid 42 (syncer), uid 0 inumber 383241 on /usr: bad block bad block 1553153, ino 387219 pid 42 (syncer), uid 0 inumber 387219 on /usr: bad block bad block 1552704, ino 389415 pid 42 (syncer), uid 0 inumber 389415 on /usr: bad block bad block 1552707, ino 390100 pid 42 (syncer), uid 0 inumber 390100 on /usr: bad block bad block 1639665, ino 391119 pid 42 (syncer), uid 0 inumber 391119 on /usr: bad block bad block 1553170, ino 39 pid 42 (syncer), uid 0 inumber 39 on /usr: bad block bad block 1553431, ino 391118 pid 42 (syncer), uid 0 inumber 391118 on /usr: bad block bad block 1553405, ino 391122 pid 42 (syncer), uid 0 inumber 391122 on /usr: bad block To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
tunefs bug?
tunefs(8) appears to do a mount/MNT_RELOAD of an fs even when it doesn't perform any action. To reproduce: mount -r /usr tunefs -n enable /usr [repeat] Is this a bug? -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: I'm leaving the project
This type of thing caused the division of the BSD projects in the first place, and hurts the project over all and is the primary reason that Linux has such a better market position then BSD. I love FreeBSD. I dunno why. I just do. I'm no expert, but it sits right with me. It is a shame that due to people's socialization problems that such a great operating system is regulated to the backwaters of the OS oceans. I suggest some people realize that they have problems with dealing with people--we are not computers in that certain inputs cannot guarantee certain outputs--and perhaps seek therapy to improve their socialization skills. That and $1.10 might buy you a cup a coffee. Sincerely, David On Tue, 17 Dec 2002, Matthew Dillon wrote: : :Matt Dillon wrote: : Thanks to my dear friend Warner Losh. I've decided to leave FreeBSD and : flame in another project. Maybe I could join OpenBSD, the seem to share : my views on how to deal with other people. : : I hereby give maintainership of all my code to Warner, or, whoever wants : it, for that matter. : :Does anyone know why this person is trying to (poorly) impersonate MD? Probably because I lambast him mercilessly for being such a whimp. It's kinda sad, actually. He's probably not making any friends with the people running the blind proxies he abuses to post, either. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
subscribe
subscribe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: INTR_MPSAFE to network device drivers
Kyunghwan Kim writes: On Wed, Dec 18, 2002 at 04:53:00AM +0900, Kyunghwan Kim wrote: On Tue, Dec 17, 2002 at 02:31:31PM -0500, Andrew Gallatin wrote: mbuf and bpf routines are all mp-safe, so it seems that it is safe to make network device drivers out of Giant lock. Or is there any unresolved related issues? Yes, the mbuf allocator must occasionally call kmem_malloc(), which requires Giant.This means no net driver can be made INTR_MPSAFE, or it will eventually panic when kmem_malloc is called. I found and read the thread that you and Alan had discussed about this problem just before. Then what about making updated version of mb_pop_cont() that accepts occasionally acquiring Giant? Oh, sorry. Conclusion of the thread was preallocation. But it doesn't seem that preallocation is the correct way. Well, the right way is bringing kmem_malloc() out from under Giant. Preallocation would just be an interim measure until kmem_malloc() was mp-safe. The VM maintainers were only recently made aware of this issue. I have no idea what the scope of the changes to make kmem_malloc() mpsafe would be, so I have no idea when kmem_malloc() will become mpsafe. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: How to update UFS1 to UFS2?
On Tue, Dec 17, 2002 at 11:47:23AM -0500, Steven Ames wrote: On a related topic... how do you tell which of your filesystems are mounted UFS1 -vs- UFS2? 'mount -v' just says ufs. dumpfs filesystem | grep UFS -- Ray Kohler [EMAIL PROTECTED] See - the thing is - I'm an absolutist. I mean, kind of ... in a way ... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: I'm leaving the project
:You know the person by name/alias, then? Who is it? : I do not know who it is, he posts through anonymous proxies. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
5.0-RC1 /etc/rc.d/ipfw script and NAT
Hi,
There's trouble in the /etc/rc.d/ipfw script in how it changes things
versus the 4.7 /etc/rc.network script when it comes to NAT in certain
configurations.
For example, on my home gateway box, rc.conf contains:
# Network address translation:
natd_enable=YES
natd_interface=
natd_flags=-f /etc/natd.conf
Notice that I deliberately do NOT list any interfaces because I am using
an explicit configuration file (the -f /etc/natd.conf flags). Under
4.7-STABLE, the natd daemon will be started appropriately even though
the natd_interface variable is empty, so long as natd_enable is YES
and so long as I am smart enough to have some sort of configuration
available to natd.
Under 5.0-RC1, /etc/rc.d/ipfw makes a 2-line change, moving the lines
that actually start the natd daemon up inside of an if statement. This
means folks like myself who use an explicit configuration file (i.e. I
don't run natd on any one specific interface - I run it inbound on one
interface, outbound on another using a custom ipfw ruleset and natd
configuration file) cannot have natd auto-start without changing
/etc/rc.d/ipfw or starting it by hand somewhere else.
May I request that the two lines in /etc/rc.d/ipfw that start natd be
moved down a few lines outside of the enclosing if block so that the
functionality many of us -STABLE users are accustomed to may be
returned? If not, can anyone shed some light on why it's a bad idea and
offer any suggestions to me? (I like to make as few changes to my BSD
box as possible to have it run how I want it to.)
Thanks!
Aaron out.
- NATD section of /etc/rc.d/ipfw as I would like to see it -
# Network Address Translation daemon
#
if checkyesno natd_enable; then
if [ -n ${natd_interface} ]; then
if echo ${natd_interface} | \
grep -q -E '^[0-9]+(\.[0-9]+){0,3}$'; then
natd_flags=$natd_flags -a ${natd_interface}
else
natd_flags=$natd_flags -n ${natd_interface}
fi
fi
echo -n ' natd'
${natd_program:-/sbin/natd} ${natd_flags} ${natd_ifarg}
fi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
sshd and PRNG in FreeBSD 5.0 RC1
Hi All, I installed FreeBSD 5.0 RC1 and everything seems to be working just fine. I recompiled the kernel with extra hardware including IPSEC , netgraph, ipfilter and ipfw support. Againseem sto be working just fine and find and configured my hardware. However, SSHD started complaining about PRNG being not seeded. I don't know what that is. What is wrong? Thanks for your help. since then I cvsuped to -current and recompiled everything including the kernel. Again everyhting works except sshd with the error message. thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: ffs_blkfree: freeing free block
Date: Mon, 16 Dec 2002 22:42:07 -0600 From: Dan Nelson [EMAIL PROTECTED] To: Aurelien Nephtali [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: panic: ffs_blkfree: freeing free block In the last episode (Dec 16), Aurelien Nephtali said: Hi, I got a panic today which occured during a background fsck, after a hard-reboot of the system. The dump from gdb is attached and I can, of course, provide more infos if needed. Me too. My info attached as well; almost identical stack trace. Kernel was built from sources cvsupped just after 2002/12/15 17:41:07 PST. (Why in the heck are all the timestamps in commitlogs in PST??) -- Dan Nelson [EMAIL PROTECTED] I introduced a bug to snapshots on 11/30/02 which did not get fixed until 12/15/02 which caused background fsck to (silently) fail to fix certain filesystem problems. If you ran background fsck on a system between 11/30 and 12/15 and then ran background fsck again on a system after that date, the earlier missed corruption causes the panic that you have seen. Once fixed on a post 12/15 system, it should not recur. You can avoid the panic by running `fsck -f -p' on all your system after upgrading to a post 12/15 system. If you find continued evidence of trouble after following the above procedures, please send me mail. Kirk McKusick To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ia64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === sbin/gbde cc1: warnings being treated as errors /home/tinderbox/ia64/src/sbin/gbde/gbde.c: In function `cmd_init': /home/tinderbox/ia64/src/sbin/gbde/gbde.c:444: warning: `sector_size' might be used uninitialized in this function *** Error code 1 Stop in /home/tinderbox/ia64/src/sbin/gbde. *** Error code 1 Stop in /home/tinderbox/ia64/src/sbin. *** Error code 1 Stop in /home/tinderbox/ia64/src. *** Error code 1 Stop in /home/tinderbox/ia64/src. *** Error code 1 Stop in /home/tinderbox/ia64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Port package on RC1
Today for the fun of it I decided to try installing RC1 on VMware running in Win2K. (very bored today). Everything goes fine until the ports installation. I choose all the default options, I have it running in a 256mb of RAM 10gb virtual disk environment. Like I said up until the ports installation everything goes as expected. Then when it gets to unpacking the ports collection the rate goes down from about 1mb/sec for the other packages and it's now still installing at 1.5kb/sec. This is the first time I've tried installing RC1, I installed DP2 on a laptop and it went smooth. Has anyone else experienced this or is this related to running it in a VM environment. What seems odd to me is that CPU utilization for the VMware process is at 99% constantly. I'm wondering what it's doing because it isn't copying over ports very fast. Ryan PS I know this isn't the way it's meant to be run, I'm just curious why the rest would install fine until ports. (This is the second time I've tried.) -- Ryan leadZERO Sommers [EMAIL PROTECTED] ICQ: 1019590 AIM/MSN: leadZERO To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Mounting MS-DOS fs image via /dev/md*
I'm not sure this is correct way to create MS-DOS fs image and mounting it. % dd if=/dev/zero of=test.flp bs=1024 count=1440 1440+0 records in 1440+0 records out 1474560 bytes transferred in 0.044105 secs (33432904 bytes/sec) % sudo mdconfig -a -t vnode -f test.flp md1 % sudo newfs_msdos -f 1440 -L test /dev/md1 /dev/md1: 2847 sectors in 2847 FAT12 clusters (512 bytes/cluster) bps=512 spc=1 res=1 nft=2 rde=224 sec=2880 mid=0xf0 spf=9 spt=18 hds=2 hid=0 % sudo mount -t msdos /dev/md1 /mnt msdosfs: /dev/md1: No such file or directory How should I do? -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Port package on RC1
On 17 Dec 2002 16:35:50 -0600, Ryan Sommers [EMAIL PROTECTED] said: I'm wondering what it's doing because it isn't copying over ports very fast. It's slow because it's creating lots of very small directories. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: I'm leaving the project
On Tue, 17 Dec 2002, Matthew Dillon wrote: : :Matt Dillon wrote: : Thanks to my dear friend Warner Losh. I've decided to leave FreeBSD and : flame in another project. Maybe I could join OpenBSD, the seem to share : my views on how to deal with other people. : : I hereby give maintainership of all my code to Warner, or, whoever wants : it, for that matter. : :Does anyone know why this person is trying to (poorly) impersonate MD? Probably because I lambast him mercilessly for being such a whimp. It's kinda sad, actually. He's probably not making any friends with the people running the blind proxies he abuses to post, either. -Matt Matthew Dillon [EMAIL PROTECTED] God, now this thread gave me a panic (and a heartattack) ... its funny how many times you can read someone's posts, and see their writing style, and still be sucker-punched:) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kernel hangs during boot (new GEOM problem)
I built world+kernel about an hour ago ( Dec 17 about 23:00 UTC) and the kernel hangs in the middle of printing phk's GEOM diagnostics: ad0: 76319MB ST380021A [155061/16/63] at ata0-master UDMA100 ad2: 42934MB WDC WD450AA-00BAA0 [87233/16/63] at ata1-master UDMA66 acd0: CD-RW R/RW 4x4x24 at ata1-slave PIO4 snip slices 5 to 14 on ad0 MBREXT Slice 15 on ad0s4: 00 01 c1 ff a5 fe ff ff 3f 00 00 00 bd 08 fa 00 |?...| [0] f:00 typ:165 s(CHS):255/1/193 e(CHS):255/254/255 s:63 l:16386237 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 This is where the latest kernel hangs--between the first and second IDE disks. When I boot the previous kernel it continues normally with the 2nd disk as follows: MBREXT Slice 5 on ad2s4: 00 01 c1 ff 0b fe ff ff 3f 00 00 00 de 4d 94 00 |?M..| [0] f:00 typ:11 s(CHS):255/1/193 e(CHS):255/254/255 s:63 l:9719262 00 00 c1 ff 05 fe ff ff 1d 4e 94 00 bd 86 bb 00 |.N..| [1] f:00 typ:5 s(CHS):255/0/193 e(CHS):255/254/255 s:9719325 l:12289725 MBREXT Slice 6 on ad2s4: 00 01 c1 ff 83 fe ff ff 3f 00 00 00 7e 86 bb 00 |?...~...| [0] f:00 typ:131 s(CHS):255/1/193 e(CHS):255/254/255 s:63 l:12289662 00 00 c1 ff 05 fe ff ff da d4 4f 01 86 7c fc 00 |..O..|..| [1] f:00 typ:5 s(CHS):255/0/193 e(CHS):255/254/255 s:22009050 l:16546950 MBREXT Slice 7 on ad2s4: 00 01 c1 ff 83 fe ff ff 3f 00 00 00 47 7c fc 00 |?...G|..| [0] f:00 typ:131 s(CHS):255/1/193 e(CHS):255/254/255 s:63 l:16546887 00 00 c1 ff 05 fe ff ff 50 a8 04 03 7e 04 7d 00 |P...~.}.| [1] f:00 typ:5 s(CHS):255/0/193 e(CHS):255/254/255 s:50636880 l:8193150 MBREXT Slice 8 on ad2s4: 00 01 c1 ff 07 fe ff ff 3f 00 00 00 3f 04 7d 00 |?...?.}.| [0] f:00 typ:7 s(CHS):255/1/193 e(CHS):255/254/255 s:63 l:8193087 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 Mounting root from ufs:/dev/ad0s3a snip # fdisk ad2 *** Working on device /dev/ad2 *** parameters extracted from in-core disklabel are: cylinders=87233 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=87233 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 169 (0xa9),(NetBSD) start 63, size 7373772 (3600 Meg), flag 0 beg: cyl 0/ head 1/ sector 1; end: cyl 458/ head 254/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 7373835, size 17607240 (8597 Meg), flag 80 (active) beg: cyl 459/ head 0/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 3 is: sysid 12 (0x0c),(DOS or Windows 95 with 32 bit FAT (LBA)) start 24981138, size 4112577 (2008 Meg), flag 0 beg: cyl 1023/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 4 is: sysid 15 (0x0f),(Extended DOS (LBA)) start 29093715, size 58830030 (28725 Meg), flag 0 beg: cyl 1023/ head 0/ sector 1; end: cyl 1023/ head 254/ sector 63 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
You need E-MAiL AddREssES, we've got em: 40OM for $139
You want email addresses; we've got lots of fresh ones. Face it, there's no way you're going to extract 400 million email addresses with some flimsy email extractor program you downloaded from the web. You're lucky if you can extract 2 million in a year! Our email addresses are even targeted in 34 different categories to help you reach only the market you want. No need to buy any more directories from the web. We've bought almost all of them for you, cleaned them up including removal of duplicates and flamers, and compiled them into a 4 disk volume for only $139.00 Now you can send emails to millions of people worldwide. Imagine if only a small number out of even 1 million emails sent responded to your email. Don't you think you'd make something out of that? No need to worry if our email addresses will work with your mailing program. We already thought of that and made sure to save all files as text files. Text files are the most universal types of files so they will import easily. Also, there's no limit to how many times you can use our email addresses. Still have more specific questions? We're here to help. You can contact us by email At [EMAIL PROTECTED] make sure to put ENQUIRY in the subject line Want to order? Follow the instructions below: [] I want to order online Please complete ONLY section A B of the order form below and either fax or email it back to us. If you're faxing it, send it to 1-6 30-604-1030 or 1-44 3-659-0730 [] I want to order by Credit Card Please complete section A , B C of the order form below. For your security, DO NOT email anything with your credit card number on it. Please fax your order form to 1-63 0-604-10 30 or 1-4 43-659-07 30 [] I want to order by Paypal Please complete section A , B D of the order form below. You can email or fax the order form back to us for processing. Return by fax to 1-630-604-1 030 or 1-443-6 59-0730 \ SECTION A - Products (prices are in US$) [] Email Marketing CD with 100 million Addresses $69.00 [] 200 Million Email Addresses on 2 CD's $79.00 [] 1.5 Million USA Business Fax Numbers $49.00 [] PACKAGE A - ALL DIRECTORIES ABOVE (3 CDs) $99.00 [] Email Gold CD FRESHLY EXTRACTED 100 Million Addresses $99.00 [] 7 Million Chinese Email Addresses $99.00 [] PACKAGE B + PACKAGE A- All directories above (4 CDs) $139.00 [] 1 Million Email Addresses from French speaking countries $69 [] 1 Million U.K. only email addresses $69 / SECTION B - Personal Information Full Name: Company Name: Tel: ( __) ___-__ Email Address:__ Shipping Addresss:___Zip/Postal:___ City:___ State/Province: Country: \ SECTION C - Credit Card Information Card Number: Expiration Date:/CVV2 code (last 3 digits on reverse):__ Type of card : [] Visa [] Mastercard[] American Express Exact name on card:___ Billing Address:Zip/Postal___ City:State/Province:___ Country: Cardholder Signature:__ I hereby authorize F.T. Internat ion al to bill my credit card for the items ordered on this form. I understand that all sales are final and further agree not to dispute this charge. \ SECTION D - Paypal Information Email Address associated with Paypal: Note: After receiving this order form, we will send a payment request to the address above. / If you want off our list, please send an email to [EMAIL PROTECTED] with DELETE in the subject line. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Posix Semaphores in -CURRENT
Joe Kelsey wrote: OK, this is a bug. The semantics don't conform to POSIX. ... I rather imagine the correct thing to do is to root it in the FS, and, without a leading '/', treat it as relative to the process current directory. Basically, this is not a two line fix... it's a lot of work, to get a filesystem object to use. I think that it *is* a two-line fix. Remove the maximum length (or impose a maximum length of MAX_PATHNAMELEN), and simply remove the whole '/' checking. Then, the private namespace correctly emulates posix semantics, except for the rooted versus relative stuff, which would be *really* hard to do in a private namespace and of questionable value anyway. Sorry, but Garrett was right about the implementation: it should not be using a private namespace in the first place. Making it work for a private namespace that shouldn't be there in the first place seems really questionable, to me... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
John Baldwin wrote: This has nothing to do with /dev/random. Please stop with the constant FUDing Terry. | Revision 1.296 / (download) - annotate - [select for diffs], Sun Jan 14 | 10:11:10 2001 UTC (23 months ago) by jhb | Branch: MAIN | Changes since 1.295: +2 -2 lines | Diff to previous 1.295 (colored) | | Remove I386_CPU from GENERIC. Support for the 386 seriously pessimizes | performance on other x86 processors. Custom kernels can still be built | that will run on the 386. The pessimization that was being discussed right before that happened was harvesting entropy for /dev/random. I can provide mailing list quotes about that bracketing those dates. Was there a particular pessimization other than /dev/random that you were thinking of when you made the commit comment? The major functional changes immediately preceeding the disabling were 1.283, 1.279, and 1.275. 1.275 made /dev/random mandatory, and 1.283 disabled the blocking model /dev/random, to address hanges even on non-i386 architectures. 1.279 was Peter's cleanup, and doesn't seem to impact performance, even though it was moderately major. As I already pointed out: with the /dev/random algorithm now much more efficient than when it was first committed, maybe the impetus for axing i386 is no longer there. In any case, it can't hurt to periodically examine whether the reasons for the change are still valid or not, no matter what the pessimization was that was being referred to. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
Chris Doherty wrote: p.s. I somehow suspect that embedded systems vendors aren't installing from the CDROM. why is this an issue? 1) supporting every computer made since 1964 is NetBSD's job, not FreeBSD's. 2) I'm scared that 5.0 is going to be unpleasantly slow on my p2-366, let alone a 386. 3) if you feel compelled to run old hardware, why not shell out $30 for a 486 system? for $50 you can get a Pentium 166. :-) I'm really keen to see FreeBSD move *forward*. Apparently, one of the primary markets for FreeBSD is embedded devices. Macrocell libraries, from which CPU cores are assembled with purpose functional macrocells for embedded devices, such as the Apple AirPort (which is a 386 device), and similar devices, often offer 386's. Several vendors libraries offer 486's, but not all of them. Pentium macrocells generally require cooling, which means a fan, which means moving parts, which means that they do not meet selection criteria for telecomunications and military infrastructure, which often requires no moving parts. In general, it's not an issue: most embedded developement is cross-developement, where the compiling is not on the box where the code is expected to run. Even were that not the case, the special-purpose nature of the hardware often means that there is not a real BIOS supporting the hardware function, and it could not boot as a general purpose PC, in any case (it's at least as different as the PC98 -- and usually more different). I think the only place you could make a case is emerging markets in the third world, which are getting leftover equipment from the first world, which translates to them having 386 boxes, and no wayto load FreeBSD, so they go with Linux or some other OS instead. Even that argument is very weak. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Installing 5.0-RC1 on Sony Vaio z505s with Linksys Combo Card ...
Is there anyway of doing this? the boot disk is recognizing the card, but is followed by: device_probe_and_attach: ed1 attach returned 6 My first guess is that its conflicting with the existing fxp0 device that was detected before it, since its sharing the IRQ, but dont' know how to debug whether that is it or not ... Help? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
* De: Terry Lambert [EMAIL PROTECTED] [ Data: 2002-12-17 ] [ Subjecte: Re: 80386 out of GENERIC ] Apparently, one of the primary markets for FreeBSD is embedded devices. Are you implying that these people, who are undoubtedly adding and removing lots of things in the kernel, to make things fit, and to make things do their jobs, can't be bothered to use the appropriate CPU settings? -- Juli Mallett [EMAIL PROTECTED] OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === sbin/gbde cc1: warnings being treated as errors /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c: In function `rijndaelKeySched': /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:41: warning: cast increases required alignment of target type /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:41: warning: cast increases required alignment of target type /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:48: warning: cast increases required alignment of target type /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:48: warning: cast increases required alignment of target type /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:66: warning: cast increases required alignment of target type /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:66: warning: cast increases required alignment of target type /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:70: warning: cast increases required alignment of target type /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:70: warning: cast increases required alignment of target type /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:77: warning: cast increases required alignment of target type /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:77: warning: cast increases required alignment of target type /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:83: warning: cast increases required alignment of target type /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:83: warning: cast increases required alignment of target type /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c: In function `rijndaelKeyEncToDec': /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:101: warning: cast increases required alignment of target type /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:102: warning: cast increases required alignment of target type /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:103: warning: cast increases required alignment of target type /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:104: warning: cast increases required alignment of target type /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:105: warning: cast increases required alignment of target type /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:108: warning: cast increases required alignment of target type /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:109: warning: cast increases required alignment of target type /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:110: warning: cast increases required alignment of target type /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:111: warning: cast increases required alignment of target type /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:112: warning: cast increases required alignment of target type /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:115: warning: cast increases required alignment of target type /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:116: warning: cast increases required alignment of target type /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:117: warning: cast increases required alignment of target type /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:118: warning: cast increases required alignment of target type /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:119: warning: cast increases required alignment of target type /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:122: warning: cast increases required alignment of target type /tinderbox/sparc64/src/sys/crypto/rijndael/rijndael-alg-fst.c:123: warning: cast increases required alignment of target type
Re: 80386 out of GENERIC
Juli Mallett wrote: Are you implying that these people, who are undoubtedly adding and removing lots of things in the kernel, to make things fit, and to make things do their jobs, can't be bothered to use the appropriate CPU settings? Not sure where you got that from Terry's post, but... As a sometimes embedded developer (who also runs FreeBSD on his comparatively screaming Athlon desktop box), being able to run FreeBSD, fresh off a CD, on a quirky 386 embedded toaster and have it run perfectly would be a dream. Of course, that's never been the case. As others have mentioned, you're lucky if you have a working BIOS. There's usually no room for luxuries like a robust device probing system, a nice, standard PCI bus, queriable hardware, etc. Most of your devices are sitting right on the processor bus (and hopefully you've thrown in enough wait states, but if the thing doesn't respond, spin a bit and hammer it with the request again). As long as it's feasible to compile a kernel for a 386, that's all I could ever home for. Just don't go rewriting the scheduler in assembly and use MMX/SIMD instructions... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
* De: David Cuthbert [EMAIL PROTECTED] [ Data: 2002-12-17 ] [ Subjecte: Re: 80386 out of GENERIC ] Juli Mallett wrote: Are you implying that these people, who are undoubtedly adding and removing lots of things in the kernel, to make things fit, and to make things do their jobs, can't be bothered to use the appropriate CPU settings? Not sure where you got that from Terry's post, but... I misread. As a sometimes embedded developer (who also runs FreeBSD on his comparatively screaming Athlon desktop box), being able to run FreeBSD, fresh off a CD, on a quirky 386 embedded toaster and have it run perfectly would be a dream. Of course, that's never been the case. As others have mentioned, you're lucky if you have a working BIOS. There's usually no room for luxuries like a robust device probing system, a nice, standard PCI bus, queriable hardware, etc. Most of your devices are sitting right on the processor bus (and hopefully you've thrown in enough wait states, but if the thing doesn't respond, spin a bit and hammer it with the request again). As long as it's feasible to compile a kernel for a 386, that's all I could ever home for. Just don't go rewriting the scheduler in assembly and use MMX/SIMD instructions... I don't think anyone wants that to happen (though I wouldn't put it past some people to want to do that). -- Juli Mallett [EMAIL PROTECTED] OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
On Tue, 17 Dec 2002, Ruslan Ermilov wrote:
On Mon, Dec 16, 2002 at 09:05:40AM +1030, Greg 'groggy' Lehey wrote:
I suppose it would be a good idea to include an alternatvie i386
kernel on the CD-ROM. There may be a space issue, of course. How
many people participating in this thread have an i386 with at least 12
MB of memory and intended to try 5.0 on it? How many of those don't
have a machine to bootstrap off?
Having only alternative i386 kernel is not enough while userland
stuff is still compiled for i486.
Er, userland stuff is still compiled for original i386's, modulo bugs.
E.g., in the i386 endian.h:
% #if defined(_KERNEL) (defined(I486_CPU) || defined(I586_CPU) ||
defined(I686_CPU)) !defined(I386_CPU)
^^^
%
% #define __byte_swap_int(x) \
% __extension__ ({ register __uint32_t __X = (x); \
%__asm (bswap %0 : +r (__X)); \
%__X; })
% #else
%
% #define __byte_swap_int(x) \
% __extension__ ({ register __uint32_t __X = (x); \
%__asm (xchgb %h0, %b0\n\trorl $16, %0\n\txchgb %h0, %b0 \
% : +q (__X)); \
%__X; })
% #endif
The _KERNEL part of the ifdef limits the use of the i486 bswap
instruction to the kernel, so userland is properly pessimized to support
all x86's. The other parts of the ifdef properly pessimize modules to
support all x86's (options don't apply to modules so none of the XXX_CPU's
is defined).
So kernels get the full epsilon of optimizations from turning off i386
support, while userland doesn't get any (not counting ones from optimizing
for non-i386 without breaking i386).
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
ia64 tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/tinderbox/ia64/obj/home/tinderbox/ia64/src/ia64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === sbin/gbde cc1: warnings being treated as errors /home/tinderbox/ia64/src/sbin/gbde/gbde.c: In function `cmd_init': /home/tinderbox/ia64/src/sbin/gbde/gbde.c:444: warning: `sector_size' might be used uninitialized in this function *** Error code 1 Stop in /home/tinderbox/ia64/src/sbin/gbde. *** Error code 1 Stop in /home/tinderbox/ia64/src/sbin. *** Error code 1 Stop in /home/tinderbox/ia64/src. *** Error code 1 Stop in /home/tinderbox/ia64/src. *** Error code 1 Stop in /home/tinderbox/ia64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sio and ed woes
On Tue, 17 Dec 2002 [EMAIL PROTECTED] wrote: I have a problem getting CURRENT to find my ISA SMC Ultra ethernet card. No matter what I do I can't stop the kernel finding a third sio device on top of the memory and interrupt that the ed card occupies. The kernel correctly registers its surprise at finding the third sio device since no hints for it exist: sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio2: configured irq 10 not in bitmap of probed irqs 0 sio2: port may not be enabled sio2 port 0x2e8-0x2ef irq 10 on acpi0 sio2: type 16550A I've tried setting hint.sio.2.disabled=1. I've tried leaving it out. I can't not have sio because this server is my router and is permanently connected to a modem. I guess sio2 really exists. In any case, you don't really want it because iof the interrupt conflict. Try using full hints for it. I would have expected just the disabled hint to work though. Try leaving out the irq hint. This should give polled mode for sio (and thus no conflict with other devices using the irq) and works for the plain isa case. I suspect that there is a problem with resources getting merged (can the irq resource be supplied by acpi even when it is intentionally left out of the hints?). I avoid these problems by not using acpi. The SMC Ultra card exists on 0x280 irq 10 0xd8000. Has current dropped ISA support (which was hinted at in the GENERIC/80386 thread)? No. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unrar doesn't work under current
On Tue, Dec 17, 2002 at 06:44:56PM +1100, Edwin Groothuis wrote: Think it has something to do with this one: 46353 unrarCALL open(0xbfbf98e3,0,0xbef6d8) 46353 unrarNAMI ../rar/sample.rar 46353 unrarRET open 3 46353 unrarCALL flock(0x3,0x6) 46353 unrarNAMI /var/run/lock 46353 unrarRET flock -1 errno 45 Operation not supported 46353 unrarCALL close(0x3) 46353 unrarNAMI /var/run/lock 46353 unrarRET close 0 46353 unrarCALL write(0x2,0xbfbed670,0x1e) 46353 unrarGIO fd 2 wrote 30 bytes Cannot open ../rar/sample.rar That's in file.cpp:73, LOCK_EX is in /usr/include/fcntl.h Haven't looked at the rest. This is due to lack of rpc.lockd running on the nfs client and/or server. Kris msg48976/pgp0.pgp Description: PGP signature
Re: I'm leaving the project
: :Does anyone know why this person is trying to (poorly) impersonate MD? Probably because I lambast him mercilessly for being such a whimp. It's kinda sad, actually. He's probably not making any friends with the people running the blind proxies he abuses to post, either. You know the person by name/alias, then? Who is it? Probably not. Anybody who fakes messages fits the above category :-) Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
But still, would it be impossible to have both a GENERIC and a GENERIC386 kernel in the distribution? Or is the whole system compiled in non-386 mode? Even so, if just one site. www.386.freebsd.org were having a 386-enabled version available, wouldn't that make everybody happy? Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unrar doesn't work under current
On 18-Dec-2002 (06:52:54/GMT) Kris Kennaway wrote: This is due to lack of rpc.lockd running on the nfs client and/or server. Yes, I tryed on a nfs mounted dir from my -CURRENT home machine. This means that this is a pilot error? Again? :-( I'm sorry. I think that I must sleep a little more... But what about rar/unrar ports that overwrite one each other? And _why_ rar port works (on same file) and unrar not? (at least this is a but in rar that doesn't do correct locking?) Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: backgroud fsck is still locking up system (fwd)
Date: Mon, 9 Dec 2002 11:19:13 -0800 From: Brooks Davis [EMAIL PROTECTED] To: Kirk McKusick [EMAIL PROTECTED] Cc: Brooks Davis [EMAIL PROTECTED], Nate Lawson [EMAIL PROTECTED], Archie Cobbs [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: backgroud fsck is still locking up system (fwd) On Fri, Dec 06, 2002 at 05:52:38PM -0800, Kirk McKusick wrote: Adding a two minute delay before starting background fsck sounds like a very good idea to me. Please send me your suggested change. Here it is. As written it doesn't add the delay, but you can change etc/defaults/rc.conf to do that it desired. -- Brooks I have added your suggested change to -current (6.0). I decided to set the default startup delay to sixty seconds as that seems to be enough time to let the initial system startup settle down. If this change proves to be popular, it can be considered for MFC'ing to 5.0. Kirk McKusick =-=-=-=-=-= From: Kirk McKusick [EMAIL PROTECTED] Date: Tue, 17 Dec 2002 23:21:31 -0800 (PST) To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: cvs commit: src/etc rc src/etc/defaults rc.conf src/etc/rc.d bgfsck src/share/man/man5 rc.conf.5 X-FreeBSD-CVS-Branch: HEAD mckusick2002/12/17 23:21:31 PST Modified files: etc rc etc/defaults rc.conf etc/rc.d bgfsck share/man/man5 rc.conf.5 Log: Delay an optional amount of time after booting before starting a background fsck. The delay defaults to sixty seconds to allow large applications such as the X server to start before disk I/O bandwidth is monopolized by fsck. Submitted by: Brooks Davis [EMAIL PROTECTED] Sponsored by: DARPA NAI Labs. Revision ChangesPath 1.165 +1 -0 src/etc/defaults/rc.conf 1.324 +8 -2 src/etc/rc 1.3 +13 -2 src/etc/rc.d/bgfsck 1.168 +5 -0 src/share/man/man5/rc.conf.5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: unrar doesn't work under current
On Wed, Dec 18, 2002 at 08:20:21AM +0100, Riccardo Torrini wrote: On 18-Dec-2002 (06:52:54/GMT) Kris Kennaway wrote: This is due to lack of rpc.lockd running on the nfs client and/or server. Yes, I tryed on a nfs mounted dir from my -CURRENT home machine. This means that this is a pilot error? Again? :-( I'm sorry. I think that I must sleep a little more... Yes (though the failure message could be more explicit). But what about rar/unrar ports that overwrite one each other? I don't know what you mean here. And _why_ rar port works (on same file) and unrar not? (at least this is a but in rar that doesn't do correct locking?) Presumably rar doesn't perform any file locking (it may or may not need to), Kris msg48981/pgp0.pgp Description: PGP signature
Re: 5.0-RC1: suspend trouble
On Mon, 16 Dec 2002, Christian Brueffer wrote: Suspend works ok on my Thinkpad R32. Which version do you have? A21e To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
