From owner-freebsd-hardware Sun Dec 29 6:21:39 2002 Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C11B837B401 for ; Sun, 29 Dec 2002 06:21:34 -0800 (PST) Received: from mail.johnrshannon.com (mail.johnrshannon.com [208.141.183.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CE8B43EA9 for ; Sun, 29 Dec 2002 06:21:33 -0800 (PST) (envelope-from john@johnrshannon.com) Received: by mail.johnrshannon.com (Postfix, from userid 1003) id D4EC21248A; Sun, 29 Dec 2002 07:21:22 -0700 (MST) Received: from pablo.johnrshannon.com (pablo.johnrshannon.com [192.168.1.3]) by mail.johnrshannon.com (Postfix) with ESMTP id C3A1412486 for ; Sun, 29 Dec 2002 07:21:21 -0700 (MST) Received: from pablo.johnrshannon.com (localhost [127.0.0.1]) by pablo.johnrshannon.com (8.12.6/8.12.6) with ESMTP id gBTELLGa000468 for ; Sun, 29 Dec 2002 07:21:21 -0700 (MST) (envelope-from john@pablo.johnrshannon.com) Received: (from john@localhost) by pablo.johnrshannon.com (8.12.6/8.12.6/Submit) id gBTELL2L000467 for freebsd-hardware@freebsd.org; Sun, 29 Dec 2002 07:21:21 -0700 (MST) (envelope-from john) Content-Type: text/plain; charset="us-ascii" From: "John R. Shannon" Reply-To: john@johnrshannon.com To: freebsd-hardware@freebsd.org Subject: Canon A40 - USB Date: Sun, 29 Dec 2002 07:21:11 -0700 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200212290721.21411.john@johnrshannon.com> Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FreeBSD 4.7-STABLE #5 pkg_info |grep gphoto gphoto2-2.1.0_3 A universal digital camera picture control tool # usbdevs -v Controller /dev/usb0: addr 1: self powered, config 1, UHCI root hub(0x0000), VIA(0x0000), rev 1= =2E00 port 1 powered port 2 powered Controller /dev/usb1: addr 1: self powered, config 1, UHCI root hub(0x0000), VIA(0x0000), rev 1= =2E00 port 1 powered port 2 powered # env LANG=3DC gphoto2 --debug --camera "Canon PowerShot A40" --port "usb= " -L 0.000470 main(2): ALWAYS INCLUDE THE FOLLOWING LINE WHEN SENDING DEBUG=20 MESSAGES TO THE MAILING LIST: 0.001199 main(2): gphoto2 2.1.0 0.001605 main(2): Setting port to 'usb'... 0.002000 main(2): Ports must look like 'serial:/dev/ttyS0' or 'usb:', but= =20 'usb' is missing a colon so I am going to guess what you mean. 0.002419 main(2): Guessed port name. Using port 'usb:' from now on. 0.002784 main(2): Setting camera model to 'Canon PowerShot A40'... 0.003268 gphoto2-filesystem(2): Internally appending folder /... 0.003706 gphoto2-port(2): Creating new device... 0.004109 gphoto2-abilities-list(2): Loading camera libraries in=20 '/usr/local/lib/gphoto2/2.1.0'... 0.004148 gphoto2-abilities-list(2): Note that failing to load *.a and *.l= a is=20 NOT an error! 0.004727 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_agfa.so'... 0.005333 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_barbie.so'... 0.005912 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_canon.so'... 0.006285 canon/library.c(2): camera_id() 0.006328 canon/library.c(2): camera_abilities() 0.009788 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_casio_qv.so'... 0.011988 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_digita.so'... 0.018261 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_dimera3500.so'... 0.020539 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_directory.so'... 0.021690 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_fuji.so'... 0.029448 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_jamcam.so'... 0.030868 jamcam/jamcam.c(2): * camera_id 0.031354 jamcam/jamcam.c(2): * camera_abilities 0.032125 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_jd11.so'... 0.037736 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_kodak_dc120.so'... 0.039019 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_kodak_dc240.so'... 0.042850 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_kodak_dc3200.so'... 0.044071 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_konica.so'... 1.051567 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_dimagev.so'... 1.054340 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_mustek.so'... 1.055532 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_panasonic_coolshot.so'... 1.056326 coolshot/coolshot.c(2): * camera_id 1.056774 coolshot/coolshot.c(2): * camera_abilities 1.059845 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_panasonic_l859.so'... 1.060689 l859/l859.c(2): Camera ID 1.063307 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_panasonic_dc1000.so'... 1.064484 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_panasonic_dc1580.so'... 1.068396 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_polaroid_pdc320.so'... 1.070894 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_polaroid_pdc640.so'... 1.073667 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_polaroid_pdc700.so'... 1.075878 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_ptp.so'... 1.096779 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_ricoh.so'... 1.101663 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_samsung.so'... 1.106625 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_sierra.so'... 1.231760 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_sipix.so'... 1.232977 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_stv0680.so'... 1.266995 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_sony_dscf1.so'... 1.271459 gphoto2-abilities-list(2): Trying to load=20 '/usr/local/lib/gphoto2/2.1.0/libgphoto2_sony_dscf55.so'... 1.319355 gp-port-info-list(2): Loading io-drivers from=20 '/usr/local/lib/gphoto2_port/0.5.0'... 1.320684 gphoto2-port-serial(2): Trying to lock '/dev/cuaa0'... 1.321627 gphoto2-port-serial(2): Trying to lock '/dev/cuaa1'... 1.322374 gphoto2-port-serial(2): Trying to lock '/dev/cuaa2'... 1.322843 gphoto2-port-serial(2): Trying to lock '/dev/cuaa3'... 1.323278 gphoto2-port-serial(2): Trying to lock '/dev/cuaa4'... 1.323719 gphoto2-port-serial(2): Trying to lock '/dev/cuaa5'... 1.324162 gphoto2-port-serial(2): Trying to lock '/dev/cuaa6'... 1.324589 gphoto2-port-serial(2): Trying to lock '/dev/cuaa7'... 1.324984 gphoto2-port-serial(2): Trying to lock '/dev/cuaa8'... 1.325410 gphoto2-port-serial(2): Trying to lock '/dev/cuaa9'... 1.325815 gphoto2-port-serial(2): Trying to lock '/dev/cuaaa'... 1.326251 gphoto2-port-serial(2): Trying to lock '/dev/cuaab'... 1.326654 gphoto2-port-serial(2): Trying to lock '/dev/cuaac'... 1.327120 gphoto2-port-serial(2): Trying to lock '/dev/cuaad'... 1.327523 gphoto2-port-serial(2): Trying to lock '/dev/cuaae'... 1.327950 gphoto2-port-serial(2): Trying to lock '/dev/cuaaf'... 1.328351 gphoto2-port-core(2): Loaded 'Serial Port 0' (serial:/dev/cuaa0)= from=20 'libgphoto2_port_serial.so' 1.328787 gphoto2-port-core(2): Loaded 'Serial Port 1' (serial:/dev/cuaa1)= from=20 'libgphoto2_port_serial.so' 1.329174 gphoto2-port-core(2): Loaded '' (^serial) from=20 'libgphoto2_port_serial.so' 1.330279 gphoto2-port-core(2): Loaded 'Universal Serial Bus' (usb:) from=20 'libgphoto2_port_usb.so' 1.330984 gphoto2-camera(2): Setting abilities ('Canon PowerShot A40')... 1.331415 setting/gphoto2-setting.c(2): Creating $HOME/.gphoto 1.346461 setting/gphoto2-setting.c(2): Loading settings from file=20 "/root/.gphoto/settings" 1.347314 gphoto2-setting(2): Setting key 'model' to value 'Canon PowerSho= t=20 A40' (gphoto2) 1.347744 gphoto2-setting(2): Saving 2 setting(s) to file=20 "/root/.gphoto/settings" 1.348770 gphoto2-port-info-list(2): Looking for path 'usb:' (4 entries=20 available)... 1.349277 gphoto2-port-info-list(2): Getting info of entry 2 (4 available)= =2E.. 1.349705 gphoto2-camera(2): Setting port info for port 'Universal Serial = Bus'=20 at 'usb:'... 1.351658 gphoto2-port(2): Setting timeout to 5000 millisecond(s)... 1.352103 gphoto2-port(2): Setting settings... 1.352533 gphoto2-setting(2): Setting key 'port' to value 'usb:' (gphoto2) 1.352942 gphoto2-setting(2): Saving 2 setting(s) to file=20 "/root/.gphoto/settings" 1.354464 gphoto2-camera(2): Listing files in '/'... 1.355044 gphoto2-camera(2): Initializing camera... 1.355551 gphoto2-port(0): Could not find USB device (vendor 0x4a9, produc= t=20 0x3058). Make sure this device is connected to the computer. 1.355976 context(0): An error occurred in the io-library ('Bad parameters= '):=20 Could not find USB device (vendor 0x4a9, product 0x3058). Make sure this=20 device is connected to the computer. *** Error *** An error occurred in the io-library ('Bad parameters'): Could not find US= B=20 device (vendor 0x4a9, product 0x3058). Make sure this device is connected= to=20 the computer. *** Error ('Bad parameters') *** Any suggestions? Camera is connected to computer, powerdered on, and swit= ched=20 to dowload setting. - --=20 John R. Shannon john@johnrshannon.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iEYEARECAAYFAj4PBN8ACgkQOKbCxya4HYsP8QCaA/P7S8W1i/URUxGmc695wDvA ZrcAoJyk5hnLn3yt+9De5R3YMK8zlDkv =3D0A9/ -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message From owner-freebsd-hardware Tue Dec 31 7: 8:44 2002 Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66C7637B401; Tue, 31 Dec 2002 07:08:43 -0800 (PST) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4E7243EC2; Tue, 31 Dec 2002 07:08:42 -0800 (PST) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Dec 2002 10:08:42 -0500 Message-ID: From: Don Bowman To: "'George J.V. Cox'" , freebsd-net@freebsd.org, freebsd-hardware@freebsd.org Subject: RE: Broadcom BCM5703X Gigabit Ethernet woes, panics, no MIIs, oh my! Date: Tue, 31 Dec 2002 10:08:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org From: George J.V. Cox [mailto:gjvc@extremis.net] > I have a Dell 1655MC blade server, and a compiled-this-week > 4.7-STABLE kernel. > The hardware is a chassis of 6 PCs in a 3U case. Each blade > has two Broadcom > BCM5703 interfaces. Unfortunately, its behaviour is rather > non-deterministic. ... I'm seeing similar behaviour with a 5704 (dual gmac). I will let you know if I find a fix for it. I'm suspecting the timing on the eeprom interface right now since I sometimes get a MAC of 0. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message From owner-freebsd-hardware Tue Dec 31 8:12:59 2002 Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95BD637B401 for ; Tue, 31 Dec 2002 08:12:53 -0800 (PST) Received: from jawa.at (inforum.at [213.229.17.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5792E43EC5 for ; Tue, 31 Dec 2002 08:12:46 -0800 (PST) (envelope-from mbretter@jawa.at) Received: from jawa.at (worf.jawa.at [192.168.201.12]) by jawa.at (8.12.6/8.12.6) with ESMTP id gBVGCT7K085847 for ; Tue, 31 Dec 2002 17:12:30 +0100 (CET) (envelope-from mbretter@jawa.at) Message-ID: <3E11C1B0.7020500@jawa.at> Date: Tue, 31 Dec 2002 17:11:28 +0100 From: Michael Bretterklieber User-Agent: Mozilla/5.0 (X11; U; Linux i386; de-AT; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hardware@freebsd.org Subject: APIC on non SMP-systems Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-0.5 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, does FreeBSD (stable) support APIC on non SMP-Systems? I tried to add only APIC_IO to the kernel-conf, but the I get these compiler errors: cc -c -x assembler-with-cpp -DLOCORE -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -I../../contrib/ipfilter -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../i386/i386/exception.s {standard input}: Assembler messages: {standard input}:3041: Error: invalid character '_' in mnemonic {standard input}:3070: Error: invalid character '_' in mnemonic {standard input}:3215: Error: invalid character '_' in mnemonic {standard input}:3215: Error: invalid character '_' in mnemonic {standard input}:3215: Error: invalid character '_' in mnemonic {standard input}:3215: Error: invalid character '_' in mnemonic {standard input}:3215: Error: invalid character '_' in mnemonic {standard input}:3215: Error: invalid character '_' in mnemonic {standard input}:3215: Error: invalid character '_' in mnemonic {standard input}:3215: Error: invalid character '_' in mnemonic {standard input}:3216: Error: invalid character '_' in mnemonic {standard input}:3216: Error: invalid character '_' in mnemonic {standard input}:3216: Error: invalid character '_' in mnemonic {standard input}:3216: Error: invalid character '_' in mnemonic {standard input}:3216: Error: invalid character '_' in mnemonic {standard input}:3216: Error: invalid character '_' in mnemonic {standard input}:3216: Error: invalid character '_' in mnemonic {standard input}:3216: Error: invalid character '_' in mnemonic {standard input}:3217: Error: invalid character '_' in mnemonic {standard input}:3217: Error: invalid character '_' in mnemonic {standard input}:3217: Error: invalid character '_' in mnemonic {standard input}:3217: Error: invalid character '_' in mnemonic {standard input}:3217: Error: invalid character '_' in mnemonic {standard input}:3217: Error: invalid character '_' in mnemonic {standard input}:3217: Error: invalid character '_' in mnemonic {standard input}:3217: Error: invalid character '_' in mnemonic {standard input}:3218: Error: invalid character '_' in mnemonic {standard input}:3218: Error: invalid character '_' in mnemonic {standard input}:3218: Error: invalid character '_' in mnemonic {standard input}:3218: Error: invalid character '_' in mnemonic {standard input}:3218: Error: invalid character '_' in mnemonic {standard input}:3218: Error: invalid character '_' in mnemonic {standard input}:3218: Error: invalid character '_' in mnemonic {standard input}:3218: Error: invalid character '_' in mnemonic {standard input}:3219: Error: invalid character '_' in mnemonic {standard input}:3219: Error: invalid character '_' in mnemonic {standard input}:3219: Error: invalid character '_' in mnemonic {standard input}:3219: Error: invalid character '_' in mnemonic {standard input}:3219: Error: invalid character '_' in mnemonic {standard input}:3219: Error: invalid character '_' in mnemonic {standard input}:3219: Error: invalid character '_' in mnemonic {standard input}:3219: Error: invalid character '_' in mnemonic {standard input}:3220: Error: invalid character '_' in mnemonic {standard input}:3220: Error: invalid character '_' in mnemonic {standard input}:3220: Error: invalid character '_' in mnemonic {standard input}:3220: Error: invalid character '_' in mnemonic {standard input}:3220: Error: invalid character '_' in mnemonic {standard input}:3220: Error: invalid character '_' in mnemonic {standard input}:3220: Error: invalid character '_' in mnemonic {standard input}:3220: Error: invalid character '_' in mnemonic {standard input}:3221: Error: invalid character '_' in mnemonic {standard input}:3221: Error: invalid character '_' in mnemonic {standard input}:3221: Error: invalid character '_' in mnemonic {standard input}:3221: Error: invalid character '_' in mnemonic {standard input}:3221: Error: invalid character '_' in mnemonic {standard input}:3221: Error: invalid character '_' in mnemonic {standard input}:3221: Error: invalid character '_' in mnemonic {standard input}:3221: Error: invalid character '_' in mnemonic {standard input}:3222: Error: invalid character '_' in mnemonic {standard input}:3222: Error: invalid character '_' in mnemonic {standard input}:3222: Error: invalid character '_' in mnemonic {standard input}:3222: Error: invalid character '_' in mnemonic {standard input}:3222: Error: invalid character '_' in mnemonic {standard input}:3222: Error: invalid character '_' in mnemonic {standard input}:3222: Error: invalid character '_' in mnemonic {standard input}:3222: Error: invalid character '_' in mnemonic {standard input}:3223: Error: invalid character '_' in mnemonic {standard input}:3223: Error: invalid character '_' in mnemonic {standard input}:3223: Error: invalid character '_' in mnemonic {standard input}:3223: Error: invalid character '_' in mnemonic {standard input}:3223: Error: invalid character '_' in mnemonic {standard input}:3223: Error: invalid character '_' in mnemonic {standard input}:3223: Error: invalid character '_' in mnemonic {standard input}:3223: Error: invalid character '_' in mnemonic {standard input}:3224: Error: invalid character '_' in mnemonic {standard input}:3224: Error: invalid character '_' in mnemonic {standard input}:3224: Error: invalid character '_' in mnemonic {standard input}:3224: Error: invalid character '_' in mnemonic {standard input}:3224: Error: invalid character '_' in mnemonic {standard input}:3224: Error: invalid character '_' in mnemonic {standard input}:3224: Error: invalid character '_' in mnemonic {standard input}:3224: Error: invalid character '_' in mnemonic {standard input}:3225: Error: invalid character '_' in mnemonic {standard input}:3225: Error: invalid character '_' in mnemonic {standard input}:3225: Error: invalid character '_' in mnemonic {standard input}:3225: Error: invalid character '_' in mnemonic {standard input}:3225: Error: invalid character '_' in mnemonic {standard input}:3225: Error: invalid character '_' in mnemonic {standard input}:3225: Error: invalid character '_' in mnemonic {standard input}:3225: Error: invalid character '_' in mnemonic {standard input}:3226: Error: invalid character '_' in mnemonic {standard input}:3226: Error: invalid character '_' in mnemonic {standard input}:3226: Error: invalid character '_' in mnemonic {standard input}:3226: Error: invalid character '_' in mnemonic {standard input}:3226: Error: invalid character '_' in mnemonic {standard input}:3226: Error: invalid character '_' in mnemonic {standard input}:3226: Error: invalid character '_' in mnemonic {standard input}:3226: Error: invalid character '_' in mnemonic {standard input}:3227: Error: invalid character '_' in mnemonic {standard input}:3227: Error: invalid character '_' in mnemonic {standard input}:3227: Error: invalid character '_' in mnemonic {standard input}:3227: Error: invalid character '_' in mnemonic {standard input}:3227: Error: invalid character '_' in mnemonic {standard input}:3227: Error: invalid character '_' in mnemonic {standard input}:3227: Error: invalid character '_' in mnemonic {standard input}:3227: Error: invalid character '_' in mnemonic {standard input}:3228: Error: invalid character '_' in mnemonic {standard input}:3228: Error: invalid character '_' in mnemonic {standard input}:3228: Error: invalid character '_' in mnemonic {standard input}:3228: Error: invalid character '_' in mnemonic {standard input}:3228: Error: invalid character '_' in mnemonic {standard input}:3228: Error: invalid character '_' in mnemonic {standard input}:3228: Error: invalid character '_' in mnemonic {standard input}:3228: Error: invalid character '_' in mnemonic {standard input}:3229: Error: invalid character '_' in mnemonic {standard input}:3229: Error: invalid character '_' in mnemonic {standard input}:3229: Error: invalid character '_' in mnemonic {standard input}:3229: Error: invalid character '_' in mnemonic {standard input}:3229: Error: invalid character '_' in mnemonic {standard input}:3229: Error: invalid character '_' in mnemonic {standard input}:3229: Error: invalid character '_' in mnemonic {standard input}:3229: Error: invalid character '_' in mnemonic {standard input}:3230: Error: invalid character '_' in mnemonic {standard input}:3230: Error: invalid character '_' in mnemonic {standard input}:3230: Error: invalid character '_' in mnemonic {standard input}:3230: Error: invalid character '_' in mnemonic {standard input}:3230: Error: invalid character '_' in mnemonic {standard input}:3230: Error: invalid character '_' in mnemonic {standard input}:3230: Error: invalid character '_' in mnemonic {standard input}:3230: Error: invalid character '_' in mnemonic {standard input}:3231: Error: invalid character '_' in mnemonic {standard input}:3231: Error: invalid character '_' in mnemonic {standard input}:3231: Error: invalid character '_' in mnemonic {standard input}:3231: Error: invalid character '_' in mnemonic {standard input}:3231: Error: invalid character '_' in mnemonic {standard input}:3231: Error: invalid character '_' in mnemonic {standard input}:3231: Error: invalid character '_' in mnemonic {standard input}:3231: Error: invalid character '_' in mnemonic {standard input}:3232: Error: invalid character '_' in mnemonic {standard input}:3232: Error: invalid character '_' in mnemonic {standard input}:3232: Error: invalid character '_' in mnemonic {standard input}:3232: Error: invalid character '_' in mnemonic {standard input}:3232: Error: invalid character '_' in mnemonic {standard input}:3232: Error: invalid character '_' in mnemonic {standard input}:3232: Error: invalid character '_' in mnemonic {standard input}:3232: Error: invalid character '_' in mnemonic {standard input}:3233: Error: invalid character '_' in mnemonic {standard input}:3233: Error: invalid character '_' in mnemonic {standard input}:3233: Error: invalid character '_' in mnemonic {standard input}:3233: Error: invalid character '_' in mnemonic {standard input}:3233: Error: invalid character '_' in mnemonic {standard input}:3233: Error: invalid character '_' in mnemonic {standard input}:3233: Error: invalid character '_' in mnemonic {standard input}:3233: Error: invalid character '_' in mnemonic {standard input}:3234: Error: invalid character '_' in mnemonic {standard input}:3234: Error: invalid character '_' in mnemonic {standard input}:3234: Error: invalid character '_' in mnemonic {standard input}:3234: Error: invalid character '_' in mnemonic {standard input}:3234: Error: invalid character '_' in mnemonic {standard input}:3234: Error: invalid character '_' in mnemonic {standard input}:3234: Error: invalid character '_' in mnemonic {standard input}:3234: Error: invalid character '_' in mnemonic {standard input}:3235: Error: invalid character '_' in mnemonic {standard input}:3235: Error: invalid character '_' in mnemonic {standard input}:3235: Error: invalid character '_' in mnemonic {standard input}:3235: Error: invalid character '_' in mnemonic {standard input}:3235: Error: invalid character '_' in mnemonic {standard input}:3235: Error: invalid character '_' in mnemonic {standard input}:3235: Error: invalid character '_' in mnemonic {standard input}:3235: Error: invalid character '_' in mnemonic {standard input}:3236: Error: invalid character '_' in mnemonic {standard input}:3236: Error: invalid character '_' in mnemonic {standard input}:3236: Error: invalid character '_' in mnemonic {standard input}:3236: Error: invalid character '_' in mnemonic {standard input}:3236: Error: invalid character '_' in mnemonic {standard input}:3236: Error: invalid character '_' in mnemonic {standard input}:3236: Error: invalid character '_' in mnemonic {standard input}:3236: Error: invalid character '_' in mnemonic {standard input}:3237: Error: invalid character '_' in mnemonic {standard input}:3237: Error: invalid character '_' in mnemonic {standard input}:3237: Error: invalid character '_' in mnemonic {standard input}:3237: Error: invalid character '_' in mnemonic {standard input}:3237: Error: invalid character '_' in mnemonic {standard input}:3237: Error: invalid character '_' in mnemonic {standard input}:3237: Error: invalid character '_' in mnemonic {standard input}:3237: Error: invalid character '_' in mnemonic {standard input}:3238: Error: invalid character '_' in mnemonic {standard input}:3238: Error: invalid character '_' in mnemonic {standard input}:3238: Error: invalid character '_' in mnemonic {standard input}:3238: Error: invalid character '_' in mnemonic {standard input}:3238: Error: invalid character '_' in mnemonic {standard input}:3238: Error: invalid character '_' in mnemonic {standard input}:3238: Error: invalid character '_' in mnemonic {standard input}:3238: Error: invalid character '_' in mnemonic {standard input}:3884: Error: invalid character '_' in mnemonic {standard input}:3903: Error: invalid character '_' in mnemonic {standard input}:3916: Error: invalid character '_' in mnemonic {standard input}:3935: Error: invalid character '_' in mnemonic bye, -- ------------------------------- ---------------------------------- Michael Bretterklieber - Michael.Bretterklieber@jawa.at JAWA Management Software GmbH - http://www.jawa.at Liebenauer Hauptstr. 200 -------------- privat ------------ A-8041 GRAZ GSM: ++43-(0)676-93 96 698 Tel: ++43-(0)316-403274-12 E-mail: mbretter@inode.at Fax: ++43-(0)316-403274-10 http://www.bretterklieber.com ------------------------------- ---------------------------------- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message From owner-freebsd-hardware Tue Dec 31 10: 5:19 2002 Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4702137B44B for ; Tue, 31 Dec 2002 10:05:18 -0800 (PST) Received: from mail.speakeasy.net (mail13.speakeasy.net [216.254.0.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2C3C43E4A for ; Tue, 31 Dec 2002 10:05:17 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 27248 invoked from network); 31 Dec 2002 18:05:22 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail13.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 31 Dec 2002 18:05:22 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.6/8.12.6) with ESMTP id gBVI5FUT054269; Tue, 31 Dec 2002 13:05:15 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3E11C1B0.7020500@jawa.at> Date: Tue, 31 Dec 2002 13:05:21 -0500 (EST) From: John Baldwin To: Michael Bretterklieber Subject: RE: APIC on non SMP-systems Cc: freebsd-hardware@freebsd.org Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 31-Dec-2002 Michael Bretterklieber wrote: > Hi, > > does FreeBSD (stable) support APIC on non SMP-Systems? No, it doesn't right now. It will eventually but that's going to take a while to get done. :) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message From owner-freebsd-hardware Tue Dec 31 10:50:42 2002 Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEFD837B401; Tue, 31 Dec 2002 10:50:41 -0800 (PST) Received: from borg-cube.com (213-106.adsl3.netlojix.net [207.71.213.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BA9B43EC2; Tue, 31 Dec 2002 10:50:41 -0800 (PST) (envelope-from dburr@borg-cube.com) Received: from borg-cube.com (dburr@borg-cube.com [207.71.213.106]) by borg-cube.com (8.12.6/8.12.6) with ESMTP id gBVIoUH2052132; Tue, 31 Dec 2002 10:50:30 -0800 (PST) (envelope-from dburr@borg-cube.com) Date: Tue, 31 Dec 2002 10:50:30 -0800 (PST) From: Donald Burr of Borg To: FreeBSD Hardware Cc: FreeBSD Questions Subject: Support for Seagate TRAVAN NS20 (using FreeCom USB-ATAPI chip)? Message-ID: <20021231104840.F52084-100000@borg-cube.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org We'd like to hook an external USB tape backup drive (Seagate Travan NS20 device, it uses the Freecom USB-ATAPI bridge chip) to our FreeBSD server to do backups. (Yes, we know it'll be slow...) When we plug it in, the device is recognized and "grabbed" by the ugen driver. Is there any hope of getting this thing to work (anyone know of any drivers out there, etc.) or are we SOL? We're runninng 4.7-RELEASE. -- Donald Burr of Borg | FreeBSD: The Power to Serve! WWW: http://www.borg-cube.com/ ICQ #16997506 | http://www.freebsd.org/ P.O. Box 91212, Santa Barbara, CA 93190-1212 \----------------------------- Phone: (805)563-0672 Present Day... Present Time! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message From owner-freebsd-hardware Tue Dec 31 11:53:18 2002 Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70B2537B401; Tue, 31 Dec 2002 11:53:17 -0800 (PST) Received: from jawa.at (inforum.at [213.229.17.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4ED8243ED1; Tue, 31 Dec 2002 11:53:16 -0800 (PST) (envelope-from mbretter@jawa.at) Received: from jawa.at (worf.jawa.at [192.168.201.12]) by jawa.at (8.12.6/8.12.6) with ESMTP id gBVJr57K096398; Tue, 31 Dec 2002 20:53:05 +0100 (CET) (envelope-from mbretter@jawa.at) Message-ID: <3E11F565.8080503@jawa.at> Date: Tue, 31 Dec 2002 20:52:05 +0100 From: Michael Bretterklieber User-Agent: Mozilla/5.0 (X11; U; Linux i386; de-AT; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin Cc: freebsd-hardware@FreeBSD.ORG Subject: Re: APIC on non SMP-systems References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Spam-Status: No, hits=-1.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, John Baldwin wrote: > On 31-Dec-2002 Michael Bretterklieber wrote: > >>Hi, >> >>does FreeBSD (stable) support APIC on non SMP-Systems? > > > No, it doesn't right now. It will eventually but that's going to take > a while to get done. :) > no hurry, my system works well without APIC, was just a test. If you have patches I can test it. thanx for your reply, happy new year, bye, -- ------------------------------- ---------------------------------- Michael Bretterklieber - Michael.Bretterklieber@jawa.at JAWA Management Software GmbH - http://www.jawa.at Liebenauer Hauptstr. 200 -------------- privat ------------ A-8041 GRAZ GSM: ++43-(0)676-93 96 698 Tel: ++43-(0)316-403274-12 E-mail: mbretter@inode.at Fax: ++43-(0)316-403274-10 http://www.bretterklieber.com ------------------------------- ---------------------------------- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message From owner-freebsd-hardware Tue Dec 31 12:58:38 2002 Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B728837B401; Tue, 31 Dec 2002 12:58:35 -0800 (PST) Received: from level.uwaterloo.ca (level.uwaterloo.ca [129.97.50.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1318C43E4A; Tue, 31 Dec 2002 12:58:35 -0800 (PST) (envelope-from bruce@engmail.uwaterloo.ca) Received: from level.uwaterloo.ca (localhost [127.0.0.1]) by level.uwaterloo.ca (8.12.3/8.12.3) with ESMTP id gBVKvG5n046340; Tue, 31 Dec 2002 15:57:16 -0500 (EST) (envelope-from bruce@engmail.uwaterloo.ca) Received: (from www@localhost) by level.uwaterloo.ca (8.12.3/8.12.3/Submit) id gBVKvGDx046339; Tue, 31 Dec 2002 15:57:16 -0500 (EST) X-Authentication-Warning: level.uwaterloo.ca: www set sender to bruce@engmail.uwaterloo.ca using -f Received: from 65.93.103.72 ( [65.93.103.72]) as user bruce@engmail.uwaterloo.ca by www.nexusmail.uwaterloo.ca with HTTP; Tue, 31 Dec 2002 15:57:16 -0500 Message-ID: <1041368236.3e1204ac45da5@www.nexusmail.uwaterloo.ca> Date: Tue, 31 Dec 2002 15:57:16 -0500 From: Bruce Campbell To: freebsd-hardware@freebsd.org, freebsd-questions@freebsd.org Subject: ata "fallback to PIO mode" on dual processor AMD systems MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 / FreeBSD-4.6.2 X-Originating-IP: 65.93.103.72 Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I am seeing a problem with ata disks on 4 new systems, which I believe is either a bug in the ata driver, or a problem with the onboard IDE controller, or something else. Systems are as follows: Motherboard: ASUS A7M266-D CPUs : 2 x 2000+ AMD MP Memory : 2 x 512MB Crucial part: CT6472Y265 Disks (all UDMA100): Master Slave System 1: WDC WD400BB WDC WD1000BB System 2: WDC WD400BB WDC WD1000BB System 3: WDC WD400BB WDC WD800BB System 4: WDC WD400BB Maxtor 98196H8 Kernel : 4.7-RELEASE, custom kernel (compared to GENERIC): commented out: cpu I386_CPU cpu I486_CPU enabled options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O I am running a test with "dbench" (/usr/ports/benchmarks/dbench) with a script which runs: dbench 1 sleep for 5 minutes dbench 2 sleep for 5 minutes dbench 3 ... to simulate 1,2,3... clients. The following has happened on systems 2,3 and 4, after about 15 hours of running the test: Dec 30 23:26:59 ecserv13 /kernel: ad0: WRITE command timeout tag=0 serv=0 - resetting Dec 30 23:26:59 ecserv13 /kernel: ata0: resetting devices .. done Dec 30 23:26:59 ecserv13 /kernel: ad0: WRITE command timeout tag=0 serv=0 resetting Dec 30 23:27:00 ecserv13 /kernel: ata0: resetting devices .. done Dec 30 23:27:00 ecserv13 /kernel: ad0: WRITE command timeout tag=0 serv=0 resetting Dec 30 23:27:00 ecserv13 /kernel: ata0: resetting devices .. done Dec 30 23:27:00 ecserv13 /kernel: ad0: WRITE command timeout tag=0 serv=0 resetting Dec 30 23:27:00 ecserv13 /kernel: ad0: timeout waiting for cmd=ef s=d0 e=00 Dec 30 23:27:00 ecserv13 /kernel: ad0: trying fallback to PIO mode Dec 30 23:27:00 ecserv13 /kernel: ata0: resetting devices .. done The test continues to run with the ata controller in PIO mode, with slower performance, and higher load average. Once the master drops to PIO, attempts to access the slave then cause it to drop to PIO. If I run: atacontrol mode 0 UDMA100 UDMA100 attempts to access either drive result in a delay until the controller drops to PIO, and then operations resume. A soft reboot and things work in UDMA mode again. Also tried UDMA33 and UDMA66 with no change. I also tried "atacontrol reinit 0" with no help. Theories when I search the web for "fallback to PIO mode" include: - bad disks - something to do with thermal recalibration I don't believe the problems are bad disks, as the slave drops to PIO after the master does, and I can't get in back to UDMA, other than by soft reboot. Plus I see the problem on 6 of 8 disks. The problem is very repeatable. Can anyone offer any ideas, or suggest investigative steps ? I have a system in PIO mode right now. Thanks, -- Bruce Campbell Engineering Computing CPH-2374B University of Waterloo (519)888-4567 ext 5889 ---------------------------------------- This mail sent through www.mywaterloo.ca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message From owner-freebsd-hardware Tue Dec 31 13:16:30 2002 Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6F1437B406 for ; Tue, 31 Dec 2002 13:16:29 -0800 (PST) Received: from mail.engr.ucsb.edu (mail.engr.ucsb.edu [128.111.53.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9010D43ED8 for ; Tue, 31 Dec 2002 13:16:29 -0800 (PST) (envelope-from shvetima@engineering.ucsb.edu) Received: from ecipc056.engr.ucsb.edu ([128.111.53.119]) by mail.engr.ucsb.edu with esmtp (Exim 4.12) id 18TTkP-0004Ly-00 for freebsd-hardware@freebsd.org; Tue, 31 Dec 2002 13:16:25 -0800 Date: Tue, 31 Dec 2002 13:15:46 -0800 (PST) From: Shvetima Gulati X-X-Sender: To: Message-ID: MIME-Version: 1.0 Subject: Blade servers and BSD (fwd) Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=8.0 tests=none version=2.31 X-Spam-Level: Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi all, We are planning on purchasing blade servers for our datacenter. We want to run FreeBSD on these. We are currently considering looking at Dell PowerEdge 1655MC, IBM Bladecenter, RLX serverblade and HP Proliant BLp series. If anyone has used any of these machines with FreeBSD, we would be happy to know about your experiences and recommendations. Thanks for your time, -Shvetima. P.s. Please cc me on the reply. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message From owner-freebsd-hardware Tue Dec 31 13:23:29 2002 Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0FA937B401; Tue, 31 Dec 2002 13:23:25 -0800 (PST) Received: from tomts11-srv.bellnexxia.net (tomts11.bellnexxia.net [209.226.175.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1112C43ED4; Tue, 31 Dec 2002 13:23:25 -0800 (PST) (envelope-from matt@gsicomp.on.ca) Received: from xena.gsicomp.on.ca ([65.95.176.107]) by tomts11-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP id <20021231212324.EZRF8221.tomts11-srv.bellnexxia.net@xena.gsicomp.on.ca>; Tue, 31 Dec 2002 16:23:24 -0500 Received: from hermes (hermes.gsicomp.on.ca [192.168.0.18]) by xena.gsicomp.on.ca (8.11.3/8.11.3) with SMTP id gBVLLup41930; Tue, 31 Dec 2002 16:21:57 -0500 (EST) (envelope-from matt@gsicomp.on.ca) Message-ID: <025701c2b112$ddfbf580$1200a8c0@gsicomp.on.ca> From: "Matthew Emmerton" To: "Bruce Campbell" , , Cc: References: <1041368236.3e1204ac45da5@www.nexusmail.uwaterloo.ca> Subject: Re: ata "fallback to PIO mode" on dual processor AMD systems Date: Tue, 31 Dec 2002 16:23:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [ cc'ing Soren since he's the ATA guru ] > I am seeing a problem with ata disks on 4 new systems, which > I believe is either a bug in the ata driver, or a problem with > the onboard IDE controller, or something else. Systems are as follows: > > Motherboard: ASUS A7M266-D > CPUs : 2 x 2000+ AMD MP > Memory : 2 x 512MB Crucial part: CT6472Y265 > > Disks (all UDMA100): > > Master Slave > System 1: WDC WD400BB WDC WD1000BB > System 2: WDC WD400BB WDC WD1000BB > System 3: WDC WD400BB WDC WD800BB > System 4: WDC WD400BB Maxtor 98196H8 > > Kernel : 4.7-RELEASE, custom kernel (compared to GENERIC): > > commented out: > > cpu I386_CPU > cpu I486_CPU > > enabled > > options SMP # Symmetric MultiProcessor Kernel > options APIC_IO # Symmetric (APIC) I/O > > > I am running a test with "dbench" (/usr/ports/benchmarks/dbench) > with a script which runs: > > dbench 1 > sleep for 5 minutes > dbench 2 > sleep for 5 minutes > dbench 3 > ... > > to simulate 1,2,3... clients. > > The following has happened on systems 2,3 and 4, after about 15 hours > of running the test: > > Dec 30 23:26:59 ecserv13 /kernel: ad0: WRITE command timeout tag=0 serv=0 - > resetting > Dec 30 23:26:59 ecserv13 /kernel: ata0: resetting devices .. done > Dec 30 23:26:59 ecserv13 /kernel: ad0: WRITE command timeout tag=0 serv=0 > resetting > Dec 30 23:27:00 ecserv13 /kernel: ata0: resetting devices .. done > Dec 30 23:27:00 ecserv13 /kernel: ad0: WRITE command timeout tag=0 serv=0 > resetting > Dec 30 23:27:00 ecserv13 /kernel: ata0: resetting devices .. done > Dec 30 23:27:00 ecserv13 /kernel: ad0: WRITE command timeout tag=0 serv=0 > resetting > Dec 30 23:27:00 ecserv13 /kernel: ad0: timeout waiting for cmd=ef s=d0 e=00 > Dec 30 23:27:00 ecserv13 /kernel: ad0: trying fallback to PIO mode > Dec 30 23:27:00 ecserv13 /kernel: ata0: resetting devices .. done > > The test continues to run with the ata controller in PIO mode, with > slower performance, and higher load average. > > Once the master drops to PIO, attempts to access the slave then cause > it to drop to PIO. > > If I run: > > atacontrol mode 0 UDMA100 UDMA100 > > attempts to access either drive result in a delay until the controller > drops to PIO, and then operations resume. A soft reboot and things > work in UDMA mode again. Also tried UDMA33 and UDMA66 with no change. > I also tried "atacontrol reinit 0" with no help. > > Theories when I search the web for "fallback to PIO mode" include: > > - bad disks > - something to do with thermal recalibration > > I don't believe the problems are bad disks, as the slave drops to PIO > after the master does, and I can't get in back to UDMA, other than by > soft reboot. Plus I see the problem on 6 of 8 disks. > > The problem is very repeatable. > > Can anyone offer any ideas, or suggest investigative steps ? I have a system > in PIO mode right now. The reason the slave drops to PIO after the master does is by design - the master and slave have to use the same signalling mode since they're on the same cable. (People often report lackluster performance of fast UDMA hard drives with non-UDMA CD-ROMs on the same channel.) Are you using 80-conductor cables on all your drives? These are required to get consistent high throughput, and running without them may cause the problems you're seeing. -- Matt Emmerton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message From owner-freebsd-hardware Tue Dec 31 13:51:19 2002 Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7161737B401; Tue, 31 Dec 2002 13:51:17 -0800 (PST) Received: from level.uwaterloo.ca (level.uwaterloo.ca [129.97.50.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D7B043EC5; Tue, 31 Dec 2002 13:51:16 -0800 (PST) (envelope-from bruce@engmail.uwaterloo.ca) Received: from level.uwaterloo.ca (localhost [127.0.0.1]) by level.uwaterloo.ca (8.12.3/8.12.3) with ESMTP id gBVLnw5n047159; Tue, 31 Dec 2002 16:49:58 -0500 (EST) (envelope-from bruce@engmail.uwaterloo.ca) Received: (from www@localhost) by level.uwaterloo.ca (8.12.3/8.12.3/Submit) id gBVLnv1N047158; Tue, 31 Dec 2002 16:49:57 -0500 (EST) X-Authentication-Warning: level.uwaterloo.ca: www set sender to bruce@engmail.uwaterloo.ca using -f Received: from 65.93.103.72 ( [65.93.103.72]) as user bruce@engmail.uwaterloo.ca by www.nexusmail.uwaterloo.ca with HTTP; Tue, 31 Dec 2002 16:49:57 -0500 Message-ID: <1041371397.3e121105cdf30@www.nexusmail.uwaterloo.ca> Date: Tue, 31 Dec 2002 16:49:57 -0500 From: Bruce Campbell To: Matthew Emmerton Cc: freebsd-hardware@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG, sos@FreeBSD.ORG Subject: Re: ata "fallback to PIO mode" on dual processor AMD systems References: <1041368236.3e1204ac45da5@www.nexusmail.uwaterloo.ca> <025701c2b112$ddfbf580$1200a8c0@gsicomp.on.ca> In-Reply-To: <025701c2b112$ddfbf580$1200a8c0@gsicomp.on.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 / FreeBSD-4.6.2 X-Originating-IP: 65.93.103.72 Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Quoting Matthew Emmerton : > [ cc'ing Soren since he's the ATA guru ] > > > Dec 30 23:27:00 ecserv13 /kernel: ad0: trying fallback to PIO mode > > Dec 30 23:27:00 ecserv13 /kernel: ata0: resetting devices .. done > > > > The test continues to run with the ata controller in PIO mode, with > > slower performance, and higher load average. > > > > Once the master drops to PIO, attempts to access the slave then cause > > it to drop to PIO. > > Are you using 80-conductor cables on all your drives? These are required to > get consistent high throughput, and running without them may cause the > problems you're seeing. Thanks for the information about the design of IDE etc, and the suggestion about the cables. I was about to shuffle things to get the disks onto separate channels, but I now see that would be a mistake as my CD drive would share a cable with a disk. Anyway, they all have the 80 conductor cable. I forgot to add some environmental and other information. The 4 AMD systems are in Aopen hx08 towers, with 400 watt power supplies, and 5 auxilliary fans (in addition to the power supply fan, and fan on each cpu). They are in an air conditioned machine room. The CPU and motherboard temperatures are within spec. I mention this as I note many reported AMD system problems traced to overheating. All drives are installed in removeable drive bays. I don't have the make/model on hand right now. They were $19 CAD. ($13USD). The low cost makes me suspicious now, but... I'm running the same tests on 4 single processor 2.4GHz Intel systems. They have not failed in this manner so far. Initially, I had 1GB memory modules in the AMD systems (I can't remember the make) and the systems froze and rebooted randomly. I moved to Crucial 512MB modules to cure that problem. ---------------------------------------- This mail sent through www.mywaterloo.ca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message From owner-freebsd-hardware Tue Dec 31 14:42:49 2002 Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64F4637B401 for ; Tue, 31 Dec 2002 14:42:48 -0800 (PST) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F77C43E4A for ; Tue, 31 Dec 2002 14:42:47 -0800 (PST) (envelope-from mike@sentex.net) Received: from house (cage.simianscience.com [64.7.134.1]) by smtp2.sentex.ca (8.12.6/8.12.6) with SMTP id gBVMgeAJ069965; Tue, 31 Dec 2002 17:42:40 -0500 (EST) (envelope-from mike@sentex.net) From: Mike Tancsa To: Bruce Campbell Cc: freebsd-hardware@freebsd.org Subject: Re: ata "fallback to PIO mode" on dual processor AMD systems Date: Tue, 31 Dec 2002 17:42:41 -0500 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 31 Dec 2002 15:57:16 -0500, in sentex.lists.freebsd.hardware you wrote: > >I am seeing a problem with ata disks on 4 new systems, which >I believe is either a bug in the ata driver, or a problem with >the onboard IDE controller, or something else. Systems are as follows: What does dmesg show for the ATA controller ? Also, what does atacontrol cap 0 0 atacontrol cap 0 1 atacontrol cap 1 0 atacontrol cap 1 1 show ? Do you have tags enabled ? My first guess is poor power supply or bad drives.... But if it goes 15hrs my guess bad sector on the disk. ---Mike Mike Tancsa (mike@sentex.net)=09 http://www.sentex.net/mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message From owner-freebsd-hardware Tue Dec 31 14:48:12 2002 Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA0DE37B401 for ; Tue, 31 Dec 2002 14:48:11 -0800 (PST) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CB2E43EB2 for ; Tue, 31 Dec 2002 14:48:11 -0800 (PST) (envelope-from mike@sentex.net) Received: from house (cage.simianscience.com [64.7.134.1]) by smtp2.sentex.ca (8.12.6/8.12.6) with SMTP id gBVMlrAJ092958; Tue, 31 Dec 2002 17:47:53 -0500 (EST) (envelope-from mike@sentex.net) From: Mike Tancsa To: Bruce Campbell Cc: freebsd-hardware@freebsd.org Subject: Re: ata "fallback to PIO mode" on dual processor AMD systems Date: Tue, 31 Dec 2002 17:47:54 -0500 Message-ID: References: <1041368236.3e1204ac45da5@www.nexusmail.uwaterloo.ca> <025701c2b112$ddfbf580$1200a8c0@gsicomp.on.ca> In-Reply-To: X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 31 Dec 2002 16:49:57 -0500, in sentex.lists.freebsd.hardware you wrote: > All drives are installed in removeable drive bays. I don't have the = make/model > on hand right now. They were $19 CAD. ($13USD). The low cost makes > me suspicious now, but... > possibly. If they are made by Startech, you will get the occasional bad one that will show similar behaviour. We make heavy use of 3ware cards = on our FreeBSD servers and they are much more sensitive to bad trays in our experience. We go through quite a few as we use pullouts on all our = boxes at the office and for customer servers we build. If possible, run the problem drive directly on the cable, or move the drives around to see if your problems follow the drives or the trays. ---Mike Mike Tancsa (mike@sentex.net)=09 http://www.sentex.net/mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message From owner-freebsd-hardware Tue Dec 31 19: 2:54 2002 Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 570DB37B401 for ; Tue, 31 Dec 2002 19:02:51 -0800 (PST) Received: from level.uwaterloo.ca (level.uwaterloo.ca [129.97.50.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8895B43EA9 for ; Tue, 31 Dec 2002 19:02:50 -0800 (PST) (envelope-from bruce@engmail.uwaterloo.ca) Received: from level.uwaterloo.ca (localhost [127.0.0.1]) by level.uwaterloo.ca (8.12.3/8.12.3) with ESMTP id h0131V5n050062; Tue, 31 Dec 2002 22:01:31 -0500 (EST) (envelope-from bruce@engmail.uwaterloo.ca) Received: (from www@localhost) by level.uwaterloo.ca (8.12.3/8.12.3/Submit) id h0131V4N050061; Tue, 31 Dec 2002 22:01:31 -0500 (EST) X-Authentication-Warning: level.uwaterloo.ca: www set sender to bruce@engmail.uwaterloo.ca using -f Received: from 65.93.103.72 ( [65.93.103.72]) as user bruce@engmail.uwaterloo.ca by www.nexusmail.uwaterloo.ca with HTTP; Tue, 31 Dec 2002 22:01:31 -0500 Message-ID: <1041390091.3e125a0b19c58@www.nexusmail.uwaterloo.ca> Date: Tue, 31 Dec 2002 22:01:31 -0500 From: Bruce Campbell To: Mike Tancsa Cc: freebsd-hardware@freebsd.org Subject: Re: ata "fallback to PIO mode" on dual processor AMD systems References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 / FreeBSD-4.6.2 X-Originating-IP: 65.93.103.72 Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Quoting Mike Tancsa : > On Tue, 31 Dec 2002 15:57:16 -0500, in sentex.lists.freebsd.hardware you > wrote: > > > > >I am seeing a problem with ata disks on 4 new systems, which > >I believe is either a bug in the ata driver, or a problem with > >the onboard IDE controller, or something else. Systems are as follows: > > What does dmesg show for the ATA controller ? atapci0: port 0xb800-0xb80f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ad0: 38166MB [77545/16/63] at ata0-master UDMA100 ad1: 76319MB [155061/16/63] at ata0-slave UDMA100 acd0: CDROM at ata1-master PIO4 > Also, what does > > atacontrol cap 0 0 ATA channel 0, Master, device ad0: ATA/ATAPI revision 5 device model WDC WD400BB-00DGA0 serial number WD-WMADK1157258 firmware revision 05.03E05 cylinders 16383 heads 16 sectors/track 63 lba supported 78165360 sectors lba48 not supported dma supported overlap not supported Feature Support Enable Value Vendor write cache yes yes read ahead yes yes dma queued no no 0/00 SMART yes no microcode download yes yes security yes no power management yes yes advanced power management no no 0/00 automatic acoustic management yes no 254/FE 128/80 > atacontrol cap 0 1 TA channel 0, Slave, device ad1: ATA/ATAPI revision 5 device model WDC WD800BB-00CAA1 serial number WD-WMA8E3816404 firmware revision 17.07W17 cylinders 16383 heads 16 sectors/track 63 lba supported 156301488 sectors lba48 not supported dma supported overlap not supported Feature Support Enable Value Vendor write cache yes yes read ahead yes yes dma queued no no 0/00 SMART yes no microcode download yes yes security yes no power management yes yes advanced power management no no 0/00 automatic acoustic management yes no 254/FE 128/80 > atacontrol cap 1 0 ATA channel 1, Master, device acd0: ATA/ATAPI revision 0 device model HL-DT-ST CD-ROM GCR-8520B serial number firmware revision 1.00 cylinders 0 heads 0 sectors/track 0 lba supported lba48 not supported dma supported overlap not supported Feature Support Enable Value Vendor write cache no no read ahead no no dma queued no no 0/00 SMART no no microcode download no no security no no power management no no advanced power management no no 0/00 automatic acoustic management no no 0/00 0/00 > atacontrol cap 1 1 ATA channel 1, Slave: no device present > > show ? Do you have tags enabled ? hw.ata.tags: 0 are tags a good thing ? ---------------------------------------- This mail sent through www.mywaterloo.ca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message From owner-freebsd-hardware Tue Dec 31 19: 9:43 2002 Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 236A437B401 for ; Tue, 31 Dec 2002 19:09:42 -0800 (PST) Received: from level.uwaterloo.ca (level.uwaterloo.ca [129.97.50.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52C1243E4A for ; Tue, 31 Dec 2002 19:09:41 -0800 (PST) (envelope-from bruce@engmail.uwaterloo.ca) Received: from level.uwaterloo.ca (localhost [127.0.0.1]) by level.uwaterloo.ca (8.12.3/8.12.3) with ESMTP id h0138M5n050101; Tue, 31 Dec 2002 22:08:22 -0500 (EST) (envelope-from bruce@engmail.uwaterloo.ca) Received: (from www@localhost) by level.uwaterloo.ca (8.12.3/8.12.3/Submit) id h0138MZb050100; Tue, 31 Dec 2002 22:08:22 -0500 (EST) X-Authentication-Warning: level.uwaterloo.ca: www set sender to bruce@engmail.uwaterloo.ca using -f Received: from 65.93.103.72 ( [65.93.103.72]) as user bruce@engmail.uwaterloo.ca by www.nexusmail.uwaterloo.ca with HTTP; Tue, 31 Dec 2002 22:08:22 -0500 Message-ID: <1041390502.3e125ba66487e@www.nexusmail.uwaterloo.ca> Date: Tue, 31 Dec 2002 22:08:22 -0500 From: Bruce Campbell To: Mike Tancsa Cc: freebsd-hardware@freebsd.org Subject: Re: ata "fallback to PIO mode" on dual processor AMD systems References: <1041368236.3e1204ac45da5@www.nexusmail.uwaterloo.ca> <025701c2b112$ddfbf580$1200a8c0@gsicomp.on.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 / FreeBSD-4.6.2 X-Originating-IP: 65.93.103.72 Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Curiously, the 4 Intel systems that are working without problems are UDMA33: atapci0: port 0xb800-0xb80f at device 2.5 on pci0 while the problematic AMD systems are UDMA100: atapci0: port 0xb800-0xb80f at device 7.1 on pci0 The removeable drive bays use a short piece of 80 conductor cable to go from a large centronics type connector to the drive. Maybe it is a stub matching problem. The boxes that these enclosures came in had a sticker which said "UDMA33/66/100" but under the sticker it just said "UDMA33/66". Maybe I was ripped off. Quoting Mike Tancsa : > On Tue, 31 Dec 2002 16:49:57 -0500, in sentex.lists.freebsd.hardware you > wrote: > > > > All drives are installed in removeable drive bays. I don't have the > make/model > > on hand right now. They were $19 CAD. ($13USD). The low cost makes > > me suspicious now, but... > > > > possibly. If they are made by Startech, you will get the occasional bad > one that will show similar behaviour. We make heavy use of 3ware cards on > our FreeBSD servers and they are much more sensitive to bad trays in our > experience. We go through quite a few as we use pullouts on all our boxes > at the office and for customer servers we build. If possible, run the > problem drive directly on the cable, or move the drives around to see if > your problems follow the drives or the trays. > > ---Mike > Mike Tancsa (mike@sentex.net) > http://www.sentex.net/mike > -- Bruce Campbell Engineering Computing CPH-2374B University of Waterloo (519)888-4567 ext 5889 ---------------------------------------- This mail sent through www.mywaterloo.ca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message From owner-freebsd-hardware Tue Dec 31 21:30: 1 2002 Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3581037B401; Tue, 31 Dec 2002 21:29:58 -0800 (PST) Received: from beaujolais.extremis.net (beaujolais.extremis.net [217.158.56.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F5B443E4A; Tue, 31 Dec 2002 21:29:57 -0800 (PST) (envelope-from gjvc@extremis.net) Received: from localhost (localhost.extremis.net [127.0.0.1]) by beaujolais.extremis.net (Postfix) with ESMTP id 789227250B; Wed, 1 Jan 2003 05:29:56 +0000 (UTC) Received: by beaujolais.extremis.net (Postfix, from userid 1010) id 08AF572506; Wed, 1 Jan 2003 05:29:56 +0000 (UTC) Date: Wed, 1 Jan 2003 05:29:56 +0000 From: "George J.V. Cox" To: freebsd-hardware@freebsd.org, freebsd-net@freebsd.org Subject: SOLVED: Broadcom BCM5703X Gigabit Ethernet woes Message-ID: <20030101052956.GA21888@beaujolais.extremis.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i X-Razor-id: 91159f1c1d78f960f778c5b354d74f5335743210 Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 24/12 14:20, George J.V. Cox wrote: > I have a Dell 1655MC blade server. It's a chassis of 6 PCs in a 3U > case. Each blade has two Broadcom BCM5703 interfaces. Unfortunately, > its behaviour is rather non-deterministic. Each blade has 2 BCM5703X chips. At least that's what it says on the chips themselves. However, at boot time the PCI subsystem IDs appear to match those of the BCM5702 chip. How confusing. What is even more confusing is that there appear to be different revisons of the chipsets in same set of 3 blades we received from Dell. This is also noticable by one of the blades having MAC addresses which differ in the first 3 octets. The 1655MC has an internal switch unit, which has 4 100Mb uplink ports to the outside world and six downlink ports to the blade servers. The downlink ports are fixed at 1000baseSX in the switch configuration and this cannot be changed. Hence, enabling the ten bit interface and forcing 1000baseSX mode on the host interfaces is the way to go. No MII bus probing is performed by the kernel and everything is peachy. Cursory testing shows that TCP transfer rates of about 50 Mbyte/second are possible between hosts in the same chassis. (The only tuning was to set the net.inet.tcp.sendspace and net.inet.tcp.recvspace sysctls to 100Kb) Here's some dmesg output when the patch below is applied: bge0: mem 0xed010000-0xed01ffff irq 7 at device 10.0 on pci1 bge0: Ethernet address: 00:06:5b:0e:6d:1c bge0: PCI subsystem ID is 0x00001646 bge1: mem 0xed000000-0xed00ffff irq 10 at device 11.0 on pci1 bge1: Ethernet address: 00:06:5b:0e:6d:1d bge1: PCI subsystem ID is 0x00001646 Values of 0x0126 and 0x0124 have also been seen. As I mentioned above, no MII probing is performed. # ifconfig bge0 bge0: flags=8843 mtu 1500 options=3 inet 10.2.10.51 netmask 0xffff0000 broadcast 10.2.255.255 ether 00:06:5b:0e:6d:1c media: Ethernet 1000baseSX status: active The media type and options need not be forcibly set to 1000baseSX and full-duplex respectively, as they have been above. Here is my patch against -STABLE which fixes the problem. Resolving the BCOM_SUBSYSID_UNKNOWN_* IDs to some sensible names is left as an exercise for the reader. :-) The original PR is i386/46484. best; gjvc --- if_bge.c.orig Tue Dec 31 01:21:41 2002 +++ if_bge.c Wed Jan 1 04:51:08 2003 @@ -1519,7 +1519,7 @@ u_int32_t command; struct ifnet *ifp; struct bge_softc *sc; - u_int32_t hwcfg = 0; + u_int32_t hwcfg = 0, pcissid = 0; u_int32_t mac_addr = 0; int unit, error = 0, rid; @@ -1701,9 +1701,19 @@ if ((ntohl(hwcfg) & BGE_HWCFG_MEDIA) == BGE_MEDIA_FIBER) sc->bge_tbi = 1; - /* The SysKonnect SK-9D41 is a 1000baseSX card. */ - if ((pci_read_config(dev, BGE_PCI_SUBSYS, 4) >> 16) == SK_SUBSYSID_9D41) - sc->bge_tbi = 1; + /* check for 1000baseSX cards detectable via their PCI subsystem IDs */ + pcissid = (pci_read_config(dev, BGE_PCI_SUBSYS, 4) >> 16); + printf("bge%d: PCI subsystem ID is 0x%08x\n", sc->bge_unit, pcissid); + + switch (pcissid) { + case SK_SUBSYSID_9D41: + case BCOM_SUBSYSID_UNKNOWN_0x0124: + case BCOM_SUBSYSID_UNKNOWN_0x0126: + case BCOM_SUBSYSID_UNKNOWN_0x1646: + printf("bge%d: 1000baseSX capable; enabling TBI\n", sc->bge_unit); + sc->bge_tbi = 1; + default: + } if (sc->bge_tbi) { ifmedia_init(&sc->bge_ifmedia, IFM_IMASK, --- if_bgereg.h.orig Sun Dec 29 10:50:06 2002 +++ if_bgereg.h Wed Jan 1 04:50:56 2003 @@ -1787,6 +1787,10 @@ #define BCOM_DEVICEID_BCM5702X 0x16A6 #define BCOM_DEVICEID_BCM5703X 0x16A7 +#define BCOM_SUBSYSID_UNKNOWN_0x0124 0x0124 +#define BCOM_SUBSYSID_UNKNOWN_0x0126 0x0126 +#define BCOM_SUBSYSID_UNKNOWN_0x1646 0x1646 + /* * Alteon AceNIC PCI vendor/device ID. */ -- [gjvc] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message