Re: alpha devfs feedback
In message [EMAIL PROTECTED], Matthew Jacob writes: I compiled and booted on alpha. It sees my ad0 now. Plus it also sees the 3 'da' disks that were found. The only real problem is that it won't see the partitions made for 'dangerously dedicated' 'da' disks. What's the plan for addressing this? Hmm, which exact names are you missing ? Have you tried accessing them directly, for instance: ls -l /dev/da0s2e or whatever their names are ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha devfs feedback
In message [EMAIL PROTECTED], Matthew Jacob writes: On Mon, 28 Aug 2000, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Matthew Jacob writes: I compiled and booted on alpha. It sees my ad0 now. Plus it also sees the 3 'da' disks that were found. The only real problem is that it won't see the partitions made for 'dangerously dedicated' 'da' disks. What's the plan for addressing this? Hmm, which exact names are you missing ? Have you tried accessing them directly, for instance: ls -l /dev/da0s2e or whatever their names are ? Sure. They're not there. A reboot still just has da0[c], da1[c], and da2[c] show up. Remember that there's no such thing as slices in alpha. What names do you usually access your disks by ? Just da0a etc ? You should be able to find those as well with the clone stuff... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha devfs feedback
What names do you usually access your disks by ? Just da0a etc ?
da0{a,b,c,d} and so on..
You should be able to find those as well with the clone stuff...
Nope. Weren't there.
I booted up once. I had 3 disks- none with a FreeBSD label. The
contents of /dev for da disks was /dev/da{0,1,2}[c].
So, I did the '-Brw da0 auto' and disklabel -e trick to add
a da0a to da0. disklabel happily saw da0a after this. Nothing
in /dev. Okay- so this kind of rescan doesn't work yet.
So, I reboot. The contents of dev still are /dev/da{0,1,2}[c]. I mostly
was raising this to see if someone else has tried alpha in this regard.
If not- I can help debug this and fix it, but next week.
-matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: hints static wiring
Brooks Davis writes: On Sun, Aug 27, 2000 at 09:33:21PM +0900, Motomichi Matsuzaki wrote: Doing 'make install' without /boot/device.hints is failed, saying "You must set up a /boot/device.hints file first." Is this right? You should read cvs-all. There was a commit by Peter which forces you to install a /boot/device.hints file to install a kernel as an anti-foot shooting measure. An empty file (ie touch /boot/device.hints) is acceptable for those who don't want to use a hints file. I do read cvs-all, and I missed it. Not did I find device.hints in the relevant Makefiles. Can you provide a pointer to details on how /boot/device.hints is used in the build process, or how having an empty one keeps you from shooting yourself in the foot? Thanx, mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha devfs feedback
In message [EMAIL PROTECTED], Matthew
Jacob writes:
What names do you usually access your disks by ? Just da0a etc ?
da0{a,b,c,d} and so on..
You should be able to find those as well with the clone stuff...
Nope. Weren't there.
I booted up once. I had 3 disks- none with a FreeBSD label. The
contents of /dev for da disks was /dev/da{0,1,2}[c].
So, I did the '-Brw da0 auto' and disklabel -e trick to add
a da0a to da0. disklabel happily saw da0a after this. Nothing
in /dev. Okay- so this kind of rescan doesn't work yet.
So, I reboot. The contents of dev still are /dev/da{0,1,2}[c]. I mostly
was raising this to see if someone else has tried alpha in this regard.
If not- I can help debug this and fix it, but next week.
Hmm, can you send me a ls -l /dev from a !devfs alpha so I can
see what it looks like ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: hints static wiring
I do read cvs-all, and I missed it. Not did I find device.hints in the relevant Makefiles. Can you provide a pointer to details on how /boot/device.hints is used in the build process, or how having an empty one keeps you from shooting yourself in the foot? cvs-all is not appropriate. I am noticing a 3-7 day lag on UPDATING. Bad. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Installkernel
James Johnson writes: The method of building and installing a kernel to me seems a bit off.. Both the buildworld and installworld targets default to GENERIC, yet GENERIC is a file checked into the -CURRENT CVS repository.. Any changes to this file will get blown away if whenever you update the sources unless you explicity exclude this file. No one I know runs BSD with a GENERIC kernel, they have specific requirements for the hardware in their machines. Having to specify which kernel to build with the KERNEL= parameter seems to indicate that people should be running GENERIC kernels all the time as it is the default. This just doesnt seem right. Now that it's all working properly, I like it. I build for multiple machines on one box, and then NFS-mount /usr/src /usr/obj to do the installs. Being able to build all the kernels with one command, and use the same install commands on each box makes my life much simpler. As for GENERIC, it's what people run by default, and it can be used as is on much hardware. The documentation is a bit behind - the handbook should mention setting KERNEL in /etc/make.conf when it talks about buildkernel and installkernel. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs
On Sun, 27 Aug 2000 21:35:26 +0200, Poul-Henning Kamp wrote: Do you have devfs in /etc/fstab ? That is *not* needed, /sbin/init will mount devfs on /dev automatically. Out of curiosity, what's the motivation behind this decision? Why don't you allow defvs to be mounted on an arbitrary mount point? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devfs
In message [EMAIL PROTECTED], Sheldon Hearn writes: On Sun, 27 Aug 2000 21:35:26 +0200, Poul-Henning Kamp wrote: Do you have devfs in /etc/fstab ? That is *not* needed, /sbin/init will mount devfs on /dev automatically. Out of curiosity, what's the motivation behind this decision? Why don't you allow defvs to be mounted on an arbitrary mount point? You can also mount it other places: mount -t devfs foo /usr/jail/jail1/dev (but the "no new devices" feature is not committed yet, I'm still working on it). The reason for mounting it in /sbin/init is historical and possibly wrong but it does have the benefit that it will DTRT for people. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: hints static wiring
Mike Meyer wrote: I do read cvs-all, and I missed it. Not did I find device.hints in the relevant Makefiles. Can you provide a pointer to details on how /boot/device.hints is used in the build process, or how having an empty one keeps you from shooting yourself in the foot? Actually, device.hints isn't used in the build process. Your KERNEL.hints file is hard-coded into the kernel when your kernel is built (assuming you use one). /boot/device.hints is used to override the "hardcoded" values of hints, KERNEL.hints, at boot time. Sometimes, people can make a mistake in KERNEL.hints, and it's necessary to override those hints with /boot/device.hints. So, device.hints is created after-the-fact, and not part of the kernel build. Of course, if you don't have any hints to override, then just install an empty device.hints file. device.hints is there to save you from rebuilding your kernel every time you want to change a hint value. -Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Monitor dies and doesn't come back.
I did just notice something.. why would I have sc0/sc1 and vga0/vga1? Or is that just because of the 'options SC_PIXEL_MODE' that I have? Jason DiCioccio - IBM Global Services - [EMAIL PROTECTED] - www.ibm.com Systems Admin - Open Domain Server - [EMAIL PROTECTED] - www.ods.org FreeBSD - The Power to Serve - - www.freebsd.org On Mon, 28 Aug 2000, Greg Lehey wrote: [dropping -questions, this is a -CURRENT problem] On Sunday, 27 August 2000 at 22:28:34 -0400, Systems Administrator wrote: I've been having a strange problem recently after installing a new harddrive.. the harddrive works fine in other OS's, but in FreeBSD, (seemingly after the HD install), the Monitor (CTX VL19") goes into powersaving and you cant get it back without doing a cold reboot.. not even a warm reboot will work. I am not sure exactly what is happening here, perhaps something borked? I have a Western Digital Caviar 45GB drive running at UDMA33. Well, this isn't the monitor, of course. Your system is probably dying a horrible death and not producing any video output. ad0: 9671MB WDC AC310100B [19650/16/63] at ata0-master using UDMA33 ad1: 42934MB WDC WD450AA-00BAA0 [87233/16/63] at ata0-slave using UDMA33 acd0: CD-RW PLEXTOR CD-R PX-W8432T at ata1-master using WDMA2 acd1: CDROM FX001DE at ata1-slave using PIO3 Mounting root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted Well, it's not a good idea to put both disks on the same controller anyway. What happens if you put the disks on the primaries of each controller, and the CD-ROMS on the secondaries? If that doesn't help, does the system at least work without the 45 GB drive? Anyway, how far do you get in the book process? Can you get into single user mode the way you are now? Greg -- When replying to this message, please copy the original recipients. For more information, see http://www.lemis.com/questions.html 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: hints static wiring
Donn Miller writes: Mike Meyer wrote: I do read cvs-all, and I missed it. Not did I find device.hints in the relevant Makefiles. Can you provide a pointer to details on how /boot/device.hints is used in the build process, or how having an empty one keeps you from shooting yourself in the foot? Actually, device.hints isn't used in the build process. In that case, why does the kernel build process fail if it doesn't exist? KERNEL.hints file is hard-coded into the kernel when your kernel is built (assuming you use one). /boot/device.hints is used to override the "hardcoded" values of hints, KERNEL.hints, at boot time. Sometimes, people can make a mistake in KERNEL.hints, and it's necessary to override those hints with /boot/device.hints. So, device.hints is created after-the-fact, and not part of the kernel build. Of course, if you don't have any hints to override, then just install an empty device.hints file. Will the system fail to boot if there isn't an empty device.hints file? mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 3.4STABLE to 4.1STABLE can't make modules (fwd)
Although binary distribution would be easier, I suspect that many of us would prefer to build everything locally. That is one of the unique features of FreeBSD, even if it is time consuming. On Sat, Aug 27, 2000 , Gary Kline wrote: BTW, I have some ideas how this entire issue of updating one's FBSD system can be done lots easier: say, by doing essentially an ftp binary up-rev across major releases: 2 - 3 or 3 - 4. Then using a relatively simple build|install and mergemaster moving within released. Like everything else, it's a matter of time and prio gary -- Gary D. Kline [EMAIL PROTECTED] Public service Unix I vote for that! Thanks. Lazaro To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
vn broken?
-current from Aug, 22, cd9660 image file mounted via vn reports this:
Aug 28 13:45:51 counter /kernel: unexpected vn driver lock: 0xccf008c0: type VREG,
usecount 2, writecount 1, refcount 452, flags (VOBJBUF)
Aug 28 13:45:51 counter /kernel: tag VT_UFS, ino 357635, on dev #da/6 (13, 6) lock
type inode: EXCL (count 1) by pid 5
This happens when multiple parallel things are done to the iso
filesystem inside the vnode, i.e.:
A single
find /mnt -type f -exec cat {} \; | wc -c
works without problems, two of them started with a delay cause these
messages.
Martin
--
%
Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/
BSD User Group Hamburg, Germany http://www.bsdhh.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: vn broken?
I should haven mentioned that this is a SMP machine (i440BX P-III 550 dual) and is running vmware. -current from Aug, 22, cd9660 image file mounted via vn reports this: Aug 28 13:45:51 counter /kernel: unexpected vn driver lock: 0xccf008c0: type VREG, usecount 2, writecount 1, refcount 452, flags (VOBJBUF) Aug 28 13:45:51 counter /kernel: tag VT_UFS, ino 357635, on dev #da/6 (13, 6) lock type inode: EXCL (count 1) by pid 5 This happens when multiple parallel things are done to the iso filesystem inside the vnode, i.e.:[...] dmesg: Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Tue Aug 22 12:47:31 MEST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/COUNTER Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (551.25-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,XMM real memory = 268423168 (262132K bytes) avail memory = 257658880 (251620K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 IOAPIC #0 intpin 16 - irq 11 IOAPIC #0 intpin 18 - irq 10 IOAPIC #0 intpin 19 - irq 12 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 0xc0396000. ccd0-3: Concatenated disk drivers Pentium Pro MTRR support enabled VESA: v2.0, 32768k memory, flags:0x1, mode table:0xc00c6974 (c0006974) VESA: Matrox Graphics Inc. md0: Malloc disk apm0: APM BIOS on motherboard apm0: found APM BIOS v1.2, connected at v1.2 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 pci0: Intel 82443BX (440 BX) host to PCI bridge at 0.0 pcib1: Intel 82443BX (440 BX) PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: Matrox MGA G400 AGP graphics accelerator at 0.0 irq 11 isab0: Intel 82371AB PCI to ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 pci0: Intel PIIX4 ATA controller at 4.1 pci0: Intel 82371AB/EB (PIIX4) USB controller at 4.2 irq 12 intpm0: Intel 82371AB Power management controller port 0xe800-0xe80f irq 9 at device 4.3 on pci0 intpm0: I/O mapped e800 intpm0: intr IRQ 9 enabled revision 0 smbus0: System Management Bus on intsmb0 smb0: SMBus general purpose I/O on smbus0 intpm0: PM I/O mapped e400 ahc0: Adaptec aic7890/91 Ultra2 SCSI adapter port 0xd000-0xd0ff mem 0xe000-0xefff irq 12 at device 6.0 on pci0 ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 32/255 SCBs fxp0: Intel Pro 10/100B/100+ Ethernet port 0xb800-0xb83f mem 0xdf00-0xdf0f,0xdf80-0xdf800fff irq 12 at device 9.0 on pci0 fxp0: Ethernet address 00:d0:b7:92:4e:cc ahc1: Adaptec 2940 SCSI adapter port 0xb400-0xb4ff mem 0xde80-0xde800fff irq 10 at device 10.0 on pci0 ahc1: aic7870 Single Channel A, SCSI Id=7, 16/255 SCBs isa0: too many memory ranges fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 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: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 unknown: PNP0401 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0700 can't assign resources unknown: PNP0303 can't assign resources unknown: PNP0c02 can't assign resources APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 SMP: AP CPU #1 Launched! Mounting root from ufs:/dev/da0a da0 at ahc0 bus 0 target 1 lun 0 da0: IBM DMVS36V 0250 Fixed Direct Access SCSI-3 device da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit) da0: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C) WARNING: / was not properly dismounted cd0 at ahc1 bus 0 target 4 lun 0 cd0: TEAC CD-ROM CD-56S 1.0D Removable CD-ROM SCSI-2 device cd0: 5.000MB/s transfers (5.000MHz, offset 8) cd0: cd present [352862 x 2048 byte records] /dev/vmmon: Module vmmon: registered with major=200 minor=0 tag=$Name: build-570 $ /dev/vmmon: Module vmmon: initialized (cd0:ahc1:0:4:0): PAUSE/RESUME. CDB: 4b
Re: IDE RAID (HPT-370/Abit KT7-RAID) install questions..
-On [2827 23:05], Soren Schmidt ([EMAIL PROTECTED]) wrote: Well, this wouldn't have happend without Jeroen (asmodai) having good contacts at HighPoint, so I thank him for making this possible. No problem. It's all team work anyways, I couldn't write the driver. ;) Hopefully Highpoint will be so friendly to help me out on this RAID issue. -- Jeroen Ruigrok van der Werven Network- and systemadministrator [EMAIL PROTECTED]VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl You are more than you think, less than you could be... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: hints static wiring
Mike Meyer wrote: Donn Miller writes: Mike Meyer wrote: I do read cvs-all, and I missed it. Not did I find device.hints in the relevant Makefiles. Can you provide a pointer to details on how /boot/device.hints is used in the build process, or how having an empty one keeps you from shooting yourself in the foot? Actually, device.hints isn't used in the build process. In that case, why does the kernel build process fail if it doesn't exist? Probably because you have `hints "BLABLA.hints"' line in your kernel config file. KERNEL.hints file is hard-coded into the kernel when your kernel is built (assuming you use one). /boot/device.hints is used to override the "hardcoded" values of hints, KERNEL.hints, at boot time. Sometimes, people can make a mistake in KERNEL.hints, and it's necessary to override those hints with /boot/device.hints. So, device.hints is created after-the-fact, and not part of the kernel build. Of course, if you don't have any hints to override, then just install an empty device.hints file. Will the system fail to boot if there isn't an empty device.hints file? No, it will boot, but some devices (like keyboard, console etc) would not work. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: hints static wiring
Maxim Sobolev writes: Mike Meyer wrote: Donn Miller writes: Mike Meyer wrote: I do read cvs-all, and I missed it. Not did I find device.hints in the relevant Makefiles. Can you provide a pointer to details on how /boot/device.hints is used in the build process, or how having an empty one keeps you from shooting yourself in the foot? Actually, device.hints isn't used in the build process. In that case, why does the kernel build process fail if it doesn't exist? Probably because you have `hints "BLABLA.hints"' line in your kernel config file. That doesn't really answer the question. Yup, I use GENERIC.hints. That exists. I can see why that not existing would cause problems, but not /boot/device.hints? *Especially* when I'm building a kernel for a different machine? KERNEL.hints file is hard-coded into the kernel when your kernel is built (assuming you use one). /boot/device.hints is used to override the "hardcoded" values of hints, KERNEL.hints, at boot time. Sometimes, people can make a mistake in KERNEL.hints, and it's necessary to override those hints with /boot/device.hints. So, device.hints is created after-the-fact, and not part of the kernel build. Of course, if you don't have any hints to override, then just install an empty device.hints file. Will the system fail to boot if there isn't an empty device.hints file? No, it will boot, but some devices (like keyboard, console etc) would not work. That's clearly not true - I just removed an empty /boot/device.hints and rebooted, and all those things work fine. I can believe that such things won't work if they aren't specified in some hints file, but an empty /boot/device.hints doesn't do anything more to specify them than one that isn't there. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Linux ABI no longer supports staroffice
Up until this weekend, I was able to use the staroffice52 port with little problem (I had installed it earlier without benefit of the port and it worked fine.) I did a 5.0-current kernel rebuild on Thursday with sources current on that day and things were fine. When I rebuilt my kernel yesterday afternoon with sources from Saturday morning, the port stopped working. I get the following error messages I18N: X Window System doesn't support locale "C" _X11TransSocketOpen: socket() failed for local _X11TransSocketOpenCOTSClient: Unable to open socket for local _X11TransOpen: transport open failed for local/dinolt1.bingdrive:0 setup.bin: cannot open display ":0.0" Please check your "DISPLAY" environment variable, as well as the permissions to access that display (See "man X" resp. "man xhost" for details) same here :( i got original Sun CD with StartOffice 5.1a and tried to install it. it failed. i used # make WITH_CDROM=yes USE_CDROM=yes install and everything was fine, but then i got exactly the same error. XFree86-3.3.6 and XFree86-contrib-3.3.6 both working just fine. ``xhost +'' did not resolve the problem. thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: hints static wiring
Mike Meyer wrote: Will the system fail to boot if there isn't an empty device.hints file? No, it will boot, but some devices (like keyboard, console etc) would not work. That's clearly not true - I just removed an empty /boot/device.hints and rebooted, and all those things work fine. I can believe that such things won't work if they aren't specified in some hints file, but an empty /boot/device.hints doesn't do anything more to specify them than one that isn't there. That's probably because you have hints compiled into your kernel. Try to compile kernel w/o hints and use it with empty/unexistent /boot/device.hints and you will see what I mean. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: hints static wiring
Maxim Sobolev writes: Mike Meyer wrote: Will the system fail to boot if there isn't an empty device.hints file? No, it will boot, but some devices (like keyboard, console etc) would not work. That's clearly not true - I just removed an empty /boot/device.hints and rebooted, and all those things work fine. I can believe that such things won't work if they aren't specified in some hints file, but an empty /boot/device.hints doesn't do anything more to specify them than one that isn't there. That's probably because you have hints compiled into your kernel. Try to compile kernel w/o hints and use it with empty/unexistent /boot/device.hints and you will see what I mean. Well, yeah, I'd expect that. I'm still trying to figure out what *good* failing to compile unless there's an empty /boot/device.hints does. I mean, if I didn't provide kernel hints, it would make some sense if the build process could determine that it was building on the machine it was running on. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
(no subject)
To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP and softupdates?
Brad Knowles wrote: At 7:36 PM + 2000/8/28, Alex Zepeda wrote: Perhaps in a rush to get started, I've compiled and been using a SMP kernel even before the second processor arrives. This has worked fine, however I've gotten some rather weird hangs and crashes resulting in a nice lost+found directory on the usr fs. Personally, I'm astonished that an SMP kernel will actually boot and run on a uniprocessor machine. Well, it does work. Right now if we enable multiple CPU's with SMPng the machine instantly panics, so we use a sysctl that keeps all the extra processors waiting until we are ready to kill the machine. Until that point in time, however, the machine runs happily on 1 cpu, and can build world ok, etc. -- 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
devname(3) broken for DEFVS
Hi Poul-Henning, I've been having trouble with ps(1) printing invalid controlling terminal names for processes connected to psuedo-terminals. This only seems to be a problem for DEVFS-enabled systems. The output that makes it look like things are broken is this: $ ps -t p7 PID TT STAT TIME COMMAND 80571 #C5 Ss 0:00.10 bash It seems to be breakage in devname(3): $ gdb /usr/obj/usr/src/bin/ps/ps GNU gdb 4.18 [...] (gdb) break print.c:311 Breakpoint 1 at 0x8048cb6: file /usr/src/bin/ps/print.c, line 311. (gdb) run Starting program: /usr/obj/usr/src/bin/ps/ps PID TT STAT TIME COMMAND Breakpoint 1, tname (k=0x8090690, ve=0x8086040) at /usr/src/bin/ps/print.c:311 311 if (dev == NODEV || (ttname = devname(dev, S_IFCHR)) == NULL) (gdb) n 314 if (strncmp(ttname, "tty", 3) == 0 || (gdb) print ttname $2 = 0x807afe8 "#C5:1" Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha devfs feedback
On Mon, 28 Aug 2000, Matthew Jacob wrote: On Mon, 28 Aug 2000, Poul-Henning Kamp wrote: Have you tried accessing them directly, for instance: ls -l /dev/da0s2e or whatever their names are ? Sure. They're not there. A reboot still just has da0[c], da1[c], and da2[c] show up. That's more than show up on i386's :-). After booting with -s, only the whole disk devices and the root device show up. Devices for slices and partitions slices only show up when they are opened or stat'ed. This bug is normally mostly hidden by opening most partitions to mount them. Remember that there's no such thing as slices in alpha. I thought that they worked. They should work if they are configured. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: devname(3) broken for DEFVS
Hi Poul-Henning, I've been having trouble with ps(1) printing invalid controlling terminal names for processes connected to psuedo-terminals. This only seems to be a problem for DEVFS-enabled systems. Yes, devname(3) need to learn a few things. It's actually always been a problem if you added device nodes after boot where dev_mkdb was run. I think the DTRT solution is a sysctl where kern_conf.c can answer the question. It's on my list. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha devfs feedback
In message [EMAIL PROTECTED], Bruce Ev ans writes: Sure. They're not there. A reboot still just has da0[c], da1[c], and da2[c] show up. That's more than show up on i386's :-). After booting with -s, only the whole disk devices and the root device show up. Devices for slices and partitions slices only show up when they are opened or stat'ed. This bug is normally mostly hidden by opening most partitions to mount them. Well, this "bug" is built into the current diskslice/label code as you know (you wrote it :-) It doesn't have anything to do with DEVFS as such. My proposed solution for this can be found in the bio/buf paper I wrote. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha devfs feedback
That's more than show up on i386's :-). After booting with -s, only the whole disk devices and the root device show up. Devices for slices and partitions slices only show up when they are opened or stat'ed. This bug is normally mostly hidden by opening most partitions to mount them. Hmm. Well, it turned out that after a period of time da0a showed up. Poul says I might be out of date src-wise. I'll update again and see. Remember that there's no such thing as slices in alpha. I thought that they worked. They should work if they are configured. Sorry- I meant "SRM doesnt' grok i386 labels". -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: hints static wiring
Ahh..., I tried to summarize my opinion. If you find any misunderstandings of me, please correct them. *** What's happen if there's no /boot/device.hints? case A kernel has no built-in hints ... some devices would not work, system would stall! You can tell whole hints to the kernel interactively on /boot/loader, however it's a tiresome task. YES, this is the abominable situation. To avoid it, you should be warned at kernel-install-time. case B kernel has built-in hints (i.e. config has "hints" line) B-1: wrong hints ... some devices would not work, system could stall. You can correct hints interactively on /boot/loader. You can override hints by making /boot/device.hints also. B-2: suitable hints ... everything goes OK You can override hints by /boot/device.hints. Currently, 'make install' will be aborted in every case above, but this treatment is suitable only for case A. And it would be technically possible to limit this treatment to case A. This treatment will do accoring to Makefile, which is controled by config(8) (src/usr.sbin/config/mkmakefile.c). -- Motomichi Matsuzaki [EMAIL PROTECTED] Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux ABI no longer supports staroffice
"Yevmenkin, Maksim N, CSCIO" wrote: [snip] same here :( i got original Sun CD with StartOffice 5.1a and tried to install it. it failed. i used # make WITH_CDROM=yes USE_CDROM=yes install and everything was fine, but then i got exactly the same error. XFree86-3.3.6 and XFree86-contrib-3.3.6 both working just fine. ``xhost +'' did not resolve the problem. Should be fixed already. Please re-cvsup. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: hints static wiring
On Mon, Aug 28, 2000 at 03:19:15AM -0500, Mike Meyer wrote: I do read cvs-all, and I missed it. Not did I find device.hints in the relevant Makefiles. Can you provide a pointer to details on how /boot/device.hints is used in the build process, or how having an empty one keeps you from shooting yourself in the foot? Having an empty one will not help you, but installing a post hints change GENERIC without a hints file will results in a system that does not boot. Thus you are required to have a hints file. The ability to install a bogus (empty) one is for those who want static hints. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: hints static wiring
On Mon, Aug 28, 2000 at 08:24:50AM -0500, Mike Meyer wrote: Well, yeah, I'd expect that. I'm still trying to figure out what *good* failing to compile unless there's an empty /boot/device.hints The kernel does not fail to *BUILD*. ``make install'' is what fails. I agree that the requirement is somewhat anonying. But, it is better to have this slight anonyance than for many to to install and boot a kernel that would be broken. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0-current 20000826 snapshot problems
John Baldwin writes: FreeBSD/i386 bootstrap loader, Revision 0.8 ([EMAIL PROTECTED], Sat Aug 26 11:14:35 GMT 2000) /kernel text=0x2432ca zf_read: fill error elf_loadexec: archsw.readin failed Your floppy is bad. Try a different one. Not necessarily. This also happens if you try to boot boot.flp instead of kern.flp. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: hints static wiring
In message [EMAIL PROTECTED] Tony Fleisher writes: : Just a suggestion, but isn't this the type of thing that : should be added to UPDATING? Quoting from the UPDATING file: ... 2825: /boot/device.hints is now required for installkernel to succeed. ... 2612: Peter took an axe to config(8). Besure that you read his mail on the topic before even thinking about updating. You will need to create a /boot/device.hints or add a hints directive to your config file to compile them in statically. The format of the config file has changed as well. Please see GENERIC or NEWCARD for examples of the new format. ... Granted, I did commit the first entry only a few hours before you posted... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: hints static wiring
In message [EMAIL PROTECTED] Matthew Jacob writes: : I do read cvs-all, and I missed it. Not did I find device.hints in the : relevant Makefiles. Can you provide a pointer to details on how : /boot/device.hints is used in the build process, or how having an : empty one keeps you from shooting yourself in the foot? : : cvs-all is not appropriate. I am noticing a 3-7 day lag on UPDATING. : Bad. cvs-all *IS*REQUIRED* for all people running -current. UPDATING tries to cull things from there on an as needed basis. It is a service that gets done when I have time. If someone wants to pay me a stipend to drop everything the instant something is committed to the tree and update UPDATING, then the lag will improve. Otherwise, 3-7 days really isn't that bad and will continue to be the case. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: hints static wiring
In message [EMAIL PROTECTED] Matthew Jacob writes: : I do read cvs-all, and I missed it. Not did I find device.hints in the : relevant Makefiles. Can you provide a pointer to details on how : /boot/device.hints is used in the build process, or how having an : empty one keeps you from shooting yourself in the foot? : : cvs-all is not appropriate. I am noticing a 3-7 day lag on UPDATING. : Bad. cvs-all *IS*REQUIRED* for all people running -current. UPDATING tries to cull things from there on an as needed basis. It is a service that gets done when I have time. If someone wants to pay me a stipend to drop everything the instant something is committed to the tree and update UPDATING, then the lag will improve. Otherwise, 3-7 days really isn't that bad and will continue to be the case. Warner Oops- I realize that what I said might have been construed as criticism- not meant at all! What I meant is that while cvs-all can be read by everyone, it's not always obvious from the flood of mail there, or if you're not a developer, what needs to change. In my opinion, people making major changes that require something in UPDATING, should coordinate with you *before* the commit. Only 5 or 6 brain cells are needed for this- I sure wish some of my fellow committers weren't such skinflints in this area. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: hints static wiring
In message [EMAIL PROTECTED] Mike Meyer writes: : Will the system fail to boot if there isn't an empty device.hints : file? If the kernel doesn't have a hints file compiled into it, then you will have problems. However, you may not have a video console. I've been able to boot my laptop with a kernel that had no hints and this was the result. All the PCI based things worked, as did those things that had a PnP ID, except the video console. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0-current 20000826 snapshot problems
On Mon, Aug 28, 2000 at 10:23:34AM -0700, Archie Cobbs wrote: John Baldwin writes: FreeBSD/i386 bootstrap loader, Revision 0.8 ([EMAIL PROTECTED], Sat Aug 26 11:14:35 GMT 2000) /kernel text=0x2432ca zf_read: fill error elf_loadexec: archsw.readin failed Your floppy is bad. Try a different one. Not necessarily. This also happens if you try to boot boot.flp instead of kern.flp. It turns out it was a bad floppy, which I didn't even think of because I don't think I've had a bad floppy disk in years and years (plus I had been up all night beating my head on the desk over the whole mess). Thanks to everyone who replied. I'm now typing this message from the machine that I had to do the re-install on, so all is good. -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: hints static wiring
In message [EMAIL PROTECTED] Matthew Jacob writes: : In my opinion, people making major changes that require something in : UPDATING, should coordinate with you *before* the commit. Only 5 or : 6 brain cells are needed for this- I sure wish some of my fellow : committers weren't such skinflints in this area. About 10% of the commmits that are known to need an UPDATING entry get sent to me first. About 50%-70% are posted to -current, -stable or committers, which is less well because I get busy.. The remaining entries are not well communicated and could be near the "oops" category. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0-current 20000826 snapshot problems
John Baldwin writes: FreeBSD/i386 bootstrap loader, Revision 0.8 ([EMAIL PROTECTED], Sat Aug 26 11:14:35 GMT 2000) /kernel text=0x2432ca zf_read: fill error elf_loadexec: archsw.readin failed Your floppy is bad. Try a different one. Not necessarily. This also happens if you try to boot boot.flp instead of kern.flp. Only if you've been silly enough to only put *half* of boot.flp on a disk. If it's all there, it works just fine. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0-current 20000826 snapshot problems
Mike Smith writes: /kernel text=0x2432ca zf_read: fill error elf_loadexec: archsw.readin failed Your floppy is bad. Try a different one. Not necessarily. This also happens if you try to boot boot.flp instead of kern.flp. Only if you've been silly enough to only put *half* of boot.flp on a disk. If it's all there, it works just fine. 8) Doesn't matter how silly it is -- I can guarantee you that at least one person has done it :-) -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposal to clarify mbuf handling rules
On Sun, 27 Aug 2000, David Malone wrote: [...] (This is why the flag I was talking about in the other mail would be useful for spotting other cases where the storage may be writable, even if it's not a cluster). Thoughts: 1) The mbuf should be marked read-only explicitly with a single additional M_FLAG. #define M_RDONLY0x0x2000 2) The flag should be ORed in in MEXT_ADD_REF() only if the ref_cnt is equal to or greater than 2. This is unfortunate because an additional check would have to be introduced. INPUT ALTERNATIVE HERE 3) The flag should be removed in _MEXTFREE only if that first MEXT_IS_REF() evaluates true and if, upon returning from MEXT_REM_REF(), the new ref_cnt is exactly 1. I'm pretty sure that this way, the subsystem will take care of the read-onlyness itself pretty transparently, so that relevant code can simply check for the M_RDONLY bit. (2) is questionable. As for the protocol routines that rely on the mbuf to be "read-only," there may be other side-effects besides for this illegal sharing of multiple-reference ext_bufs that could result from the possibility of passing these "read-only mbufs" to them. This possibility should be investigated. Cleaning up this sounds like a good plan. It would be worth getting Ian and Bosko involved if possible. David. Sure. If I remember correctly, it was Ian who initially brought this up. This is perhaps a 2-month old issue by now -- I, at the time, was busy with the referencing stuff as well as the allocator re-writing/playing around with (which I will have to continue once the direction of SMP is further cleared up - at least for this part of the code) - so I did not want to mix apples and oranges. I wonder if Ian has some code, though. I have _some_ modifications regarding this already in my local tree but have not yet been able to roll over a diff as my monitor is presently broken (until the end of this week). In any case, how do you propose coordinating the work? This seems like a fairly straightforward change. I'm ready to put on hold whatever I'm doing right now in order to do this, but only if that's okay with you guys - I want to make sure that no efforts are being duplicated. Regards, Bosko. [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposal to clarify mbuf handling rules
[ note: trimming -current from the CC: list ] Bosko Milekic writes: 1)The mbuf should be marked read-only explicitly with a single additional M_FLAG. #define M_RDONLY0x0x2000 2)The flag should be ORed in in MEXT_ADD_REF() only if the ref_cnt is equal to or greater than 2. This is unfortunate because an additional check would have to be introduced. INPUT ALTERNATIVE HERE 3)The flag should be removed in _MEXTFREE only if that first MEXT_IS_REF() evaluates true and if, upon returning from MEXT_REM_REF(), the new ref_cnt is exactly 1. I'm pretty sure that this way, the subsystem will take care of the read-onlyness itself pretty transparently, so that relevant code can simply check for the M_RDONLY bit. (2) is questionable. Sounds good. By the way, MEXT_REM_REF() should be defined differently if INVARIANTS is defined so it KASSERT's the reference count is 0. As for the protocol routines that rely on the mbuf to be "read-only," there may be other side-effects besides for this illegal sharing of multiple-reference ext_bufs that could result from the possibility of passing these "read-only mbufs" to them. This possibility should be investigated. Not sure what you mean here.. got an example? Cleaning up this sounds like a good plan. It would be worth getting Ian and Bosko involved if possible. Sure. If I remember correctly, it was Ian who initially brought this up. This is perhaps a 2-month old issue by now -- I, at the time, was busy with the referencing stuff as well as the allocator re-writing/playing around with (which I will have to continue once the direction of SMP is further cleared up - at least for this part of the code) - so I did not want to mix apples and oranges. I wonder if Ian has some code, though. I have _some_ modifications regarding this already in my local tree but have not yet been able to roll over a diff as my monitor is presently broken (until the end of this week). In any case, how do you propose coordinating the work? This seems like a fairly straightforward change. I'm ready to put on hold whatever I'm doing right now in order to do this, but only if that's okay with you guys - I want to make sure that no efforts are being duplicated. Let's keep the discussion on freebsd-net. Here's a proposed sequence of steps, at least to get started.. 1. Implement your 1, 2, 3 above: add the flag and adjust the macros 2. Sprinkle code with const's and KASSERT()'s 3. Wait and see what blows up 4. Continue with my proposed changes -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: hints static wiring
In message [EMAIL PROTECTED] Mike Meyer writes: : Maxim Sobolev writes: : Mike Meyer wrote: : : Donn Miller writes: :Mike Meyer wrote: : I do read cvs-all, and I missed it. Not did I find device.hints in the : relevant Makefiles. Can you provide a pointer to details on how : /boot/device.hints is used in the build process, or how having an : empty one keeps you from shooting yourself in the foot? :Actually, device.hints isn't used in the build process. : In that case, why does the kernel build process fail if it doesn't : exist? : Probably because you have `hints "BLABLA.hints"' line in your kernel config : file. : : That doesn't really answer the question. Yup, I use : GENERIC.hints. That exists. I can see why that not existing would : cause problems, but not /boot/device.hints? *Especially* when I'm : building a kernel for a different machine? The build of the kernel isn't forbidden by not having /boot/device.hints, just the install. I just copied my GENERIC.hints to /boot/device.hints and things were happy. : That's clearly not true - I just removed an empty /boot/device.hints : and rebooted, and all those things work fine. I can believe that such : things won't work if they aren't specified in some hints file, but an : empty /boot/device.hints doesn't do anything more to specify them than : one that isn't there. Specifically, the console will not work without hints. These hints can be compiled in or in /boot/device.hints. You need to have hint.atkbdc.0.at="isa" hint.atkbdc.0.port="0x060" hint.atkbd.0.at="atkbdc" hint.atkbd.0.irq="1" hint.atkbd.0.flags="0x1" hint.vga.0.at="isa" hint.sc.0.at="isa" hint.sc.0.flags="0x100" At a minimum, but I might be mistaken about that. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP and softupdates?
On Mon, Aug 28, 2000 at 03:46:20PM +0200, Brad Knowles wrote: Personally, I'm astonished that an SMP kernel will actually boot and run on a uniprocessor machine. Grr, still getting used to mutt, and I didn't reply to the list. Yes, I'm using an SMP board, and waiting on the arrival of the 2nd processor. It boots up and runs fine. Before pointing any fingers at softupdates, etc... I think that the first thing I'd do on this machine is switch back to using a real uniprocessor kernel, and then see if I could replicate the problems. Yup, I've "fallen back to" a UP kernel, which hasn't crashed at all, and I've done the same thing (rm -rf, cvs update) many more times than were required to crash the SMP kernel. Before I try this again, I'll have a second processor in there.. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: hints static wiring
On Monday, 28 August 2000 at 8:24:50 -0500, Mike Meyer wrote: Maxim Sobolev writes: Mike Meyer wrote: Will the system fail to boot if there isn't an empty device.hints file? No, it will boot, but some devices (like keyboard, console etc) would not work. That's clearly not true - I just removed an empty /boot/device.hints and rebooted, and all those things work fine. I can believe that such things won't work if they aren't specified in some hints file, but an empty /boot/device.hints doesn't do anything more to specify them than one that isn't there. That's probably because you have hints compiled into your kernel. Try to compile kernel w/o hints and use it with empty/unexistent /boot/device.hints and you will see what I mean. Well, yeah, I'd expect that. I'm still trying to figure out what *good* failing to compile unless there's an empty /boot/device.hints does. I mean, if I didn't provide kernel hints, it would make some sense if the build process could determine that it was building on the machine it was running on. On Monday, 28 August 2000 at 14:45:23 -0600, Warner Losh wrote: In message [EMAIL PROTECTED] Mike Meyer writes: Maxim Sobolev writes: Mike Meyer wrote: Donn Miller writes: Mike Meyer wrote: I do read cvs-all, and I missed it. Not did I find device.hints in the relevant Makefiles. Can you provide a pointer to details on how /boot/device.hints is used in the build process, or how having an empty one keeps you from shooting yourself in the foot? Actually, device.hints isn't used in the build process. In that case, why does the kernel build process fail if it doesn't exist? Probably because you have `hints "BLABLA.hints"' line in your kernel config file. That doesn't really answer the question. Yup, I use GENERIC.hints. That exists. I can see why that not existing would cause problems, but not /boot/device.hints? *Especially* when I'm building a kernel for a different machine? The build of the kernel isn't forbidden by not having /boot/device.hints, just the install. I just copied my GENERIC.hints to /boot/device.hints and things were happy. That's clearly not true - I just removed an empty /boot/device.hints and rebooted, and all those things work fine. I can believe that such things won't work if they aren't specified in some hints file, but an empty /boot/device.hints doesn't do anything more to specify them than one that isn't there. Specifically, the console will not work without hints. These hints can be compiled in or in /boot/device.hints. You need to have hint.atkbdc.0.at="isa" hint.atkbdc.0.port="0x060" hint.atkbd.0.at="atkbdc" hint.atkbd.0.irq="1" hint.atkbd.0.flags="0x1" hint.vga.0.at="isa" hint.sc.0.at="isa" hint.sc.0.flags="0x100" At a minimum, but I might be mistaken about that. At the very least, there appears to be confusion about how to use the hints. I can see two conflicting views here: 1. You must have a /boot/device.hints file, but it may be empty. 2. You must have a /boot/device.hints file, and it must contain at least some entries. I ran into this same problem yesterday. I had noticed it in the cvs mailing list, and I found the first entry in UPDATING. But it didn't say what to put in, and I found no other documentation. Finally John Baldwin told me to copy my GENERIC.hints, so I did that, and it worked. But it seems that we should have some documentation here. On the face of it, (1) above seems the most obvious solution. In that case, 'make install' shouldn't fail if there's no device.hints file, it should make one. If it's (2), it can still copy the MYKERNEL.hints file. Which begs the question: when should the hints file be updated? 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: hints static wiring
On Tue, Aug 29, 2000 at 10:25:26AM +0930, Greg Lehey wrote: At the very least, there appears to be confusion about how to use the hints. I can see two conflicting views here: 1. You must have a /boot/device.hints file, but it may be empty. This is minimally correct. I.e. that's what the build system requires. This works if you build static hints into your kernel. 2. You must have a /boot/device.hints file, and it must contain at least some entries. This is more correct. The new world order says that hints are not in the kernel, instead they are loaded by the loader at boot time. By default they are loaded from /boot/device.hints. Without hints in some form old, stupid devices don't work. Unfortunatly, PC consoles are old, stupid devices for compatability reasons so it's best to have a working hints file around. I ran into this same problem yesterday. I had noticed it in the cvs mailing list, and I found the first entry in UPDATING. But it didn't say what to put in, and I found no other documentation. Finally John Baldwin told me to copy my GENERIC.hints, so I did that, and it worked. But it seems that we should have some documentation here. On the face of it, (1) above seems the most obvious solution. In that case, 'make install' shouldn't fail if there's no device.hints file, it should make one. If it's (2), it can still copy the MYKERNEL.hints file. Installing GENERIC.hints might run the risk of turning the current anti-footshooting mechinism into a foot shooting device on non-standard hardware, but I'm kinda inclined to say, who cares since that's a very far out edge case. The only problem is that it might annoy those who insist on static hints. Which begs the question: when should the hints file be updated? When you add new devices which require hints to work. Since GENERIC.hints covers the defaults for most of those devices and I don't see too many new isa drivers going in to the kernel I think that roughly translates to "never" on modern system and "rarely" on strange systems made of scavenged parts. Heck, on most legacy free systems, it really does translate to never because you can't add anything that would effect drivers that need hints (device wiring being the only exception I can think of there). -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: reducing sbsize: lost count, uid = 1001
In article [EMAIL PROTECTED], Brian Fundakowski Feldman [EMAIL PROTECTED] wrote: Woops, I have the KASSERT bungled up. Please change KASSERT(to *hiwat uip != NULL, to KASSERT(to = *hiwat || uip != NULL, It seems to be fixed now. I've had a script pounding on it all afternoon -- 843 runs so far -- and haven't been able to make it misbehave. Before, it only took a few tries to make it panic. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
