Re: rm -rf behavior on readonly nfs
On Sun, Jan 30, 2000 at 09:06:33AM +0900, Jun Kuriyama wrote: I found difference between "rm -rf" for non-exist file on readonly nfs and usual non-writable directory. In this example, /usr/src is readonly nfs mounted and /usr/bin is normal filesystem but not writable. And file "a" is not exist. - % rm /usr/bin/a rm: /usr/bin/a: No such file or directory % rm -f /usr/bin/a % rm -rf /usr/bin/a % rm /usr/src/a rm: /usr/src/a: No such file or directory % rm -f /usr/src/a % rm -rf /usr/src/a rm: /usr/src/a: Read-only file system % - For "-f" option, last behavior is expected one, or not? This happens on either NFS-mounted or real directories. It think that since the manual of rm(1) says: -f Attempt to remove the files without prompting for confirma- tion, regardless of the file's permissions. If the file does not exist, do not display a diagnostic message or modify the exit status to reflect an error. it ought to print nothing in such a case. Let me know if the small patch shown below helps in correcting this. I can't check this cause I got bitten by getflags() in(s)anity last night when I cvsup'ed. The diff -u output is: %%% patch begins here %%% --- /usr/src/bin/rm/rm.cSat Jan 29 01:14:23 2000 +++ rm.cSun Jan 30 09:32:18 2000 @@ -196,7 +196,9 @@ } continue; case FTS_ERR: - errx(1, "%s: %s", p-fts_path, strerror(p-fts_errno)); + if (!fflag) + errx(1, "%s: %s", p-fts_path, +strerror(p-fts_errno)); case FTS_NS: /* * FTS_NS: assume that if can't stat the file, it %%% patch ends here %%% -- Giorgos Keramidas, keramida @ ceid . upatras . gr "Don't let your schooling interfere with your education." [Mark Twain] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Loader.rc: unknown command
On Sun, Jan 30, 2000 at 02:50:22PM +0900, Daniel C. Sobral wrote: Jean-Marc Zucconi wrote: With a new installed world I get this message at boot: \ Loader.rc Loader.rc: unknown command Fortunately this does not prevent the machine to boot :-) Any clue? The \ command is not working correctly, resulting in the "Loader.rc" comment being executed instead of ignored. Why? I don't have a clue. Is *ANYONE* being able to reproduce this problem? If so, please contact me ASAP, since we have almost no time to fix this before 4.0-RELEASE. Jean, I need more information about your setup. What was it running before? How did you install this new world? Did you ever touch any file in /boot? Can you give me a date of your world source? I can reproduce this. My world source was cvsuped on Fri 1/28 @ ~1:30EST. Before, it was running code from two weeks ago (1/14). I get the exact same error message as Jean-Marc. All I did was a make buildworld, make installworld, and the only file I've ever touched in /boot is loader.conf.local. Eric To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rm -rf behavior on readonly nfs
:This happens on either NFS-mounted or real directories. It think that since :the manual of rm(1) says: : : -f Attempt to remove the files without prompting for confirma- : tion, regardless of the file's permissions. If the file does : not exist, do not display a diagnostic message or modify the : exit status to reflect an error. : :it ought to print nothing in such a case. Let me know if the small patch :shown below helps in correcting this. I can't check this cause I got bitten :by getflags() in(s)anity last night when I cvsup'ed. No, it should definitely print an error. If the file didn't exist it should stay silent but if the file exists and cannot be removed, that should generate an error. The -f option does not mean "silently fail", it simply means that no error message should be printed if the error is innocuous. i.e. you try to remove a file that is already removed. -Matt Matthew Dillon [EMAIL PROTECTED] :The diff -u output is: : :%%% patch begins here %%% :--- /usr/src/bin/rm/rm.cSat Jan 29 01:14:23 2000 :+++ rm.cSun Jan 30 09:32:18 2000 :@@ -196,7 +196,9 @@ :} :continue; :case FTS_ERR: :- errx(1, "%s: %s", p-fts_path, strerror(p-fts_errno)); :+ if (!fflag) :+ errx(1, "%s: %s", p-fts_path, :+strerror(p-fts_errno)); :case FTS_NS: :/* : * FTS_NS: assume that if can't stat the file, it :%%% patch ends here %%% : :-- :Giorgos Keramidas, keramida @ ceid . upatras . gr :"Don't let your schooling interfere with your education." [Mark Twain] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rm -rf behavior on readonly nfs
On Sun, 30 Jan 2000, Jun Kuriyama wrote: I found difference between "rm -rf" for non-exist file on readonly nfs and usual non-writable directory. In this example, /usr/src is readonly nfs mounted and /usr/bin is normal filesystem but not writable. And file "a" is not exist. - % rm /usr/bin/a rm: /usr/bin/a: No such file or directory % rm -f /usr/bin/a % rm -rf /usr/bin/a % rm /usr/src/a rm: /usr/src/a: No such file or directory % rm -f /usr/src/a % rm -rf /usr/src/a rm: /usr/src/a: Read-only file system % - For "-f" option, last behavior is expected one, or not? The kernel returns EROFS for unlink() without even looking up the last component of the filename. This is a cosmetic bug IMO. The errors listed in POSIX.1 are not required to be checked for in the given order. However, checking in that order usually gives the most logical results. For unlink() and similar syscalls, EROFS is at the end of the list. Once unlink() returns EROFS, POSIX.2 requires the error to be reported for rm -f (POSIX.2 requires rm -f to be silent about ENOENT but not about all other errors). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More world breakage
Whichever system they run on. This can be the host machine even for
cross-compiling, if the target root is remote mounted. The main problem
with this in -current is that some install rules put ${DESTDIR} in the
installed files. perl is the main offender.
Which install rules? I'd like to fix this. (I know libraries are a
big mess).
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Still problems with latest ATA
It seems Kris Kennaway wrote: My CDROM still refuses to work with cdcontrol, although the 30-seconds of kernel spinning is now fixed. Trying to play a track gives: acd0: PLAY_BIG - ILLEGAL REQUEST asc=21 ascq=00 error=04 I'll bet this drive doesn't support PLAY_BIG but only PLAY_MSF. The problem here is that PLAY_MSF's parameters are either in binary or in BCD, but you dont know which one to use, as this is screwed in more drives than those missing PLAY_BIG. One of my WDC's still falls back to PIO mode at boot time (see previous messages, nothing has changed). Its not able to do DMA then, besides cluttering up the console with the retries, it does work afterwards right ? If anything has changed in the verbose boot I can provide a copy of it, otherwise all my relevant details are in the archives from previous messages.. Send me one, there are a few changed items, I'll see what can be done... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PAIN
On Sat, 29 Jan 2000, Alex Zepeda wrote: On Sun, 30 Jan 2000, kibbet wrote: /me looks at the bunch of 386 mobo's... lets not go there.. :) /me looks at the stack of 386sx chips he has and wonders why no-one did 8 way SMP with these! uky.edu once had a Sequent Symmetry with twenty-six 386DX's in it -- 20 mhz if I remember right. Interesting box, to say the least... Mike Andrews (MA12) * [EMAIL PROTECTED] * http://www.bit0.com/ VP, sysadmin, network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Printer fiascos.
Matthew Dillon wrote:
When the new parallel port stuff was put several months ago, my
machine stopped working. I had to set flags to 0x40 to make it
work again. Flags of 0x40 force the driver to use the most
basic probes possible. It was put in because a number of people's
machines stopped working.
It looks like Peter removed the flags 0x40 in rev 1.228 of GENERIC
on Jan 14.
At the time I had an argument with the author who insisted that
the correct way to force 'basic' probing of the printer was to
set the flags field in GENERIC rather then make the default a basic
probe.
* Peter, the comment in your log message makes no mention of the reason
* for removing the flags. If you did this by accident could you please
* set the flags back to 0x40?
The reason I did that was because flags 0x40 only does something if you
activate the PPC_PROBE_CHIPSET option. By default you get flags 0x40
type behavior and the intrusive probes are simply not even compiled into
the driver. If you activate the option, then you can also specify
flags 0x40 to disable the code you compiled in. In other words, GENERIC
does not require the flag any more as it doesn't have the option active.
#ifdef PPC_PROBE_CHIPSET
/* we have to differenciate available chipset modes,
* chipset running modes and IEEE-1284 operating modes
*
* after detection, the port must support running in compatible mode
*/
if (ppc-ppc_flags 0x40) {
if (bootverbose)
printf("ppc: chipset forced to generic\n");
#endif
Now, a huge number of changes have been made since the original problem
was reported, so I could be puffing smoke here. I didn't see anything
in the CVS logs, though, so I am assuming that the removal of the
flags field was a mistake.
David, try putting flags 0x40 back in and see if that fixes your
problem.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
:Why is it that a properly functioning printer is such a moving target
:in FreeBSD?
:
:I don't mean to be argumentative, but under 3.x, the magic cookie to
:make printers work (it appeared to be a flow control problem) was to
:change
:
:device ppc0at isa? port? flags 0x40 net irq 7
:
:to
:
:device ppc0at isa? port? flags 0x40 tty irq 7
:
:Now... I've upgraded to -CURRENT, and it has a much more serious
:problem. The line now reads
:
:device ppc0at isa? port? irq 7
:
:... so I havn't tried putting net or tty in it, but I have a printer
:with a particular problem --- it will often fail to pick up a sheet of
:paper. I suspect that this sets the paper out sense line of the
:parallel port (?).
:
:When this happens, the entire machine freezes until someone feeds the
:printer --- the momment it starts printing again, the computer
:unfreezes.
:
:Printer-port related things probe as:
:
:ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0
:ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode
:ppbus0: IEEE1284 device found /NIBBLE/PS2/ECP
:Probing for PnP devices on ppbus0:
:ppbus0: HEWLETT-PACKARD DESKJET 870C PCL,MLC,PML
:lpt0: Printer on ppbus0
:lpt0: Interrupt-driven port
:plip0: PLIP network interface on ppbus0
:ppi0: Parallel I/O on ppbus0
:
:(I have tried putting the BIOS in different parallel port modes.)
:
:Dave.
:
:--
:
:|David Gilbert, Velocet Communications. | Two things can only be |
:|Mail: [EMAIL PROTECTED] | equal if and only if they |
:|http://www.velocet.net/~dgilbert | are precisely opposite. |
:=GLO
Cheers,
-Peter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: More world breakage
On Sun, 30 Jan 2000, Mark Murray wrote:
Whichever system they run on. This can be the host machine even for
cross-compiling, if the target root is remote mounted. The main problem
with this in -current is that some install rules put ${DESTDIR} in the
installed files. perl is the main offender.
Which install rules? I'd like to fix this. (I know libraries are a
big mess).
Ones in perl's internal makefiles. I hardly know what they are, but
their are 1384 lines of messages in my buildworld output despite my
use of `make -s' to turn off verbose output. Headers are converted
and packing lists are built...
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Still problems with latest ATA
On Sun, 30 Jan 2000, Soren Schmidt wrote: Trying to play a track gives: acd0: PLAY_BIG - ILLEGAL REQUEST asc=21 ascq=00 error=04 I'll bet this drive doesn't support PLAY_BIG but only PLAY_MSF. The problem here is that PLAY_MSF's parameters are either in binary or in BCD, but you dont know which one to use, as this is screwed in more drives than those missing PLAY_BIG. This drive worked fine under wcd. It would be kind of disconcerting to be told that my CD is no longer supported and I have to buy a new one. One of my WDC's still falls back to PIO mode at boot time (see previous messages, nothing has changed). Its not able to do DMA then, besides cluttering up the console with the retries, it does work afterwards right ? It works fine afterwards, but according to http://www.westerndigital.com/products/drives/specs/oldspecs/AC26400.html it is certainly DMA-capable. It *does* say, interestingly, that older versions cannot do Ultra ATA 66 (I purchased this as an Ultra ATA 66 drive, but..). I'll see what the diagnostic utility has to say about it. Send me one, there are a few changed items, I'll see what can be done... Will do tomorrow.. Kris "How many roads must a man walk down, before you call him a man?" "Eight!" "That was a rhetorical question!" "Oh..then, seven!" -- Homer Simpson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Still problems with latest ATA
It seems Kris Kennaway wrote: On Sun, 30 Jan 2000, Soren Schmidt wrote: Trying to play a track gives: acd0: PLAY_BIG - ILLEGAL REQUEST asc=21 ascq=00 error=04 I'll bet this drive doesn't support PLAY_BIG but only PLAY_MSF. The problem here is that PLAY_MSF's parameters are either in binary or in BCD, but you dont know which one to use, as this is screwed in more drives than those missing PLAY_BIG. This drive worked fine under wcd. It would be kind of disconcerting to be told that my CD is no longer supported and I have to buy a new one. Hmm, I'll have to check up on the exact model then... One of my WDC's still falls back to PIO mode at boot time (see previous messages, nothing has changed). Its not able to do DMA then, besides cluttering up the console with the retries, it does work afterwards right ? It works fine afterwards, but according to http://www.westerndigital.com/products/drives/specs/oldspecs/AC26400.html it is certainly DMA-capable. It *does* say, interestingly, that older versions cannot do Ultra ATA 66 (I purchased this as an Ultra ATA 66 drive, but..). I'll see what the diagnostic utility has to say about it. I'm sorry to tell you, by my experience with WDC drives are, well, not good, there has been lots of flukes. The latest ones that is relabeled IBM drives works just fine though. Ssdly the same can be said about Maxtor. For a laugh grep for all the blacklisted drives in the Linux drivers :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: identcpu.c change causes panic
Kris Kennaway [EMAIL PROTECTED] wrote: This commit causes my P5 to panic at boot: kato2000/01/28 23:49:03 PST Modified files: sys/i386/i386identcpu.c Log: Simplify messages of Pentium II, Pentium II Xeon, Celeron, Pentium III and Pentium III Xeon CPUs. If a CPU is one of Pentium II, Pentium II Xeon and Celeron, the message is always "Pentium II/Pentium II Xeon/Celeron". If a CPU is one of Pentium III and Pentium III Xeon, the message is always "Pentium III/Pentium III Xeon". Revision ChangesPath 1.80 +5 -12 src/sys/i386/i386/identcpu.c It sounds strange. I didn't modify any P5 stuff. I attached the patch from 1.79 to 1.80 diff in this mail. - Could you try to this patch with the -R option? - Please report the panic message you got. ---+--+ KATO Takenori [EMAIL PROTECTED] |FreeBSD | Dept. Earth Planet. Sci, Nagoya Univ. |The power to serve! | Nagoya, 464-8602, Japan| http://www.FreeBSD.org/ | |http://www.jp.FreeBSD.org/| FreeBSD(98) 3.3R-Rev. 01 available! +==+ Index: identcpu.c === RCS file: /home/ncvs/src/sys/i386/i386/identcpu.c,v retrieving revision 1.79 retrieving revision 1.80 diff -c -c -r1.79 -r1.80 *** identcpu.c 2000/01/15 06:29:03 1.79 --- identcpu.c 2000/01/29 07:49:02 1.80 *** *** 36,42 * SUCH DAMAGE. * *from: Id: machdep.c,v 1.193 1996/06/18 01:22:04 bde Exp ! * $FreeBSD: src/sys/i386/i386/identcpu.c,v 1.79 2000/01/15 06:29:03 tanimura Exp $ */ #include "opt_cpu.h" --- 36,42 * SUCH DAMAGE. * *from: Id: machdep.c,v 1.193 1996/06/18 01:22:04 bde Exp ! * $FreeBSD: src/sys/i386/i386/identcpu.c,v 1.80 2000/01/29 07:49:02 kato Exp $ */ #include "opt_cpu.h" *** *** 199,221 strcat(cpu_model, "Pentium Pro"); break; case 0x30: - strcat(cpu_model, "Pentium II"); - cpu = CPU_PII; - break; case 0x50: - strcat(cpu_model, "Pentium II/Xeon/Celeron"); - cpu = CPU_PII; - break; case 0x60: ! strcat(cpu_model, "Pentium II/Celeron"); cpu = CPU_PII; break; case 0x70: - strcat(cpu_model, "Pentium III/Xeon"); - cpu = CPU_PIII; - break; case 0x80: ! strcat(cpu_model, "Pentium III"); cpu = CPU_PIII; break; default: --- 199,214 strcat(cpu_model, "Pentium Pro"); break; case 0x30: case 0x50: case 0x60: ! strcat(cpu_model, ! "Pentium II/Pentium II Xeon/Celeron"); cpu = CPU_PII; break; case 0x70: case 0x80: ! strcat(cpu_model, ! "Pentium III/Pentium III Xeon"); cpu = CPU_PIII; break; default:
Re: INET6 and fxp
If I put INET6 in my kernelconfig my network stops working. Even IPv4. I have a Intel EtherExpress Pro 10/100B Ethernet (fxp) card. I found a fix for FreeBSD on an OpenBSD mailinglist :-) http://www.sigmasoft.com/~openbsd/archive/openbsd-tech/199912/msg00321.html Something better than that is probably needed in the long run. Let me confirm it. Does this also fix your problem on your freebsd-current? Yes. I have only tried ping6, but that works, and IPv4 works. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
old style pcic attach messages - conversion to newbus
To go from pcic-pci0: TI PCI-1131 PCI-CardBus Bridge irq 9 at device 19.0 on pci0 pcic-pci0: driver is using old-style compatability shims pcic-pci1: TI PCI-1131 PCI-CardBus Bridge irq 9 at device 19.1 on pci0 pcic-pci1: driver is using old-style compatability shims to pcic-pci0: TI PCI-1131 PCI-CardBus Bridge irq 9 at device 19.0 on pci0 pcic-pci1: TI PCI-1131 PCI-CardBus Bridge irq 9 at device 19.1 on pci0 in less than 1 minute, you'll need the attached patch. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
problems rebooting (hanging on ata0)
I've had the following problem with several recent versions of current. (dmesg of maching included below) Typing `reboot' kills everything but doesn't reboot machine. And then when I break into DDB and type panic twice it tries to dump but then it fails and goes into an infinite loop of `ad0: timeout waiting for DRQ'. Any ideas? /assar Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #8: Fri Jan 28 23:47:23 CET 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/HUNAHPU Timecounter "i8254" frequency 1193182 Hz CPU: Pentium Pro (199.31-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x617 Stepping = 7 Features=0xfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV real memory = 134217728 (131072K bytes) config di lnc0 No such device: lnc0 Invalid command or syntax. Type `?' for help. config di le0 No such device: le0 Invalid command or syntax. Type `?' for help. config di ie0 No such device: ie0 Invalid command or syntax. Type `?' for help. config di fe0 No such device: fe0 Invalid command or syntax. Type `?' for help. config di ex0 config di ed0 config di cs0 No such device: cs0 Invalid command or syntax. Type `?' for help. config q avail memory = 126758912 (123788K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 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 0xc0348000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc034809c. Pentium Pro MTRR support enabled md0: Malloc disk npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard pci0: PCI bus on pcib0 isab0: Intel 82371SB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 ata-pci0: Intel PIIX3 ATA controller port 0xffa0-0xffaf at device 7.1 on pci0 ata0 at 0x01f0 irq 14 on ata-pci0 vga-pci0: S3 968 graphics accelerator mem 0x8000-0x81ff irq 0 at device 12.0 on pci0 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 ata-isa0: already registered as ata0 atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 vga0: Generic ISA VGA at port 0x3c0-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: Parallel port at port 0x378-0x37f irq 7 flags 0x40 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppi0: Parallel I/O on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port plip0: PLIP network interface on ppbus0 ed0: not probed (disabled) ex0: not probed (disabled) ep0: 3Com 3C509-Combo EtherLink III at port 0x300-0x30f irq 9 on isa0 ep0: Ethernet address 00:a0:24:77:5d:eb ep0: supplying EUI64: 00:a0:24:ff:fe:77:5d:eb APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 SMP: AP CPU #1 Launched! ad0: 775MB IBM-DSOA-20810 [1575/16/63] at ata0-master using WDMA2 Mounting root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted ep0: starting DAD for fe80:0002::02a0:24ff:fe77:5deb ep0: DAD complete for fe80:0002::02a0:24ff:fe77:5deb - no duplicates found
make installworld broken???
I'm seeing the following failure on my -current box with sources cvsupped last night about 11:30 est. === bin/ps install -C -c -s -o root -g wheel -m 555 ps /bin install -C -c -o root -g wheel -m 444 ps.1.gz /usr/share/man/man1 === bin/pwd install -C -c -s -o root -g wheel -m 555 pwd /bin install -C -c -o root -g wheel -m 444 pwd.1.gz /usr/share/man/man1 === bin/rcp install -C -c -s -o root -g wheel -m 4555 -fschg rcp /bin /usr/libexec/ld-elf.so.1: install: Undefined symbol "string_to_flags" *** Error code 1 Stop in /usr/src/bin/rcp. *** Error code 1 Stop in /usr/src/bin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. #;^) -- So ya want ta hear da roots? bush doctor [EMAIL PROTECTED] Of course I run FreeBSD!! http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Printer fiascos.
On Sat, Jan 29, 2000 at 09:49:40PM -0600, Chris Costello wrote: On Saturday, January 29, 2000, David Gilbert wrote: When this happens, the entire machine freezes until someone feeds the printer --- the momment it starts printing again, the computer unfreezes. Could it be a printer-specific (or printer-compatibility) problem? My HP DeskJet 880C does not have that problem at all: ppc0 at port 0x378-0x37f irq 7 flags 0x40 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppb0: IEEE1284 device found /NIBBLE/ECP Probing for PnP devices on ppbus0: ppbus0: HEWLETT-PACKARD DESKJET 880C MLC,PCL,PML 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 Note that you're using an older ppbus/lpt drivers. -- [EMAIL PROTECTED] / [EMAIL PROTECTED] FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Printer fiascos.
On Sat, Jan 29, 2000 at 10:59:15PM -0500, David Gilbert wrote: "Chris" == Chris Costello [EMAIL PROTECTED] writes: Chris On Saturday, January 29, 2000, David Gilbert wrote: When this happens, the entire machine freezes until someone feeds the printer --- the momment it starts printing again, the computer unfreezes. ChrisCould it be a printer-specific (or printer-compatibility) Chris problem? My HP DeskJet 880C does not have that problem at all: To my mind, the printer shouldn't be able to hang the comptuer ... no matter what it does. My biggest problem is that it hangs the system. Even if rapid interrupts are sent to the computer? A priority issue among various interrupt sources maybe. -- [EMAIL PROTECTED] / [EMAIL PROTECTED] FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PAIN
On 30-Jan-00 Mike Andrews wrote: On Sat, 29 Jan 2000, Alex Zepeda wrote: On Sun, 30 Jan 2000, kibbet wrote: /me looks at the bunch of 386 mobo's... lets not go there.. :) /me looks at the stack of 386sx chips he has and wonders why no-one did 8 way SMP with these! uky.edu once had a Sequent Symmetry with twenty-six 386DX's in it -- 20 mhz if I remember right. Interesting box, to say the least... Certainly sounds interesting. Back a couple of years a friend (electronics guru) and I wanted to do some PP'ing for a little astronomy project. It never eventuated but we were thinking of a tying the 6 odd 486's together directly via a pci to pci circuit. We wanted SPEED though so we tossed around the idea of direct pc/pc communication via SIMM sockets. Idea being, chunk of ram for local processing, starting on a SIMM boundary a circuit (running at cpu bus speed) to communicate with the other pc's. All highly unlikely, but logic didn't enter into it back then :) Cheers... Kent Ibbetson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Printer fiascos.
On Sat, Jan 29, 2000 at 08:21:33PM -0800, Matthew Dillon wrote: When the new parallel port stuff was put several months ago, my machine stopped working. I had to set flags to 0x40 to make it work again. Flags of 0x40 force the driver to use the most basic probes possible. It was put in because a number of people's machines stopped working. It looks like Peter removed the flags 0x40 in rev 1.228 of GENERIC on Jan 14. Specific chipset detection is now disabled by default since most of the chipsets detected on new MB are not recognised by ppc. A MACHINE option shall be set to activate chipset detection. See http://www.freebsd.org/~nsouch/ppbus.html for more info. [...] David, try putting flags 0x40 back in and see if that fixes your problem. 0x40 has the same effect only if chipset specific detection is activated at compile time by the correct option. Otherwise the action is null. -- [EMAIL PROTECTED] / [EMAIL PROTECTED] FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make installworld broken???
You need to manually recompile and install your "install" command. It's source-dir is called "xinstall" btw. Poul-Henning In message [EMAIL PROTECTED], bush doctor writes: I'm seeing the following failure on my -current box with sources cvsupped last night about 11:30 est. === bin/ps install -C -c -s -o root -g wheel -m 555 ps /bin install -C -c -o root -g wheel -m 444 ps.1.gz /usr/share/man/man1 === bin/pwd install -C -c -s -o root -g wheel -m 555 pwd /bin install -C -c -o root -g wheel -m 444 pwd.1.gz /usr/share/man/man1 === bin/rcp install -C -c -s -o root -g wheel -m 4555 -fschg rcp /bin /usr/libexec/ld-elf.so.1: install: Undefined symbol "string_to_flags" *** Error code 1 Stop in /usr/src/bin/rcp. *** Error code 1 Stop in /usr/src/bin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. #;^) -- So ya want ta hear da roots? bush doctor [EMAIL PROTECTED] Of course I run FreeBSD!! http://www.freebsd.org/ 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: make installworld broken???
Out of da blue Poul-Henning Kamp aka ([EMAIL PROTECTED]) said: You need to manually recompile and install your "install" command. Thanxs. I had looked at this, but wasn't sure. It's source-dir is called "xinstall" btw. Why is the source called "xinstall"? Poul-Henning In message [EMAIL PROTECTED], bush doctor writes: I'm seeing the following failure on my -current box with sources cvsupped last night about 11:30 est. [snippage ...] -- 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! #;^) -- So ya want ta hear da roots? bush doctor [EMAIL PROTECTED] Of course I run FreeBSD!! http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problems rebooting (hanging on ata0)
I've had the following problem with several recent versions of current. (dmesg of maching included below) Typing `reboot' kills everything but doesn't reboot machine. And then when I break into DDB and type panic twice it tries to dump but then it fails and goes into an infinite loop of `ad0: timeout waiting for DRQ'. Any ideas? Same message here, but after a panic of the USB subsystem. I blamed the current spl. Until I did a 'call splx(0)' right before giving the command panic. It still did not give me a dump. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: old style pcic attach messages - conversion to newbus
In message Pine.BSF.4.20.0001301011280.843-10@localhost Nick Hibma writes: : pcic-pci0: TI PCI-1131 PCI-CardBus Bridge irq 9 at device 19.0 on pci0 : pcic-pci0: driver is using old-style compatability shims : pcic-pci1: TI PCI-1131 PCI-CardBus Bridge irq 9 at device 19.1 on pci0 : pcic-pci1: driver is using old-style compatability shims : : to : : pcic-pci0: TI PCI-1131 PCI-CardBus Bridge irq 9 at device 19.0 on pci0 : pcic-pci1: TI PCI-1131 PCI-CardBus Bridge irq 9 at device 19.1 on pci0 : : in less than 1 minute, you'll need the attached patch. Need the attached patch... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Error in Makefile one needs to correct before a `make world'
If you installed world after my libreadline header moving, you probably
have readline headers in /usr/include you'll want to rm.
Index: Makefile
===
RCS file: /home/ncvs/src/gnu/lib/libreadline/readline/Makefile,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- Makefile2000/01/29 12:01:52 1.4
+++ Makefile2000/01/30 17:11:46 1.5
@@ -17,6 +17,8 @@
DPADD+= $(LIBTERMCAP)
LDADD+= -ltermcap
+
+INCDIR=/usr/include/readline
.for hdr in ${INSTALLED_HEADERS}
INCS+= ${SRCDIR}/${hdr}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Loader.rc: unknown command
On Sun, 30. Jan. 2000 at 14:50:22 +0900, Daniel C. Sobral wrote: Jean-Marc Zucconi wrote: With a new installed world I get this message at boot: \ Loader.rc Loader.rc: unknown command Fortunately this does not prevent the machine to boot :-) Any clue? The \ command is not working correctly, resulting in the "Loader.rc" comment being executed instead of ignored. Why? I don't have a clue. Is *ANYONE* being able to reproduce this problem? If so, please contact me ASAP, since we have almost no time to fix this before 4.0-RELEASE. I can reproduce this. I use CTM and the delta that broke the loader is number 4202 of src-cur, which was generated on Jan 28 11:02. I think it's the time when cdldr was committed. There problem seems not to depend on which forth scripts I put into /boot. I tried some old ones from my first install (3.2-RELEASE) that had worked up to that point, and the new ones from the -current source tree. -- Jan Andres [EMAIL PROTECTED]Ham radio: DH2JAN "Bell Labs Unix -- reach out and grep someone." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problems rebooting (hanging on ata0)
Nick Hibma [EMAIL PROTECTED] writes: Same message here, but after a panic of the USB subsystem. I blamed the current spl. Until I did a 'call splx(0)' right before giving the command panic. It still did not give me a dump. There seems to be two problems here: 1) It hangs instead of rebooting 2) It doesn't manage to write a dump. It doesn't happen every reboot and I haven't been able to figure out what's triggering it. /assar To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Printer fiascos.
For what its worth, I am able to reproduce this problem on my system. Simply submit something to lpr, wait for the printer light to blink, and pull the paper tray. The system hangs hard as described and does not return to normal until the paper tray is put back in. I haven't been able to make it do anything while the printer has the system hung, so I haven't been able to track it down, yet. However, I haven't had much time to spend on this problem, but thought I'd chime in a "me too" when I saw someone had the (apparently) same problem. I have an HP LaserJet 4 connected to the parallel port. I am running -current, and a buildworld as of about a week ago. -Brian -- Brian Dean [EMAIL PROTECTED] Here's my dmesg: Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Sun Jan 23 09:10:33 EST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/VGER Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 300682757 Hz CPU: Pentium II/Xeon/Celeron (300.68-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 201326592 (196608K bytes) avail memory = 192131072 (187628K bytes) Preloaded elf kernel "kernel" at 0xc02f3000. Pentium Pro MTRR support enabled md0: Malloc disk 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 ata-pci0: Intel PIIX4 ATA-33 controller port 0xf000-0xf00f at device 7.1 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 pci0: Intel 82371AB/EB (PIIX4) USB controller (vendor=0x8086, dev=0x7112) at 7.2 irq 11 chip1: Intel 82371AB Power management controller port 0x5000-0x500f at device 7.3 on pci0 vga-pci0: NVidia Riva128 graphics accelerator mem 0xe500-0xe5ff,0xe400-0xe4ff irq 10 at device 9.0 on pci0 xl0: 3Com 3c905-TX Fast Etherlink XL port 0xc400-0xc43f irq 5 at device 10.0 on pci0 xl0: Ethernet address: 00:60:08:17:67:f9 miibus0: MII bus on xl0 nsphy0: DP83840 10/100 media interface on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ahc0: Adaptec 2940 Ultra SCSI adapter port 0xc800-0xc8ff mem 0xe900-0xe9000fff irq 9 at device 11.0 on pci0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs pci0: unknown card (vendor=0x1102, dev=0x0002) at 12.0 irq 11 pci0: unknown card (vendor=0x1102, dev=0x7002) at 12.1 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 ata-isa0: already registered as ata0 atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 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 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 IP packet filtering initialized, divert enabled, rule-based forwarding disabled, unlimited logging Waiting 15 seconds for SCSI devices to settle acd0: BCD-40XH CD-ROM/VER 3.1 CDROM drive at ata0 as master acd0: 128KB buffer, PIO4 acd0: Reads: CD-R, CD-RW, CD-DA stream, packet acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked Mounting root from ufs:/dev/da0a da2 at ahc0 bus 0 target 2 lun 0 da2: SEAGATE ST32550N 0021 Fixed Direct Access SCSI-2 device da2: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da2: 2047MB (4194058 512 byte sectors: 255H 63S/T 261C) da1 at ahc0 bus 0 target 1 lun 0 da1: SEAGATE ST32550N 0019 Fixed Direct Access SCSI-2 device da1: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da1: 2047MB (4194058 512 byte sectors: 255H 63S/T 261C) da0 at ahc0 bus 0 target 0 lun 0 da0: SEAGATE ST32550N 0019 Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da0: 2047MB (4194058 512 byte sectors: 255H 63S/T 261C) da4 at ahc0 bus 0 target 6 lun 0 da4: iomega jaz 1GB H.72 Removable Direct Access SCSI-2 device da4: 10.000MB/s transfers (10.000MHz, offset 15) da4: Attempt to query device size failed: NOT READY, Medium not present da3 at ahc0 bus 0 target 3 lun 0
Re: new C++ compiler changes
rename it libstdc++.so.1. Then you just have to modify your executable so that it looks for libstdc++.so.1 instead of libstdc++.so.3 Why not just reinstall the problematic executables? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More world breakage
On Fri, Jan 28, 2000 at 08:30:55PM -0500, John Baldwin wrote: I don't think we should change yet another thing before a release. The problem shouldn't have been created this close to a release in the first place. We have to stop somewhere, and I think we should stop "fixing" right here, right now unless there's a *really* good reason not to (IMO of course). You're right. I guess the proper solution is to just back these changes out until after 4.0 when you can finish fixing up install side of 'world'. I just got ahead of myself a little. I've been thinking about this - being the one who made the original commit! This problem is the product of _two_ recent changes in -current only. In -stable, and in -current before the end of December the following tools: ls, rm, chflags, find, xinstall and mtree used a common set of routines to manipulate file flags. These were borrowed from bin/ls/stat_flags.c and statically compiled into each tool. At the beginnig of January, because of the proliferation of utilities using these functions, I moved them to libutil in -current. There were however various objections to this change, on the basis that libutil isn't a utility library as its name suggest, but has a much more narrow definition relating to login related code. It was proposed by Bruce to move these to libc and to change their name to be in keeping with similar routines for manipulating file modes (setmode/getmode). This was what I did last week, renaming flags_to_string to getflags, and string_to_flags to setflags. I missed the clash of name space in a couple of unrelated tools, like mount_nfs, I agree that I should have been more careful here - sorry. There is now a problem for some people with the build chain due to xinstall being dependant upon a function that has changed its name for its file flags support. There is also a secondary question of whether getflags/setflags are good names for these functions (based as there were on getmode/setmode). Thinking out loud: If we back out the name change (string_to_flags-setflags) we'll bump into the buildchain problem again for people who've now got a new xinstall dependant upon setflags. Moving the functions back into libutil, from libc, is the wrong thing to do, IMHO, because the problem here isn't one of which library placement, it's one of function names. Libutil is the wrong place for these functions, which is why I wanted them in libc for the 4.0 release. It may be argued that we should back out _both_ commits and resurrect bin/ls/stat_flags.c. Would this gain us anything? I'm quite happy to DTRT(tm); I'm unsure that backing this change out _is_ the right thing however. Can we discuss it some more first please? Joe -- Josef KarthauserFreeBSD: Take the red pill and we'll show you just how Technical Manager deep the rabbit hole goes. (http://www.uk.freebsd.org) Pavilion Internet plc. [[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: identcpu.c change causes panic
On Sun, 30 Jan 2000, KATO Takenori wrote: It sounds strange. I didn't modify any P5 stuff. I attached the patch from 1.79 to 1.80 diff in this mail. - Could you try to this patch with the -R option? Yes, when I back out this revision ( nothing else) I can boot fine :-) - Please report the panic message you got. I'll have to write this down by hand - it didn't look very interesting, though. Kris "How many roads must a man walk down, before you call him a man?" "Eight!" "That was a rhetorical question!" "Oh..then, seven!" -- Homer Simpson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More world breakage
On Fri, Jan 28, 2000 at 08:30:55PM -0500, John Baldwin wrote: I don't think we should change yet another thing before a release. The problem shouldn't have been created this close to a release in the first place. We have to stop somewhere, and I think we should stop "fixing" right here, right now unless there's a *really* good reason not to (IMO of course). You're right. I guess the proper solution is to just back these changes out until after 4.0 when you can finish fixing up install side of 'world'. I just got ahead of myself a little. I've been thinking about this - being the one who made the original commit! This problem is the product of _two_ recent changes in -current only. In -stable, and in -current before the end of December the following tools: ls, rm, chflags, find, xinstall and mtree used a common set of routines to manipulate file flags. These were borrowed from bin/ls/stat_flags.c and statically compiled into each tool. At the beginnig of January, because of the proliferation of utilities using these functions, I moved them to libutil in -current. There were however various objections to this change, on the basis that libutil isn't a utility library as its name suggest, but has a much more narrow definition relating to login related code. It was proposed by Bruce to move these to libc and to change their name to be in keeping with similar routines for manipulating file modes (setmode/getmode). This was what I did last week, renaming flags_to_string to getflags, and string_to_flags to setflags. I missed the clash of name space in a couple of unrelated tools, like mount_nfs, I agree that I should have been more careful here - sorry. There is now a problem for some people with the build chain due to xinstall being dependant upon a function that has changed its name for its file flags support. There is also a secondary question of whether getflags/setflags are good names for these functions (based as there were on getmode/setmode). Thinking out loud: If we back out the name change (string_to_flags-setflags) we'll bump into the buildchain problem again for people who've now got a new xinstall dependant upon setflags. Moving the functions back into libutil, from libc, is the wrong thing to do, IMHO, because the problem here isn't one of which library placement, it's one of function names. Libutil is the wrong place for these functions, which is why I wanted them in libc for the 4.0 release. It may be argued that we should back out _both_ commits and resurrect bin/ls/stat_flags.c. Would this gain us anything? I'm quite happy to DTRT(tm); I'm unsure that backing this change out _is_ the right thing however. Can we discuss it some more first please? I think that getflags()/setflags() should stay where they are, but I can't comment on the namespace pollution issue. If/When the functions are renamed, they'll probably break make world again (because the new libc and old install will be there for a while), but to be honest, this *is* current. I think the issue to focus on is the function names. Joe -- Josef Karthauser FreeBSD: Take the red pill and we'll show you just how Technical Manager deep the rabbit hole goes. (http://www.uk.freebsd.org) Pavilion Internet plc. [[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]] -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.Awfulhak.org [EMAIL PROTECTED] Don't _EVER_ lose your sense of humour ! [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More world breakage
On Sun, 30 Jan 2000, Brian Somers wrote: I'm quite happy to DTRT(tm); I'm unsure that backing this change out _is_ the right thing however. Can we discuss it some more first please? I think that getflags()/setflags() should stay where they are, but I can't comment on the namespace pollution issue. If/When the functions are renamed, they'll probably break make world again (because the new libc and old install will be there for a while), but to be honest, this *is* current. I think the issue to focus on is the function names. I agree that folks should read current, and be able to do fixes. Do the fix, though, in a way that *doesn't* require yet another fix later on, and post the extraordinary steps clearly here, in a "HEADS-UP" mail that folks will definitely see, and maybe stick something in UPDATING too? At least, give everyone a fair chance, don't embed the fix as the end of a 1,000 words of context email, at the end of a long thread. That wouldn't be fair. Not for extraordinary breakage. Chuck Robey| Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More world breakage
On 30-Jan-00 Josef Karthauser wrote: On Fri, Jan 28, 2000 at 08:30:55PM -0500, John Baldwin wrote: I don't think we should change yet another thing before a release. The problem shouldn't have been created this close to a release in the first place. We have to stop somewhere, and I think we should stop "fixing" right here, right now unless there's a *really* good reason not to (IMO of course). You're right. I guess the proper solution is to just back these changes out until after 4.0 when you can finish fixing up install side of 'world'. I just got ahead of myself a little. I've been thinking about this - being the one who made the original commit! :) There is now a problem for some people with the build chain due to xinstall being dependant upon a function that has changed its name for its file flags support. There is also a secondary question of whether getflags/setflags are good names for these functions (based as there were on getmode/setmode). I have no opinion on the function names used except that strflags() would be bad, IMO. Thinking out loud: If we back out the name change (string_to_flags-setflags) we'll bump into the buildchain problem again for people who've now got a new xinstall dependant upon setflags. My main concern is people going from 3.x to 4.0. Since the xinstall binary on 3.x doesn't call a string_to_flags() function from libc but has it statically compiled in, the upgrade path should work fine for them. I'll test that tonight. If that path works fine, then the problem only exists for the people using fairly recent -current who have an xinstall binary that tries to use string_to_flags() from libc. Given, then, that they are all -current users, their being able to work around this is not too much to ask. I didn't originally realize that 3.x xinstall binaries didn't try to call the string_to_flags() function from libc. With that in mind, the upgrade path is only going to be broken for a few people who should be reading -current and thus know how to work around the problem, so I repeal my request for the changes to be backed out. My apologies. Moving the functions back into libutil, from libc, is the wrong thing to do, IMHO, because the problem here isn't one of which library placement, it's one of function names. Libutil is the wrong place for these functions, which is why I wanted them in libc for the 4.0 release. Agreed. It may be argued that we should back out _both_ commits and resurrect bin/ls/stat_flags.c. Would this gain us anything? No. I'm quite happy to DTRT(tm); I'm unsure that backing this change out _is_ the right thing however. Can we discuss it some more first please? Joe -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "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: More world breakage
On Sun, Jan 30, 2000 at 04:51:44PM -0500, John Baldwin wrote: [cut] With that in mind, the upgrade path is only going to be broken for a few people who should be reading -current and thus know how to work around the problem, so I repeal my request for the changes to be backed out. My apologies. Great :) So, has anyone any strong ideas on both the "correct" function names to use and what the correct API should be for the functions. Joe -- Josef KarthauserFreeBSD: Take the red pill and we'll show you just how Technical Manager deep the rabbit hole goes. (http://www.uk.freebsd.org) Pavilion Internet plc. [[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
bootp and diskless failure
Hi,
Is there something changed on BOOTP/diskless configuration?
This problem reappears some times and was fixed in August if I remember.
A hack was proposed before August, something like 'make root dev' call in
bootp_subr.c
Thanks,
Nicholas
bootpc_init: using network interface 'ed0'
Bootpc testing starting
bootpc hw address is 0:40:5:e2:a0:e9
My ip address is 10.2.0.1
Server ip address is 10.2.0.2
Gateway ip address is 0.0.0.0
boot file is kernel.coreff
Ignoring field type 54
Subnet mask is 255.255.0.0
rootfs is 10.2.0.2:/diskless/rootfs/current
Ignoring field type 28
no B_DEVMAGIC (bootdev=0x)
Manual root filesystem specification:
fstype:device Mount device using filesystem fstype
eg. ufs:/dev/da0s1a
? List valid disk boot devices
empty line Abort manual input
panic: Root mount failed, startup aborted.
Debugger("panic")
Stopped at Debugger+0x35: movb$0,0xc02d7f00
db panic
--
[EMAIL PROTECTED] / [EMAIL PROTECTED]
FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Printer fiascos.
This is on 3.4 Stable, Another "me too", BUT, with a "data point". NEC SuperScript 870, ASUS MB. Had the same problem when the BIOS was set to ECP+EPP on the parallel port. Sinces it only a printer, I set the BIOS to Normal and deliberately tried to introduce the problem (pull paper tray, etc). Didn't have the problem. Two things had happened, the BIOS change and I removed the "flags 0x40" from the config file. Relevant piece of dmesg: ppc0 at 0x378 irq 7 on isa ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppb0: IEEE1284 device found /NIBBLE Probing for PnP devices on ppbus0: ppbus0: NEC SuperScript 870 PRINTER PrintGear,PCL,PJL lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port dmesg prior to the change: ppc0 at 0x378 irq 7 flags 0x40 on isa ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/7 bytes threshold lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port Notice it used to say SMC-like chipset? Just a data point. m On Sun, 30 Jan 2000, Brian Dean wrote: For what its worth, I am able to reproduce this problem on my system. Simply submit something to lpr, wait for the printer light to blink, and pull the paper tray. The system hangs hard as described and does not return to normal until the paper tray is put back in. I haven't been able to make it do anything while the printer has the system hung, so I haven't been able to track it down, yet. However, I haven't had much time to spend on this problem, but thought I'd chime in a "me too" when I saw someone had the (apparently) same problem. I have an HP LaserJet 4 connected to the parallel port. I am running -current, and a buildworld as of about a week ago. -Brian -- Brian Dean[EMAIL PROTECTED] Here's my dmesg: Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Sun Jan 23 09:10:33 EST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/VGER Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 300682757 Hz CPU: Pentium II/Xeon/Celeron (300.68-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 201326592 (196608K bytes) avail memory = 192131072 (187628K bytes) Preloaded elf kernel "kernel" at 0xc02f3000. Pentium Pro MTRR support enabled md0: Malloc disk 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 ata-pci0: Intel PIIX4 ATA-33 controller port 0xf000-0xf00f at device 7.1 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 pci0: Intel 82371AB/EB (PIIX4) USB controller (vendor=0x8086, dev=0x7112) at 7.2 irq 11 chip1: Intel 82371AB Power management controller port 0x5000-0x500f at device 7.3 on pci0 vga-pci0: NVidia Riva128 graphics accelerator mem 0xe500-0xe5ff,0xe400-0xe4ff irq 10 at device 9.0 on pci0 xl0: 3Com 3c905-TX Fast Etherlink XL port 0xc400-0xc43f irq 5 at device 10.0 on pci0 xl0: Ethernet address: 00:60:08:17:67:f9 miibus0: MII bus on xl0 nsphy0: DP83840 10/100 media interface on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ahc0: Adaptec 2940 Ultra SCSI adapter port 0xc800-0xc8ff mem 0xe900-0xe9000fff irq 9 at device 11.0 on pci0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs pci0: unknown card (vendor=0x1102, dev=0x0002) at 12.0 irq 11 pci0: unknown card (vendor=0x1102, dev=0x7002) at 12.1 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 ata-isa0: already registered as ata0 atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 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 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 IP packet filtering initialized, divert enabled, rule-based forwarding disabled, unlimited logging Waiting 15 seconds for SCSI devices to settle acd0: BCD-40XH CD-ROM/VER 3.1 CDROM drive at ata0 as master acd0: 128KB
Re: INET6 and fxp
[EMAIL PROTECTED] wrote: FWIW this doesn't happen with my card: fxp0: Intel InBusiness 10/100 Ethernet port 0x1000-0x103f mem 0xf400-0xf40 f,0xf410-0xf4100fff irq 10 at device 15.0 on pci0 fxp0: Ethernet address 00:90:27:d1:83:6a fxp0: supplying EUI64: 00:90:27:ff:fe:d1:83:6a fxp0: starting DAD for fe80:0001::0290:27ff:fed1:836a fxp0: DAD complete for fe80:0001::0290:27ff:fed1:836a - no duplicates found 'course I don't actually use the card for internet access, just a local lan and the occasional IPv6 testing. (from what I've heard) the symptom highly depends on chip revision so you are lucky. itojun The problem only occurs on faster machines. For me it didn't work in a PII 400MHz machine but moving the offending card to a P133 machine made it work again. The addition of the DELAY() fixes the problem. The problem stems from the fact that the driver init routine is called twice in quick succession - once for IPv4 and again for IPv6. The other way of fixing it is to disable the call to ifp-if_ioctl in netinet6/in6_ifattach.c Wayne -- _ Wayne Knowles, Systems Manager / o \/ National Institute of Water Atmospheric Research Ltd \/ v /\ P.O. Box 14-901 Kilbirnie, Wellington, NEW ZEALAND `---' Email: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: identcpu.c change causes panic
Kris Kennaway [EMAIL PROTECTED] wrote: Yes, when I back out this revision ( nothing else) I can boot fine :-) Hmm, I cannot know why you got panic On your CPU (P54C: 586-class CPU), the part which I changed is not executed. I have tested the change on: - Intel MMX Pentium 166MHz - Intel Pentium Pro 200MHz - Intel Pentium II 400MHz (Dual) - AMD Athlon 700MHz - AMD K6-2 400MHz - Cyrix 5x86 100MHz and they work without problem. I'll have to write this down by hand - it didn't look very interesting, though. I'm interested in it. What I want to know is whether a bug is in my change or in other part. ---+--+ KATO Takenori [EMAIL PROTECTED] |FreeBSD | Dept. Earth Planet. Sci, Nagoya Univ. |The power to serve! | Nagoya, 464-8602, Japan| http://www.FreeBSD.org/ | |http://www.jp.FreeBSD.org/| FreeBSD(98) 3.3R-Rev. 01 available! +==+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Occurred during installworld (Makeworld went off perfectly).
Please note, I'm attempting to upgrade from -stable to -current. install-info --quiet --defsection="Programming development tools." --defentry="* libcom_err: (com_err).A Common Error Description Library for UNIX." com_err.info /usr/share/info/dir install-info: unrecognized option `--defsection=Programming development tools.' Try `install-info --help' for a complete list of options. *** Error code 1 -- Rod Taylor Partner of Zort (zort.on.ca) -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Printer fiascos
For what its worth, I am able to reproduce this problem on my system. Simply submit something to lpr, wait for the printer light to blink, and pull the paper tray. The system hangs hard as described and does not return to normal until the paper tray is put back in. I haven't been able to make it do anything while the printer has the system hung, so I haven't been able to track it down, yet. However, I haven't had much time to spend on this problem, but thought I'd chime in a "me too" when I saw someone had the (apparently) same problem. I have an HP LaserJet 4 connected to the parallel port. I am running -current, and a buildworld as of about a week ago. -Brian -- Brian Dean [EMAIL PROTECTED] I will confirm this problem with the lpt driver. Even worse, on my LaserJet IIIsi printer... Not only did it hang the system, but I went as far as turning the printer off, then back on. THE SYSTEM REBOOTED. There was no panic or other context to share. I suspect it MAY have been related to the about of time it takes the LJ III to cycle on a power-up. Regardless, this is wholly unacceptable for a RELEASE. FWIW, my dmesg follows to show the port-type, etc. ppp0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 pps0: Pulse per second Timing Interface on ppbus0 Cheers, -skots -- Scott G. Akmentins-Taylor InterNet: [EMAIL PROTECTED] MRY Systems [EMAIL PROTECTED] (Skots Gregorijs Akmentins-Teilors -- just call me "Skots") - Labak miris neka sarkans - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Occurred during installworld (Makeworld went off perfectly).
On Sun, 30 Jan 2000, you wrote: I've re-cvsupped and noticed UPDATING was changed this time. Upon remaking xinistall, I also discovered I had an incorrect version of libc. (it wanted libc.so.4, I had libc.so.3). Symlinked 3 to 4, we'll see what happens... Please note, I'm attempting to upgrade from -stable to -current. install-info --quiet --defsection="Programming development tools." --defentry="* libcom_err: (com_err).A Common Error Description Library for UNIX." com_err.info /usr/share/info/dir install-info: unrecognized option `--defsection=Programming development tools.' Try `install-info --help' for a complete list of options. *** Error code 1 -- Rod Taylor Partner of Zort (zort.on.ca) -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
libstdc++.so.3
I make a new world today after reinstalling xinstall and thought that along with recompiling my applications that are having problems that I assume started with the c++ compiler change, but I have recompiled several applications and still have the errors. If someone would tell me what I am doing wrong. This is from the latest version of mysql that I just compiled. Error: /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined symbol "_vt$9exception" TIA, ed To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PAIN
On Sat, 29 Jan 2000, Warner Losh wrote: In message [EMAIL PROTECTED] Greg Lehey writes: : I did a make world on my PDP-11 yesterday. It took less than a day. : But that's 2.11BSD. Turns out that 12MB + 30MB of swap isn't enough to build world. I ran out of swap and the machine rebooted (at least that's what I think happened, since it silently rebooted). Are you using -pipe? That drastically increases memory requirements. David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libstdc++.so.3
On Sun, 30 Jan 2000, Edwin Culp wrote: I make a new world today after reinstalling xinstall and thought that along with recompiling my applications that are having problems that I assume started with the c++ compiler change, but I have recompiled several applications and still have the errors. If someone would tell me what I am doing wrong. This is from the latest version of mysql that I just compiled. Error: /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined symbol "_vt$9exception" Please read the first 2124 entry of src/UPDATING. - Chris D. Faulhaber - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: 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: libstdc++.so.3
Looks like I have to cvsup again, it's not in my UPDATING from 11:40 PST today. That was the first place I checked. Sorry and thanks, ed "Chris D. Faulhaber" wrote: On Sun, 30 Jan 2000, Edwin Culp wrote: I make a new world today after reinstalling xinstall and thought that along with recompiling my applications that are having problems that I assume started with the c++ compiler change, but I have recompiled several applications and still have the errors. If someone would tell me what I am doing wrong. This is from the latest version of mysql that I just compiled. Error: /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined symbol "_vt$9exception" Please read the first 2124 entry of src/UPDATING. - Chris D. Faulhaber - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: 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: crashes
* From: Matthew Dillon [EMAIL PROTECTED] * Ah, that's good. I still have one person reporting a panic with 1.56 * (which I have a core for). w/1.56 my own buildworld tests succeed * and except for this one person everyone else is reporting their * softupdates problems solved. Actually maybe I spoke too soon. Two of the machines just hung this morning. Same symptom (responds to ping, telnet connects but gets only blank lines in responses to return) as before. This is a slightly newer kernel (had to put IPv6 in it) but ffs_softdep.c is still at 1.56. Satoshi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libstdc++.so.3
I just got the new UPDATING and I seem to have done everything. Until I built xinstall, I wasn't able to make world, made a new kernel and rebooted and built a new version of mysql and am still getting the error. I'm going to build a new world, just in case my cvsup timing was bad. Thanks a lot for your help, ed Edwin Culp wrote: Looks like I have to cvsup again, it's not in my UPDATING from 11:40 PST today. That was the first place I checked. Sorry and thanks, ed "Chris D. Faulhaber" wrote: On Sun, 30 Jan 2000, Edwin Culp wrote: I make a new world today after reinstalling xinstall and thought that along with recompiling my applications that are having problems that I assume started with the c++ compiler change, but I have recompiled several applications and still have the errors. If someone would tell me what I am doing wrong. This is from the latest version of mysql that I just compiled. Error: /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined symbol "_vt$9exception" Please read the first 2124 entry of src/UPDATING. - Chris D. Faulhaber - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Printer fiascos.
"Michael" == Michael Remski [EMAIL PROTECTED] writes: Michael ppc0 at 0x378 irq 7 flags 0x40 on isa ppc0: SMC-like chipset Michael (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with Michael 16/16/7 bytes threshold lpt0: generic printer on ppbus 0 Michael lpt0: Interrupt-driven port I don't get the FIFO portion of the probe. Dave. -- |David Gilbert, Velocet Communications. | Two things can only be | |Mail: [EMAIL PROTECTED] | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =GLO To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: INET6 and fxp
http://www.sigmasoft.com/~openbsd/archive/openbsd-tech/199912/msg00321.html Something better than that is probably needed in the long run. Let me confirm it. Does this also fix your problem on your freebsd-current? Yes. I have only tried ping6, but that works, and IPv4 works. Thanks, then it might be better to add same kind of fix to if.c's "#ifdef INET6" part, as a workaround only for 4.0. Yoshinobu Inoue To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: new C++ compiler changes
rename it libstdc++.so.1. Then you just have to modify your executable so that it looks for libstdc++.so.1 instead of libstdc++.so.3 Why not just reinstall the problematic executables? Yeap, we do that quite often in Linux 8) Cheers -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
suspend problems
i'm running world built on the 26th, and a kernel built immediately afterwards.. machine is a chembook 3300. if i suspend, upon resuming i get a brief flash of X, and then a black screen. i have to kill X to get a display back. also, while my 3c574 comes back up, it loses the configuration info that was entered by hand after the card came up. (actually, this might have happened when i killed X.. the realaudio stream that i was playing when i suspended came back when i resumed..) Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #9: Thu Jan 27 02:08:53 PST 2000 [EMAIL PROTECTED]:/c1/current/src/sys/compile/ROADWARRIOR Timecounter "i8254" frequency 1193182 Hz CPU: Pentium/P55C (233.86-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x543 Stepping = 3 Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX real memory = 100663296 (98304K bytes) avail memory = 93683712 (91488K bytes) Preloaded elf kernel "kernel" at 0xc03b4000. Preloaded elf module "splash_bmp.ko" at 0xc03b409c. Preloaded elf module "vesa.ko" at 0xc03b4140. Preloaded splash_image_data "/boot/splash.bmp" at 0xc03b41dc. Preloaded elf module "cd9660.ko" at 0xc03b422c. Preloaded elf module "linux.ko" at 0xc03b42cc. Intel Pentium detected, installing workaround for F00F bug VESA: v1.2, 2048k memory, flags:0x0, mode table:0xc00c7a88 (c0007a88) VESA: Copyright 1994 TRIDENT MICROSYSTEMS INC. md0: Malloc disk apm0: APM BIOS on motherboard apm: found APM BIOS v1.2, connected at v1.2 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard pci0: PCI bus on pcib0 isab0: Intel 82371AB PCI to ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 ata-pci0: Intel PIIX4 ATA-33 controller port 0x1100-0x110f at device 1.1 on pci0 ata0 at 0x01f0 irq 14 on ata-pci0 ata1 at 0x0170 irq 15 on ata-pci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller irq 0 at device 1.2 on pci0 uhci0: could not map ports device_probe_and_attach: uhci0 attach returned 6 chip1: Intel 82371AB Power management controller port 0x1400-0x140f at device 1.3 on pci0 vga-pci0: Trident model 9660 VGA-compatible display device mem 0xfe00-0xfe3f,0xfe7f-0xfe7f,0xfdc0-0xfdff at device 2.0 on pci0 pcic-pci0: TI PCI-1220 PCI-CardBus Bridge irq 10 at device 3.0 on pci0 pcic-pci1: TI PCI-1220 PCI-CardBus Bridge irq 10 at device 3.1 on pci0 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 pcic: management irq 10 pcic0: VLSI 82C146 at irq 10 on isa0 pccard0: PC Card bus -- kludge version on pcic0 pccard1: PC Card bus -- kludge version on pcic0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio2: not probed (disabled) sio3: not probed (disabled) ppc0: Parallel port at port 0x378-0x37f irq 7 flags 0x40 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode lpt0: Printer on ppbus0 lpt0: Interrupt-driven port unknown0: ESS ES1869 Plug and Play AudioDrive at port 0x800-0x807 on isa0 sbc0: ESS ES1869 at port 0x220-0x22f,0x388-0x38b,0x330-0x331 irq 5 drq 1,0 on isa0 pcm0: SB DSP 3.01 (ESS mode) on sbc0 unknown1: ESS ES1869 Plug and Play AudioDrive at port 0x201 on isa0 pccard: card inserted, slot 1 ata1-slave: ata_command: timeout waiting for intr ata1-slave: identify failed ad0: 3909MB TOSHIBA MK4006MAV [7944/16/63] at ata0-master using UDMA33 acd0: CDROM UJDA110 at ata1-master using PIO4 Mounting root from ufs:/dev/ad0s1a ep0: 3Com 3C574B, Megahertz 3CCFE574BT or Fast Etherlink 3C574-TX at port 0x240-0x25f irq 9 slot 1 on pccard1 ep0: Ethernet address 00:50:04:8f:2a:8b ep0: unload stray irq 9 pccard: card disabled, slot 1 pccard: card inserted, slot 1 resumed from suspended mode (slept 00:01:30) ata0: resetting devices .. done ata1: resetting devices .. done ep0: 3Com 3C574B, Megahertz 3CCFE574BT or Fast Etherlink 3C574-TX at port 0x240-0x25f irq 9 slot 1 on pccard1 ep0: Ethernet address 00:50:04:8f:2a:8b # # ROADWARRIOR -- Laptop machine with ide/usb/pcmcia/tools # # $Id: ROADWARRIOR,v 1.143.3.1.3 1999/12/08 23:00:00 techie Exp $ machine "i386" cpu I586_CPU# aka Pentium(tm) ident ROADWARRIOR maxusers30 makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols options INET#InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT
Re: identcpu.c change causes panic - not identcpu.c?
A panic also occurred on my Pentium (P54C) 66MHz, but backing identcpu.c to 1.79 didn't stop the panic. Here is the panic info, copied by hand. (I hope there are no typos!) Lots of 'ad1: timeout waiting for DRQ' followed by Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc04e5000 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01c56b0 stack pointer = 0x10:0xc49efd7c frame pointer = 0x10:0xc49efda0 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 = 133 (ldconfig) interrupt mask = net tty bio cam trap number = 12 panic: page fault Uptime: 12s Unfortunately, I don't have time right now to explore this further, but if more info is needed, just tell me what to do and I can help tomorrow evening (EST). Greg Yes, when I back out this revision ( nothing else) I can boot fine :-) Hmm, I cannot know why you got panic On your CPU (P54C: 586-class CPU), the part which I changed is not executed. I have tested the change on: - Intel MMX Pentium 166MHz - Intel Pentium Pro 200MHz - Intel Pentium II 400MHz (Dual) - AMD Athlon 700MHz - AMD K6-2 400MHz - Cyrix 5x86 100MHz and they work without problem. I'll have to write this down by hand - it didn't look very interesting, though. I'm interested in it. What I want to know is whether a bug is in my change or in other part. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pmap_remove_pages panic during installworld
Well, with all problems with buildworld and building kernels, and my limited time. I have only just gotten back to a point where I can retest the crash I was having. This time, no crash. Apparently, my milage is varying... -- Danny J. Zerkel [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PAIN
On Mon, 31 Jan 2000, Gary Palmer wrote: /me looks at the stack of 386sx chips he has and wonders why no-one did 8 way SMP with these! You never heard of the Sequent boxes, did you? :) In fact I haven't. But I also don't have DXs either. :) - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PAIN
On Mon, Jan 31, 2000 at 01:00:44AM -0500, TrouBle wrote: : Geee lets see i have a 386 sx with a really tiny MFM in it still, its just : sitting here, doing nothing, wonder if i can get current on it, the thought is : killing me... : )) its got 8 megs of ram in it too ??? ~GRIN~ I'm running a PicoBSD firewall on a 386DX with 8MB. (Well, maybe it's just a screening router...). Mind you, it's pBSD off 3.4-STABLE, not off -CURRENT. But I'm planning to see whether I can do it with -CURRENT so I can get IPv6 in there too. (I'm not using any HD at the moment, but I may have to steal a bit of space of MSW3.11.) -- Christopher Vance To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
VMware SCSI CDROM - fix
This fixes the error messages seen when attempting to use a SCSI cdrom drive with vmware. It is unclear to me whether this would do more harm than good, since I don't really know what the CDIOCREADSUBCHANNEL ioctl does. But it does look righteous to me, since without it, the 'track' variable in the bsdsc will be not be initialized prior to the fo_ioctl(). I can commit this if it would be easiest, though I think someone who knows this area better than me should comment first. :-) --- sys/i386/linux/linux_ioctl.c.orig Sun Jan 30 23:09:11 2000 +++ sys/i386/linux/linux_ioctl.c Sun Jan 30 22:56:07 2000 @@ -890,6 +890,7 @@ sizeof(struct cd_sub_channel_info)); bsdsc.address_format = CD_LBA_FORMAT; bsdsc.data_format = CD_CURRENT_POSITION; + bsdsc.track = 0; bsdsc.data_len = sizeof(struct cd_sub_channel_info); bsdsc.data = bsdinfo; error = fo_ioctl(fp, CDIOCREADSUBCHANNEL, (caddr_t)bsdsc, p); To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
