BTX: Error: Client format not supported
Hello, upgraded to todays morning current from DP1, and btx loader complains about $subj, which as I see from btxldr.s means, I'm missing something ;) in ELF format: cmpl $0x464c457f,(%ebx) # ELF magic number? je start.3 # Yes movl $e_fmt,%esi# Display error And that something should be /boot/loader, but it's ELF ;) What should I do now? ;) TIA Paulius To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP: Method of disabling acpi(4) has changed
If you want to stop auto-loading acpi.ko or to disable acpi(4), please change hint.acpi.0.disable=1 to hint.acpi.0.disabled=1 in your /boot/device.hints. Thanks From: Mitsuru IWASAKI [EMAIL PROTECTED] Subject: cvs commit: src/share/man/man5 device.hints.5 src/sys/boot/common loader.8 src/sys/boot/i386/libi386 i386_module.c src/sys/boot/i386/loader help.i386 src/sys/dev/acpica acpi.c Date: Fri, 30 Aug 2002 04:11:07 -0700 (PDT) Message-ID: [EMAIL PROTECTED] iwasaki 2002/08/30 04:11:07 PDT Modified files: share/man/man5 device.hints.5 sys/boot/common loader.8 sys/boot/i386/libi386 i386_module.c sys/boot/i386/loader help.i386 sys/dev/acpica acpi.c Log: s/hint.acpi.0.disable/hint.acpi.0.disabled/ Fix device hints entry for disabling acpi(4). This also should fix the arbitration with apm(4) when both drivers are enabled. Note that your /boot/device.hints needs to be updated if you want to stop auto-loading acpi.ko or disable acpi(4). Revision ChangesPath 1.6 +1 -1 src/share/man/man5/device.hints.5 1.47 +1 -1 src/sys/boot/common/loader.8 1.8 +1 -1 src/sys/boot/i386/libi386/i386_module.c 1.7 +1 -1 src/sys/boot/i386/loader/help.i386 1.72 +5 -0 src/sys/dev/acpica/acpi.c To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
make release (CURRENT) on 4.6 build machine?
Hi, I recently started building -current daily on my 4.6-STABLE build machine.After buildworld and -kernel I install via nfs on my testboxes. So far Ihaven't been able to provide any relevant feedback, but it's fun and I'mlearning :-)Now, I would like to 'make release' for CURRENT, as I'm doing for RELENG_4and RELENG_4_6, so I can automate the installation process on my testboxesSo far I have not been successful.Can someone give me a clue about why I'm getting signal 12 (see below) ? I have the -current sources in /usr/build/current/usr/src, local cvs treein /usr/build/ncvs and use the following command from the release directory: make -DNO_WERROR release CHROOTDIR=/usr/build/chroot-current \ BUILDNAME=CURRENT-`date +%Y%m%d` \ CVSROOT=/usr/build/ncvs \ NODOC=YES NOPORTS=YES The process stops after a while with the following error: -- stage 4: populating /usr/obj/usr/src/i386/usr/include--cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE=i386 OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec GROFF_BIN_PATH=/usr/obj/usr/src/i386/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/i386/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386/usr/share/tmac DESTDIR=/usr/obj/usr/src/i386 INSTALL=sh /usr/src/tools/install.sh PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 SHARED=symlinks par-includes=== share/infocd /usr/src/share/info; make buildincludes; make installincludes=== includecd /usr/src/include; make buildincludes; make installincludescreating osreldate.h from newvers.shsetvar PARAMFILE /usr/src/include/../sys/sys/param.h; . /usr/src/include/../sys/conf/newvers.sh; echo $COPYRIGHT osreldate.h; echo #ifdef _KERNEL osreldate.h; echo '#error /usr/include/osreldate.h cannot be used in the kernel, use sys/param.h' osreldate.h; echo #else osreldate.h; echo \#'undef __FreeBSD_version' osreldate.h; echo \#'define __FreeBSD_version' $RELDATE osreldate.h; echo #endif osreldate.h*** Signal 12 Stop in /usr/src/include.*** Error code 1 Thanks, _ ¿©¸§¹æÇÐ ¿Â¶óÀÎ ÇнÀ â°í- ¾ßÈÄ! ¹è¿òÅÍ http://kr.education.yahoo.com/ Ä£±¸µé°ú ÇÔ²² ¹Ù²ãº¸¼¼¿ä. - ¾ßÈÄ! ¸Þ½ÅÀú http://kr.messenger.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
/boot/loader problem
After make world/kernel yesterday I get this error from the bootloader: BTX version =0.00 (instead of 1.01) Client format not supported. and then it hangs. I have to do a hard reset to reboot at that point. I can still boot with /boot/loader.old which works fine. I see that today's /boot/loader is 10kb smaller(166960) than loader.old(176128). I'm going to try updating again now to see if the problem goes away. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: BTX: Error: Client format not supported
On 30-Aug-2002 Paulius Bulotas wrote: Hello, upgraded to todays morning current from DP1, and btx loader complains about $subj, which as I see from btxldr.s means, I'm missing something ;) in ELF format: cmpl $0x464c457f,(%ebx) # ELF magic number? je start.3 # Yes movl $e_fmt,%esi# Display error And that something should be /boot/loader, but it's ELF ;) What should I do now? ;) When boot2 starts to do its spin, hit a character and then type in /boot/loader.old to boot off your old loader. Once you've booted, mv /boot/loader.old /boot/loader, then update to the latest sources and you should be fine on your next rebuild. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
BTX Loader issue with today current
Trying to boot with today's current I am getting GTX Loader 1.0 BTX Version 0.00 Error: Client format not supported Anyone have any ideas to be able to boot. Thanks, ed I haven't seen murphy for a while but boy did he show up today. (I don't think I have ever rebooted both my machines here at home simultaneously, before to keep this from happening.) Someday, I'll learn. __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BTX Loader issue with today current
GTX Loader 1.0 BTX Version 0.00 Error: Client format not supported Anyone have any ideas to be able to boot. I'm seeing this as well. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: /boot/loader problem
On Fri, Aug 30, 2002 at 11:48:52AM -0700, walt wrote: After make world/kernel yesterday I get this error from the bootloader: BTX version =0.00 (instead of 1.01) Client format not supported. and then it hangs. I have to do a hard reset to reboot at that point. I can still boot with /boot/loader.old which works fine. I see that today's /boot/loader is 10kb smaller(166960) than loader.old(176128). I can't seem to get far enough to pick my /boot/loader -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BTX Loader issue with today current
Make a GRUB floppy root (hd0,0,a) [first partition, first slice, first drive] kernel=/boot/loader boot have fun :) On Friday, Aug 30, 2002, at 11:33AM, David W. Chapman Jr. [EMAIL PROTECTED] wrote: GTX Loader 1.0 BTX Version 0.00 Error: Client format not supported Anyone have any ideas to be able to boot. I'm seeing this as well. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer 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: /boot/loader problem
Quoting David W. Chapman Jr. [EMAIL PROTECTED]: | On Fri, Aug 30, 2002 at 11:48:52AM -0700, walt wrote: | After make world/kernel yesterday I get this error from the bootloader: | | BTX version =0.00 (instead of 1.01) | Client format not supported. | | and then it hangs. I have to do a hard reset to reboot at that point. | | I can still boot with /boot/loader.old which works fine. I see that | today's /boot/loader is 10kb smaller(166960) than loader.old(176128). | | I can't seem to get far enough to pick my /boot/loader David, Good morning. I was able to get both my machines up by giving /boot/loader.old at the first prompt after the F? rather than the second. ed | | -- | David W. Chapman Jr. | [EMAIL PROTECTED]Raintree Network Services, Inc. www.inethouston.net | [EMAIL PROTECTED]FreeBSD Committer 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: USB slowdown on recent -current [PATCH]
Hackers, please find attached patch for UHCI that fixes bus hanging after a device has been unplugged. i can not provide a patch for OHCI because i do not have hardware to test. after looking into this in more detail i found a somewhat similar patch in PR kern/37928. also if someone can comment on http://mail-index.netbsd.org/current-users/2001/04/13/0022.html regarding to FreeBSD. another problems i'm having with USB are 1) when i put my laptop into docking station it somewhat hard to attach USB device. i'm getting device problem errors (see attached usb.errors file). however if i try to plug/ unplug device several times then it works. perhaps something is wrong with USB hub in docking station? there is no such problem when i connect device directly to the laptop, i.e. no docking station. 2) there is bug somewhere which i can reproduce at will with my hardware. it seems that USB stack missing one interrupt transfer from the device. in only happens when driver re-opens USB pipes, i.e. 1) Device plugged 2) Driver open USB pipe 3) Driver sends control request 4) Device sends interrupt transfer 1 5) Device sends interrupt transfer 2 6) Driver closes USB pipe 7) Driver opens USB pipe 8) Driver sends control request 9) ??? no interrupt transfer 1 ??? 10) Device sends interrupt transfer 2 if i re-plug device than everything works again. i can reproduce it with both my driver and ugen driver. any clues? thanks, max Josef Karthauser wrote: On Tue, Aug 27, 2002 at 01:46:25PM -0700, Maksim Yevmenkin wrote: Hackers, Replying to myself and -current. Strange, but commenting out #define USB_USE_SOFTINTR in /sys/dev/usb_ports.h fixed my problem. USB device back to full speed and now i'm getting solid ~60 KBytes/sec. Note: this is _the_only_ change i made. the rest of the code has not been changed. Hmmm Anyone care to comment? That's interesting and was going to be my suggestion. Unfortunately there's a nasty bug in there without that defined, which I've not managed to track down yet. If you come across it please let me know privately and we'll try and nail it. It manifests itself as the bus hanging after a device has been unplugged. Joe -- As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. - Albert Einstein, 1921 Aug 30 11:34:22 beetle kernel: usbd_new_device: addr=3, getting first desc failed Aug 30 11:34:23 beetle kernel: uhub_explore: usb_new_device failed, error=IOERROR Aug 30 11:34:23 beetle kernel: uhub1: device problem, disabling port 1 Aug 30 11:34:27 beetle kernel: usbd_new_device: addr=3, getting first desc failed Aug 30 11:34:27 beetle kernel: uhub_explore: usb_new_device failed, error=IOERROR Aug 30 11:34:27 beetle kernel: uhub1: device problem, disabling port 2 Aug 30 11:34:30 beetle kernel: usbd_new_device: addr=3, getting first desc failed Aug 30 11:34:30 beetle kernel: uhub_explore: usb_new_device failed, error=IOERROR Aug 30 11:34:30 beetle kernel: uhub1: device problem, disabling port 2 Aug 30 11:34:33 beetle kernel: usbd_new_device: addr=3, getting first desc failed Aug 30 11:34:33 beetle kernel: uhub_explore: usb_new_device failed, error=IOERROR Aug 30 11:34:33 beetle kernel: uhub1: device problem, disabling port 1 Aug 30 11:34:36 beetle kernel: usbd_new_device: addr=3, getting first desc failed Aug 30 11:34:36 beetle kernel: uhub_explore: usb_new_device failed, error=IOERROR Aug 30 11:34:36 beetle kernel: uhub1: device problem, disabling port 2 Aug 30 11:34:38 beetle kernel: usbd_new_device: addr=3, getting first desc failed Aug 30 11:34:38 beetle kernel: uhub_explore: usb_new_device failed, error=IOERROR Aug 30 11:34:38 beetle kernel: uhub1: device problem, disabling port 1 Aug 30 11:34:41 beetle kernel: usbd_new_device: addr=3, getting first desc failed Aug 30 11:34:41 beetle kernel: uhub_explore: usb_new_device failed, error=IOERROR Aug 30 11:34:41 beetle kernel: uhub1: device problem, disabling port 2 Aug 30 11:34:44 beetle kernel: usbd_new_device: addr=3, getting first desc failed Aug 30 11:34:44 beetle kernel: uhub_explore: usb_new_device failed, error=IOERROR Aug 30 11:34:44 beetle kernel: uhub1: device problem, disabling port 1 Aug 30 11:34:46 beetle kernel: usbd_new_device: addr=3, getting first desc failed Aug 30 11:34:46 beetle kernel: uhub_explore: usb_new_device failed, error=IOERROR Aug 30 11:34:46 beetle kernel: uhub1: device problem, disabling port 1 Aug 30 11:34:49 beetle kernel: ubt0: 3Com product 0x00a0, rev 1.10/1.15, addr 3 Aug 30 11:34:49 beetle kernel: ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 Aug 30 11:34:49 beetle kernel: ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; nframes=6, buffer size=294 --- uhci.c.orig Thu Aug 29 09:30:08 2002 +++ uhci.c
[long] Server motherboard recommendations for 4.X/5.X?
[I'm posting this query separately on the freebsd-current and freebsd-stable mailing lists, so as not to cross the streams. If you subscribe to both and see it both places, no need to reply to both.] We are about to spec and buy a new central mail server at LavaNet, and we want to be sure that the motherboard/CPU combo we buy runs well both with FreeBSD 4.6/4.7 (at the time we install it) and also down the road when we upgrade to what's now -CURRENT, probably around 5.1. This server will initially be in a non-redundant configuration (because of the difficulty of virtualizing mailspool access) so our major concerns are stability, stability, disk I/O performance, and stability. We'd like to have console video, IDE (for CD-ROM), SCSI, and at least 2 100BaseT LAN ports integrated on the motherboard because of our experience that this improves reliability. The Intel Ethernet chipsets and the Adaptec SCSI chipset are pluses, because they've given us good performance under both BSD/OS and FreeBSD. Disk storage will be external RAID, probably 10Krpm SCSI drives striped as RAID 1+0, on an Ultra-160 SCSI bus back to the main server. Eventually we might migrate to serving or mounting files via NFS, which would make GigE a plus. CPU performance is not a concern because disk I/O dominates performance on most mail servers; we'll probably put 1.8GHz CPUs into it due to price. We've settled on a dual P4-Xeon board on grounds of wide support and expected stability. (No Intel-AMD holy wars please; we may try out dual Athlon MP boards like the Tyan K7 on a different server.) The Tyan Thunder i7500 *tentatively* looks like a good candidate to us. It meets all the above criteria, uses the Adaptec 7899 onboard 2-channel Ultra-160 SCSI controller (equivalent to 39160), has an Intel 82550 (10/100) and 82544GC (10/100/1000) LAN port, takes up to 6 slots of ECC PC2100/PC1600 DDR RAM, and has multiple 64-bit/133 MHz PCI-X slots for expansion. It uses the AMI BIOS and Intel E7500 chipset. http://www.tyan.com/products/html/thunderi7500.html If anybody is using these boards and is either unhappy or happy with their FreeBSD compatibility, I'd very much like to hear. Otherwise, if you have a favorite P4-Xeon high-integration server board that meets the above criteria and you know it works with both 4.x and -CURRENT, we'll happily take recommendations. If anyone wants to also recommend us a favorite rackmount server integrator, that wouldn't hurt. We're aware of FreeBSDSystems, ASA Computers, IXsystems, Arista IPC, and California Digital (formerly VA Linux) and have bought from the last few. We're particularly looking for one who can provide a system with dual power supplies fed from two separate power cords, similar to what you find on a high-end router or switch; we're thinking a 4U system for ease of adding any expansion cards we might need down the road. We'll install the OS, etc. but if we can take the assembly time off our hands that would be nice. Thanks in advance for any answers, -- Clifton -- Clifton Royston -- LavaNet Systems Architect -- [EMAIL PROTECTED] What do we need to make our world come alive? What does it take to make us sing? While we're waiting for the next one to arrive... - Sisters of Mercy To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CURRENT's termcap broken
On Thu, Aug 29, 2002 at 05:03:17PM +0400, Vladimir B. Grebenschikov wrote: # ? Wed, 28.08.2002, ? 23:46, Bruce A. Mah ???: # If memory serves me right, Jens Schweikhardt wrote: # # # Do you have time to commit mention of it to UPDATING? If so, please # # draw Bruce Mah's attention to the delta so that he can steal your text # # for use in the release notes. If not, I'll get around to it eventually. # # :-) # # I just added a note to src/UPDATING. Bruce, are you listening # for the release notes? # # 20020827: # Our /etc/termcap now has all the entries from the XFree86 xterm # almost unchanged. This means xterm now supports color by default. # If you used TERM=xterm-color in the past you now should use # TERM=xterm. (xterm-color will lead to benign warnings). # # # After this update, xterm-color produce warnings: # vbook:/home/vova 129_ mc # TERMCAP, line 0, terminal 'xterm-color': enter_alt_charset_mode but no # acs_chars # TERMCAP, line 0, terminal 'xterm-color': exit_alt_charset_mode but no # acs_chars # # and midnight commander shows all with -, +, | instead of # pesudo-graphics. It seems this is the price we pay for alignment with what XFree86 ships. # Ok I have tried setenv TERM xterm, midnight commander now black and # white, where I have mistaken ? I just installed the misc/mc package from 4.6 and midc is fully colored under xterm, rxvt and the console. Do you have a stale termcap.db? Does midc use/read some config file that says no color? Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CURRENT's termcap broken
On Sat, Aug 31, 2002 at 00:04:44 +0200, Jens Schweikhardt wrote: # and midnight commander shows all with -, +, | instead of # pesudo-graphics. It seems this is the price we pay for alignment with what XFree86 ships. We don't need to pay, if entries will be _really_ corrected instead of _blindly_ updated. If you don't have experience to correct new entry afterwards to satisfy requirements, better back out this commit. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CURRENT's termcap broken
On Sat, Aug 31, 2002 at 00:04:44 +0200, Jens Schweikhardt wrote: # and midnight commander shows all with -, +, | instead of # pesudo-graphics. It seems this is the price we pay for alignment with what XFree86 ships. We don't need to pay, if entries will be _really_ corrected instead of _blindly_ updated. IMHO, it has been corrected, and was incorrect before. FWIW, this would also appear to be the opinion of the current maintainer of 'xterm' for XFree86. Ache, have you read bin/41143? Regards, AS msg42324/pgp0.pgp Description: PGP signature
Re: CURRENT's termcap broken
On Fri, Aug 30, 2002 at 21:47:16 -0400, Andy Sparrow wrote: On Sat, Aug 31, 2002 at 00:04:44 +0200, Jens Schweikhardt wrote: # and midnight commander shows all with -, +, | instead of # pesudo-graphics. It seems this is the price we pay for alignment with what XFree86 ships. We don't need to pay, if entries will be _really_ corrected instead of _blindly_ updated. IMHO, it has been corrected, and was incorrect before. I mean, corrected for ACS characters (pseudo-graphics), which are correct before. Read complains above. Ache, have you read bin/41143? To fix what you mean, just moving 'xterm-color' entry additional color capabilities directly to 'xterm' entry and making 'xterm-color' as alias to 'xterm' will be enough to fix PR. -- Andrey A. Chernov http://ache.pp.ru/ msg42325/pgp0.pgp Description: PGP signature
Re: CURRENT's termcap broken
IMHO, it has been corrected, and was incorrect before. I mean, corrected for ACS characters (pseudo-graphics), which are correct before. Read complains above. I believe that these are fixed by not using an incorrect termtype (e.g. 'xterm-color', which refers to another terminal type altogether). Ache, have you read bin/41143? To fix what you mean, just moving 'xterm-color' entry additional color capabilities directly to 'xterm' entry and making 'xterm-color' as alias to 'xterm' will be enough to fix PR. Hmmm. Except that 'xterm-color' is widely used as a cap for an older (and incompatible) termtype, as stated in the PR. And the author of xterm has widely criticised FreeBSD's incorrect handling of other attributes. To the point where he has documented the brokeness in his FAQ, and specifically advises to use the termcap supplied with 'xterm'. Again, as stated in the PR. Specifically: http://dickey.his.com/xterm/xterm.faq.html#xterm_terminfo Regards, AS msg42326/pgp0.pgp Description: PGP signature
Re: CURRENT's termcap broken
On Fri, Aug 30, 2002 at 22:12:33 -0400, Andy Sparrow wrote: And the author of xterm has widely criticised FreeBSD's incorrect handling of other attributes. To the point where he has documented the brokeness in his FAQ, and specifically advises to use the termcap supplied with 'xterm'. Again, as stated in the PR. Specifically: http://dickey.his.com/xterm/xterm.faq.html#xterm_terminfo This info is obsoleted. 'bce' issue was already corrected few commits before. -- Andrey A. Chernov http://ache.pp.ru/ msg42327/pgp0.pgp Description: PGP signature
