install problem with 4.0 (spec_getpages)
Hi, While trying to boot from the 4.0 installation disks, I get the following error after the devices have been probed: (I couldn't get a screen dump, so I had to write this down) md0: raw partition size != slice size md0: start 0, end 607, size 608 md0c: start 0, end 5759, size 5760 md0: truncating raw partition md0: rejecting partition in BSD label, it isn't entirely withing the slice md0: start 0, end 607, size 608 md0a: start 0, end 5759, size 5760 spec_getpages: (#md/2) I/O read failure: (error = 22) bp 0xc31dea20 vp 0xc7739f60, size 4096, resid: 4096, a_count: 4096, valid 0x0, nread: 0, reqpage: 0, pindex: 392, pcount: 1 vmfault: pager read error, pid 1 init died (signal 6, exit 0) panic: going nowhere without my init And then it reboots, I have been looking in the mailing archives for this problem, but the latest occurence was januari last year, and it didn't look like the same problem. So has anyone any idea about how to proceed? Here is my dmesg from 3.3: Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.3-RELEASE #4: Mon Jan 10 23:27:28 CET 2000 root@localhost:/usr/src/sys/compile/SCHOPENHAUER Timecounter "i8254" frequency 1193182 Hz CPU: Celeron (412.50-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x665 Stepping = 5 Features=0x183f9ff real memory = 134217728 (131072K bytes) avail memory = 127463424 (124476K bytes) Preloaded elf kernel "kernel" at 0xc02d4000. Pentium Pro MTRR support enabled Probing for devices on PCI bus 0: chip0: rev 0x03 on pci0.0.0 chip1: rev 0x03 on pci0.1.0 chip2: rev 0x02 on pci0.2.0 ide_pci0: rev 0x01 on pci0.2.1 chip3: rev 0x02 on pci0.2.3 ncr0: rev 0x03 int a irq 11 on pci0.14.0 es1: rev 0x01 int a irq 11 on pci0.15.0 pcm1: using I/O space register mapping at 0xe800 Probing for devices on PCI bus 1: vga0: rev 0x04 int a irq 255 on pci1.0. 0 Probing for PnP devices: CSN 1 Vendor ID: TCM5095 [0x95506d50] Serial 0x4b58aba7 Comp ID: @@@ [0x ] Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <16 virtual consoles, flags=0x0> ed0 not found at 0x280 atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0 irq 12 on isa psm0: model Generic PS/2 mouse, device ID 0 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A pcm0 not found fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): wd0: 1536MB (3145968 sectors), 3121 cyls, 16 heads, 63 S/T, 512 B/S wdc1 at 0x170-0x177 irq 15 on isa wdc1: unit 0 (atapi): , removable, accel, dma, ior dis acd0: drive speed 1722 - 4134KB/sec, 512KB cache acd0: supported read types: CD-R, CD-RW, CD-DA, packet track acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked ppc0 at 0x378 irq 7 on isa ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppi0: on ppbus 0 plip0: on ppbus 0 1 3C5x9 board(s) on ISA found at 0x300 ep0 at 0x300-0x30f irq 10 on isa ep0: utp[*UTP*] address 00:10:4b:58:ab:a7 isic0: Error, signature 1 0xff != 0x51 for Teles S0/16.3!isic0 not found at 0xe8 0 vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa npx0 on motherboard npx0: INT 16 interface IP packet filtering initialized, divert enabled, rule-based forwarding disabled, unlimited logging i4b: ISDN call control device attached i4bisppp: 4 ISDN SyncPPP device(s) attached i4bctl: ISDN system control port attached i4bipr: 4 IP over raw HDLC ISDN device(s) attached (VJ header compression) i4btel: 2 ISDN telephony interface device(s) attached i4brbch: 4 raw B channel access device(s) attached i4btrc: 4 ISDN trace device(s) attached Waiting 3 seconds for SCSI devices to settle sa0 at ncr0 bus 0 target 5 lun 0 sa0: Removable Sequential Access SCSI-CCS device sa0: 3.300MB/s transfers da0 at ncr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 20.000MB/s transfers (10.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4101MB (8399520 512 byte sectors: 255H 63S/T 522C) changing root device to da0s1a To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: install problem with 4.0 (spec_getpages)
> Marc van Kempen wrote: > > > > Hi, > > > > While trying to boot from the 4.0 installation disks, > > I get the following error after the devices have been probed: > > > > [SNIP] > > > root@localhost:/usr/src/sys/compile/SCHOPENHAUER > > Timecounter "i8254" frequency 1193182 Hz > > CPU: Celeron (412.50-MHz 686-class CPU) > > 412 MHz is a non-conventional speed for a Celly : if you are > overclocking (I'm doing it, too), does the bug repeats itself when at > the normal speed ? > I will try that, it didn't occur to me to do that, since I've been running that for a year or so now, without any problems. Regards, Marc. -- Marc van Kempen BowTie Technology Email: [EMAIL PROTECTED]WWW & Databases tel. +31 40 2 43 20 65 fax. +31 40 2 44 21 86 http://www.bowtie.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: install problem with 4.0 (spec_getpages)
On Mon, Mar 20, 2000 at 01:55:11AM +1000, Idea Receiver wrote: > > > On Sun, 19 Mar 2000, Thierry.herbelot wrote: > > > Marc van Kempen wrote: > > > > > > Hi, > > > > > > While trying to boot from the 4.0 installation disks, > > > I get the following error after the devices have been probed: > > > > > > > [SNIP] > > > > > root@localhost:/usr/src/sys/compile/SCHOPENHAUER > > > Timecounter "i8254" frequency 1193182 Hz > > > CPU: Celeron (412.50-MHz 686-class CPU) > > > > 412 MHz is a non-conventional speed for a Celly : if you are > > overclocking (I'm doing it, too), does the bug repeats itself when at > > the normal speed ? > > yes it does. > anyway.. problem fixed this afternoon (australia time :P)! > What are you saying? That you have the same problem and that you managed to fix it? -- Marc van Kempen BowTie Technology Email: [EMAIL PROTECTED]WWW & Databases tel. +31 40 2 43 20 65 fax. +31 40 2 44 21 86 http://www.bowtie.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: install problem with 4.0 (spec_getpages)
> > You also ought to make sure the floppies can get through a complete > format before dd'ing the images over them. > This was it! I went through 8 floppies before I found a decent pair, these 3.5" things s*ck. Thanks, Marc. -- ------------ Marc van Kempen BowTie Technology Email: [EMAIL PROTECTED]WWW & Databases tel. +31 40 2 43 20 65 fax. +31 40 2 44 21 86 http://www.bowtie.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Other Linux stuff...
> "Bruce A. Mah" wrote: > > > > If memory serves me right, Marcel Moolenaar wrote: > > > > > So, from a pure > > > ELF layout point of view, both shared objects and executables are the > > > same. But a shared library is not guaranteed to be executable. Allowing > > > shared objects to be executed is in violation with the specs: > > > > This may be a really stupid question, but what on Earth do they gain by > > allowing the execution of shared object files? > > The only gain I see, if you can call it a gain, is that you can get > non-trivial information out of a shared object from within scripts, but > I don't know if this has been the reason. If you don't allow execution > of shared objects, you have to use dlopen(3) and call some functions or > query some variables. > Would it be possible to write a small wrapper to load the shared library and execute some entryfunction to get it started? I suppose that's what the elf-loader under linux does. If so that would be a simple addition to the linux-lib port. Marc. -- Marc van Kempen BowTie Technology Raiffeisenstraat 7 5611 CH Eindhoven tel. +31 40 2 64 98 60 mailto:[EMAIL PROTECTED] fax. +31 40 2 64 98 61 http://www.bowtie.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: btokup().. patch to STYLE(9) (fwd)
> so far you are the first and only objector.. > which makes you outnumbered by 10 to 1 on email counts.. > I agree completely, saving a few bytes in the source code is not worth the obfuscation that results, writing correct programs is hard enough as it is, without having to suffer from obfuscation. Marc. ---- Marc van Kempen BowTie Technology Email: m...@bowtie.nlWWW & Databases tel. +31 40 2 43 20 65 fax. +31 40 2 44 21 86 http://www.bowtie.nl To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message