From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 01:47:27 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A05B116A4CE for ; Sun, 6 Jun 2004 01:47:26 -0700 (PDT) Received: from email11.aon.at (WARSL402PIP7.highway.telekom.at [195.3.96.94]) by mx1.FreeBSD.org (Postfix) with SMTP id 6ED7043D1D for ; Sun, 6 Jun 2004 01:47:25 -0700 (PDT) (envelope-from shoesoft@gmx.net) Received: (qmail 174304 invoked from network); 6 Jun 2004 08:47:11 -0000 Received: from m095p020.dipool.highway.telekom.at (HELO ?62.46.1.212?) ([62.46.1.212]) (envelope-sender ) by qmail2rs.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 6 Jun 2004 08:47:11 -0000 From: Stefan Ehmann To: current@freebsd.org Content-Type: text/plain Message-Id: <1086511629.1509.13.camel@taxman> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 06 Jun 2004 10:47:09 +0200 Content-Transfer-Encoding: 7bit Subject: esd leaking file descriptors X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 08:47:27 -0000 When i run mpg321 -o esd foo.mp3 (or any other player that uses esd as output) lsof shows an increasing number of open files. It increases at a rate of about 50 files per second. System will run out of file descriptor eventually. I run CURRENT from yesterday. esound-0.2.34 A sound library for enlightenment package The same version of esound runs fine on another pc running an older current. So this seems to be a problem of current rather than esd. From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 02:39:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7EBE516A4CE for ; Sun, 6 Jun 2004 02:39:58 -0700 (PDT) Received: from mail.tpgi.com.au (mail.tpgi.com.au [203.12.160.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E6F443D45 for ; Sun, 6 Jun 2004 02:39:57 -0700 (PDT) (envelope-from agh@tpg.com.au) Received: from [192.168.0.4] (220-244-72-6.tpgi.com.au [220.244.72.6]) by mail.tpgi.com.au (8.12.10/8.12.10) with ESMTP id i569do6A023464 for ; Sun, 6 Jun 2004 19:39:51 +1000 From: "Alastair G. Hogge" To: freebsd-current@FreeBSD.ORG Date: Sun, 6 Jun 2004 19:40:15 +1000 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406061940.15400.agh@tpg.com.au> X-TPG-Antivirus: Passed Subject: Custom kernels causing Promise ATA RAID to go down. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 09:39:58 -0000 Hello, For a couple of weeks now I've been having problems with my custom kernel crashing the system. I've re-cvsup'd and nuked /usr/obj and rebuild worlds and kernels alike, but the only solution is to boot with a generic kernel....which smurfs me to tears The problem is that my kernel keeps causing ATA DMA READ/WRITE errors and then eventually causing my RAID array to go down, thus needing a deletation and re-definition thru the BIOS. Plus uncountable fsck run thru. I've not been able to catch any of the error messages but I did see a error reference to a ffs/softupdate source code file. I don't know how to capture and store the output. As the system just basicly hangs and freezes the keyboard. Most of the time I've been X, which can only be solved with a hard reboot. Running a GENERIC kernel is (with debuging things removed) is so slow. X/KDE performs so poorly now. My dmesg -v cane be found here: users.tpg.com.au/adsl55l9/dmesg.out Custom kernel conf: users.tpg.com.au/adsl55l9/NOVA Boot loader.conf users.tpg.com.au/adsl55l9/loader.conf Thanks in advance. From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 03:31:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 835F116A4CE; Sun, 6 Jun 2004 03:31:12 -0700 (PDT) Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 983A243D58; Sun, 6 Jun 2004 03:31:11 -0700 (PDT) (envelope-from Alexander@Leidinger.net) Received: from fwd05.aul.t-online.de by mailout10.sul.t-online.com with smtp id 1BWuvl-0000Ki-01; Sun, 06 Jun 2004 12:31:09 +0200 Received: from Andro-Beta.Leidinger.net (STD3UGZa8eXOboXsbwMDvgHEzdsojw8J9NkBkj-FYpQEHFrZf2AqoK@[80.131.127.215]) by fmrl05.sul.t-online.com with esmtp id 1BWuvb-1MuoNc0; Sun, 6 Jun 2004 12:30:59 +0200 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) i56AUsLE097490; Sun, 6 Jun 2004 12:30:54 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Sun, 6 Jun 2004 12:32:24 +0200 From: Alexander Leidinger To: current@freebsd.org Message-Id: <20040606123224.46e27502@Magellan.Leidinger.net> X-Mailer: Sylpheed version 0.9.11claws (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Seen: false X-ID: STD3UGZa8eXOboXsbwMDvgHEzdsojw8J9NkBkj-FYpQEHFrZf2AqoK@t-dialin.net cc: sos@freebsd.org Subject: hang after after update: "adX: FAILURE - already active DMA on this device" (ICH5 system) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 10:31:12 -0000 Hi, after updating from a ~May 15 kernel to yesterdays kernel the system hangs while probing: ---snip--- ata3: reset tp1 mask=03 ostat0=d0 ostat1=00 ad3: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata3-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata3: reset tp2 mask=03 stat0=50 stat1=00 devices=0x1 ata3: resetting done .. ad3: pio=0x0c wdma=0x22 udma=0x46 cable=40pin ad3: FAILURE - SETFEATURES SET TRANSFER MODE status=51 error=4 ata3: device config done .. ad3: FAILURE - READ_DMA status=51 error=0 dma=0x06 LBA=0 ad2: FAILURE - already active DMA on this device ad2: setting up DMA failed ad2: TIMEOUT - READ_DMA retrying (2 retries left) LBA=63 ata2: reiniting channel .. ata2: reset tp1 mask=03 ostat0=d0 ostat1=00 ad2: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata2-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 mask=0x stat0=50 stat1=00 devices=0x1 ata2: resetting done .. ad2: pio=0x0c wdma=0x22 udma=0x46 cable=40pin ata2: device config done .. ad2: FAILURE - already active DMA on this device ad2: setting up DMA failed ad2: TIMEOUT - READ_DMA retrying (2 retries left) LBA=191 ---snip--- This is an ICH5 system: ---snip--- atapci0: port 0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf000 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: at 0x1f0 irq 14 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: at 0x170 irq 15 on atapci0 atapci1: port 0xd000-0xd00f,0xcc00-0xcc03,0xc800-0xc807,0xc400-0xc403,0xc000-0xc007 irq 18 at device 31.2 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xd000 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0xc000 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xc400 ata2: at 0xc000 on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0xc800 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xcc00 ata3: at 0xc800 on atapci1 ad0: 78167MB [158816/16/63] at ata0-master UDMA100 ata1-master: DMA limited to UDMA33, non-ATA66 cable or device ad1: 19547MB [39714/16/63] at ata1-master UDMA33 acd0: DVDROM at ata1-slave PIO4 ad2: 78167MB [158816/16/63] at ata2-master SATA150 ad3: 78167MB [158816/16/63] at ata3-master SATA150 ---snip--- The CPU is with HT, but SMP is disabled in the loader. Any ideas? Bye, Alexander. -- I'm available to get hired (preferred in .lu). http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 03:46:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB5C816A4CE for ; Sun, 6 Jun 2004 03:46:15 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id CDEF843D55 for ; Sun, 6 Jun 2004 03:46:14 -0700 (PDT) (envelope-from tomonage2@gmx.de) Received: (qmail 31639 invoked by uid 65534); 6 Jun 2004 10:46:13 -0000 Received: from pD9E77456.dip.t-dialin.net (EHLO [192.168.0.196]) (217.231.116.86) by mail.gmx.net (mp009) with SMTP; 06 Jun 2004 12:46:13 +0200 X-Authenticated: #7843803 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sun, 06 Jun 2004 12:46:09 +0200 From: Jonathan Weiss To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Loading the PF ruleset fails due to ppp X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 10:46:16 -0000 Hi folks, I updated my 5.2.1 box to current today und changed from the PF-port to the new base-PF. Everything went fine, but when I rebooted the box, it hangs when samba was starting up. The problem was, that samba could not bind to its ports due to the default pf rulesset being loaded (only ssh-in is allowed). The problem originates in the fact, that I have a DSl modem and pppd connects on startup. Because I get only a dynamic IP, I use such statements in my ruleset : pass in on $tun_if inet proto tcp from any to ($tun_if) port 22 flags S/SA modulate state label The ($tun_if) gives me the current IP of the tun0-interface and this is often used by users with dynamic Ips. The problem is, that ppp is not fast enough for PF. PF is starting up before ppp gets an IP for tun0, so loading the ruleset fails. While using the PF-port, the time lag between starting ppp and PF was big enough, as PF was started whith the other third-party tools. With PF now in the basesystem, it is too fast for ppp. Inserting a "sleep 10" in the pf_start()-function in /etc/rc.d/pf solved my problem, as PF waits 10 seconds before loading the ruleset and ppp now gets the dynamic IP in time. Could we add the "sleep 10" or maybe a "sleep 5" in this function? I'm sure when current become 5.3 I'll be not alone with my problem. Greets, Jonathan Weiss From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 04:24:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDD2A16A4CF for ; Sun, 6 Jun 2004 04:24:44 -0700 (PDT) Received: from pcat.heimat.gr.jp (catv-118-241.tees.ne.jp [203.141.118.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id A944243D2D for ; Sun, 6 Jun 2004 04:24:43 -0700 (PDT) (envelope-from nakaji@tutrp.tut.ac.jp) Received: from xa12.heimat.gr.jp (xa12.heimat.gr.jp [202.216.136.35]) by pcat.heimat.gr.jp (8.12.11/8.12.11) with ESMTP id i56BOc4m013502 for ; Sun, 6 Jun 2004 20:24:38 +0900 (JST) (envelope-from nakaji@tutrp.tut.ac.jp) To: freebsd-current@freebsd.org From: NAKAJI Hiroyuki MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Date: Sun, 06 Jun 2004 20:24:36 +0900 Message-ID: <867julgc97.fsf@xa12.heimat.gr.jp> User-Agent: T-gnus/6.17.3 (based on No Gnus v0.3) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Subject: [pc98] recent current kernel gets fatal trap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 11:24:45 -0000 Hi, I'm still using old current kernel on my PC-9821Xa12/C8, FreeBSD xa12.heimat.gr.jp 5.2-CURRENT FreeBSD 5.2-CURRENT #2: Sun Jan 4 12:30:30 JST 2004 root@xa12.heimat.gr.jp:/usr/obj/usr/src/sys/NAKAJI i386 because recent current kernels always get fatal trap. I noticed this problem in March, and on the end of May, the problem still exists. For example, the kernel compiled on Sat May 29 09:40:01 JST 2004 gets Fatal trap 12 just after detection of ad1. I'm not sure this is because of ata driver problem or not, but some FreeBSD/pc98 users say they don't have such problem because their pc98 is all SCSI. Is this pc98 specific ata problem? --->8------>8------>8------>8------>8------>8------>8------>8--- Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1994-2004 FreeBSD(98) porting team. Copyright (c) 1992 A.Kojima F.Ukai M.Ishii (KMC). Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.2-CURRENT #55: Sat May 29 09:40:01 JST 2004 root@xa12.heimat.gr.jp:/usr/obj/usr/src/sys/NAKAJI Preloaded elf kernel "/boot/kernel/kernel" at 0xc08c8000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc08c80d8. Calibrating clock(s) ... i8254 clock: 2457608 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 2457600 Hz quality 0 Calibrating TSC clock ... TSC clock: 331784183 Hz CPU: AMD-K6(tm) 3D processor (331.78-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x58c Stepping = 12 Features=0x8021bf AMD Features=0x80000800 Data TLB: 128 entries, 2-way associative Instruction TLB: 64 entries, 1-way associative L1 data cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative L1 instruction cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative Write Allocate Disable real memory = 134217728 (128 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009ffff, 651264 bytes (159 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c26000 - 0x0000000007d8dfff, 118915072 bytes (29032 pages) avail memory = 121790464 (116 MB) bios32: Found BIOS32 Service Directory header at 0xc00f4c40 bios32: Entry = 0xf5612 (c00f5612) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xd90f0+0x1c52b pnpbios: Found PnP BIOS data at 0xc00f51b0 pnpbios: Entry = d8000:3a Rev = 1.0 pnpbios: OEM ID 38394350 Other BIOS signatures found: wlan: <802.11 Link Layer> null: mem: K6-family MTRR support enabled (2 registers) random: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface pci_open(1): mode 1 addr port (0x0cf8) is 0x80000064 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=00071004) pcibios: BIOS_PRESENT call failed pcib0: at pcibus 0 on motherboard pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x1004, dev=0x0007, revid=0x01 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2280, cachelnsz=0 (dwords) lattimer=0x10 (480 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1033, dev=0x0001, revid=0x02 bus=0, slot=6, func=0 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x010f, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1033, dev=0x0009, revid=0x01 bus=0, slot=7, func=0 class=03-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 1, range 32, base 20000000, size 22, enabled map[14]: type 1, range 32, base 20400000, size 16, enabled found-> vendor=0x1023, dev=0x9660, revid=0xd3 bus=0, slot=8, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0002, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[10]: type 1, range 32, base 20410000, size 14, enabled map[14]: type 3, range 32, base 20800000, size 23, enabled found-> vendor=0x102b, dev=0x0519, revid=0x01 bus=0, slot=13, func=0 class=03-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0082, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[10]: type 4, range 32, base 00006000, size 8, enabled map[14]: type 1, range 32, base 20414000, size 8, enabled map[18]: type 1, range 32, base 20415000, size 12, enabled found-> vendor=0x1000, dev=0x000f, revid=0x03 bus=0, slot=14, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0157, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x60 (2880 ns), mingnt=0x11 (4250 ns), maxlat=0x40 (16000 ns) intpin=a, irq=10 PCI-ISA bridge with incorrect subclass 0x80 PCI-ISA bridge with incorrect subclass 0x80 isab0: at device 6.0 on pci0 isa0: on isab0 pci0: at device 7.0 (no driver attached) pci0: at device 8.0 (no driver attached) pci0: at device 13.0 (no driver attached) sym0: <875> port 0x6000-0x60ff mem 0x20415000-0x20415fff,0x20414000-0x204140ff irq 10 at device 14.0 on pci0 sym0: Reserved 0x100 bytes for rid 0x14 type 3 at 0x20414000 sym0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0x20415000 sym0: Symbios NVRAM, ID 7, Fast-20, SE, NO parity sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. sym0: [GIANT-LOCKED] cpu0 on motherboard Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 pnpbios: error 0/82 getting device count/size limit pnpbios: 1 devices, largest 0 bytes pnpbios: error 0x82 fetching node 0 gdc: gdc0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices atacbus0 at port 0x432,0x74c,0x640-0x64f irq 9 on isa0 atacbus0: [MPSAFE] ata0: reset tp1 mask=03 ostat0=50 ostat1=50 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 mask=03 stat0=50 stat1=50 devices=0x3 ata0 at bank 0 on atacbus0 ata0: [MPSAFE] ata1: reset tp1 mask=03 ostat0=10 ostat1=00 ata1-master: stat=0x10 err=0x01 lsb=0x14 msb=0xeb ata1-slave: stat=0x00 err=0x01 lsb=0xff msb=0xff ata1: reset tp2 mask=03 stat0=10 stat1=00 devices=0x4 ata1 at bank 1 on atacbus0 ata1: [MPSAFE] ed9 at port 0x7d0-0x7df,0x3d0-0x3df irq 3 flags 0xb00000 on isa0 ed9: [GIANT-LOCKED] ed9: bpf attached ed9: Ethernet address: 00:80:4c:20:a1:6b type CNET98E/L (16 bit) fdc0 at port 0x4be,0xbe,0x94,0x92,0x90 irq 11 drq 2 on isa0 fd0: <1.44M FDD> on fdc0 drive 0 gdc0: at port 0xaf,0xad,0xab,0xa9,0xa7,0xa5,0xa3,0xa1,0x7e,0x7c,0x7a,0x78,0x76,0x74,0x72,0x70,0x9ae,0x9ac,0x9aa,0x9a8,0x9a6,0x9a4,0x9a2,0x9a0,0x4ae,0x4ac,0x4aa,0x4a8,0x4a6,0x4a4,0x4a2,0x4a0,0xae,0xac,0xaa,0xa8,0xa6,0xa4,0xa2,0xa0,0x6e,0x6c,0x6a,0x68,0x66,0x64,0x62,0x60 iomem 0xe0000-0xe7fff,0xa8000-0xbffff,0xa0000-0xa4fff on isa0 fb0: gdc0, gdc, type:PC-98x1 (6), flags:0x700c3 fb0: port:0x60-0x6f, crtc:0x60, mem:0xa0000 0x48000 fb0: init mode:98, bios mode:98, current mode:98 fb0: window:0xc00a0000 size:32k gran:32k, buf:0 size:0k mse0: at port 0x7fdf,0x7fdd,0x7fdb,0x7fd9 irq 13 on isa0 olpt0 failed to probe at port 0x40 on isa0 pcic0 failed to probe at port 0x3e0 on isa0 pckbd0: at port 0x43,0x41 irq 1 on isa0 kbd0 at pckbd0 kbd0: pckbd0, generic (0), config:0x0, flags:0x1d0000 Found OPTi device OPTi930 mss_detect() - Detected OPTi930 pcm0: at port 0xf8f-0xf97,0xe0e,0xf40-0xf47 irq 12 drq 1 flags 0x1b000 on isa0 drq/irq conf 22 pcm0: [GIANT-LOCKED] pcm0: sndbuf_setmap 188000, 1000; 0xc8ca5000 -> 188000 pcm0: sndbuf_setmap 189000, 1000; 0xc8ca6000 -> 189000 ppc0: parallel port found at 0x140 ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0: at port 0x140-0x147 irq 14 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: on isa0 sc0: PC-98x1 <16 virtual consoles, flags=0x0> sc0: fb0, kbd0, terminal emulator: sck (syscons kanji terminal) sio0 at port 0x30 irq 4 on isa0 sio0: type (internal fifo v-fast) sio1: irq maps: 0xc081 0xc0a1 0xc081 0xc081 sio1 at port 0x238-0x23f irq 5 flags 0x12000010 on isa0 sio1: type 16550A, console isa_probe_children: probing PnP devices BIOS Geometries: 0:2fe30811 0..12259=12260 cylinders, 0..8=9 heads, 1..17=17 sectors 1:f2a70811 0..62119=62120 cylinders, 0..8=9 heads, 1..17=17 sectors 2:80c30820 0..32963=32964 cylinders, 0..8=9 heads, 1..32=32 sectors 3:c1aa0820 0..49578=49579 cylinders, 0..8=9 heads, 1..32=32 sectors 4:e5040880 0..58628=58629 cylinders, 0..8=9 heads, 1..128=128 sectors 5:004f020f 0..79=80 cylinders, 0..2=3 heads, 1..15=15 sectors 6:004f020f 0..79=80 cylinders, 0..2=3 heads, 1..15=15 sectors 7:004f020f 0..79=80 cylinders, 0..2=3 heads, 1..15=15 sectors 0 accounted for Device configuration finished. procfs registered Timecounter "TSC" frequency 331784183 Hz quality 800 Timecounters tick every 10.000 msec lo0: bpf attached Stack backtrace: backtrace(0,c07ddf8c,c0c21cac,c0573dcc,c07de0a0) at backtrace+0x12 sched_switch(c07de0a0) at sched_switch+0x6b mi_switch(1,c07de0a0,1,c0c21ccc,c058d05b) at mi_switch+0x1a0 sleepq_switch(c1fd706c) at sleepq_switch+0x135 sleepq_wait(c1fd706c,0,c1fd706c,c1fd7048,c071eaf8) at sleepq_wait+0xb cv_wait(c1fd706c,c1fd7048,c1fd7048,1,c0c21d2c) at cv_wait+0x102 _sema_wait(c1fd7048,0,0,c1fd7000,c0c21d4c) at _sema_wait+0x4a ata_queue_request(c1fd7000,c,ec57bb0c,c129a600,0) at ata_queue_request+0x1e1 ata_getparam(c129a6dc,ec) at ata_getparam+0x9a ata_identify_devices(c129a600) at ata_identify_devices+0x21 ata_boot_attach(0) at ata_boot_attach+0x27 run_interrupt_driven_config_hooks(0,c1ec00,c1e000,0,c0434d00) at run_interrupt_driven_config_hooks+0x18 mi_startup() at mi_startup+0x96 begin() at begin+0x2c ata0-slave: pio=0x0c wdma=0x22 udma=0x42 cable=40pin ata0-master: pio=0x0b wdma=0x21 udma=0xffffffff cable=40pin ad0: ATA-0 disk at ata0-master ad0: 814MB (1667232 sectors), 12259 C, 8 H, 17 S, 512 B ad0: 1 secs/int, 1 depth queue, PIO3 GEOM: new disk ad0 PC98 Slice 1 on ad0: 0000 94 c4 00 00 00 00 01 00 00 00 01 00 00 00 e2 2f |.............../| 0010 46 72 65 65 42 53 44 00 00 00 00 00 00 00 00 00 |FreeBSD.........| [0] mid:148(0x94) sid:196(0xc4) s:1/0/0 e:12258/0/0 sname:FreeBSD PC98 Slice 2 on ad0: 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| [1] mid:0(0x0) sid:0(0x0) s:0/0/0 e:0/0/0 sname: PC98 Slice 3 on ad0: 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| [2] mid:0(0x0) sid:0(0x0) s:0/0/0 e:0/0/0 sname: PC98 Slice 4 on ad0: 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| [3] mid:0(0x0) sid:0(0x0) s:0/0/0 e:0/0/0 sname: PC98 Slice 5 on ad0: 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| [4] mid:0(0x0) sid:0(0x0) s:0/0/0 e:0/0/0 sname: PC98 Slice 6 on ad0: 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| [5] mid:0(0x0) sid:0(0x0) s:0/0/0 e:0/0/0 sname: PC98 Slice 7 on ad0: 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| [6] mid:0(0x0) sid:0(0x0) s:0/0/0 e:0/0/0 sname: PC98 Slice 8 on ad0: 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| [7] mid:0(0x0) sid:0(0x0) s:0/0/0 e:0/0/0 sname: PC98 Slice 9 on ad0: 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| [8] mid:0(0x0) sid:0(0x0) s:0/0/0 e:0/0/0 sname: PC98 Slice 10 on ad0: 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| [9] mid:0(0x0) sid:0(0x0) s:0/0/0 e:0/0/0 sname: PC98 Slice 11 on ad0: 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| [10] mid:0(0x0) sid:0(0x0) s:0/0/0 e:0/0/0 sname: PC98 Slice 12 on ad0: 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| [11] mid:0(0x0) sid:0(0x0) s:0/0/0 e:0/0/0 sname: PC98 Slice 13 on ad0: 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| [12] mid:0(0x0) sid:0(0x0) s:0/0/0 e:0/0/0 sname: PC98 Slice 14 on ad0: 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| [13] mid:0(0x0) sid:0(0x0) s:0/0/0 e:0/0/0 sname: PC98 Slice 15 on ad0: 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| [14] mid:0(0x0) sid:0(0x0) s:0/0/0 e:0/0/0 sname: PC98 Slice 16 on ad0: 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| [15] mid:0(0x0) sid:0(0x0) s:0/0/0 e:0/0/0 sname: GEOM: Configure ad0s1, start 69632 length 853549056 end 853618687 ad1: ATA-3 disk at ata0-slave ad1: 4125MB (8448300 sectors), 62119 C, 8 H, 17 S, 512 B ad1: 16 secs/int, 1 depth queue, PIO4 ata1-master: pio=0x0c wdma=0x22 udma=0x42 cable=40pin kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8:0xc058ea58 stack pointer = 0x10:0xc864cc70 frame pointer = 0x10:0xc864cc80 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 28 (swi8: tty:sio clock) kernel: type 12 trap, code=0 Stopped at propagate_priority+0x78: movl 0x24(%edi),%eax db> t propagate_priority(c12a1000,c07e5fb8,c07e1ba0,c12a1000,c07de0a2) at propagate_priority+0x78 turnstile_wait(0,c07e1ba0,c07de0a0) at turnstile_wait+0x2a4 _mtx_lock_sleep(c07e1ba0,0,0,0) at _mtx_lock_sleep+0xbd softclock(0) at softclock+0x210 ithread_loop(c129e500,c864cd48) at ithread_loop+0x1c1 fork_exit(c055b440,c129e500,c864cd48) at fork_exit+0x71 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc864cd7c, ebp = 0 --- db> c Fatal trap 12: page fault while in kernel mode fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8:0xc058ea58 stack pointer = 0x10:0xc864cc70 frame pointer = 0x10:0xc864cc80 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 28 (swi8: tty:sio clock) kernel: type 12 trap, code=0 Stopped at propagate_priority+0x78: movl 0x24(%edi),%eax db> t propagate_priority(c12a1000,c07e5fb8,c07e1ba0,c12a1000,c07de0a2) at propagate_priority+0x78 turnstile_wait(0,c07e1ba0,c07de0a0) at turnstile_wait+0x2a4 _mtx_lock_sleep(c07e1ba0,0,0,0) at _mtx_lock_sleep+0xbd softclock(0) at softclock+0x210 ithread_loop(c129e500,c864cd48) at ithread_loop+0x1c1 fork_exit(c055b440,c129e500,c864cd48) at fork_exit+0x71 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc864cd7c, ebp = 0 --- db> reset --->8------>8------>8------>8------>8------>8------>8------>8--- Kernel configuration: include GENERIC ident NAKAJI nooption INVARIANTS nooption INVARIANT_SUPPORT nooption WITNESS nooption WITNESS_SKIPSPIN options NETATALK options QUOTA options MSGBUF_SIZE=40960 device pcm -- NAKAJI Hiroyuki From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 04:36:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0044616A4CF for ; Sun, 6 Jun 2004 04:36:37 -0700 (PDT) Received: from mtaw4.prodigy.net (mtaw4.prodigy.net [64.164.98.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id B534F43D1D for ; Sun, 6 Jun 2004 04:36:36 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (0dcb38c480ef13c00900872181c12cb7@adsl-67-115-73-128.dsl.lsan03.pacbell.net [67.115.73.128]) by mtaw4.prodigy.net (8.12.10/8.12.10) with ESMTP id i56BaYfY014525; Sun, 6 Jun 2004 04:36:35 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id F37E554A93; Sun, 6 Jun 2004 04:36:34 -0700 (PDT) Date: Sun, 6 Jun 2004 04:36:34 -0700 From: Kris Kennaway To: some one Message-ID: <20040606113634.GA61092@xor.obsecurity.org> References: <20040605214444.GB65326@xor.obsecurity.org> <20040606104652.6757.qmail@web25202.mail.ukl.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline In-Reply-To: <20040606104652.6757.qmail@web25202.mail.ukl.yahoo.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org cc: Kris Kennaway Subject: Re: Network going nuts on -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 11:36:37 -0000 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 06, 2004 at 12:46:52PM +0200, some one wrote: > > I had this problem with SCHED_ULE on sparc64.=20 > > Reverting to SCHED_4BSD > > fixed it. Can you confirm that this works for you > > too? > >=20 > > Kris > >=20 >=20 > Hi Kris, >=20 > Thanks for the suggestion. I tried with SCHED_ULE and > managed to reproduce the problem quite quickly, so > that wasn't it. Do you mean SCHED_4BSD, or did you misread my email? Kris --+HP7ph2BbKc20aGI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAwwHCWry0BWjoQKURAn8PAJ46aKdxHQRhSASCI/lfHOlL+o7+cACfdGfV tUok7FRQPNPCDIYR2XsuXGo= =O7Gi -----END PGP SIGNATURE----- --+HP7ph2BbKc20aGI-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 04:50:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F25116A4CE; Sun, 6 Jun 2004 04:50:10 -0700 (PDT) Received: from av11-1-sn2.hy.skanova.net (av11-1-sn2.hy.skanova.net [81.228.8.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CCE543D2F; Sun, 6 Jun 2004 04:50:09 -0700 (PDT) (envelope-from manlix@demonized.net) Received: by av11-1-sn2.hy.skanova.net (Postfix, from userid 502) id B7CD437EA5; Sun, 6 Jun 2004 13:50:00 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av11-1-sn2.hy.skanova.net (Postfix) with ESMTP id A822237E80; Sun, 6 Jun 2004 13:50:00 +0200 (CEST) Received: from fisk.demonized.net (h137n2fls33o834.telia.com [213.66.186.137]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id F28BB37E46; Sun, 6 Jun 2004 13:49:59 +0200 (CEST) Received: from beard.demonized.net (beard.demonized.net [192.168.0.2]) by fisk.demonized.net (Postfix) with SMTP id 0B6CD6138; Sun, 6 Jun 2004 13:50:04 +0200 (CEST) Date: Sun, 6 Jun 2004 13:50:00 +0200 From: Johan Pettersson To: Alexander Leidinger Message-Id: <20040606135000.3b6f35c9.manlix@demonized.net> In-Reply-To: <20040606123224.46e27502@Magellan.Leidinger.net> References: <20040606123224.46e27502@Magellan.Leidinger.net> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i386-portbld-freebsd5.2.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: current@freebsd.org cc: sos@freebsd.org Subject: Re: hang after after update: "adX: FAILURE - already active DMA on this device" (ICH5 system) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 11:50:10 -0000 On Sun, 6 Jun 2004 12:32:24 +0200 Alexander Leidinger wrote: > Hi, > > after updating from a ~May 15 kernel to yesterdays kernel the system > hangs while probing: > ---snip--- > ata3: reset tp1 mask=03 ostat0=d0 ostat1=00 > ad3: stat=0x50 err=0x01 lsb=0x00 msb=0x00 > ata3-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 > ata3: reset tp2 mask=03 stat0=50 stat1=00 devices=0x1 > ata3: resetting done .. > ad3: pio=0x0c wdma=0x22 udma=0x46 cable=40pin > ad3: FAILURE - SETFEATURES SET TRANSFER MODE > status=51 error=4 ata3: device config done > .. ad3: FAILURE - READ_DMA status=51 error=0 dma=0x06 > LBA=0 ad2: FAILURE - already active DMA on this device > ad2: setting up DMA failed > ad2: TIMEOUT - READ_DMA retrying (2 retries left) LBA=63 > ata2: reiniting channel .. > ata2: reset tp1 mask=03 ostat0=d0 ostat1=00 > ad2: stat=0x50 err=0x01 lsb=0x00 msb=0x00 > ata2-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 > ata2: reset tp2 mask=0x stat0=50 stat1=00 devices=0x1 > ata2: resetting done .. > ad2: pio=0x0c wdma=0x22 udma=0x46 cable=40pin > ata2: device config done .. > ad2: FAILURE - already active DMA on this device > ad2: setting up DMA failed > ad2: TIMEOUT - READ_DMA retrying (2 retries left) LBA=191 > ---snip--- > > This is an ICH5 system: > ---snip--- > atapci0: port > 0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on > pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf000 > atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 > atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 > ata0: at 0x1f0 irq 14 on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 > atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 > ata1: at 0x170 irq 15 on atapci0 > atapci1: port > 0xd000-0xd00f,0xcc00-0xcc03,0xc800-0xc807,0xc400-0xc403,0xc000-0xc007 > irq 18 at device 31.2 on pci0 atapci1: Reserved 0x10 bytes for rid > 0x20 type 4 at 0xd000 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 > at 0xc000 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xc400 > ata2: at 0xc000 on atapci1 > atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0xc800 > atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xcc00 > ata3: at 0xc800 on atapci1 > > ad0: 78167MB [158816/16/63] at ata0-master UDMA100 > ata1-master: DMA limited to UDMA33, non-ATA66 cable or device > ad1: 19547MB [39714/16/63] at ata1-master UDMA33 > acd0: DVDROM at ata1-slave PIO4 > ad2: 78167MB [158816/16/63] at ata2-master SATA150 > ad3: 78167MB [158816/16/63] at ata3-master SATA150 > ---snip--- > > The CPU is with HT, but SMP is disabled in the loader. > > Any ideas? > > Bye, > Alexander. > > -- > I'm available to get hired (preferred in .lu). > I have these problems too. Look here http://docs.freebsd.org/cgi/mid.cgi?20040604144627.CFD7A613D I havn't got any response from the developers. Maybe Soren Schmidt have experienced the same thing on his system? He purchased a P4 HTT ICH5 system a while ago I think. ;) From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 05:03:14 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 600A416A4CE; Sun, 6 Jun 2004 05:03:14 -0700 (PDT) Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98B3443D49; Sun, 6 Jun 2004 05:03:13 -0700 (PDT) (envelope-from Alexander@Leidinger.net) Received: from fwd01.aul.t-online.de by mailout10.sul.t-online.com with smtp id 1BWwMq-0004zj-02; Sun, 06 Jun 2004 14:03:12 +0200 Received: from Andro-Beta.Leidinger.net (rI6YD4Ze8eGgVS-PHWCTKgIsBcD7z0f+Vs6OqlRwU-RiRZdeGX3WQQ@[80.131.123.52]) by fmrl01.sul.t-online.com with esmtp id 1BWwMe-2FiDdA0; Sun, 6 Jun 2004 14:03:00 +0200 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) i56C3HwL003526; Sun, 6 Jun 2004 14:03:17 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Sun, 6 Jun 2004 14:04:41 +0200 From: Alexander Leidinger To: Johan Pettersson Message-Id: <20040606140441.13e52926@Magellan.Leidinger.net> In-Reply-To: <20040606135000.3b6f35c9.manlix@demonized.net> References: <20040606123224.46e27502@Magellan.Leidinger.net> <20040606135000.3b6f35c9.manlix@demonized.net> X-Mailer: Sylpheed version 0.9.11claws (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Seen: false X-ID: rI6YD4Ze8eGgVS-PHWCTKgIsBcD7z0f+Vs6OqlRwU-RiRZdeGX3WQQ@t-dialin.net cc: current@freebsd.org cc: sos@freebsd.org Subject: Re: hang after after update: "adX: FAILURE - already active DMA on this device" (ICH5 system) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 12:03:14 -0000 On Sun, 6 Jun 2004 13:50:00 +0200 Johan Pettersson wrote: > I have these problems too. Look here > > http://docs.freebsd.org/cgi/mid.cgi?20040604144627.CFD7A613D But your system boots? My system doesn't, it hangs there. Bye, Alexander. -- I'm available to get hired (preferred in .lu). http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 05:09:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F66216A4CF; Sun, 6 Jun 2004 05:09:49 -0700 (PDT) Received: from av9-2-sn2.hy.skanova.net (av9-2-sn2.hy.skanova.net [81.228.8.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34BDE43D54; Sun, 6 Jun 2004 05:09:49 -0700 (PDT) (envelope-from manlix@demonized.net) Received: by av9-2-sn2.hy.skanova.net (Postfix, from userid 502) id 6898837EA6; Sun, 6 Jun 2004 14:09:30 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av9-2-sn2.hy.skanova.net (Postfix) with ESMTP id 55BFD37E60; Sun, 6 Jun 2004 14:09:30 +0200 (CEST) Received: from fisk.demonized.net (h137n2fls33o834.telia.com [213.66.186.137]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 4635337E43; Sun, 6 Jun 2004 14:09:30 +0200 (CEST) Received: from beard.demonized.net (beard.demonized.net [192.168.0.2]) by fisk.demonized.net (Postfix) with SMTP id 8AC326138; Sun, 6 Jun 2004 14:09:29 +0200 (CEST) Date: Sun, 6 Jun 2004 14:09:25 +0200 From: Johan Pettersson To: Alexander Leidinger Message-Id: <20040606140925.62d98ea9.manlix@demonized.net> In-Reply-To: <20040606140441.13e52926@Magellan.Leidinger.net> References: <20040606123224.46e27502@Magellan.Leidinger.net> <20040606135000.3b6f35c9.manlix@demonized.net> <20040606140441.13e52926@Magellan.Leidinger.net> X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i386-portbld-freebsd5.2.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: current@freebsd.org cc: sos@freebsd.org Subject: Re: hang after after update: "adX: FAILURE - already active DMA on this device" (ICH5 system) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 12:09:49 -0000 On Sun, 6 Jun 2004 14:04:41 +0200 Alexander Leidinger wrote: > On Sun, 6 Jun 2004 13:50:00 +0200 > Johan Pettersson wrote: > > > I have these problems too. Look here > > > > http://docs.freebsd.org/cgi/mid.cgi?20040604144627.CFD7A613D > > But your system boots? My system doesn't, it hangs there. > > Bye, > Alexander. > My systems hangs there to, IF not disabling apic at the boot prompt. Try that. set hint.apic.0.disabled=1 But after a while I get those messages again and the computer needs to be reset. From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 05:14:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADB0416A4D1 for ; Sun, 6 Jun 2004 05:14:09 -0700 (PDT) Received: from mail.dt.e-technik.uni-dortmund.de (krusty.dt.e-technik.Uni-Dortmund.DE [129.217.163.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1282343D41 for ; Sun, 6 Jun 2004 05:14:09 -0700 (PDT) (envelope-from ma@dt.e-technik.uni-dortmund.de) Received: from m2a2.dyndns.org (krusty.dt.e-technik.uni-dortmund.de [129.217.163.1])657A82F473 for ; Sun, 6 Jun 2004 14:13:52 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id C2F68BA059 for ; Sun, 6 Jun 2004 14:13:50 +0200 (CEST) Received: from merlin.emma.line.org ([127.0.0.1]) by localhost (m2a2.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 30935-03 for ; Sun, 6 Jun 2004 14:13:49 +0200 (CEST) Received: by merlin.emma.line.org (Postfix, from userid 500) id 0EACAB9EBB; Sun, 6 Jun 2004 14:13:49 +0200 (CEST) To: freebsd-current@freebsd.org From: Matthias Andree Date: Sun, 06 Jun 2004 14:13:49 +0200 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new at m2a2.dyndns.org Subject: xl(4) watchdog timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 12:14:10 -0000 Hello, I have CVSupped my -CURRENT i386 machine (CPUTYPE=athlon-xp) and rebooted and found the network non-functional, I get a message "xl0: watchdog timeout" (or similar) every couple of seconds. The card in use is a 3C900Combo, with the 10Base2/BNC port configured in /etc/rc.conf and that is fine with older -CURRENT kernels (that are still younger than 5.2.1-RELEASE). Any idea how to debug this? -- Matthias Andree Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 From owner-freebsd-current@FreeBSD.ORG Sat Jun 5 15:48:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B0D116A4CE for ; Sat, 5 Jun 2004 15:48:43 -0700 (PDT) Received: from mail.ciam.ru (mail.ciam.ru [213.147.57.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7205543D1D for ; Sat, 5 Jun 2004 15:48:42 -0700 (PDT) (envelope-from sem@ciam.ru) Received: from ppp8-72.pppoe.mtu-net.ru ([81.195.8.72] helo=ciam.ru) by mail.ciam.ru with asmtp (Exim 4.x) id 1BWjxw-0002bv-KR for current@freebsd.org; Sun, 06 Jun 2004 02:48:40 +0400 Message-ID: <40C24DC8.80907@ciam.ru> Date: Sun, 06 Jun 2004 02:48:40 +0400 From: Sergey Matveychuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 06 Jun 2004 05:15:30 -0700 Subject: CARP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2004 22:48:43 -0000 Do you plan to port CARP from OpenBSD? I see there is a patch for it: http://pf4freebsd.love2party.net/carp.html I'm intersted in it. And I'd like to help. But I'm not a network stack programming expert and I'm ready to pay a developer for this work. And I'm ready to test it. -- Sem. From owner-freebsd-current@FreeBSD.ORG Sat Jun 5 21:30:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1257216A4CE; Sat, 5 Jun 2004 21:30:09 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD01643D2D; Sat, 5 Jun 2004 21:30:08 -0700 (PDT) (envelope-from DougB@dougbarton.net) Received: from dougbarton.net (c-24-130-110-32.we.client2.attbi.com[24.130.110.32]) by comcast.net (rwcrmhc13) with ESMTP id <2004060604300801500mei90e> (Authid: domain_name_tsar); Sun, 6 Jun 2004 04:30:08 +0000 Message-ID: <40C29DCF.6080205@DougBarton.net> Date: Sat, 05 Jun 2004 21:30:07 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040418 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <20040604092313.GA12314@ip.net.ua> <40C0414F.4040108@freebsd.org> In-Reply-To: <40C0414F.4040108@freebsd.org> X-Enigmail-Version: 0.84.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 06 Jun 2004 05:15:30 -0700 cc: current@freebsd.org Subject: Re: Can the disklabel(8) link go now? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 04:30:09 -0000 Scott Long wrote: > My vote is 'not right now'. My vote is "never." I've already expressed why when this came up the last time, but I'll be happy to elaborate if anyone cares. Doug -- If you're never wrong, you're not trying hard enough From owner-freebsd-current@FreeBSD.ORG Sat Jun 5 21:43:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E86C16A4CE for ; Sat, 5 Jun 2004 21:43:26 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9123743D53 for ; Sat, 5 Jun 2004 21:43:26 -0700 (PDT) (envelope-from DougB@dougbarton.net) Received: from dougbarton.net (c-24-130-110-32.we.client2.attbi.com[24.130.110.32]) by comcast.net (rwcrmhc13) with ESMTP id <2004060604432601500mf441e> (Authid: domain_name_tsar); Sun, 6 Jun 2004 04:43:26 +0000 Message-ID: <40C2A0ED.7070509@DougBarton.net> Date: Sat, 05 Jun 2004 21:43:25 -0700 From: Doug Barton User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040418 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John-Mark Gurney References: <6B4993A2-A50E-11D8-B826-0003930F38CE@mithrandir.com> <20040513194709.GI601@funkthat.com> In-Reply-To: <20040513194709.GI601@funkthat.com> X-Enigmail-Version: 0.84.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 06 Jun 2004 05:15:30 -0700 cc: freebsd-current@freebsd.org cc: Scott Harrison Subject: Re: DNS problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 04:43:26 -0000 John-Mark Gurney wrote: > Most likely your named.root is out of date. Last week b.root-servers.net > changed IP address and took my dns server off line. For the record, there is no way that these two events could have been related. The IP actually updated in January, and the old IP is still answering queries (and will be for some time). Root server IP changes are very carefully orchestrated to avoid problems like the ones you are concerned about. HTH, Doug -- If you're never wrong, you're not trying hard enough From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 03:47:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A394316A4CE for ; Sun, 6 Jun 2004 03:47:10 -0700 (PDT) Received: from web25202.mail.ukl.yahoo.com (web25202.mail.ukl.yahoo.com [217.12.10.62]) by mx1.FreeBSD.org (Postfix) with SMTP id D23EA43D3F for ; Sun, 6 Jun 2004 03:47:09 -0700 (PDT) (envelope-from devnullaccount@yahoo.se) Message-ID: <20040606104652.6757.qmail@web25202.mail.ukl.yahoo.com> Received: from [213.100.201.151] by web25202.mail.ukl.yahoo.com via HTTP; Sun, 06 Jun 2004 12:46:52 CEST Date: Sun, 6 Jun 2004 12:46:52 +0200 (CEST) From: =?iso-8859-1?q?some=20one?= To: Kris Kennaway In-Reply-To: <20040605214444.GB65326@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sun, 06 Jun 2004 05:15:30 -0700 cc: freebsd-current@freebsd.org Subject: Re: Network going nuts on -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 10:47:10 -0000 --- Kris Kennaway skrev: > On Sat, Jun 05, 2004 at 01:22:33PM +0200, some one > wrote: > > Hi all! > > > > I have a Dell laptop running -CURRENT (built from > CVS > > May 18th, generic kernel except SMP disabled) > which > > most of the time works like a charm. But every now > and > > then when I boot it, the network get horrible > delays > > which makes it unusable. > > For example, a ping to the local network will give > > results like 100,93,83,73,63,53,43,33,23,13,100,93 > and > > continue to cycle in the same way. > > I had this problem with SCHED_ULE on sparc64. > Reverting to SCHED_4BSD > fixed it. Can you confirm that this works for you > too? > > Kris > Hi Kris, Thanks for the suggestion. I tried with SCHED_ULE and managed to reproduce the problem quite quickly, so that wasn't it. BR, Chris Höstrusk och grå moln - köp en resa till solen på Yahoo! Resor på adressen http://se.docs.yahoo.com/travel/index.html From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 05:18:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CC7716A4CE for ; Sun, 6 Jun 2004 05:18:29 -0700 (PDT) Received: from bbnest.net (v230102.ap.plala.or.jp [222.150.230.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D5BF43D41 for ; Sun, 6 Jun 2004 05:18:28 -0700 (PDT) (envelope-from bland@FreeBSD.org) Received: from FreeBSD.org (bland@localhost [127.0.0.1]) by bbnest.net (8.12.11/8.12.11) with ESMTP id i56CHPdI001227; Sun, 6 Jun 2004 21:17:26 +0900 (JST) (envelope-from bland@FreeBSD.org) Message-ID: <40C30B52.9080809@FreeBSD.org> Date: Sun, 06 Jun 2004 21:17:22 +0900 From: Alexander Nedotsukov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: "M. Warner Losh" cc: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Subject: Hangups, panics and X malfunction with today kernel. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 12:18:29 -0000 Guys, I'd like to inform you that recently (after May 23) something was changed in kernel code wich makes a lot of troubles on my machine. Panics during boot stage. Usually I see them inside cambio and once in taskqueue. Boot hangups during acd0 detection phase. I can see messages like bellow before hangup/panic: ... Jun 5 17:42:53 bbnest kernel: acd0: WARNING - MODE_SENSE_BIG read data overrun 34>18 Jun 5 17:42:53 bbnest kernel: acd0: FAILURE - MODE_SENSE_BIG HARDWARE ERROR asc=0xf1 ascq=0x63 error=0 Jun 5 17:42:53 bbnest kernel: acd0: WARNING - MODE_SENSE_BIG read data overrun 34>18 Jun 5 17:42:53 bbnest kernel: acd0: FAILURE - MODE_SENSE_BIG HARDWARE ERROR asc=0xf1 ascq=0x63 error=0 Jun 5 17:42:53 bbnest kernel: acd0: WARNING - MODE_SENSE_BIG read data overrun 34>18 ... And even system boots successfuly X (with nvidia driver) won't start. It stuck in text moderight after video memory probe with a lot of garbage on the screen. The only way I can go fother is to press c-a-d/power keys (i mean no console switching or X kill sequences availabe). There is kernel config and dmesgs (obtained with kernel from May 23 and today) available http://bbnest.net/~bland/sysinfo/ Not sure if this connected to the case but early last month I found myself unable to boot system with secondary IDE controller disabled in BIOS. It was ok before. All the best, Alexander. From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 05:23:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FBA916A4CE; Sun, 6 Jun 2004 05:23:41 -0700 (PDT) Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9A4A43D5D; Sun, 6 Jun 2004 05:23:40 -0700 (PDT) (envelope-from Alexander@Leidinger.net) Received: from fwd00.aul.t-online.de by mailout03.sul.t-online.com with smtp id 1BWwgZ-0002r6-00; Sun, 06 Jun 2004 14:23:35 +0200 Received: from Andro-Beta.Leidinger.net (JrWuw8ZLoeKz1RBh4bzvqELAz9FACdrtE4kgWiI0BWKo0uG2rHllEr@[80.131.123.52]) by fmrl00.sul.t-online.com with esmtp id 1BWwg5-27VV9U0; Sun, 6 Jun 2004 14:23:05 +0200 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) i56CNNve006395; Sun, 6 Jun 2004 14:23:23 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Sun, 6 Jun 2004 14:24:46 +0200 From: Alexander Leidinger To: current@freebsd.org Message-Id: <20040606142446.2900a97e@Magellan.Leidinger.net> X-Mailer: Sylpheed version 0.9.11claws (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Seen: false X-ID: JrWuw8ZLoeKz1RBh4bzvqELAz9FACdrtE4kgWiI0BWKo0uG2rHllEr@t-dialin.net cc: alc@freebsd.org Subject: comments in the page coloring options in /sys/conf/NOTES X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 12:23:41 -0000 Hi, the comments about the page coloring in the VM system seem to talk about L2/L1 cache size combinations, e.g. PQ_CACHESIZE=512 for a 512k/16k cache. The comment above the PQ_CACHESIZE line just talks about the size of the L2 cache. If it indeed talks about L2/L1 combinations, we should make it explicit. And what about a 512k/8k combination? If it just talks about the L2 cache size, what is the meaning of the second number? Bye, Alexander. -- I'm available to get hired (preferred in .lu). http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 06:33:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7BA216A4CE for ; Sun, 6 Jun 2004 06:33:19 -0700 (PDT) Received: from black3.imgsrc.co.jp (black3.imgsrc.co.jp [210.226.20.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED33643D39 for ; Sun, 6 Jun 2004 06:33:18 -0700 (PDT) (envelope-from kuriyama@imgsrc.co.jp) Received: from localhost (localhost [127.0.0.1]) by black3.imgsrc.co.jp (Postfix) with ESMTP id AF0E250B5D; Sun, 6 Jun 2004 22:33:17 +0900 (JST) Received: from black3.imgsrc.co.jp (black3.imgsrc.co.jp [IPv6:2001:218:422:2::9999]) by black3.imgsrc.co.jp (Postfix) with ESMTP id 6372B50881; Sun, 6 Jun 2004 22:33:16 +0900 (JST) Date: Sun, 06 Jun 2004 22:33:16 +0900 Message-ID: <7moenw4xr7.wl@black3.imgsrc.co.jp> From: Jun Kuriyama To: Kirk McKusick In-Reply-To: References: User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd 0.1 cc: freebsd-current@freebsd.org cc: Frode Nordahl Subject: Re: UFS snapshot deadlocks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 13:33:19 -0000 At Fri, 4 Jun 2004 15:06:55 +0000 (UTC), Frode Nordahl wrote: > The following is a 100% reproducible procedure to make it happen: > > Running 5.2-CURRENT #0: Fri Jun 4 15:07:54 CEST 2004 > > tty1: > while (1) > ls -la /usr/.snap > end > > tty2: > dump -0af /some/where -C 32 -L /dev/ad0s1f I can also reproduce this with above steps. FWIW, I did them with debug.snapdebug=1. It looks we are in the deadlock between mksnap_ffs and ls... ----- ffs_snapgone: lost snapshot vnode 1346 ffs_snapshot: busy vnode: 0xc1354924: tag ufs, type VDIR, usecount 1, writecount 0, refcount 1, flags (VV_ROOT|VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc12ff420 (pid 870) ino 2, on dev ad0s1e (4, 16) ### go to debugger ### db> ps pid proc uarea uid ppid pgrp flag stat wmesg wchan cmd 874 c12fec08 c9e16000 1021 562 874 0004002 [SLPQ ufs 0xc1356bd8][SLP] ls 870 c13f1370 ca01a000 0 869 866 0004002 [SLPQ ufs 0xc14ad3b8][SLP] mksnap_ffs ... db> show lockedvnods Locked vnodes 0xc14ad30c: tag ufs, type VDIR, usecount 3, writecount 0, refcount 2, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc12ff9a0 (pid 874) with 1 pending ino 3, on dev ad0s1e (4, 16) 0xc1356b2c: tag ufs, type VREG, usecount 2, writecount 0, refcount 16, lock type ufs: EXCL (count 1) by thread 0xc12ff420 (pid 870) with 1 pending ino 1347, on dev ad0s1e (4, 16) -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 11:20:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B716C16A4CE for ; Sun, 6 Jun 2004 11:20:07 -0700 (PDT) Received: from lakermmtao08.cox.net (lakermmtao08.cox.net [68.230.240.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3659043D2D for ; Sun, 6 Jun 2004 11:20:05 -0700 (PDT) (envelope-from conrads@cox.net) Received: from ip68-11-70-23.no.no.cox.net ([68.11.70.23]) by lakermmtao08.cox.netESMTP <20040606182004.RZPU5121.lakermmtao08.cox.net@ip68-11-70-23.no.no.cox.net>; Sun, 6 Jun 2004 14:20:04 -0400 Received: from ip68-11-70-23.no.no.cox.net (localhost.no.no.cox.net [127.0.0.1])i56IK4VL033816; Sun, 6 Jun 2004 13:20:04 -0500 (CDT) (envelope-from conrads@ip68-11-70-23.no.no.cox.net) Received: (from conrads@localhost)i56IJwFd033815; Sun, 6 Jun 2004 13:19:58 -0500 (CDT) (envelope-from conrads) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sun, 06 Jun 2004 13:19:58 -0500 (CDT) From: Conrad Sabatier To: freebsd-current@freebsd.org cc: =?iso-8859-1?Q?S=F8ren?= Schmidt Subject: One more followup on atapi issues (broken device now removed) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: conrads@cox.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 18:20:07 -0000 Just another quick update: I've now completely disabled the broken device, disconnecting it completely from the system. The system now boots and shuts down just fine with a world/kernel updated and built yesterday (Saturday, June 5), and the DVD-ROM on acd0 is working just fine. I may go buy a replacement for the burner later today, if I can find anything around here that I like. We'll see. Anyway, it looks like the current ata/atapi/atapicam code is fine. Just wanted to let you know, Soren. -- Conrad Sabatier - "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 11:35:05 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9E4016A4CE for ; Sun, 6 Jun 2004 11:35:05 -0700 (PDT) Received: from dsl-mail.kamp.net (mail.kamp-dsl.de [195.62.99.42]) by mx1.FreeBSD.org (Postfix) with SMTP id B6D3043D55 for ; Sun, 6 Jun 2004 11:35:04 -0700 (PDT) (envelope-from root@pukruppa.de) Received: (qmail 4759 invoked by uid 513); 6 Jun 2004 18:37:58 -0000 Received: from root@pukruppa.de by dsl-mail by uid 89 with qmail-scanner-1.21 Clear:RC:1(213.146.114.24):SA:0(-4.9/5.0):. Processed in 0.570118 secs); 06 Jun 2004 18:37:58 -0000 X-Spam-Status: No, hits=-4.9 required=5.0 Received: from unknown (HELO reverse-213-146-114-24.dialin.kamp-dsl.de) (213.146.114.24) by dsl-mail.kamp.net with SMTP; 6 Jun 2004 18:37:57 -0000 Date: Sun, 6 Jun 2004 20:35:18 +0200 (CEST) From: Peter Ulrich Kruppa X-X-Sender: root@pukruppa.net To: Kris Kennaway In-Reply-To: <20040605214557.GC65326@xor.obsecurity.org> Message-ID: <20040606202947.J844@pukruppa.net> References: <20040605092412.R856@pukruppa.net> <20040605214557.GC65326@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-current@freebsd.org Subject: Re: Today's -CURRENT doesn't boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 18:35:05 -0000 On Sat, 5 Jun 2004, Kris Kennaway wrote: > On Sat, Jun 05, 2004 at 09:32:25AM +0200, Peter Ulrich Kruppa wrote: >> Hi, >> >> this morning I cvsup'ped my sources and rebuilt my system. >> Booting stops with this message >> >> ------------------------------------------------ >> >> panic NG_MKMESSAGE() with how=M_DONTWAIT (1) >> at line 913 in file /usr/src/sys/netgraph/ng_pppoe.c >> Debugger("panic") >> Stopped at Debugger+0x45 xchgl %ebx, in_Debugger.0 >> db> > > Make sure you're not using stale modules. Without deeper knowledge of what I'm doing I removed the module ng_pppoe.ko from /boot/kernel . Now the system booted and rebooted fine, but I couldn't connect to the internet anymore (my ppp stup needs netgraph/pppoe stuff for this). What can I do now? Uli. > > Kris > +---------------------------+ | Peter Ulrich Kruppa | | Wuppertal | | Germany | +---------------------------+ From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 11:49:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9E5716A4CE for ; Sun, 6 Jun 2004 11:49:32 -0700 (PDT) Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B55543D58 for ; Sun, 6 Jun 2004 11:49:30 -0700 (PDT) (envelope-from j.e.drews@att.net) Received: from 204.127.135.58 ([204.127.135.58]) by worldnet.att.net (mtiwmhc12) with SMTP id <2004060618492911200jakage>; Sun, 6 Jun 2004 18:49:29 +0000 Received: from [64.105.56.145] by 204.127.135.58; Sun, 06 Jun 2004 18:49:27 +0000 From: j.e.drews@att.net To: Nate Lawson Date: Sun, 06 Jun 2004 18:49:27 +0000 Message-Id: <060620041849.21327.40C36736000B93F10000534F21602810609C990A9D0BD20AD206@att.net> X-Mailer: AT&T Message Center Version 1 (May 27 2004) X-Authenticated-Sender: ai5lLmRyZXdzQGF0dC5uZXQ= cc: current@freebsd.org Subject: Re: ACPI Error: AE_NO_HARDWARE_RESPONSE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 18:49:33 -0000 OK Nate: Hopefully I have gotten it right this time. The Regents of the University of California. All rights reserved. FreeBSD 5.2-CURRENT #0: Sat Jun 5 22:58:42 CDT 2004 root@notebook.silbsd.org:/usr/obj/usr/src/sys/NOTEBOOK Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a15000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a15244. I never could get it to laod at the prompt so I transfered the acpi.ko with debugging enabled into /boot/kernel. the new dmesg is here: http://www.silbsd.org/bugreports/acpi.dmesg2.txt Kind regards, Jonathan > On Sun, 6 Jun 2004 j.e.drews@att.net wrote: > > I have followed your instructions and the output of dmesg is here: > >d > This indicates you didn't copy acpi.ko to / and maybe copied acpi.kld. > Thus there is no debugging output. If it was acpi.ko, it would be labeled > "elf module" as below: > > > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a6127c. > ^^^^^^^^^^^^^^^^^^^ > > Since the kld was not the kernel module, your kernel went and loaded the > original acpi.ko from /boot/kernel, which doesn't have debugging enabled. > > Please check against the instructions I list again below: > > -Nate From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 12:15:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 46B3D16A4CE; Sun, 6 Jun 2004 12:15:31 -0700 (PDT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id CAA3F43D5A; Sun, 6 Jun 2004 12:15:30 -0700 (PDT) (envelope-from scottl@freebsd.org) Received: from freebsd.org (junior-wifi.samsco.home [192.168.0.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i56JMvcH043370; Sun, 6 Jun 2004 13:22:57 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <40C36D31.4010003@freebsd.org> Date: Sun, 06 Jun 2004 13:14:57 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@freebsd.org, current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org Subject: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 19:15:31 -0000 All, We are about 4-6 weeks away from starting the 5.3 release cycle. As it stands, KSE still only works reliably on i386. There are reports of significant instability on amd64, and it doesn't work at all on alpha and sparc64. I'm willing to drop the alpha requirement and maybe even the sparc64 requirement, but there absolutely will not be a 5.3 until amd64 is solid. Please contact myself, Dan Eischen, and David Xu if you are interested in helping out. Thanks, Scott From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 12:24:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFCB416A4CE for ; Sun, 6 Jun 2004 12:24:59 -0700 (PDT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 7C9C543D2D for ; Sun, 6 Jun 2004 12:24:59 -0700 (PDT) (envelope-from nate@root.org) Received: (qmail 66458 invoked by uid 1000); 6 Jun 2004 19:25:00 -0000 Date: Sun, 6 Jun 2004 12:25:00 -0700 (PDT) From: Nate Lawson To: j.e.drews@att.net In-Reply-To: <060620041849.21327.40C36736000B93F10000534F21602810609C990A9D0BD20AD206@att.net> Message-ID: <20040606122441.D66448@root.org> References: <060620041849.21327.40C36736000B93F10000534F21602810609C990A9D0BD20AD206@att.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: ACPI Error: AE_NO_HARDWARE_RESPONSE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 19:24:59 -0000 Closer. :) You need options DDB in your kernel. FreeBSD 5.2-CURRENT #0: Sat Jun 5 22:58:42 CDT 2004 root@notebook.silbsd.org:/usr/obj/usr/src/sys/NOTEBOOK Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a15000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a15244. link_elf: symbol db_readline undefined ^^^^^^^^^^^^^^ KLD file acpi.ko - could not finalize loading On Sun, 6 Jun 2004 j.e.drews@att.net wrote: > OK Nate: > > Hopefully I have gotten it right this time. > > The Regents of the University of California. All rights reserved. > FreeBSD 5.2-CURRENT #0: Sat Jun 5 22:58:42 CDT 2004 > root@notebook.silbsd.org:/usr/obj/usr/src/sys/NOTEBOOK > Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a15000. > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a15244. > > I never could get it to laod at the prompt so I transfered the acpi.ko with debugging enabled into /boot/kernel. > > the new dmesg is here: > http://www.silbsd.org/bugreports/acpi.dmesg2.txt > > Kind regards, > Jonathan > > > > On Sun, 6 Jun 2004 j.e.drews@att.net wrote: > > > I have followed your instructions and the output of dmesg is here: > > >d > > This indicates you didn't copy acpi.ko to / and maybe copied acpi.kld. > > Thus there is no debugging output. If it was acpi.ko, it would be labeled > > "elf module" as below: > > > > > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a6127c. > > ^^^^^^^^^^^^^^^^^^^ > > > > Since the kld was not the kernel module, your kernel went and loaded the > > original acpi.ko from /boot/kernel, which doesn't have debugging enabled. > > > > Please check against the instructions I list again below: > > > > -Nate > From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 12:35:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAAB016A4CE; Sun, 6 Jun 2004 12:35:10 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E32743D2F; Sun, 6 Jun 2004 12:35:10 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp50.pn.xcllnt.net (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.12.11/8.12.11) with ESMTP id i56JZAkK005117; Sun, 6 Jun 2004 12:35:10 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp50.pn.xcllnt.net (localhost [127.0.0.1]) i56JZA07095921; Sun, 6 Jun 2004 12:35:10 -0700 (PDT) (envelope-from marcel@dhcp50.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp50.pn.xcllnt.net (8.12.11/8.12.11/Submit) id i56JZAPL095920; Sun, 6 Jun 2004 12:35:10 -0700 (PDT) (envelope-from marcel) Date: Sun, 6 Jun 2004 12:35:10 -0700 From: Marcel Moolenaar To: Scott Long Message-ID: <20040606193510.GA95886@dhcp50.pn.xcllnt.net> References: <40C36D31.4010003@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40C36D31.4010003@freebsd.org> User-Agent: Mutt/1.4.2.1i cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 19:35:10 -0000 On Sun, Jun 06, 2004 at 01:14:57PM -0600, Scott Long wrote: > All, > > We are about 4-6 weeks away from starting the 5.3 release cycle. As it > stands, KSE still only works reliably on i386. I don't have any problems on ia64. > ... I'm willing to drop the alpha requirement and maybe even > the sparc64 requirement, but there absolutely will not be a 5.3 until > amd64 is solid. I think sparc64 should have KSE too. If we already accept that sparc64 is feature incomplete, we set/acknowledge a really bad precedence. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 12:40:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9772C16A4CE for ; Sun, 6 Jun 2004 12:40:11 -0700 (PDT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF66243D49 for ; Sun, 6 Jun 2004 12:40:10 -0700 (PDT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id E27F61FFDC1 for ; Sun, 6 Jun 2004 21:40:08 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id EC1171FF931; Sun, 6 Jun 2004 21:40:06 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id B5A311559F; Sun, 6 Jun 2004 19:38:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id A9F4015329 for ; Sun, 6 Jun 2004 19:38:14 +0000 (UTC) Date: Sun, 6 Jun 2004 19:38:14 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: FreeBSD current mailing list Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Subject: vfs_syscalls / fhstatfs / suser() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 19:40:11 -0000 Hi, if I am not wrong the part removed by the atatched diff is not needed because at the very beginning of the function there is a error = suser(td); if (error) return (error); so a second check should never become true again (if threads cannot be move in and out of jails). please correct me if I am wrong. --- ./vfs_syscalls.c.orig Sun Jun 6 19:32:23 2004 +++ ./vfs_syscalls.c Sun Jun 6 19:33:12 2004 @@ -4128,11 +4128,6 @@ fhstatfs(td, uap) sp->f_flags = mp->mnt_flag & MNT_VISFLAGMASK; if ((error = VFS_STATFS(mp, sp, td)) != 0) return (error); - if (suser(td)) { - bcopy(sp, &sb, sizeof(sb)); - sb.f_fsid.val[0] = sb.f_fsid.val[1] = 0; - sp = &sb; - } return (copyout(sp, uap->buf, sizeof(*sp))); } -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 12:55:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26C9D16A4CE; Sun, 6 Jun 2004 12:55:25 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0C9243D41; Sun, 6 Jun 2004 12:55:24 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i56JtNtD017955; Sun, 6 Jun 2004 15:55:23 -0400 (EDT) Date: Sun, 6 Jun 2004 15:55:23 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Scott Long In-Reply-To: <40C36D31.4010003@freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@FreeBSD.org cc: current@FreeBSD.org Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 19:55:25 -0000 On Sun, 6 Jun 2004, Scott Long wrote: > All, > > We are about 4-6 weeks away from starting the 5.3 release cycle. As it > stands, KSE still only works reliably on i386. There are reports of > significant instability on amd64, and it doesn't work at all on alpha > and sparc64. I'm willing to drop the alpha requirement and maybe even > the sparc64 requirement, but there absolutely will not be a 5.3 until > amd64 is solid. Please contact myself, Dan Eischen, and David Xu if > you are interested in helping out. amd64 looks to be a problem in readline which doesn't seem to redispatch signal handlers with SA_SIGINFO arguments. David also has patches for debugging support at: http://people.freebsd.org/~davidxu/kse/dbg/ Doug Rabson also has basic TLS support working in perforce. It'd be nice to get TLS and debugging in before 5.3-release. -- Dan Eischen From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 13:12:42 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5CD0516A4CE for ; Sun, 6 Jun 2004 13:12:42 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA96C43D41 for ; Sun, 6 Jun 2004 13:12:41 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i56KCMjt008540; Sun, 6 Jun 2004 13:12:29 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200406062012.i56KCMjt008540@gw.catspoiler.org> Date: Sun, 6 Jun 2004 13:12:22 -0700 (PDT) From: Don Lewis To: avatar@mmlab.cse.yzu.edu.tw In-Reply-To: <0406061343047.77519@www.mmlab.cse.yzu.edu.tw> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-current@FreeBSD.org cc: dl@leo.org Subject: Re: LOR No 9 and strange other kernel messages X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 20:12:42 -0000 On 6 Jun, Tai-hwa Liang wrote: > On Sat, 5 Jun 2004, Don Lewis wrote: >> On 5 Jun, Tai-hwa Liang wrote: >> > On Fri, 4 Jun 2004, Don Lewis wrote: >> >> On 4 Jun, Tai-hwa Liang wrote: >> >> > On Fri, 4 Jun 2004, Daniel Lang wrote: >> >> >> Hi, >> >> >> >> >> >> I just went through my syslog and stumbled across a LOR, which is >> >> >> documented on the Zabbadoz LOR page (id 009). >> >> >> >> >> >> The reason for this mail is the following kernel messages: >> >> >> >> >> >> [..] >> >> >> Jun 1 11:08:06 atrbg11 kernel: x: 2 >> >> >> Jun 1 11:08:06 atrbg11 kernel: x: 2 >> >> >> [..] >> >> >> >> >> >> Seems some leftovers from a developer who did not want to >> >> >> bother others with the gory details. ;-)) >> >> > >> >> > I guess that came from sys/dev/sound/pcm/sound.c:872. My Thinkpad T40 also >> >> > ran into this when the disk/network(combination) load is high enough. >> >> >> >> Looks likely, but I'd expect this would only get triggered when sysctl >> >> is used to set or query the number of vchans. In any case, this marks >> >> another spot where locking is broken in the sound code. >> > >> > I use the default setting without tweaking any vchan related sysctl >> > such like hw.snd.pcm0.vchans(leave it to default 0) or hw.snd.maxautovchans >> > (also left to 0 on my T40). >> >> Maybe your sound client software (or something else on the system) is >> querying for the number of vchans. Even "sysctl -a" will invoke the >> handler. > > I'm using the stock mpg123 0.59r to play MP3 files. Since I've never read > the source before, I'm not sure whether it utilised vchan related sysctls > or not. The code that calls pcm_inprog() and prints the "x: 2" debug message appears to be an attempt at implementing a reader/writer lock. I'm pretty sure the failure that triggers the debug message is harmless, other than causing the sysctl() call to return EWOULDBLOCK. The most likely trigger for this event is if the client software is writing data to sound device and is blocked in the write() syscall when another thread calls sysctl(). You could find out which process is calling sysctl() by printing curproc->p_pid in place of or in addition to x. >> > I'm wondering about whether this "bug" is ACPI related(interrupt storm?) >> > since recently when I run "make buildworld buildkernel" on one terminal and >> > do large file transmission(FTP ISO images on using em0) at the same time, >> > the sound tends to become "broken." Meanwhile, the "x: 2" message popped >> > on my console and later on my em0 doesn't work anymore(I have to do a reboot >> > to get it back; however, the other part of the system still works while >> > em0 was dead: sound continue playing, can compile/edit programs). >> >> It is quite possible that locking collisions in the sound code might >> happen more frequently when the system is busy. >> >> Do your sound hardware and em0 share the same irq? If they do, that > > Nope. > > interrupt total rate > irq0: clk 356127 99 > irq1: atkbd0 6006 1 > irq4: cbb0 em0++ 1378364 386 > irq6: cbb1 pcm0 110211 30 > irq7: ppc0 3 0 > irq8: rtc 455852 127 > irq12: psm0 16785 4 > irq13: npx0 1 0 > irq14: ata0 322853 90 > irq15: ata1 55 0 > Total 2646257 742 In that case, the em0 problem is likely to be something else. Does em0 lock up even if you don't use the sound hardware? >> might be a clue that the problems are related. Can you boot with ACPI >> disabled, and if so, does it change the symptoms? > > Whoops! My first trial on booting without ACPI -- kernel panic in > usb_get_next_event(). Apparently I have to disconnect the USB mouse > prior to kernel booting. See final section for the backtrace. Sounds like bug #3. > And, yes, the em0 didn't hang after booting to the non-ACPI environment. > However, there're still something weird happening at that moment: > > 1. There're still a couple of "x: 2" dumped on console. Test case: > "make buildworld buildkernel -DNOCLEAN" in one xterm, mpg123 in > another xterm, and providing file downloading to another Windoze > box. > > 2. While the remote box was downloading(Intel eepro 100/VE) files, > the number of interrupt on em0 was dramatically reduced to 300 ~ 500+ > per second. It was 3000+ when ACPI was enabled(no device polling in > kernel). > > 3. The system average load is surprising low(I'm using SCHED_4BSD), > about 0.06 ~ 0.30; however, the download was awfully slooowwwww. > It took my brother's Windoze XP about 25 minutes to complete the > whole downloading(3 ISO files, about 2GB in total). I'm pretty sure > that the mediaopt on em0 was 100baseTX + full-duplex. I wonder if the em0 interrupt is not getting enabled or is getting misrouted and the em0 interrupt service routing is getting triggered by another interrupt source that is happening at a lower rate. Print out the irq mapping with ACPI disabled to see what em0 is sharing its irq with. This is probably something that jhb and njl will need to look at. From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 13:12:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B87216A4D4; Sun, 6 Jun 2004 13:12:54 -0700 (PDT) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3266843D3F; Sun, 6 Jun 2004 13:12:54 -0700 (PDT) (envelope-from alc@cs.rice.edu) Received: from localhost (calypso.cs.rice.edu [128.42.1.127]) by cs.rice.edu (Postfix) with ESMTP id 91AA34ABA8; Sun, 6 Jun 2004 15:12:49 -0500 (CDT) Received: from cs.rice.edu ([128.42.1.30]) by localhost (calypso.cs.rice.edu [128.42.1.127]) (amavisd-new, port 10024) with LMTP id 17878-01-41; Sun, 6 Jun 2004 15:12:49 -0500 (CDT) Received: by cs.rice.edu (Postfix, from userid 19572) id 3F9684AB0E; Sun, 6 Jun 2004 15:12:49 -0500 (CDT) Date: Sun, 6 Jun 2004 15:12:49 -0500 From: Alan Cox To: Alexander Leidinger Message-ID: <20040606201249.GH24461@cs.rice.edu> References: <20040606142446.2900a97e@Magellan.Leidinger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040606142446.2900a97e@Magellan.Leidinger.net> User-Agent: Mutt/1.4.2i X-Virus-Scanned: by amavis-20030616-p7 at cs.rice.edu cc: alc@freebsd.org cc: current@freebsd.org Subject: Re: comments in the page coloring options in /sys/conf/NOTES X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 20:12:54 -0000 On Sun, Jun 06, 2004 at 02:24:46PM +0200, Alexander Leidinger wrote: > Hi, > > the comments about the page coloring in the VM system seem to talk about > L2/L1 cache size combinations, e.g. PQ_CACHESIZE=512 for a 512k/16k > cache. The comment above the PQ_CACHESIZE line just talks about the size > of the L2 cache. > > If it indeed talks about L2/L1 combinations, we should make it explicit. > And what about a 512k/8k combination? > > If it just talks about the L2 cache size, what is the meaning of the > second number? My recent commit fixed a "syntax" error in the comments, specifically, a reference to a missing macro. The comments are, however, still "semantically" broken: 1. Cache size alone does not correctly determine the number of colors, except for direct map caches. The correct formula is (cache size in bytes / page size in bytes) / degree of cache associativity Thus, the comments would lead one to configure his/her system with too many colors. (Relative to configuring a system with too few colors, this is not so bad.) 2. The references to L1 should be removed. They are historical leftovers. To conclude, I would be thrilled if someone wanted to work on automating this. I don't think it's reasonable to expect users to configure this. Alan From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 13:27:42 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 533A316A4CE; Sun, 6 Jun 2004 13:27:42 -0700 (PDT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9BD943D46; Sun, 6 Jun 2004 13:27:41 -0700 (PDT) (envelope-from scottl@freebsd.org) Received: from freebsd.org (junior-wifi.samsco.home [192.168.0.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i56KZ8Ma043698; Sun, 6 Jun 2004 14:35:08 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <40C37E1C.4000402@freebsd.org> Date: Sun, 06 Jun 2004 14:27:08 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 20:27:42 -0000 Daniel Eischen wrote: > On Sun, 6 Jun 2004, Scott Long wrote: > > >>All, >> >>We are about 4-6 weeks away from starting the 5.3 release cycle. As it >>stands, KSE still only works reliably on i386. There are reports of >>significant instability on amd64, and it doesn't work at all on alpha >>and sparc64. I'm willing to drop the alpha requirement and maybe even >>the sparc64 requirement, but there absolutely will not be a 5.3 until >>amd64 is solid. Please contact myself, Dan Eischen, and David Xu if >>you are interested in helping out. > > > amd64 looks to be a problem in readline which doesn't seem > to redispatch signal handlers with SA_SIGINFO arguments. > > David also has patches for debugging support at: > > http://people.freebsd.org/~davidxu/kse/dbg/ > > Doug Rabson also has basic TLS support working in perforce. What platforms? My understanding was that new binutils and gcc was needed for sparc64 at a minimum. > It'd be nice to get TLS and debugging in before 5.3-release. > Yes. Be aware that there is a serious effort to get GDB 6.x into the tree for 5.3. That presents us with a bit of a dilemma since David's work is against GDB 5.x. It's hard to back off on the GDB 6 requirement since it is needed for amd64 and sparc64. We need to get David, Marcel, David O'brien, and Alexander Kabaev together to work out the combined picture. Scott From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 13:32:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4DC7716A4CE; Sun, 6 Jun 2004 13:32:29 -0700 (PDT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id F03A643D4C; Sun, 6 Jun 2004 13:32:28 -0700 (PDT) (envelope-from scottl@freebsd.org) Received: from freebsd.org (junior-wifi.samsco.home [192.168.0.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i56Kduj1043744; Sun, 6 Jun 2004 14:39:56 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <40C37F3C.1050602@freebsd.org> Date: Sun, 06 Jun 2004 14:31:56 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcel Moolenaar References: <40C36D31.4010003@freebsd.org> <20040606193510.GA95886@dhcp50.pn.xcllnt.net> In-Reply-To: <20040606193510.GA95886@dhcp50.pn.xcllnt.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 20:32:29 -0000 Marcel Moolenaar wrote: > On Sun, Jun 06, 2004 at 01:14:57PM -0600, Scott Long wrote: > >>All, >> >>We are about 4-6 weeks away from starting the 5.3 release cycle. As it >>stands, KSE still only works reliably on i386. > > > I don't have any problems on ia64. > Good to hear =-) > >>... I'm willing to drop the alpha requirement and maybe even >>the sparc64 requirement, but there absolutely will not be a 5.3 until >>amd64 is solid. > > > I think sparc64 should have KSE too. If we already accept that sparc64 > is feature incomplete, we set/acknowledge a really bad precedence. > I do too, but there is the difficult fact in that there are few people out there that are willing to work on sparc64. One person offered to try to learn it and tackle it, but that's a lot to ask. As with Alpha, the fate of a platform rests on the people who are willing to work on it, not on whether it is in a particular list. Scott From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 13:48:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40D7E16A4CE for ; Sun, 6 Jun 2004 13:48:22 -0700 (PDT) Received: from ganymede.hub.org (u46n208.hfx.eastlink.ca [24.222.46.208]) by mx1.FreeBSD.org (Postfix) with ESMTP id C93D843D45 for ; Sun, 6 Jun 2004 13:48:21 -0700 (PDT) (envelope-from scrappy@hub.org) Received: by ganymede.hub.org (Postfix, from userid 1000) id F33763BF49; Sun, 6 Jun 2004 17:48:14 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id EEEFF3B3D7; Sun, 6 Jun 2004 17:48:14 -0300 (ADT) Date: Sun, 6 Jun 2004 17:48:14 -0300 (ADT) From: "Marc G. Fournier" To: Eirik Oeverby In-Reply-To: <40BEC4D7.8070804@anduin.net> Message-ID: <20040606172659.T88480@ganymede.hub.org> References: <40BEC4D7.8070804@anduin.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: current@freebsd.org Subject: Re: unionfs issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 20:48:22 -0000 Eirik ... can you provide some details on exactly what you are trying to do? For instance, as Dave posts in a follow up, there are several known conditions that will cause a system to panic ... Now, in your case, you say it panic's ... do you have DEBUG enabled and core dumping? That would help to narrow down if its a "known condition" or something new ... On Thu, 3 Jun 2004, Eirik Oeverby wrote: > Hi, > > Recently (3 days ago) I upgraded my main server with 5.2.1, and then > cvsupped to latest current in order to solve some problems in 5.2.1. > Among those was the fact that unionfs was non-functional in the release. > After cvsupping it seemed to work, but when doing some heavy file > copying operations inside a mountpoint the box paniced. > > Problem is - the box is headless, 1000kms away, and with no serial > access. So I'll just ask if this is expected behaviour at the current > state of source, or if those in the know can say anything more about why > this happened and if it has already been fixed. > > I apologise for the vague description of this problem - I know I'm > probably reaching for straws here. > > Wbr., > /Eirik > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 13:48:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE79016A4D3; Sun, 6 Jun 2004 13:48:25 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 016C243D55; Sun, 6 Jun 2004 13:48:25 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp50.pn.xcllnt.net (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.12.11/8.12.11) with ESMTP id i56KmHmh005403; Sun, 6 Jun 2004 13:48:17 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp50.pn.xcllnt.net (localhost [127.0.0.1]) i56KmH55096731; Sun, 6 Jun 2004 13:48:17 -0700 (PDT) (envelope-from marcel@dhcp50.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp50.pn.xcllnt.net (8.12.11/8.12.11/Submit) id i56KmHd3096730; Sun, 6 Jun 2004 13:48:17 -0700 (PDT) (envelope-from marcel) Date: Sun, 6 Jun 2004 13:48:17 -0700 From: Marcel Moolenaar To: Scott Long Message-ID: <20040606204817.GB96607@dhcp50.pn.xcllnt.net> References: <40C37E1C.4000402@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40C37E1C.4000402@freebsd.org> User-Agent: Mutt/1.4.2.1i cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 20:48:26 -0000 On Sun, Jun 06, 2004 at 02:27:08PM -0600, Scott Long wrote: > > > >Doug Rabson also has basic TLS support working in perforce. > > What platforms? My understanding was that new binutils and gcc was > needed for sparc64 at a minimum. Yes. It's i386 only and not even close to being complete. In fact, there has been discussions that the thread pointer on i386 needs to change. Whether that's the case or not, it's likely that TLS will complicate matters way too much to for it to ever work in 5.3. > >It'd be nice to get TLS and debugging in before 5.3-release. > > > > Yes. Be aware that there is a serious effort to get GDB 6.x into the > tree for 5.3. I just asked cvs@ and core@ to advice about importing gdb 6.1 into src/contrib/gdb6. We need to break this vicious circle of people waiting on each other. > That presents us with a bit of a dilemma since David's > work is against GDB 5.x. And not even complete. There are still issues that haven't found a solution or even compromise and it too is only for i386. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 14:12:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07A7E16A4CF; Sun, 6 Jun 2004 14:12:50 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCCD543D1F; Sun, 6 Jun 2004 14:12:49 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp50.pn.xcllnt.net (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.12.11/8.12.11) with ESMTP id i56LCncF005473; Sun, 6 Jun 2004 14:12:49 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp50.pn.xcllnt.net (localhost [127.0.0.1]) i56LCnbt096799; Sun, 6 Jun 2004 14:12:49 -0700 (PDT) (envelope-from marcel@dhcp50.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp50.pn.xcllnt.net (8.12.11/8.12.11/Submit) id i56LCnZD096798; Sun, 6 Jun 2004 14:12:49 -0700 (PDT) (envelope-from marcel) Date: Sun, 6 Jun 2004 14:12:49 -0700 From: Marcel Moolenaar To: Scott Long Message-ID: <20040606211249.GC96607@dhcp50.pn.xcllnt.net> References: <40C36D31.4010003@freebsd.org> <20040606193510.GA95886@dhcp50.pn.xcllnt.net> <40C37F3C.1050602@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40C37F3C.1050602@freebsd.org> User-Agent: Mutt/1.4.2.1i cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 21:12:50 -0000 On Sun, Jun 06, 2004 at 02:31:56PM -0600, Scott Long wrote: > As with Alpha, > the fate of a platform rests on the people who are willing to work on > it, not on whether it is in a particular list. Agreed, but it's the projects responsibility to take the tierness and the intend to support multiple platforms serious and not to chicken out at the first signs of complications or hurdles. We labeled sparc64 as a tier 1 platform and we better deal with the consequences. As for alpha, we don't even seem to be able to degrade it to tier 2 without losing face. kris@ has already stopped package builds for it for his own sake. Wake up, people. This is quickly becoming a joke... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 14:16:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 27DC416A4CE for ; Sun, 6 Jun 2004 14:16:11 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A03A43D41 for ; Sun, 6 Jun 2004 14:16:11 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc13) with ESMTP id <2004060621161001500mdmple>; Sun, 6 Jun 2004 21:16:10 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA12756 for ; Sun, 6 Jun 2004 14:16:08 -0700 (PDT) Date: Sun, 6 Jun 2004 14:16:07 -0700 (PDT) From: Julian Elischer To: FreeBSD current users Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: need frame-relay testers using sr and ar cards.... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 21:16:11 -0000 If you use the sr or ar drivers with the netgraph frame relay code, I really need someone to test some changes that affect this setup.. contact me so we can test it before committing! From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 14:27:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C97A16A4CE; Sun, 6 Jun 2004 14:27:57 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9CF643D1F; Sun, 6 Jun 2004 14:27:56 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i56LRutD012553; Sun, 6 Jun 2004 17:27:56 -0400 (EDT) Date: Sun, 6 Jun 2004 17:27:56 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Marcel Moolenaar In-Reply-To: <20040606211249.GC96607@dhcp50.pn.xcllnt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 21:27:57 -0000 On Sun, 6 Jun 2004, Marcel Moolenaar wrote: > On Sun, Jun 06, 2004 at 02:31:56PM -0600, Scott Long wrote: > > > As with Alpha, > > the fate of a platform rests on the people who are willing to work on > > it, not on whether it is in a particular list. > > Agreed, but it's the projects responsibility to take the tierness and > the intend to support multiple platforms serious and not to chicken out > at the first signs of complications or hurdles. We labeled sparc64 as > a tier 1 platform and we better deal with the consequences. Not to take away from the tremendous effort that jake had done for sparc64, but it should really take more than one or two supporting developers to obtain tier 1 support. People come and go, and tierness should take that into account. > As for alpha, we don't even seem to be able to degrade it to tier 2 > without losing face. kris@ has already stopped package builds for it > for his own sake. We shouldn't keep an arch at tier 1 just to save face. Better to just lower it to tier 2 and be done with it. My $.02, FWIW. From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 14:41:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8FF416A4CE for ; Sun, 6 Jun 2004 14:41:00 -0700 (PDT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27AB643D45 for ; Sun, 6 Jun 2004 14:41:00 -0700 (PDT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i56Lc3lO059052 for current@FreeBSD.ORG.checked; (8.12.8/vak/2.1) Mon, 7 Jun 2004 01:38:03 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (rik.cronyx.ru [172.22.4.1]) by hanoi.cronyx.ru with ESMTP id i56LameR058993; (8.12.8/vak/2.1) Mon, 7 Jun 2004 01:36:48 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <40C38D03.6070006@cronyx.ru> Date: Mon, 07 Jun 2004 01:30:43 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.2.1) Gecko/20030426 X-Accept-Language: ru-ru, en MIME-Version: 1.0 To: Julian Elischer References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit cc: FreeBSD current users Subject: Re: need frame-relay testers using sr and ar cards.... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 21:41:01 -0000 Julian Elischer ÐÉÛÅÔ: >If you use the sr or ar drivers with the netgraph frame relay >code, I really need someone to test some changes that affect this >setup.. > Is it only ar&sr specific? If not you could ask also users of Cronyx cx,ctau and cp cards. If you describe the problem, probably I can be a tester, if I'll have some spare time and ability to set configuration you need with my hardware. rik > >contact me so we can test it before committing! > > >_______________________________________________ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 14:43:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD5F416A4CE; Sun, 6 Jun 2004 14:43:16 -0700 (PDT) Received: from smtp-out5.xs4all.nl (smtp-out5.xs4all.nl [194.109.24.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C33E43D2D; Sun, 6 Jun 2004 14:43:16 -0700 (PDT) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-out5.xs4all.nl (8.12.10/8.12.10) with ESMTP id i56LhFUY068069; Sun, 6 Jun 2004 23:43:15 +0200 (CEST) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.11/8.12.9) with ESMTP id i56LgS99044309; Sun, 6 Jun 2004 23:42:28 +0200 (CEST) (envelope-from wkb@freebie.xs4all.nl) Received: (from wkb@localhost) by freebie.xs4all.nl (8.12.11/8.12.11/Submit) id i56LgSYM044308; Sun, 6 Jun 2004 23:42:28 +0200 (CEST) (envelope-from wkb) Date: Sun, 6 Jun 2004 23:42:28 +0200 From: Wilko Bulte To: Marcel Moolenaar Message-ID: <20040606214228.GA44280@freebie.xs4all.nl> References: <40C36D31.4010003@freebsd.org> <20040606193510.GA95886@dhcp50.pn.xcllnt.net> <40C37F3C.1050602@freebsd.org> <20040606211249.GC96607@dhcp50.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040606211249.GC96607@dhcp50.pn.xcllnt.net> User-Agent: Mutt/1.4.1i X-OS: FreeBSD 4.10-STABLE X-PGP: finger wilko@freebsd.org cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 21:43:16 -0000 On Sun, Jun 06, 2004 at 02:12:49PM -0700, Marcel Moolenaar wrote: > On Sun, Jun 06, 2004 at 02:31:56PM -0600, Scott Long wrote: > > > As with Alpha, > > the fate of a platform rests on the people who are willing to work on > > it, not on whether it is in a particular list. > > Agreed, but it's the projects responsibility to take the tierness and > the intend to support multiple platforms serious and not to chicken out > at the first signs of complications or hurdles. We labeled sparc64 as > a tier 1 platform and we better deal with the consequences. > > As for alpha, we don't even seem to be able to degrade it to tier 2 > without losing face. kris@ has already stopped package builds for it > for his own sake. > > Wake up, people. This is quickly becoming a joke... Right... Basically only i386 is a Tier 1. The rest is a joke if it is called Tier 1. If only because there are insufficient numbers of committers actively working on the arch. (maybe pc98 should be called Tier 1, I just don't know enough about that one). -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 14:43:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A617F16A4CE for ; Sun, 6 Jun 2004 14:43:55 -0700 (PDT) Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60B9F43D2D for ; Sun, 6 Jun 2004 14:43:55 -0700 (PDT) (envelope-from j.e.drews@att.net) Received: from 204.127.135.57 ([204.127.135.57]) by worldnet.att.net (mtiwmhc13) with SMTP id <20040606214353113000qkahe>; Sun, 6 Jun 2004 21:43:53 +0000 Received: from [64.105.56.145] by 204.127.135.57; Sun, 06 Jun 2004 21:43:53 +0000 From: j.e.drews@att.net To: Nate Lawson Date: Sun, 06 Jun 2004 21:43:53 +0000 Message-Id: <060620042143.25102.40C39019000787950000620E21603763169C990A9D0BD20AD206@att.net> X-Mailer: AT&T Message Center Version 1 (May 27 2004) X-Authenticated-Sender: ai5lLmRyZXdzQGF0dC5uZXQ= cc: current@freebsd.org Subject: Re: ACPI Error: AE_NO_HARDWARE_RESPONSE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 21:43:55 -0000 Thank you so much Nate: I will get compiled in tonight. Kind regards, Jonathan > Closer. :) You need options DDB in your kernel. > > FreeBSD 5.2-CURRENT #0: Sat Jun 5 22:58:42 CDT 2004 > root@notebook.silbsd.org:/usr/obj/usr/src/sys/NOTEBOOK > Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a15000. > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a15244. > link_elf: symbol db_readline undefined > ^^^^^^^^^^^^^^ > KLD file acpi.ko - could not finalize loading > > On Sun, 6 Jun 2004 j.e.drews@att.net wrote: > > OK Nate: > > > > Hopefully I have gotten it right this time. > > > > The Regents of the University of California. All rights reserved. > > FreeBSD 5.2-CURRENT #0: Sat Jun 5 22:58:42 CDT 2004 > > root@notebook.silbsd.org:/usr/obj/usr/src/sys/NOTEBOOK > > Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a15000. > > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a15244. > > > > I never could get it to laod at the prompt so I transfered the acpi.ko with > debugging enabled into /boot/kernel. > > > > the new dmesg is here: > > http://www.silbsd.org/bugreports/acpi.dmesg2.txt > > > > Kind regards, > > Jonathan > > > > > > > On Sun, 6 Jun 2004 j.e.drews@att.net wrote: > > > > I have followed your instructions and the output of dmesg is here: > > > >d > > > This indicates you didn't copy acpi.ko to / and maybe copied acpi.kld. > > > Thus there is no debugging output. If it was acpi.ko, it would be labeled > > > "elf module" as below: > > > > > > > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a6127c. > > > ^^^^^^^^^^^^^^^^^^^ > > > > > > Since the kld was not the kernel module, your kernel went and loaded the > > > original acpi.ko from /boot/kernel, which doesn't have debugging enabled. > > > > > > Please check against the instructions I list again below: > > > > > > -Nate > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 14:47:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08A0F16A4CE; Sun, 6 Jun 2004 14:47:47 -0700 (PDT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9232843D1F; Sun, 6 Jun 2004 14:47:46 -0700 (PDT) (envelope-from scottl@freebsd.org) Received: from [192.168.0.12] (g4.samsco.home [192.168.0.12]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i56LtD6b044025; Sun, 6 Jun 2004 15:55:13 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <40C390C4.1000609@freebsd.org> Date: Sun, 06 Jun 2004 15:46:44 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcel Moolenaar References: <40C36D31.4010003@freebsd.org> <20040606193510.GA95886@dhcp50.pn.xcllnt.net> <40C37F3C.1050602@freebsd.org> <20040606211249.GC96607@dhcp50.pn.xcllnt.net> In-Reply-To: <20040606211249.GC96607@dhcp50.pn.xcllnt.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 21:47:47 -0000 Marcel Moolenaar wrote: > On Sun, Jun 06, 2004 at 02:31:56PM -0600, Scott Long wrote: > > >>As with Alpha, >>the fate of a platform rests on the people who are willing to work on >>it, not on whether it is in a particular list. > > > Agreed, but it's the projects responsibility to take the tierness and > the intend to support multiple platforms serious and not to chicken out > at the first signs of complications or hurdles. We labeled sparc64 as > a tier 1 platform and we better deal with the consequences. > > As for alpha, we don't even seem to be able to degrade it to tier 2 > without losing face. kris@ has already stopped package builds for it > for his own sake. > > Wake up, people. This is quickly becoming a joke... > It's not that there is face to loose on alpha, it's that every time I announce that alpha is going to be killed unless issues X, Y, and Z are fixed, someone comes along and fixes X, part of Y, and promises to fix Z. There is nothing wrong with this, and I definitely appreciate it when people step up to fix things. However, it does prolong the process and doesn't leave us with 100% of what we need. At this point, I'm going to advocate that Alpha be dropped from Tier-1 status for 5.3 and 5-STABLE and no longer be a blocking item for releases. I made it very clear last winter that alpha needed a full time maintainer in order to stay viable, and that really never happened. As I said back then, demotion is not a terminal condition, and I would be thrilled if someone comes forward in the future and brings the platform back up to date. If anyone wants to claim it now and keep it alive for 5.3, they need to both finish KSE, make KSE work reliably, and be very responsive to Kris Kenneway about ports issues. This needs to happen in no more than 4 weeks. After that, I will turn away even the best of intentions. Anyways, moving on, KSE needs attention. Please figure out what can be done for sparc64 and amd64 and do it. Scott From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 14:48:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57F5816A4CE for ; Sun, 6 Jun 2004 14:48:37 -0700 (PDT) Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id F020B43D1F for ; Sun, 6 Jun 2004 14:48:36 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (d8cf2f5a10d55cb91b30e78cd9506e14@adsl-67-115-73-128.dsl.lsan03.pacbell.net [67.115.73.128])i56LmYQU006490; Sun, 6 Jun 2004 16:48:35 -0500 (CDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id C42DC53A32; Sun, 6 Jun 2004 14:48:33 -0700 (PDT) Date: Sun, 6 Jun 2004 14:48:33 -0700 From: Kris Kennaway To: Peter Ulrich Kruppa Message-ID: <20040606214833.GA96006@xor.obsecurity.org> References: <20040605092412.R856@pukruppa.net> <20040605214557.GC65326@xor.obsecurity.org> <20040606202947.J844@pukruppa.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline In-Reply-To: <20040606202947.J844@pukruppa.net> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org cc: Kris Kennaway Subject: Re: Today's -CURRENT doesn't boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 21:48:37 -0000 --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 06, 2004 at 08:35:18PM +0200, Peter Ulrich Kruppa wrote: > On Sat, 5 Jun 2004, Kris Kennaway wrote: >=20 > >On Sat, Jun 05, 2004 at 09:32:25AM +0200, Peter Ulrich Kruppa wrote: > >>Hi, > >> > >>this morning I cvsup'ped my sources and rebuilt my system. > >>Booting stops with this message > >> > >> ------------------------------------------------ > >> > >>panic NG_MKMESSAGE() with how=3DM_DONTWAIT (1) > >>at line 913 in file /usr/src/sys/netgraph/ng_pppoe.c > >>Debugger("panic") > >>Stopped at Debugger+0x45 xchgl %ebx, in_Debugger.0 > >>db> > > > >Make sure you're not using stale modules. > Without deeper knowledge of what I'm doing I removed the module=20 > ng_pppoe.ko from /boot/kernel . > Now the system booted and rebooted fine, but I couldn't connect=20 > to the internet anymore (my ppp stup needs netgraph/pppoe stuff=20 > for this). > What can I do now? Rebuild the module so it is not stale (out of sync with kernel). You always need to do this, because it's a frequent cause of panics. Kris --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAw5ExWry0BWjoQKURAh+YAKDn0J0q6PB5PeW31z8jmX4mYyhvewCg+DK0 HIK+nChK8uMEZWxWWlR5r1U= =bJnB -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 14:49:36 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6366816A4CE for ; Sun, 6 Jun 2004 14:49:36 -0700 (PDT) Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EE1F43D31 for ; Sun, 6 Jun 2004 14:49:36 -0700 (PDT) (envelope-from j.e.drews@att.net) Received: from 204.127.135.57 ([204.127.135.57]) by worldnet.att.net (mtiwmhc11) with SMTP id <2004060621493511100fhqsve>; Sun, 6 Jun 2004 21:49:35 +0000 Received: from [64.105.56.145] by 204.127.135.57; Sun, 06 Jun 2004 21:49:35 +0000 From: j.e.drews@att.net To: freebsd-current@freebsd.org Date: Sun, 06 Jun 2004 21:49:35 +0000 Message-Id: <060620042149.28589.40C3916E000C1E2E00006FAD21603763169C990A9D0BD20AD206@att.net> X-Mailer: AT&T Message Center Version 1 (May 27 2004) X-Authenticated-Sender: ai5lLmRyZXdzQGF0dC5uZXQ= Subject: Re: PCMCIA Modem causes hang on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 21:49:36 -0000 FreeBSD 5.2-CURRENT #0: Sun Jun 6 15:45:41 CDT 2004 Hawking PN612 PCMCIA Modem v.90 Hi: I attempted to find some information on this modem by using pccardc. However as soon as I inserted the card in the pcmcia slot, FreeBSD CURRENT locked up. I had to power off the laptop. What information should I try and gather to help fix this bug? I looked in /var/log/messages and unfortunately nothing was recorded even though I was using verbose logging (boot option 6). Kind regards, Jonathan > Can you give me a dmesg w/o the modem card inserted? > From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 14:50:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A44A416A4CE; Sun, 6 Jun 2004 14:50:17 -0700 (PDT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FF3E43D2D; Sun, 6 Jun 2004 14:50:17 -0700 (PDT) (envelope-from scottl@freebsd.org) Received: from [192.168.0.12] (g4.samsco.home [192.168.0.12]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i56Lvgr3044052; Sun, 6 Jun 2004 15:57:42 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <40C39159.1030102@freebsd.org> Date: Sun, 06 Jun 2004 15:49:13 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wilko Bulte References: <40C36D31.4010003@freebsd.org> <20040606193510.GA95886@dhcp50.pn.xcllnt.net> <40C37F3C.1050602@freebsd.org> <20040606211249.GC96607@dhcp50.pn.xcllnt.net> <20040606214228.GA44280@freebie.xs4all.nl> In-Reply-To: <20040606214228.GA44280@freebie.xs4all.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: hackers@freebsd.org cc: current@freebsd.org cc: Marcel Moolenaar Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 21:50:17 -0000 Wilko Bulte wrote: > On Sun, Jun 06, 2004 at 02:12:49PM -0700, Marcel Moolenaar wrote: > >>On Sun, Jun 06, 2004 at 02:31:56PM -0600, Scott Long wrote: >> >> >>>As with Alpha, >>>the fate of a platform rests on the people who are willing to work on >>>it, not on whether it is in a particular list. >> >>Agreed, but it's the projects responsibility to take the tierness and >>the intend to support multiple platforms serious and not to chicken out >>at the first signs of complications or hurdles. We labeled sparc64 as >>a tier 1 platform and we better deal with the consequences. >> >>As for alpha, we don't even seem to be able to degrade it to tier 2 >>without losing face. kris@ has already stopped package builds for it >>for his own sake. >> >>Wake up, people. This is quickly becoming a joke... > > > Right... > > > > Basically only i386 is a Tier 1. The rest is a joke if it is called Tier 1. > If only because there are insufficient numbers of committers actively > working on the arch. > > (maybe pc98 should be called Tier 1, I just don't know enough about that > one). > > amd64 is approaching critical mass for tier-1. There are a number of developers that own amd64 hardware now, and a number of users who are asking about it on the mailing lists. Peter is finishing up the last blocking item for it (kld's) not including the observed KSE problems. It's very close and I _will_ hold up the release for it to get done. amd64 is the future of commodity computing and we aren't going to ignore it for 5-STABLE. Scott From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 14:53:14 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12C9A16A4CE; Sun, 6 Jun 2004 14:53:14 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0D2C43D39; Sun, 6 Jun 2004 14:53:13 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i56Lr487008714; Sun, 6 Jun 2004 14:53:08 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200406062153.i56Lr487008714@gw.catspoiler.org> Date: Sun, 6 Jun 2004 14:53:04 -0700 (PDT) From: Don Lewis To: eischen@vigrid.com In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: hackers@FreeBSD.org cc: current@FreeBSD.org cc: marcel@xcllnt.net Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 21:53:14 -0000 On 6 Jun, Daniel Eischen wrote: > On Sun, 6 Jun 2004, Marcel Moolenaar wrote: > >> On Sun, Jun 06, 2004 at 02:31:56PM -0600, Scott Long wrote: >> >> > As with Alpha, >> > the fate of a platform rests on the people who are willing to work on >> > it, not on whether it is in a particular list. >> >> Agreed, but it's the projects responsibility to take the tierness and >> the intend to support multiple platforms serious and not to chicken out >> at the first signs of complications or hurdles. We labeled sparc64 as >> a tier 1 platform and we better deal with the consequences. > > Not to take away from the tremendous effort that jake had done for > sparc64, but it should really take more than one or two supporting > developers to obtain tier 1 support. People come and go, and > tierness should take that into account. I've got some sparc64 hardware that recently became available for FreeBSD develpment. Unfortunately my time available to FreeBSD is likely to be the limiting factor. From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 14:59:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B84116A4CE; Sun, 6 Jun 2004 14:59:26 -0700 (PDT) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA1BD43D49; Sun, 6 Jun 2004 14:59:25 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (a68a602e37c500f9af2bf8d2775ee0c8@adsl-67-115-73-128.dsl.lsan03.pacbell.net [67.115.73.128])i56LxMYu027449; Sun, 6 Jun 2004 14:59:23 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 6E4C953F64; Sun, 6 Jun 2004 14:59:21 -0700 (PDT) Date: Sun, 6 Jun 2004 14:59:21 -0700 From: Kris Kennaway To: Scott Long Message-ID: <20040606215921.GA96205@xor.obsecurity.org> References: <40C36D31.4010003@freebsd.org> <20040606193510.GA95886@dhcp50.pn.xcllnt.net> <40C37F3C.1050602@freebsd.org> <20040606211249.GC96607@dhcp50.pn.xcllnt.net> <20040606214228.GA44280@freebie.xs4all.nl> <40C39159.1030102@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline In-Reply-To: <40C39159.1030102@freebsd.org> User-Agent: Mutt/1.4.2.1i cc: Marcel Moolenaar cc: hackers@freebsd.org cc: current@freebsd.org cc: Wilko Bulte Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 21:59:26 -0000 --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Jun 06, 2004 at 03:49:13PM -0600, Scott Long wrote: > amd64 is approaching critical mass for tier-1. There are a number of > developers that own amd64 hardware now, and a number of users who are > asking about it on the mailing lists. Peter is finishing up the last > blocking item for it (kld's) not including the observed KSE problems. > It's very close and I _will_ hold up the release for it to get done. > amd64 is the future of commodity computing and we aren't going to > ignore it for 5-STABLE. amd64 has a bug with swapping - when something begins to access swap, the entire system becomes almost entirely unresponsive (e.g. no mouse response for up to 10 seconds) until it stops. Peter has some ideas about it, but it's a serious enough bug that it forced me to stop using amd64 as my desktop machine (hello, kde!). Kris --Qxx1br4bt0+wmkIi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAw5O4Wry0BWjoQKURAiPKAJ45IDqrEgb6Y0BFELP5YR6oHLUdNQCfZd7U PUiwpcn9HzOPdxUUSukTvYs= =m5I3 -----END PGP SIGNATURE----- --Qxx1br4bt0+wmkIi-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 15:04:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E412C16A4CE; Sun, 6 Jun 2004 15:04:32 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84DE043D1F; Sun, 6 Jun 2004 15:04:32 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp50.pn.xcllnt.net (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.12.11/8.12.11) with ESMTP id i56M4WNP005752; Sun, 6 Jun 2004 15:04:32 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp50.pn.xcllnt.net (localhost [127.0.0.1]) i56M4WuO097124; Sun, 6 Jun 2004 15:04:32 -0700 (PDT) (envelope-from marcel@dhcp50.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp50.pn.xcllnt.net (8.12.11/8.12.11/Submit) id i56M4W6G097123; Sun, 6 Jun 2004 15:04:32 -0700 (PDT) (envelope-from marcel) Date: Sun, 6 Jun 2004 15:04:32 -0700 From: Marcel Moolenaar To: Daniel Eischen Message-ID: <20040606220432.GA97091@dhcp50.pn.xcllnt.net> References: <20040606211249.GC96607@dhcp50.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 22:04:33 -0000 On Sun, Jun 06, 2004 at 05:27:56PM -0400, Daniel Eischen wrote: > > > As for alpha, we don't even seem to be able to degrade it to tier 2 > > without losing face. kris@ has already stopped package builds for it > > for his own sake. > > We shouldn't keep an arch at tier 1 just to save face. Better to just > lower it to tier 2 and be done with it. My $.02, FWIW. You misunderstand my statement. Lowering alpha to tier 2 is what I suggested multiple times before. The point is that we haven't yet and alpha is degenerating more and more while we fail to adjust the tierness. That's where we fail to save face. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 15:09:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F00116A4CE for ; Sun, 6 Jun 2004 15:09:54 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 53A2343D49 for ; Sun, 6 Jun 2004 15:09:53 -0700 (PDT) (envelope-from ph.schulz@gmx.de) Received: (qmail 11357 invoked by uid 65534); 6 Jun 2004 22:09:48 -0000 Received: from p5090CADC.dip0.t-ipconnect.de (EHLO gmx.de) (80.144.202.220) by mail.gmx.net (mp018) with SMTP; 07 Jun 2004 00:09:48 +0200 X-Authenticated: #1954550 Message-ID: <40C3960F.4080305@gmx.de> Date: Mon, 07 Jun 2004 00:09:19 +0200 From: Phil Schulz User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040520 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Execute BIOS function X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 22:09:54 -0000 Hello List! The radio transmitter of my new centrino laptop is turned on by a BIOS function which resides at a certain location in memory. I know how to find the adress of the function's start but I don't yet know how to tell the OS that I do want to execute that memory region and make it let me do so. When running the program I get "Bus error (core dumped)". So the question is: Can I actually execute the BIOS code from userland or do I have to do it from kernelspace? How do I tell the kernel that I want the memory region to be executed and make it let me do so? Any help is appreciated. Thanks, Phil. -- This is a part of the code (I hope it's not going to be wrapped). bios_code_addr holds the BIOS function's start address and dev_mem is a file-descriptor to /dev/mem. ptr = mmap( 0, BIOS_CODE_SIZE, PROT_EXEC, 0, dev_mem, bios_code_addr ); __asm__ __volatile__ ( "call *%3 \t\n" : "=a"(eax) : "a"(eax), "b"(ebx), "c"(ptr) ); From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 15:13:30 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3B2916A4CE; Sun, 6 Jun 2004 15:13:30 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id B515C43D1D; Sun, 6 Jun 2004 15:13:30 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp50.pn.xcllnt.net (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.12.11/8.12.11) with ESMTP id i56MDUu0005776; Sun, 6 Jun 2004 15:13:30 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp50.pn.xcllnt.net (localhost [127.0.0.1]) i56MDUAC097164; Sun, 6 Jun 2004 15:13:30 -0700 (PDT) (envelope-from marcel@dhcp50.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp50.pn.xcllnt.net (8.12.11/8.12.11/Submit) id i56MDUlb097163; Sun, 6 Jun 2004 15:13:30 -0700 (PDT) (envelope-from marcel) Date: Sun, 6 Jun 2004 15:13:30 -0700 From: Marcel Moolenaar To: Scott Long Message-ID: <20040606221330.GB97091@dhcp50.pn.xcllnt.net> References: <40C36D31.4010003@freebsd.org> <20040606193510.GA95886@dhcp50.pn.xcllnt.net> <40C37F3C.1050602@freebsd.org> <20040606211249.GC96607@dhcp50.pn.xcllnt.net> <40C390C4.1000609@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40C390C4.1000609@freebsd.org> User-Agent: Mutt/1.4.2.1i cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 22:13:31 -0000 On Sun, Jun 06, 2004 at 03:46:44PM -0600, Scott Long wrote: > > > >As for alpha, we don't even seem to be able to degrade it to tier 2 > >without losing face. kris@ has already stopped package builds for it > >for his own sake. > > It's not that there is face to loose on alpha, it's that every time > I announce that alpha is going to be killed unless issues X, Y, and Z > are fixed, someone comes along and fixes X, part of Y, and promises > to fix Z. I don't read anything I haven't read before. People have made promises before and good intentions notwithstanding, you cannot keep a project hostage this way. Degrade alpha and only promote it after people have actually demonstrated that alpha is tier 1 material after all. > At this point, I'm going to advocate that Alpha be dropped from Tier-1 > status for 5.3 and 5-STABLE and no longer be a blocking item for > releases. Just *do* it. You've been advocating for way too long. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 15:31:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BD2B16A4CE; Sun, 6 Jun 2004 15:31:37 -0700 (PDT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE84343D48; Sun, 6 Jun 2004 15:31:36 -0700 (PDT) (envelope-from scottl@freebsd.org) Received: from [192.168.0.12] (g4.samsco.home [192.168.0.12]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i56Md4nf044248; Sun, 6 Jun 2004 16:39:04 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <40C39B0B.8070102@freebsd.org> Date: Sun, 06 Jun 2004 16:30:35 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcel Moolenaar References: <40C36D31.4010003@freebsd.org> <20040606193510.GA95886@dhcp50.pn.xcllnt.net> <40C37F3C.1050602@freebsd.org> <20040606211249.GC96607@dhcp50.pn.xcllnt.net> <40C390C4.1000609@freebsd.org> <20040606221330.GB97091@dhcp50.pn.xcllnt.net> In-Reply-To: <20040606221330.GB97091@dhcp50.pn.xcllnt.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 22:31:37 -0000 Marcel Moolenaar wrote: > On Sun, Jun 06, 2004 at 03:46:44PM -0600, Scott Long wrote: > >>>As for alpha, we don't even seem to be able to degrade it to tier 2 >>>without losing face. kris@ has already stopped package builds for it >>>for his own sake. >> >>It's not that there is face to loose on alpha, it's that every time >>I announce that alpha is going to be killed unless issues X, Y, and Z >>are fixed, someone comes along and fixes X, part of Y, and promises >>to fix Z. > > > I don't read anything I haven't read before. People have made promises > before and good intentions notwithstanding, you cannot keep a project > hostage this way. Degrade alpha and only promote it after people have > actually demonstrated that alpha is tier 1 material after all. > > >>At this point, I'm going to advocate that Alpha be dropped from Tier-1 >>status for 5.3 and 5-STABLE and no longer be a blocking item for >>releases. > > > Just *do* it. You've been advocating for way too long. > There are always people with good intentions, and they often want to find some way to help. I appreciate this very much and I don't want to turn them away. We also can't make a snap decision in an afternoon and risk missing people who have better things to do on their weekends/holidays than track FreeBSD mail =-) But yes, Alpha has been languishing for too long. I'll say it in a loud voice now: This is the last call for Alpha. It cannot maintain minimum tier-1 requirements and it will be demoted for 5.3. Unless you currently have access to a representative selection of hardware, the knowledge to track down platform-specific issues, the willingness to handle the current outstanding issues, and the time to do it for the next 18 months, please accept my regrets on it. Again, while I appreciate people who can pick away at some of the lesser issues or want to learn the bigger things, we need a 100% maintenance and development solution. Scott From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 17:25:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C50B16A4CE for ; Sun, 6 Jun 2004 17:25:48 -0700 (PDT) Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15C7F43D1F for ; Sun, 6 Jun 2004 17:25:48 -0700 (PDT) (envelope-from j.e.drews@att.net) Received: from 204.127.135.40 ([204.127.135.40]) by worldnet.att.net (mtiwmhc12) with SMTP id <2004060700254511200cvku0e>; Mon, 7 Jun 2004 00:25:45 +0000 Received: from [64.105.56.145] by 204.127.135.40; Mon, 07 Jun 2004 00:25:47 +0000 From: j.e.drews@att.net To: freebsd-current@freebsd.org Date: Mon, 07 Jun 2004 00:25:47 +0000 Message-Id: <060720040025.12183.40C3B60B000027DD00002F9721602807489C990A9D0BD20AD206@att.net> X-Mailer: AT&T Message Center Version 1 (May 27 2004) X-Authenticated-Sender: ai5lLmRyZXdzQGF0dC5uZXQ= Subject: Re: PCMCIA Modem causes hang on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 00:25:48 -0000 I enabled kernel debugging by following the steps in section 10, of the developers handbook. After I rebooted, I typed continue at the db> prompt and then logged in. As soon as I inserted the modem card, FreeBSD froze. After rebooting again I found that the kernel core was not saved in /var/crash. I have this in my /etc/rc.conf: dumpdev="/dev/ad0s1b" # Device name to crashdump to (or NO). dumpdir="/var/crash" # Directory where crash dumps are to be stored savecore_flags="" # Used if dumpdev is enabled above, and present. What should I do to get a kernel backtrace? BTW I meant boot option 5 and not option 6, in my last e-mail. Kind regards, Jonathan > FreeBSD 5.2-CURRENT #0: Sun Jun 6 15:45:41 CDT 2004 > Hawking PN612 PCMCIA Modem v.90 From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 17:32:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C12116A4CE; Sun, 6 Jun 2004 17:32:16 -0700 (PDT) Received: from mail.dt.e-technik.uni-dortmund.de (mail.dt.e-technik.Uni-Dortmund.DE [129.217.163.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC5CE43D45; Sun, 6 Jun 2004 17:32:15 -0700 (PDT) (envelope-from ma@dt.e-technik.uni-dortmund.de) Received: from m2a2.dyndns.org (krusty.dt.e-technik.uni-dortmund.de [129.217.163.1])DC0692854A; Mon, 7 Jun 2004 02:32:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id 5F8A0BF9C0; Mon, 7 Jun 2004 02:32:13 +0200 (CEST) Received: from merlin.emma.line.org ([127.0.0.1]) by localhost (m2a2.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14257-06; Mon, 7 Jun 2004 02:32:11 +0200 (CEST) Received: by merlin.emma.line.org (Postfix, from userid 500) id 28109BE882; Mon, 7 Jun 2004 02:32:11 +0200 (CEST) To: Marcel Moolenaar In-Reply-To: <20040606211249.GC96607@dhcp50.pn.xcllnt.net> (Marcel Moolenaar's message of "Sun, 6 Jun 2004 14:12:49 -0700") References: <40C36D31.4010003@freebsd.org> <20040606193510.GA95886@dhcp50.pn.xcllnt.net> <40C37F3C.1050602@freebsd.org> <20040606211249.GC96607@dhcp50.pn.xcllnt.net> From: Matthias Andree Date: Mon, 07 Jun 2004 02:32:11 +0200 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new at m2a2.dyndns.org cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 00:32:16 -0000 Marcel Moolenaar writes: > As for alpha, we don't even seem to be able to degrade it to tier 2 > without losing face. kris@ has already stopped package builds for it > for his own sake. Alpha is special, with what seems to me like a GDB bug. Try this: echo '#include int main() {abort();}' >abortme.c gcc -O2 -o abortme abortme.c ./abortme gdb ./abortme ./core.abortme (inside gdb:) backtrace (inside gdb:) backtrace full (inside gdb:) quit This stuff is run as part of the ports/mail/bogofilter test suite (which is part of the build) determine if core dumps from the build logs are usable. A couple of days ago, the backtrace of the trivial program ended up in an unterminated loop on the build cluster, GDB kept repeating stack frame #0. Whoops. The other architectures appeared fine though. I haven't bothered to file a PR as I don't have an Alpha machine and I'm not comfortable with filing second-hand bugs. -- Matthias Andree Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 01:35:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F2F116A4CE; Mon, 7 Jun 2004 01:35:56 +0000 (GMT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 882A243D55; Sun, 6 Jun 2004 18:35:56 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc12) with ESMTP id <2004060701355501400i4q3me>; Mon, 7 Jun 2004 01:35:56 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA15412; Sun, 6 Jun 2004 18:35:53 -0700 (PDT) Date: Sun, 6 Jun 2004 18:35:51 -0700 (PDT) From: Julian Elischer To: FreeBSD current users Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: net@freebsd.org Subject: HEADSUP! netgraph Metadata changing. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 01:35:56 -0000 If you don't know or care about netgraph metadata (e.g. packet priority) then this shouldn't worry you. We are changing the netgraph metadata facility (in which arbitrary metadata can be sent with a packet through processing) to use the mbuf TAG facility that has been imported by sam. Netgraph tags will use different cookies to the standard set of tags imported with the code, so they will live in a separate namespace, however they will be handled during GC and manipulation by the standard tag handling code (Thanks to Sam for giving us the cookie facility). In the checked in code there are only a couple of users of metadata, but there may be 3rd parties out there that use it. If so the authors should contact me as soon as possible to co-ordinate the changeover. For example the BW_MAN bandwith manager uses metadata to tag packets selected by its ipfw netgraph node. Currently the biggest user of metadata is the frame relay LMI node that tags LMI packets with a higher priority in order to meet timing constraints given by the standards. In addition the ng_ksocket node adds info into metadata and I suspect there are people using that. julian From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 01:59:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4660616A4CE; Mon, 7 Jun 2004 01:59:58 +0000 (GMT) Received: from www.russia.cz (mail.russia.cz [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 424EA43D48; Sun, 6 Jun 2004 18:59:57 -0700 (PDT) (envelope-from sobomax@portaone.com) Received: from portaone.com (localhost [127.0.0.1]) (authenticated bits=0) by www.russia.cz (8.12.8p2/8.12.8) with ESMTP id i571xhI6054988; Mon, 7 Jun 2004 03:59:44 +0200 (CEST) (envelope-from sobomax@portaone.com) Message-ID: <40C3CC0A.2030300@portaone.com> Date: Mon, 07 Jun 2004 04:59:38 +0300 From: Maxim Sobolev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, ru, uk MIME-Version: 1.0 To: wpaul@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Project Evil & ACX100-based cards (D-Link DWL-520+) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 01:59:58 -0000 Hi Bill, I'm trying to make my D-Link DWL-520+ card working with if_ndis, but no luck yet. The card is correctly detected, driver attaches to it. If I configure it in the adhoc mode it is seen from the nearby machine and connected to, but traffic doesn't flow. :-( Any ideas? Please let me know if more information is necessary. Regards, Maxim From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 02:01:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8278F16A4CE; Mon, 7 Jun 2004 02:01:18 +0000 (GMT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id B439643D2D; Sun, 6 Jun 2004 19:01:17 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp50.pn.xcllnt.net (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.12.11/8.12.11) with ESMTP id i571xxrE006401; Sun, 6 Jun 2004 18:59:59 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp50.pn.xcllnt.net (localhost [127.0.0.1]) i571xwnj097769; Sun, 6 Jun 2004 18:59:59 -0700 (PDT) (envelope-from marcel@dhcp50.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp50.pn.xcllnt.net (8.12.11/8.12.11/Submit) id i571xwvt097768; Sun, 6 Jun 2004 18:59:58 -0700 (PDT) (envelope-from marcel) Date: Sun, 6 Jun 2004 18:59:58 -0700 From: Marcel Moolenaar To: Matthias Andree Message-ID: <20040607015958.GA97735@dhcp50.pn.xcllnt.net> References: <40C36D31.4010003@freebsd.org> <20040606193510.GA95886@dhcp50.pn.xcllnt.net> <40C37F3C.1050602@freebsd.org> <20040606211249.GC96607@dhcp50.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 02:01:18 -0000 On Mon, Jun 07, 2004 at 02:32:11AM +0200, Matthias Andree wrote: > Marcel Moolenaar writes: > > > As for alpha, we don't even seem to be able to degrade it to tier 2 > > without losing face. kris@ has already stopped package builds for it > > for his own sake. > > Alpha is special, with what seems to me like a GDB bug. Try this: > > echo '#include > int main() {abort();}' >abortme.c > gcc -O2 -o abortme abortme.c > ./abortme > gdb ./abortme ./core.abortme > (inside gdb:) backtrace > (inside gdb:) backtrace full > (inside gdb:) quit > > This stuff is run as part of the ports/mail/bogofilter test suite (which > is part of the build) determine if core dumps from the build logs are > usable. > > A couple of days ago, the backtrace of the trivial program ended up in > an unterminated loop on the build cluster, GDB kept repeating stack > frame #0. Whoops. The other architectures appeared fine though. This is fixed in gdb 6.x: GNU gdb 6.1.0.90_20040413 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "alpha-intree-freebsd"... Core was generated by `abortme'. Program terminated with signal 6, Aborted. Reading symbols from /lib/libc.so.5...done. Loaded symbols for /lib/libc.so.5 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x00000001601b29bc in kill () from /lib/libc.so.5 (gdb) l 1 #include 2 int main() 3 { 4 abort(); 5 } (gdb) bt #0 0x00000001601b29bc in kill () from /lib/libc.so.5 #1 0x00000001601a5298 in raise () from /lib/libc.so.5 #2 0x0000000160233f88 in abort () from /lib/libc.so.5 #3 0x00000001200008a0 in main () at abortme.c:4 (gdb) An import of gdb 6.1 or gdb 6.1.1 will resolve this. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 02:28:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA58B16A4CE for ; Mon, 7 Jun 2004 02:28:28 +0000 (GMT) Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7021B43D1D for ; Sun, 6 Jun 2004 19:28:28 -0700 (PDT) (envelope-from j.e.drews@att.net) Received: from 204.127.135.43 ([204.127.135.43]) by worldnet.att.net (mtiwmhc11) with SMTP id <200406070228251110090j1de>; Mon, 7 Jun 2004 02:28:25 +0000 Received: from [64.105.56.145] by 204.127.135.43; Mon, 07 Jun 2004 02:28:23 +0000 From: j.e.drews@att.net To: Nate Lawson Date: Mon, 07 Jun 2004 02:28:23 +0000 Message-Id: <060720040228.15268.40C3D2C70002FD6F00003BA421587667559C990A9D0BD20AD206@att.net> X-Mailer: AT&T Message Center Version 1 (May 27 2004) X-Authenticated-Sender: ai5lLmRyZXdzQGF0dC5uZXQ= cc: current@freebsd.org Subject: Re: ACPI Error: AE_NO_HARDWARE_RESPONSE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 02:28:29 -0000 Nate: I am sorry for all the mistakes. Here is the correct dmesg output: http://www.silbsd.org/bugreports/acpi.dmesg2.txt FreeBSD 5.2-CURRENT #0: Sun Jun 6 17:03:51 CDT 2004 root@notebook.silbsd.org:/usr/obj/usr/src/sys/NOTEBOOK Preloaded elf kernel "/boot/kernel/kernel" at 0xc09f3000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc09f3244. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) M processor 1500MHz (1493.94-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x695 Stepping = 5 Features=0xa7e9f9bf real memory = 536281088 (511 MB) avail memory = 515096576 (491 MB) random: > Closer. :) You need options DDB in your kernel. > > FreeBSD 5.2-CURRENT #0: Sat Jun 5 22:58:42 CDT 2004 > root@notebook.silbsd.org:/usr/obj/usr/src/sys/NOTEBOOK > Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a15000. > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a15244. > link_elf: symbol db_readline undefined > ^^^^^^^^^^^^^^ > KLD file acpi.ko - could not finalize loading > > On Sun, 6 Jun 2004 j.e.drews@att.net wrote: > > OK Nate: > > > > Hopefully I have gotten it right this time. > > > > The Regents of the University of California. All rights reserved. > > FreeBSD 5.2-CURRENT #0: Sat Jun 5 22:58:42 CDT 2004 > > root@notebook.silbsd.org:/usr/obj/usr/src/sys/NOTEBOOK > > Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a15000. > > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a15244. > > > > I never could get it to laod at the prompt so I transfered the acpi.ko with > debugging enabled into /boot/kernel. > > > > the new dmesg is here: > > http://www.silbsd.org/bugreports/acpi.dmesg2.txt > > > > Kind regards, > > Jonathan > > > > > > > On Sun, 6 Jun 2004 j.e.drews@att.net wrote: > > > > I have followed your instructions and the output of dmesg is here: > > > >d > > > This indicates you didn't copy acpi.ko to / and maybe copied acpi.kld. > > > Thus there is no debugging output. If it was acpi.ko, it would be labeled > > > "elf module" as below: > > > > > > > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a6127c. > > > ^^^^^^^^^^^^^^^^^^^ > > > > > > Since the kld was not the kernel module, your kernel went and loaded the > > > original acpi.ko from /boot/kernel, which doesn't have debugging enabled. > > > > > > Please check against the instructions I list again below: > > > > > > -Nate > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 03:16:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D553516A4D0; Mon, 7 Jun 2004 03:16:46 +0000 (GMT) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.145.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00B7243D53; Sun, 6 Jun 2004 20:16:46 -0700 (PDT) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id 7DEF04EFCDB; Mon, 7 Jun 2004 11:16:43 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 799514EFCDA; Mon, 7 Jun 2004 11:16:43 +0800 (CST) Date: Mon, 7 Jun 2004 11:16:43 +0800 (CST) From: Tai-hwa Liang To: Don Lewis In-Reply-To: <200406062012.i56KCMjt008540@gw.catspoiler.org> Message-ID: <040607103216B.85106@www.mmlab.cse.yzu.edu.tw> References: <200406062012.i56KCMjt008540@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@FreeBSD.org cc: dl@leo.org Subject: Re: LOR No 9 and strange other kernel messages X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 03:16:47 -0000 On Sun, 6 Jun 2004, Don Lewis wrote: [...] > >> Maybe your sound client software (or something else on the system) is > >> querying for the number of vchans. Even "sysctl -a" will invoke the > >> handler. > > > > I'm using the stock mpg123 0.59r to play MP3 files. Since I've never read > > the source before, I'm not sure whether it utilised vchan related sysctls > > or not. > > The code that calls pcm_inprog() and prints the "x: 2" debug message > appears to be an attempt at implementing a reader/writer lock. I'm > pretty sure the failure that triggers the debug message is harmless, > other than causing the sysctl() call to return EWOULDBLOCK. I'm glad to know that the message is harmless. However, the "x: %d" is a little too obscured to endusers IMHO. Shouldn't that be protected by #ifdef DIAGNOSTIC or something like PCM_DEBUG? > The most likely trigger for this event is if the client software is > writing data to sound device and is blocked in the write() syscall when > another thread calls sysctl(). You could find out which process is > calling sysctl() by printing curproc->p_pid in place of or in addition > to x. Ah, that explained everything. I've added the diagnostic code in sys/dev/sound/pcm/sound.c, and can 100% trigger this while mpg123 is playing and having a "sysctl -a" running in another xterm at the same time. x: 2, current pid: 39234 (sysctl) x: 2, current pid: 39234 (sysctl) It also looks like gcc will use sysctl() to retrieve physical memory size before compilation. I guess the "x: 2" I ran into was just a result of running gcc too frequently(make buildworld buildkernel). > [...] > >> Do your sound hardware and em0 share the same irq? If they do, that > > > > Nope. > > > > interrupt total rate > > irq0: clk 356127 99 > > irq1: atkbd0 6006 1 > > irq4: cbb0 em0++ 1378364 386 > > irq6: cbb1 pcm0 110211 30 > > irq7: ppc0 3 0 > > irq8: rtc 455852 127 > > irq12: psm0 16785 4 > > irq13: npx0 1 0 > > irq14: ata0 322853 90 > > irq15: ata1 55 0 > > Total 2646257 742 > > In that case, the em0 problem is likely to be something else. Does em0 > lock up even if you don't use the sound hardware? Yes. It always locked up if the network load is high(w/ ACPI enabled). > > >> might be a clue that the problems are related. Can you boot with ACPI > >> disabled, and if so, does it change the symptoms? > > > > Whoops! My first trial on booting without ACPI -- kernel panic in > > usb_get_next_event(). Apparently I have to disconnect the USB mouse > > prior to kernel booting. See final section for the backtrace. > > Sounds like bug #3. Any idea about how bug #3 can happen? I've tried to comment out the #ifdef DIAGNOSTIC code around sys/dev/usb/usb.c:752 to see if the extra checking for NULL ue helps. Unfortunately that didn't work for me: the kernel always panic at usb_get_next_event+0x5e after starting usbd. > > And, yes, the em0 didn't hang after booting to the non-ACPI environment. > > However, there're still something weird happening at that moment: > > > > 1. There're still a couple of "x: 2" dumped on console. Test case: > > "make buildworld buildkernel -DNOCLEAN" in one xterm, mpg123 in > > another xterm, and providing file downloading to another Windoze > > box. > > > > 2. While the remote box was downloading(Intel eepro 100/VE) files, > > the number of interrupt on em0 was dramatically reduced to 300 ~ 500+ > > per second. It was 3000+ when ACPI was enabled(no device polling in > > kernel). > > > > 3. The system average load is surprising low(I'm using SCHED_4BSD), > > about 0.06 ~ 0.30; however, the download was awfully slooowwwww. > > It took my brother's Windoze XP about 25 minutes to complete the > > whole downloading(3 ISO files, about 2GB in total). I'm pretty sure > > that the mediaopt on em0 was 100baseTX + full-duplex. > > I wonder if the em0 interrupt is not getting enabled or is getting > misrouted and the em0 interrupt service routing is getting triggered by > another interrupt source that is happening at a lower rate. Print out > the irq mapping with ACPI disabled to see what em0 is sharing its irq > with. This is probably something that jhb and njl will need to look at. Oops, it looks like I accidentally enabled the DEVICE_POLLING in kernel configuration file and forgot to turn kern.polling.enable on. After disabling DEVICE_POLLING and booting w/o ACPI, I can get rid of the aforementioned em0 sluggish problem. The interrupt rate on em0 is now 5700 ~ 7200 per second while downloading a couple of files from this laptop, and the average speed is 10+ MBytes. Hmm... it seems that I have to disable USB mouse and ACPI to get em0 back to work at this moment. I'm not quite sure about where the "IRQ mapping" you're talking about to retrieve from; therefore, I assume that came from dmesg: Found $PIR table, 15 entries at 0xc00fdea0 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 0 0 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 0 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 2 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 2 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 1 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 1 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 1 0 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 1 0 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 30 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 30 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 30 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 30 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 2 0 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 2 0 B 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 1 2 2 A 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 1 2 2 B 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 2 3 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 2 3 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 2 3 D 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 2 9 0 A 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 2 9 0 B 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 2 9 0 C 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 2 9 0 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 9 1 A 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 9 2 A 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 9 2 B 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 2 1 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 2 8 A 0x68 3 4 5 6 7 9 10 11 12 14 15 embedded 0 29 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 29 B 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 29 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 29 D 0x6b 3 4 5 6 7 9 10 11 12 14 15 embedded 0 31 A 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 31 B 0x61 3 4 5 6 7 9 10 11 12 14 15 pcib0: at pcibus 0 on motherboard pir0: on motherboard $PIR: Links after initial probe: Link IRQ Rtd Ref IRQs 0x60 255 N 10 3 4 5 6 7 9 10 11 12 14 15 0x61 255 N 10 3 4 5 6 7 9 10 11 12 14 15 0x62 255 N 8 3 4 5 6 7 9 10 11 12 14 15 0x63 255 N 6 3 4 5 6 7 9 10 11 12 14 15 0x68 255 N 1 3 4 5 6 7 9 10 11 12 14 15 0x6b 255 N 1 3 4 5 6 7 9 10 11 12 14 15 $PIR: Found matching pin for 1.0.INTA at func 0: 4 $PIR: Found matching pin for 2.0.INTA at func 0: 4 $PIR: Found matching pin for 2.0.INTB at func 1: 6 $PIR: Found matching pin for 2.2.INTA at func 0: 11 $PIR: Found matching pin for 2.1.INTA at func 0: 4 $PIR: Found matching pin for 0.29.INTA at func 0: 4 $PIR: Found matching pin for 0.29.INTB at func 1: 10 $PIR: Found matching pin for 0.29.INTC at func 2: 11 $PIR: Found matching pin for 0.29.INTD at func 7: 11 $PIR: Found matching pin for 0.31.INTA at func 1: 255 $PIR: Found matching pin for 0.31.INTB at func 3: 6 $PIR: Links after initial IRQ discovery: Link IRQ Rtd Ref IRQs 0x60 4 Y 10 3 4 5 6 7 9 10 11 12 14 15 0x61 6 Y 10 3 4 5 6 7 9 10 11 12 14 15 0x62 11 Y 8 3 4 5 6 7 9 10 11 12 14 15 0x63 10 Y 6 3 4 5 6 7 9 10 11 12 14 15 0x68 255 N 1 3 4 5 6 7 9 10 11 12 14 15 0x6b 11 Y 1 3 4 5 6 7 9 10 11 12 14 15 $PIR: IRQs used by BIOS: 4 6 10 11 $PIR: Interrupt Weights: [ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ] [ 0 0 0 0 10 0 10 0 0 0 6 9 0 0 0 0 ] For the complete dmesg, please consult: http://www.mmlab.cse.yzu.edu.tw/~avatar/dmesg-noacpi.txt http://www.mmlab.cse.yzu.edu.tw/~avatar/dmesg-acpi.txt From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 04:38:04 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F20AE16A4E2; Mon, 7 Jun 2004 04:38:03 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5724643D46; Mon, 7 Jun 2004 04:38:03 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i574ZYgg010043; Sun, 6 Jun 2004 22:35:35 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 06 Jun 2004 22:35:44 -0600 (MDT) Message-Id: <20040606.223544.13027668.imp@bsdimp.com> To: marcel@xcllnt.net From: "M. Warner Losh" In-Reply-To: <20040606220432.GA97091@dhcp50.pn.xcllnt.net> References: <20040606211249.GC96607@dhcp50.pn.xcllnt.net> <20040606220432.GA97091@dhcp50.pn.xcllnt.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 04:38:04 -0000 In message: <20040606220432.GA97091@dhcp50.pn.xcllnt.net> Marcel Moolenaar writes: : On Sun, Jun 06, 2004 at 05:27:56PM -0400, Daniel Eischen wrote: : > : > > As for alpha, we don't even seem to be able to degrade it to tier 2 : > > without losing face. kris@ has already stopped package builds for it : > > for his own sake. : > : > We shouldn't keep an arch at tier 1 just to save face. Better to just : > lower it to tier 2 and be done with it. My $.02, FWIW. : : You misunderstand my statement. Lowering alpha to tier 2 is what I : suggested multiple times before. The point is that we haven't yet : and alpha is degenerating more and more while we fail to adjust : the tierness. That's where we fail to save face. I tend to agree. Tierness is a combination of politics and technical reality. The rality of the situation with alpha is that it has had no clothes long enough that it no longer reflects the Tier-1 ideas that we strive to attain. Warner From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 04:48:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A677E16A4CE for ; Mon, 7 Jun 2004 04:48:38 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id E98E143D4C for ; Mon, 7 Jun 2004 04:48:37 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i574mTpP009303; Sun, 6 Jun 2004 21:48:33 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200406070448.i574mTpP009303@gw.catspoiler.org> Date: Sun, 6 Jun 2004 21:48:29 -0700 (PDT) From: Don Lewis To: avatar@mmlab.cse.yzu.edu.tw In-Reply-To: <040607103216B.85106@www.mmlab.cse.yzu.edu.tw> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-current@FreeBSD.org cc: dl@leo.org Subject: Re: LOR No 9 and strange other kernel messages X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 04:48:38 -0000 On 7 Jun, Tai-hwa Liang wrote: > On Sun, 6 Jun 2004, Don Lewis wrote: > [...] >> >> Maybe your sound client software (or something else on the system) is >> >> querying for the number of vchans. Even "sysctl -a" will invoke the >> >> handler. >> > >> > I'm using the stock mpg123 0.59r to play MP3 files. Since I've never read >> > the source before, I'm not sure whether it utilised vchan related sysctls >> > or not. >> >> The code that calls pcm_inprog() and prints the "x: 2" debug message >> appears to be an attempt at implementing a reader/writer lock. I'm >> pretty sure the failure that triggers the debug message is harmless, >> other than causing the sysctl() call to return EWOULDBLOCK. > > I'm glad to know that the message is harmless. However, the "x: %d" is > a little too obscured to endusers IMHO. Shouldn't that be protected by > #ifdef DIAGNOSTIC or something like PCM_DEBUG? This diagnotic message should probably just go away. Also the locking should be fixed to avoid the EWOULDBLOCK error. >> The most likely trigger for this event is if the client software is >> writing data to sound device and is blocked in the write() syscall when >> another thread calls sysctl(). You could find out which process is >> calling sysctl() by printing curproc->p_pid in place of or in addition >> to x. > > Ah, that explained everything. I've added the diagnostic code in > sys/dev/sound/pcm/sound.c, and can 100% trigger this while mpg123 is > playing and having a "sysctl -a" running in another xterm at the same time. > > x: 2, current pid: 39234 (sysctl) > x: 2, current pid: 39234 (sysctl) > > It also looks like gcc will use sysctl() to retrieve physical memory size > before compilation. I guess the "x: 2" I ran into was just a result of > running gcc too frequently(make buildworld buildkernel). Gcc only looks up hw.physmem and hw.usermem, so it shouldn't trigger this message. >> > [...] >> >> Do your sound hardware and em0 share the same irq? If they do, that >> > >> > Nope. >> > >> > interrupt total rate >> > irq0: clk 356127 99 >> > irq1: atkbd0 6006 1 >> > irq4: cbb0 em0++ 1378364 386 >> > irq6: cbb1 pcm0 110211 30 >> > irq7: ppc0 3 0 >> > irq8: rtc 455852 127 >> > irq12: psm0 16785 4 >> > irq13: npx0 1 0 >> > irq14: ata0 322853 90 >> > irq15: ata1 55 0 >> > Total 2646257 742 >> >> In that case, the em0 problem is likely to be something else. Does em0 >> lock up even if you don't use the sound hardware? > > Yes. It always locked up if the network load is high(w/ ACPI enabled). > >> >> >> might be a clue that the problems are related. Can you boot with ACPI >> >> disabled, and if so, does it change the symptoms? >> > >> > Whoops! My first trial on booting without ACPI -- kernel panic in >> > usb_get_next_event(). Apparently I have to disconnect the USB mouse >> > prior to kernel booting. See final section for the backtrace. >> >> Sounds like bug #3. > > Any idea about how bug #3 can happen? I've tried to comment out the > #ifdef DIAGNOSTIC code around sys/dev/usb/usb.c:752 to see if the extra > checking for NULL ue helps. Unfortunately that didn't work for me: the > kernel always panic at usb_get_next_event+0x5e after starting usbd. I'd recommend posting a separate message about this panic. That way you are more likely to catch the attention of a USB expert. >> > And, yes, the em0 didn't hang after booting to the non-ACPI environment. >> > However, there're still something weird happening at that moment: >> > >> > 1. There're still a couple of "x: 2" dumped on console. Test case: >> > "make buildworld buildkernel -DNOCLEAN" in one xterm, mpg123 in >> > another xterm, and providing file downloading to another Windoze >> > box. >> > >> > 2. While the remote box was downloading(Intel eepro 100/VE) files, >> > the number of interrupt on em0 was dramatically reduced to 300 ~ 500+ >> > per second. It was 3000+ when ACPI was enabled(no device polling in >> > kernel). >> > >> > 3. The system average load is surprising low(I'm using SCHED_4BSD), >> > about 0.06 ~ 0.30; however, the download was awfully slooowwwww. >> > It took my brother's Windoze XP about 25 minutes to complete the >> > whole downloading(3 ISO files, about 2GB in total). I'm pretty sure >> > that the mediaopt on em0 was 100baseTX + full-duplex. >> >> I wonder if the em0 interrupt is not getting enabled or is getting >> misrouted and the em0 interrupt service routing is getting triggered by >> another interrupt source that is happening at a lower rate. Print out >> the irq mapping with ACPI disabled to see what em0 is sharing its irq >> with. This is probably something that jhb and njl will need to look at. > > Oops, it looks like I accidentally enabled the DEVICE_POLLING in kernel > configuration file and forgot to turn kern.polling.enable on. > > After disabling DEVICE_POLLING and booting w/o ACPI, I can get rid of > the aforementioned em0 sluggish problem. The interrupt rate on em0 is > now 5700 ~ 7200 per second while downloading a couple of files from this > laptop, and the average speed is 10+ MBytes. > > Hmm... it seems that I have to disable USB mouse and ACPI to get em0 > back to work at this moment. > > I'm not quite sure about where the "IRQ mapping" you're talking about to > retrieve from; therefore, I assume that came from dmesg: > > Found $PIR table, 15 entries at 0xc00fdea0 > PCI-Only Interrupts: none > Location Bus Device Pin Link IRQs > embedded 0 0 A 0x60 3 4 5 6 7 9 10 11 12 14 15 > embedded 0 0 B 0x61 3 4 5 6 7 9 10 11 12 14 15 > embedded 0 0 C 0x62 3 4 5 6 7 9 10 11 12 14 15 > embedded 0 0 D 0x63 3 4 5 6 7 9 10 11 12 14 15 > embedded 0 2 A 0x60 3 4 5 6 7 9 10 11 12 14 15 > embedded 0 2 B 0x61 3 4 5 6 7 9 10 11 12 14 15 > embedded 0 1 A 0x60 3 4 5 6 7 9 10 11 12 14 15 > embedded 0 1 B 0x61 3 4 5 6 7 9 10 11 12 14 15 > embedded 1 0 A 0x60 3 4 5 6 7 9 10 11 12 14 15 > embedded 1 0 B 0x61 3 4 5 6 7 9 10 11 12 14 15 > embedded 0 30 A 0x60 3 4 5 6 7 9 10 11 12 14 15 > embedded 0 30 B 0x61 3 4 5 6 7 9 10 11 12 14 15 > embedded 0 30 C 0x62 3 4 5 6 7 9 10 11 12 14 15 > embedded 0 30 D 0x63 3 4 5 6 7 9 10 11 12 14 15 > embedded 2 0 A 0x60 3 4 5 6 7 9 10 11 12 14 15 > embedded 2 0 B 0x61 3 4 5 6 7 9 10 11 12 14 15 > slot 1 2 2 A 0x62 3 4 5 6 7 9 10 11 12 14 15 > slot 1 2 2 B 0x63 3 4 5 6 7 9 10 11 12 14 15 > embedded 2 3 A 0x60 3 4 5 6 7 9 10 11 12 14 15 > embedded 2 3 B 0x61 3 4 5 6 7 9 10 11 12 14 15 > embedded 2 3 D 0x63 3 4 5 6 7 9 10 11 12 14 15 > slot 2 9 0 A 0x60 3 4 5 6 7 9 10 11 12 14 15 > slot 2 9 0 B 0x61 3 4 5 6 7 9 10 11 12 14 15 > slot 2 9 0 C 0x62 3 4 5 6 7 9 10 11 12 14 15 > slot 2 9 0 D 0x63 3 4 5 6 7 9 10 11 12 14 15 > embedded 9 1 A 0x61 3 4 5 6 7 9 10 11 12 14 15 > embedded 9 2 A 0x62 3 4 5 6 7 9 10 11 12 14 15 > embedded 9 2 B 0x62 3 4 5 6 7 9 10 11 12 14 15 > embedded 2 1 A 0x60 3 4 5 6 7 9 10 11 12 14 15 > embedded 2 8 A 0x68 3 4 5 6 7 9 10 11 12 14 15 > embedded 0 29 A 0x60 3 4 5 6 7 9 10 11 12 14 15 > embedded 0 29 B 0x63 3 4 5 6 7 9 10 11 12 14 15 > embedded 0 29 C 0x62 3 4 5 6 7 9 10 11 12 14 15 > embedded 0 29 D 0x6b 3 4 5 6 7 9 10 11 12 14 15 > embedded 0 31 A 0x62 3 4 5 6 7 9 10 11 12 14 15 > embedded 0 31 B 0x61 3 4 5 6 7 9 10 11 12 14 15 > pcib0: at pcibus 0 on motherboard > pir0: on motherboard > $PIR: Links after initial probe: > Link IRQ Rtd Ref IRQs > 0x60 255 N 10 3 4 5 6 7 9 10 11 12 14 15 > 0x61 255 N 10 3 4 5 6 7 9 10 11 12 14 15 > 0x62 255 N 8 3 4 5 6 7 9 10 11 12 14 15 > 0x63 255 N 6 3 4 5 6 7 9 10 11 12 14 15 > 0x68 255 N 1 3 4 5 6 7 9 10 11 12 14 15 > 0x6b 255 N 1 3 4 5 6 7 9 10 11 12 14 15 > $PIR: Found matching pin for 1.0.INTA at func 0: 4 > $PIR: Found matching pin for 2.0.INTA at func 0: 4 > $PIR: Found matching pin for 2.0.INTB at func 1: 6 > $PIR: Found matching pin for 2.2.INTA at func 0: 11 > $PIR: Found matching pin for 2.1.INTA at func 0: 4 > $PIR: Found matching pin for 0.29.INTA at func 0: 4 > $PIR: Found matching pin for 0.29.INTB at func 1: 10 > $PIR: Found matching pin for 0.29.INTC at func 2: 11 > $PIR: Found matching pin for 0.29.INTD at func 7: 11 > $PIR: Found matching pin for 0.31.INTA at func 1: 255 > $PIR: Found matching pin for 0.31.INTB at func 3: 6 > $PIR: Links after initial IRQ discovery: > Link IRQ Rtd Ref IRQs > 0x60 4 Y 10 3 4 5 6 7 9 10 11 12 14 15 > 0x61 6 Y 10 3 4 5 6 7 9 10 11 12 14 15 > 0x62 11 Y 8 3 4 5 6 7 9 10 11 12 14 15 > 0x63 10 Y 6 3 4 5 6 7 9 10 11 12 14 15 > 0x68 255 N 1 3 4 5 6 7 9 10 11 12 14 15 > 0x6b 11 Y 1 3 4 5 6 7 9 10 11 12 14 15 > $PIR: IRQs used by BIOS: 4 6 10 11 > $PIR: Interrupt Weights: > [ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ] > [ 0 0 0 0 10 0 10 0 0 0 6 9 0 0 0 0 ] > > For the complete dmesg, please consult: > > http://www.mmlab.cse.yzu.edu.tw/~avatar/dmesg-noacpi.txt > http://www.mmlab.cse.yzu.edu.tw/~avatar/dmesg-acpi.txt Wierd ... in the ACPI case, em0 gets attached, gets detached, and then gets attached again. em0: port 0x8000-0x803f mem 0xc0200000-0xc020ffff,0xc0220000-0xc023ffff irq 4 at device 1.0 on pci2 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xc0220000 em0: Reserved 0x40 bytes for rid 0x18 type 4 at 0x8000 em0: [GIANT-LOCKED] em0: bpf attached em0: Speed:N/A Duplex:N/A [ snip ] em0: Link is up 100 Mbps Full Duplex [ snip ] em0: detached [ snip ] em0: port 0x8000-0x803f mem 0xc0200000-0xc020ffff,0xc0220000-0xc023ffff irq 4 at device 1.0 on pci2 pcib2: device em0 requested decoded memory range 0xc0220000-0xc023ffff pcib2: device em0 requested decoded I/O range 0x8000-0x803f em0: [GIANT-LOCKED] em0: bpf attached em0: Speed:N/A Duplex:N/A em0: Link is up 100 Mbps Full Duplex It looks like em0 shares irq 4 with the exact same set of devices in both cases. It does seem strange to me that it is sharing irq 4 with sio0. Typically the sio ports get exclusive use of irqs. The whole part of the dmesg starting with "em0: detached" and "pci0: driver added" is something that I haven't seen before, but I'm not running bleeding edge -CURRENT at the moment. I'd recommend starting a separate thread to discuss your em0 problem. From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 04:50:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F1B516A4CE for ; Mon, 7 Jun 2004 04:50:22 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECF9E43D1F for ; Mon, 7 Jun 2004 04:50:21 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id CEA8672DF2; Sun, 6 Jun 2004 21:50:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id CCD5972DB5; Sun, 6 Jun 2004 21:50:21 -0700 (PDT) Date: Sun, 6 Jun 2004 21:50:21 -0700 (PDT) From: Doug White To: hugle In-Reply-To: <682287278.20040604094325@vkt.lt> Message-ID: <20040606215000.M12662@carver.gumbysoft.com> References: <682287278.20040604094325@vkt.lt> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: scheidell@secnap.net cc: freebsd-current@freebsd.org Subject: Re: arp: unknown hardware address format X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 04:50:22 -0000 On Fri, 4 Jun 2004, hugle wrote: > Hello > I'm currently using FreeBSD 4.10 (stable) > cvsup on 2004-05-30(31) > I also have a bge NIC, and i'm getting identical messages in dmesg Usually there's a number after that message. I usually find they're caused by something generating bad packets on the wire, or perhaps a duplex issue. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 05:05:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A658416A4CE for ; Mon, 7 Jun 2004 05:05:03 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9671C43D48 for ; Mon, 7 Jun 2004 05:05:03 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 8893472DF2; Sun, 6 Jun 2004 22:05:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 848B672DB5; Sun, 6 Jun 2004 22:05:03 -0700 (PDT) Date: Sun, 6 Jun 2004 22:05:03 -0700 (PDT) From: Doug White To: Phil Schulz In-Reply-To: <40C3960F.4080305@gmx.de> Message-ID: <20040606220342.W12662@carver.gumbysoft.com> References: <40C3960F.4080305@gmx.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: Execute BIOS function X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 05:05:03 -0000 On Mon, 7 Jun 2004, Phil Schulz wrote: > Hello List! > > The radio transmitter of my new centrino laptop is turned on by a BIOS > function which resides at a certain location in memory. I know how to > find the adress of the function's start but I don't yet know how to tell > the OS that I do want to execute that memory region and make it let me > do so. When running the program I get "Bus error (core dumped)". So the > question is: Can I actually execute the BIOS code from userland or do I > have to do it from kernelspace? How do I tell the kernel that I want the > memory region to be executed and make it let me do so? You'll have to do it from the kernel. The BIOS call will probably want to poke memory and I/O ports you won't have access to. You'll also need to know if its 32-bit protected mode safe or not; if not you'll have to set up VM86() to make the call. Have you checked for an ACPI method that implements the same thing? > > Any help is appreciated. > > Thanks, > Phil. > > -- > > This is a part of the code (I hope it's not going to be wrapped). > bios_code_addr holds the BIOS function's start address and dev_mem is a > file-descriptor to /dev/mem. > > ptr = mmap( 0, BIOS_CODE_SIZE, PROT_EXEC, > 0, dev_mem, bios_code_addr ); > > __asm__ __volatile__ ( > "call *%3 \t\n" > : "=a"(eax) > : "a"(eax), "b"(ebx), "c"(ptr) > ); > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 05:09:42 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA8C316A4CE for ; Mon, 7 Jun 2004 05:09:42 +0000 (GMT) Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id EABC343D45 for ; Mon, 7 Jun 2004 05:09:41 +0000 (GMT) (envelope-from j.e.drews@att.net) Received: from 204.127.135.57 ([204.127.135.57]) by worldnet.att.net (mtiwmhc13) with SMTP id <2004060705093911300rgkv8e>; Mon, 7 Jun 2004 05:09:39 +0000 Received: from [64.105.56.145] by 204.127.135.57; Mon, 07 Jun 2004 05:09:41 +0000 From: j.e.drews@att.net To: "M. Warner Losh" Date: Mon, 07 Jun 2004 05:09:41 +0000 Message-Id: <060720040509.2054.40C3F894000BED390000080621603763169C990A9D0BD20AD206@att.net> X-Mailer: AT&T Message Center Version 1 (May 27 2004) X-Authenticated-Sender: ai5lLmRyZXdzQGF0dC5uZXQ= cc: freebsd-current@freebsd.org Subject: Re: PCMCIA Modem causes hang on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 05:09:42 -0000 Hello Warner: I tried a good bit this weekend to get this card to work in NetBSD but it did not. The latest dmesg output is here: http://www.silbsd.org/bugreports/acpi.dmesg2.txt I also saw this entry in the /etc/defaults/pccard.conf: # Zoom 56K modem # Freezes your system entirely if you don't have the reset.. card "Zoom Telephonics, Inc." "PCMCIA 56K LT DataFax" config auto "sio" ? reset 1000 I wonder if that freeze condition would apply to this card also? Would the reset 1000 be the same? Recall that my Hawking PN612 tries to use sio4. I will continue with the kernel debugging and try to get a core file. Kind regards, Jonathan > In message: > <060520040358.29568.40C144E6000BC49F0000738021603762239C990A9D0BD20AD206@att.net > > > j.e.drews@att.net writes: > : Hello Warner: > : > : Unfortunately, other than what I have copied by hand below there is > : no dmesg. Nor is there anything in /var/log/messages, as the laptop > : hangs before anything can be written and then I have to do a hard > : reboot. > > Can you give me a dmesg w/o the modem card inserted? > > Warner From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 05:10:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECBBA16A4D0 for ; Mon, 7 Jun 2004 05:10:06 +0000 (GMT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id D96BC43D49 for ; Mon, 7 Jun 2004 05:10:06 +0000 (GMT) (envelope-from nate@root.org) Received: (qmail 68691 invoked by uid 1000); 7 Jun 2004 05:10:04 -0000 Date: Sun, 6 Jun 2004 22:10:04 -0700 (PDT) From: Nate Lawson To: j.e.drews@att.net In-Reply-To: <060220040117.21540.40BD2ABA0008FE0E000054242160281302FF8C889A8D9BD19AD1@att.net> Message-ID: <20040606215445.R68528@root.org> References: <060220040117.21540.40BD2ABA0008FE0E000054242160281302FF8C889A8D9BD19AD1@att.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: ACPI Error: AE_NO_HARDWARE_RESPONSE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 05:10:07 -0000 On Wed, 2 Jun 2004 j.e.drews@att.net wrote: > I made the polling adjustment that you suggested: > sysctl hw.acpi.thermal.polling_rate=1 > > and then ran the script while compiling qt33 and Mozilla at the same time. > the initial reading was at: hw.acpi.thermal.tz0.temperature: 3112 > the high temps were: > hw.acpi.thermal.tz0.temperature: 3242 > hw.acpi.thermal.tz0.temperature: 3252 > > the fan kicked on at 3232. I could not get the error again, even though > I ran the computer under load for quite a while. Ok, thanks for all the debugging info. There are two issues here: --- GEOM: Configure ad0s1f, start 1851564032 length 22418914816 end 24270478847 acpi_ec0: info: new max delay is 75 us acpi_ec0: info: new max delay is 90 us acpi_ec0: info: new max delay is 210 us acpi_ec0: info: new max delay is 805 us acpi_ec0: info: new max delay is 900 us system power profile changed to 'economy' --- 1. Embedded controller read times out during boot. As seen above, during the probe of your flash key, the EC hits higher and higher delays until finally timing out. The issue is that ACPI acquires Giant and so does CAM (which is probing your flash drive). Try booting without your flash key inserted and see if the error goes away. I am working on a patch for ACPI to run Giant-free that should address this. It's almost done. --- POWERRES-0257 [20] acpi_pwr_register_cons: registered power consumer \\_SB_.PCI0.USB7 POWERRES-0350 [19] acpi_pwr_switch_consum: setup to switch \\_SB_.PCI0.USB7 D255 -> D3 POWERRES-0479 [19] acpi_pwr_switch_consum: attempt to set unsupported state D3 pci0: Failed to set ACPI power state D3 on (null): AE_BAD_PARAMETER POWERRES-0257 [20] acpi_pwr_register_cons: registered power consumer \\_SB_.PCI0.MODM POWERRES-0350 [19] acpi_pwr_switch_consum: setup to switch \\_SB_.PCI0.MODM D255 -> D3 POWERRES-0479 [19] acpi_pwr_switch_consum: attempt to set unsupported state D3 pci0: Failed to set ACPI power state D3 on (null): AE_BAD_PARAMETER --- 2. Error messages for power switching consumer. These are harmless but I'll remove them. The power state routines try to power down your USB7 and built-in modem since no driver attached them. However, they don't offer power control via ACPI so the attempt returns a harmless error message. I'll add checks for this. Thanks for the help, Nate From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 05:11:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3115716A4D0 for ; Mon, 7 Jun 2004 05:11:25 +0000 (GMT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 01BDD43D49 for ; Mon, 7 Jun 2004 05:11:25 +0000 (GMT) (envelope-from nate@root.org) Received: (qmail 68714 invoked by uid 1000); 7 Jun 2004 05:11:17 -0000 Date: Sun, 6 Jun 2004 22:11:17 -0700 (PDT) From: Nate Lawson To: j.e.drews@att.net In-Reply-To: <20040606215445.R68528@root.org> Message-ID: <20040606221049.X68528@root.org> References: <060220040117.21540.40BD2ABA0008FE0E000054242160281302FF8C889A8D9BD19AD1@att.net> <20040606215445.R68528@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: ACPI Error: AE_NO_HARDWARE_RESPONSE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 05:11:25 -0000 On Sun, 6 Jun 2004, Nate Lawson wrote: > On Wed, 2 Jun 2004 j.e.drews@att.net wrote: > > I made the polling adjustment that you suggested: > > sysctl hw.acpi.thermal.polling_rate=1 > > > > and then ran the script while compiling qt33 and Mozilla at the same time. > > the initial reading was at: hw.acpi.thermal.tz0.temperature: 3112 > > the high temps were: > > hw.acpi.thermal.tz0.temperature: 3242 > > hw.acpi.thermal.tz0.temperature: 3252 > > > > the fan kicked on at 3232. I could not get the error again, even though > > I ran the computer under load for quite a while. > > Ok, thanks for all the debugging info. There are two issues here: One more thing -- you're running the Radeon driver. It's likely that would interfere with suspend/resume. But feel free to test. -Nate From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 05:19:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0977716A4CE for ; Mon, 7 Jun 2004 05:19:20 +0000 (GMT) Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC74543D48 for ; Mon, 7 Jun 2004 05:19:19 +0000 (GMT) (envelope-from j.e.drews@att.net) Received: from 204.127.135.57 ([204.127.135.57]) by worldnet.att.net (mtiwmhc12) with SMTP id <2004060705191611200ct7m6e>; Mon, 7 Jun 2004 05:19:16 +0000 Received: from [64.105.56.145] by 204.127.135.57; Mon, 07 Jun 2004 05:19:18 +0000 From: j.e.drews@att.net To: Nate Lawson Date: Mon, 07 Jun 2004 05:19:18 +0000 Message-Id: <060720040519.5589.40C3FAD600056431000015D521603763169C990A9D0BD20AD206@att.net> X-Mailer: AT&T Message Center Version 1 (May 27 2004) X-Authenticated-Sender: ai5lLmRyZXdzQGF0dC5uZXQ= cc: current@freebsd.org Subject: Re: ACPI Error: AE_NO_HARDWARE_RESPONSE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 05:19:20 -0000 Hi Nate: Good thought! I will change to the ati driver. No -- that is just a superset; which will load the radeon. Hmm I will check up on this and find a generic driver > On Sun, 6 Jun 2004, Nate Lawson wrote: > > On Wed, 2 Jun 2004 j.e.drews@att.net wrote: > > > I made the polling adjustment that you suggested: > > > sysctl hw.acpi.thermal.polling_rate=1 > > > > > > and then ran the script while compiling qt33 and Mozilla at the same time. > > > the initial reading was at: hw.acpi.thermal.tz0.temperature: 3112 > > > the high temps were: > > > hw.acpi.thermal.tz0.temperature: 3242 > > > hw.acpi.thermal.tz0.temperature: 3252 > > > > > > the fan kicked on at 3232. I could not get the error again, even though > > > I ran the computer under load for quite a while. > > > > Ok, thanks for all the debugging info. There are two issues here: > > One more thing -- you're running the Radeon driver. It's likely that > would interfere with suspend/resume. But feel free to test. > > -Nate From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 05:22:40 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53A7B16A4CE for ; Mon, 7 Jun 2004 05:22:40 +0000 (GMT) Received: from mailhub01.unibe.ch (mailhub01.unibe.ch [130.92.9.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id D496143D46 for ; Mon, 7 Jun 2004 05:22:39 +0000 (GMT) (envelope-from roth@speedy.unibe.ch) Received: from localhost (scanhub01-eth0.unibe.ch [130.92.254.65]) by mailhub01.unibe.ch (Postfix) with ESMTP id 92AF125BAA4; Mon, 7 Jun 2004 07:22:38 +0200 (MEST) Received: from mailhub01.unibe.ch ([130.92.9.52]) by localhost (scanhub01 [130.92.254.65]) (amavisd-new, port 10024) with LMTP id 23895-12-86; Mon, 7 Jun 2004 07:22:39 +0200 (CEST) Received: from asterix.unibe.ch (asterix.unibe.ch [130.92.64.4]) by mailhub01.unibe.ch (Postfix) with ESMTP id E36E525BAF5; Mon, 7 Jun 2004 07:22:37 +0200 (MEST) Received: from speedy.unibe.ch (speedy [130.92.64.35]) by asterix.unibe.ch (8.11.7p1+Sun/8.11.7) with ESMTP id i575Mbu29558; Mon, 7 Jun 2004 07:22:37 +0200 (MET DST) Received: (from roth@localhost) by speedy.unibe.ch (8.12.10+Sun/8.12.9/Submit) id i575MbMt015310; Mon, 7 Jun 2004 07:22:37 +0200 (MEST) Date: Mon, 7 Jun 2004 07:22:37 +0200 From: Tobias Roth To: Nate Lawson Message-ID: <20040607052237.GA15296@speedy.unibe.ch> References: <060220040117.21540.40BD2ABA0008FE0E000054242160281302FF8C889A8D9BD19AD1@att.net> <20040606215445.R68528@root.org> <20040606221049.X68528@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040606221049.X68528@root.org> User-Agent: Mutt/1.4i X-message-flag: Warning! Using Outlook is insecure and promotes virus distribution. Please use a different email client. X-Virus-checked: by University of Berne cc: freebsd-current@freebsd.org cc: j.e.drews@att.net Subject: Re: ACPI Error: AE_NO_HARDWARE_RESPONSE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 05:22:40 -0000 On Sun, Jun 06, 2004 at 10:11:17PM -0700, Nate Lawson wrote: > > One more thing -- you're running the Radeon driver. It's likely that > would interfere with suspend/resume. But feel free to test. just fyi, it does somewhat interfere on my thinkpad: radeon alone in the kernel is just fine, but in order to get suspend/resume from within X working, i have to turn off dri in XF86Config. Not that i mind much. cheers, t. From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 05:27:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C39A16A4CE for ; Mon, 7 Jun 2004 05:27:52 +0000 (GMT) Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1725C43D2F for ; Mon, 7 Jun 2004 05:27:52 +0000 (GMT) (envelope-from j.e.drews@att.net) Received: from 204.127.135.57 ([204.127.135.57]) by worldnet.att.net (mtiwmhc13) with SMTP id <2004060705274911300i3o0re>; Mon, 7 Jun 2004 05:27:49 +0000 Received: from [64.105.56.145] by 204.127.135.57; Mon, 07 Jun 2004 05:27:50 +0000 From: j.e.drews@att.net To: Tobias Roth Date: Mon, 07 Jun 2004 05:27:50 +0000 Message-Id: <060720040527.8717.40C3FCD5000E8E650000220D21603763169C990A9D0BD20AD206@att.net> X-Mailer: AT&T Message Center Version 1 (May 27 2004) X-Authenticated-Sender: ai5lLmRyZXdzQGF0dC5uZXQ= cc: freebsd-current@freebsd.org Subject: Re: ACPI Error: AE_NO_HARDWARE_RESPONSE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 05:27:52 -0000 Ahh thanks Tobias: So I just remove this section from my XF86Config: Section "DRI" Mode 0666 EndSection and that will turn off DRI ? I will give that a test tomorrow. > On Sun, Jun 06, 2004 at 10:11:17PM -0700, Nate Lawson wrote: > > > > One more thing -- you're running the Radeon driver. It's likely that > > would interfere with suspend/resume. But feel free to test. > > just fyi, it does somewhat interfere on my thinkpad: radeon alone in the > kernel is just fine, but in order to get suspend/resume from within X > working, i have to turn off dri in XF86Config. Not that i mind much. > > cheers, t. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 05:34:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A5BA16A4CE for ; Mon, 7 Jun 2004 05:34:55 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F2F643D2D for ; Mon, 7 Jun 2004 05:34:54 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i575XB4N010587; Sun, 6 Jun 2004 23:33:11 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 06 Jun 2004 23:33:21 -0600 (MDT) Message-Id: <20040606.233321.133019270.imp@bsdimp.com> To: j.e.drews@att.net From: "M. Warner Losh" In-Reply-To: <060720040509.2054.40C3F894000BED390000080621603763169C990A9D0BD20AD206@att.net> References: <060720040509.2054.40C3F894000BED390000080621603763169C990A9D0BD20AD206@att.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: PCMCIA Modem causes hang on boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 05:34:55 -0000 In message: <060720040509.2054.40C3F894000BED390000080621603763169C990A9D0BD20AD206@att.net> j.e.drews@att.net writes: : Hello Warner: : : I tried a good bit this weekend to get this card to work in NetBSD but it did not. The latest dmesg output is here: : http://www.silbsd.org/bugreports/acpi.dmesg2.txt : : I also saw this entry in the /etc/defaults/pccard.conf: : : # Zoom 56K modem : # Freezes your system entirely if you don't have the reset.. : card "Zoom Telephonics, Inc." "PCMCIA 56K LT DataFax" : config auto "sio" ? : reset 1000 : : I wonder if that freeze condition would apply to this card also? : Would the reset 1000 be the same? Recall that my Hawking PN612 tries : to use sio4. I will continue with the kernel debugging and try to : get a core file. Maybe. I've been thinking about this all weekened, and I don't know why it would be happening. oldcard does (did?) a COR reset, but NEWCARD doesn't, so having a longer reset time might not hekp... Warner From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 05:47:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6467F16A4CE for ; Mon, 7 Jun 2004 05:47:29 +0000 (GMT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 2A72F43D48 for ; Mon, 7 Jun 2004 05:47:29 +0000 (GMT) (envelope-from nate@root.org) Received: (qmail 68898 invoked by uid 1000); 7 Jun 2004 05:47:31 -0000 Date: Sun, 6 Jun 2004 22:47:31 -0700 (PDT) From: Nate Lawson To: Tobias Roth In-Reply-To: <20040607052237.GA15296@speedy.unibe.ch> Message-ID: <20040606224701.V68883@root.org> References: <060220040117.21540.40BD2ABA0008FE0E000054242160281302FF8C889A8D9BD19AD1@att.net> <20040606215445.R68528@root.org> <20040606221049.X68528@root.org> <20040607052237.GA15296@speedy.unibe.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: j.e.drews@att.net Subject: Re: ACPI Error: AE_NO_HARDWARE_RESPONSE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 05:47:29 -0000 On Mon, 7 Jun 2004, Tobias Roth wrote: > On Sun, Jun 06, 2004 at 10:11:17PM -0700, Nate Lawson wrote: > > One more thing -- you're running the Radeon driver. It's likely that > > would interfere with suspend/resume. But feel free to test. > > just fyi, it does somewhat interfere on my thinkpad: radeon alone in the > kernel is just fine, but in order to get suspend/resume from within X > working, i have to turn off dri in XF86Config. Not that i mind much. You're correct, dri is the issue, not Radeon in general. Linux has the same problem. -Nate From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 05:57:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7ACC016A4CE for ; Mon, 7 Jun 2004 05:57:17 +0000 (GMT) Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05B8143D5D for ; Mon, 7 Jun 2004 05:57:15 +0000 (GMT) (envelope-from j.e.drews@att.net) Received: from 204.127.135.57 ([204.127.135.57]) by worldnet.att.net (mtiwmhc13) with SMTP id <2004060705571211300m49hhe>; Mon, 7 Jun 2004 05:57:12 +0000 Received: from [64.105.56.145] by 204.127.135.57; Mon, 07 Jun 2004 05:57:13 +0000 From: j.e.drews@att.net To: Nate Lawson Date: Mon, 07 Jun 2004 05:57:13 +0000 Message-Id: <060720040557.18530.40C403B8000B853F0000486221603763169C990A9D0BD20AD206@att.net> X-Mailer: AT&T Message Center Version 1 (May 27 2004) X-Authenticated-Sender: ai5lLmRyZXdzQGF0dC5uZXQ= cc: freebsd-current@freebsd.org Subject: Re: ACPI Error: AE_NO_HARDWARE_RESPONSE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 05:57:17 -0000 Hi Nate: That is correct; even when no "Generic Flash" (USB Jump Drive ?) is present it still produces that output. Just to recap the details: FreeBSD 5.2-CURRENT #0: Sun Jun 6 17:03:51 CDT 2004 Computer: Powernotebooks C 3:16 (Pentium M) usreland kernel compiled w/ gcc version 3.3.3 [FreeBSD] 20031106 using -O -pipe as the only optimizations. Option ddb is enabled. I use this in my /etc/rc.conf: dumpdev="/dev/ad0s1b" # Device name to crashdump to (or NO). dumpdir="/var/crash" # Directory where crash dumps are to be stored savecore_flags="" # Used if dumpdev is enabled above, and present. > Whatever device is called "Generic Flash" should be disconnected to test. > > On Mon, 7 Jun 2004 j.e.drews@att.net wrote: > > This is very interesting. I get this warning even though I have no USB > > Jump Drive inserted: > > > > da0: Removable Direct Access SCSI-2 device > > da0: 1.000MB/s transfers > > da0: Attempt to query device size failed: NOT READY, Medium not present > > (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > > (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error > > (da0:umass-sim0:0:0:0): SCSI Status: Check Condition > > (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 > > (da0:umass-sim0:0:0:0): Medium not present > > (da0:umass-sim0:0:0:0): Unretryable error > > Opened disk da0 -> 6 > > (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > > (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error > > (da0:umass-sim0:0:0:0): SCSI Status: Check Condition > > (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 > > (da0:umass-sim0:0:0:0): Medium not present > > (da0:umass-sim0:0:0:0): Unretryable error > > Opened disk da0 -> 6 > > > > I suppose this is what you meant by Flash Key? As I say it happens when > > it is not inserted. Should I report that as a separate issue ? > > You're saying that this device prints these same messages when > _disconnected_? > > -Nate From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 06:09:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC2CC16A4CE; Mon, 7 Jun 2004 06:09:15 +0000 (GMT) Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EFC943D4C; Mon, 7 Jun 2004 06:09:15 +0000 (GMT) (envelope-from j.e.drews@att.net) Received: from 204.127.135.57 ([204.127.135.57]) by worldnet.att.net (mtiwmhc12) with SMTP id <2004060706091111200jakk5e>; Mon, 7 Jun 2004 06:09:11 +0000 Received: from [64.105.56.145] by 204.127.135.57; Mon, 07 Jun 2004 06:09:13 +0000 From: j.e.drews@att.net To: Nate Lawson Date: Mon, 07 Jun 2004 06:09:13 +0000 Message-Id: <060720040609.22380.40C406880008851B0000576C21603763169C990A9D0BD20AD206@att.net> X-Mailer: AT&T Message Center Version 1 (May 27 2004) X-Authenticated-Sender: ai5lLmRyZXdzQGF0dC5uZXQ= cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: ACPI Error: AE_NO_HARDWARE_RESPONSE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 06:09:15 -0000 Hi: When I was shutting down I got this output from tty0: evregion-0502: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_ RESPONSE **** Exception AE_NO_HARDWARE_RESPONSE during execution of method [\_TZ_.THRM._T MP] (Node 0xc1a777a8) Method Execution Stack: Method [_TMP] executing: 7 # 70 Store (\_SB.PCI0.LPCB.EC0.CTMP, Local1) Local Variables for method [_TMP]: Local0: 0 Local1: 0 Local2: 0 Local3: 0 Local4: 0 Local5: 0 Local6: 0 Local7: 0 Arguments for Method [_TMP]: (0 arguments defined, max concurrency = ff) Arg0: 0 Arg1: 0 Arg2: 0 Arg3: 0 Arg4: 0 Arg5: 0 Arg6: 0 psparse-1303: *** Error: Method execution failed [\_TZ_.THRM._TMP] (Node 0xc1a7 77a8), AE_NO_HARDWARE_RESPONSE I thought I would pass this info along. from: FreeBSD 5.2-CURRENT #0: Sun Jun 6 17:03:51 CDT 2004 > On Wed, 2 Jun 2004 j.e.drews@att.net wrote: > > I made the polling adjustment that you suggested: > > sysctl hw.acpi.thermal.polling_rate=1 > > > > and then ran the script while compiling qt33 and Mozilla at the same time. > > the initial reading was at: hw.acpi.thermal.tz0.temperature: 3112 > > the high temps were: > > hw.acpi.thermal.tz0.temperature: 3242 > > hw.acpi.thermal.tz0.temperature: 3252 > > > > the fan kicked on at 3232. I could not get the error again, even though > > I ran the computer under load for quite a while. > > Ok, thanks for all the debugging info. There are two issues here: > > --- > GEOM: Configure ad0s1f, start 1851564032 length 22418914816 end 24270478847 > acpi_ec0: info: new max delay is 75 us > acpi_ec0: info: new max delay is 90 us > acpi_ec0: info: new max delay is 210 us > acpi_ec0: info: new max delay is 805 us > acpi_ec0: info: new max delay is 900 us > system power profile changed to 'economy' > --- > > 1. Embedded controller read times out during boot. > As seen above, during the probe of your flash key, the EC hits higher and > higher delays until finally timing out. The issue is that ACPI acquires > Giant and so does CAM (which is probing your flash drive). Try booting > without your flash key inserted and see if the error goes away. I am > working on a patch for ACPI to run Giant-free that should address this. > It's almost done. > > --- > POWERRES-0257 [20] acpi_pwr_register_cons: registered power consumer > \\_SB_.PCI0.USB7 > POWERRES-0350 [19] acpi_pwr_switch_consum: setup to switch > \\_SB_.PCI0.USB7 D255 -> D3 > POWERRES-0479 [19] acpi_pwr_switch_consum: attempt to set unsupported state D3 > pci0: Failed to set ACPI power state D3 on (null): AE_BAD_PARAMETER > POWERRES-0257 [20] acpi_pwr_register_cons: registered power consumer > \\_SB_.PCI0.MODM > POWERRES-0350 [19] acpi_pwr_switch_consum: setup to switch > \\_SB_.PCI0.MODM D255 -> D3 > POWERRES-0479 [19] acpi_pwr_switch_consum: attempt to set unsupported state D3 > pci0: Failed to set ACPI power state D3 on (null): AE_BAD_PARAMETER > --- > > 2. Error messages for power switching consumer. > These are harmless but I'll remove them. The power state routines try to > power down your USB7 and built-in modem since no driver attached them. > However, they don't offer power control via ACPI so the attempt returns a > harmless error message. I'll add checks for this. > > Thanks for the help, > Nate From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 06:31:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00B6616A4CE for ; Mon, 7 Jun 2004 06:31:39 +0000 (GMT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id C5DE643D55 for ; Mon, 7 Jun 2004 06:31:38 +0000 (GMT) (envelope-from nate@root.org) Received: (qmail 69218 invoked by uid 1000); 7 Jun 2004 06:31:34 -0000 Date: Sun, 6 Jun 2004 23:31:34 -0700 (PDT) From: Nate Lawson To: j.e.drews@att.net In-Reply-To: <060720040609.22380.40C406880008851B0000576C21603763169C990A9D0BD20AD206@att.net> Message-ID: <20040606233110.I69215@root.org> References: <060720040609.22380.40C406880008851B0000576C21603763169C990A9D0BD20AD206@att.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: acpi@freebsd.org cc: current@freebsd.org Subject: Re: ACPI Error: AE_NO_HARDWARE_RESPONSE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 06:31:39 -0000 On Mon, 7 Jun 2004 j.e.drews@att.net wrote: > Hi: > > When I was shutting down I got this output from tty0: > evregion-0502: *** Error: Handler for [EmbeddedControl] returned AE_NO_HARDWARE_ > RESPONSE > > **** Exception AE_NO_HARDWARE_RESPONSE during execution of method [\_TZ_.THRM._T > MP] (Node 0xc1a777a8) > > Method Execution Stack: > Method [_TMP] executing: 7 # 70 Store (\_SB.PCI0.LPCB.EC0.CTMP, Local1) It's the same problem. Giant contention. -Nate From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 07:05:40 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C7F616A4CE for ; Mon, 7 Jun 2004 07:05:40 +0000 (GMT) Received: from md.gfk.ru (md.gfk.ru [62.205.179.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2441043D41 for ; Mon, 7 Jun 2004 07:05:39 +0000 (GMT) (envelope-from Yuriy.Tsibizov@gfk.ru) Received: from mx.gfk.ru ([10.0.0.30]) by md.gfk.ru (md.gfk.ru [62.205.179.201]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 32-md50000000132.tmp for ; Mon, 07 Jun 2004 11:05:12 +0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 7 Jun 2004 11:05:11 +0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What happened to src/sys/dev/sound/midi ? Thread-Index: AcRKVP77UDk+hsN9TyWlS1fVOIEdZwCArs+Q From: "Yuriy Tsibizov" To: "Mathew Kanner" X-Spam-Processed: md.gfk.ru, Mon, 07 Jun 2004 11:05:12 +0400 (not processed: message from valid local sender) X-MDRemoteIP: 10.0.0.30 X-Return-Path: Yuriy.Tsibizov@gfk.ru X-MDaemon-Deliver-To: freebsd-current@FreeBSD.org cc: freebsd-current@FreeBSD.org Subject: RE: What happened to src/sys/dev/sound/midi ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 07:05:40 -0000 > > > In my humble opinion: We should axe this driver as "the > > >current version is hurting people and should be put out of its > > >misery". The current driver (before removal) simply didn't work = and > > >people were trying to use it. > >=20 > > I send you again, > > "Are there any snapshot of your audio related work available for=20 > > review?"=20 > > At least, the older code shouldn't be removed until the replacement=20 > > appears. >=20 > In regards to MIDI, I've been posting links to patches for > about a year now. I've had relatively little feedback. I'm=20 > not sure if > the current patches that are posted will compile after some changes to > infrastructure. Mathew,=20 I've added support for your year-old midi2 code (dated June, 14th) to = emu10kx driver. It builds well under -CURRENT (with addition of = d_version to device structures). It would be nice, if you can provide = snapshot of your current work to let people test it before commiting. Now, for day and a half (this weekend), at least three people downloaded = your midi2 code that I have on my website. Emu10kx can be compiled without MIDI at all (and they do not need to = download midi2 to build driver without MIDI or with NEWMIDI), and I = think these people do need MIDI under FreeBSD-CURRENT.=20 I also can say, that old NEWMIDI was not dead (MIDI I/O was working for = me) when it was removed from -CURRENT. Yuriy Tsibizov, http://chibis.persons.gfk.ru/audigy/ From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 07:17:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 263C016A4CE; Mon, 7 Jun 2004 07:17:14 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 057EB43D48; Mon, 7 Jun 2004 07:17:14 +0000 (GMT) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i577H2vw018057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jun 2004 11:17:02 +0400 (MSD) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i577H2jC018056; Mon, 7 Jun 2004 11:17:02 +0400 (MSD) Date: Mon, 7 Jun 2004 11:17:01 +0400 From: Gleb Smirnoff To: Julian Elischer Message-ID: <20040607071701.GC17986@cell.sick.ru> References: Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: FreeBSD current users cc: net@freebsd.org Subject: Re: HEADSUP! netgraph Metadata changing. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 07:17:15 -0000 On Sun, Jun 06, 2004 at 06:35:51PM -0700, Julian Elischer wrote: J> In addition the ng_ksocket node adds info into metadata and I suspect J> there are people using that. Since ng_ksocket tags packets for itself only, we can safely change it. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 07:36:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD99A16A4CE; Mon, 7 Jun 2004 07:36:01 +0000 (GMT) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BD4B43D46; Mon, 7 Jun 2004 07:36:01 +0000 (GMT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc12) with ESMTP id <20040607073558012001h8a8e>; Mon, 7 Jun 2004 07:35:59 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id AAA19362; Mon, 7 Jun 2004 00:35:58 -0700 (PDT) Date: Mon, 7 Jun 2004 00:35:56 -0700 (PDT) From: Julian Elischer To: Gleb Smirnoff In-Reply-To: <20040607071701.GC17986@cell.sick.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD current users cc: net@freebsd.org Subject: Re: HEADSUP! netgraph Metadata changing. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 07:36:01 -0000 On Mon, 7 Jun 2004, Gleb Smirnoff wrote: > On Sun, Jun 06, 2004 at 06:35:51PM -0700, Julian Elischer wrote: > J> In addition the ng_ksocket node adds info into metadata and I suspect > J> there are people using that. > > Since ng_ksocket tags packets for itself only, we can safely change it. Since I did not add that code I am not very familiar with it or who uses it. (or why) if this is true than yes we can do this.. > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE > From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 07:38:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 818C116A4CE; Mon, 7 Jun 2004 07:38:54 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C51E943D2F; Mon, 7 Jun 2004 07:38:53 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i577iVQr096502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jun 2004 10:44:32 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i577cCDI000515; Mon, 7 Jun 2004 10:38:12 +0300 (EEST) (envelope-from ru) Date: Mon, 7 Jun 2004 10:38:12 +0300 From: Ruslan Ermilov To: Gleb Smirnoff Message-ID: <20040607073812.GA339@ip.net.ua> References: <20040607071701.GC17986@cell.sick.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline In-Reply-To: <20040607071701.GC17986@cell.sick.ru> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: net@freebsd.org cc: Julian Elischer cc: FreeBSD current users Subject: Re: HEADSUP! netgraph Metadata changing. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 07:38:54 -0000 --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 07, 2004 at 11:17:01AM +0400, Gleb Smirnoff wrote: > On Sun, Jun 06, 2004 at 06:35:51PM -0700, Julian Elischer wrote: > J> In addition the ng_ksocket node adds info into metadata and I suspect > J> there are people using that. >=20 > Since ng_ksocket tags packets for itself only, we can safely change it. >=20 I use this feature in one proprietary module (need to send/recevive UDP datagrams to/from different destinations). Cheers,=20 --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --bg08WKrSYDhXBjb5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAxBtkqRfpzJluFF4RAmvDAJ4mmauyH2vfh4VpQj2Mk+dZEnrYVgCdFAZx B1AoVPc7JEPMs1XaloOdp3I= =BaUJ -----END PGP SIGNATURE----- --bg08WKrSYDhXBjb5-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 07:40:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5833316A4CE; Mon, 7 Jun 2004 07:40:43 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98AE143D39; Mon, 7 Jun 2004 07:40:42 +0000 (GMT) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i577ebvw018303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jun 2004 11:40:38 +0400 (MSD) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i577ebrw018302; Mon, 7 Jun 2004 11:40:37 +0400 (MSD) Date: Mon, 7 Jun 2004 11:40:37 +0400 From: Gleb Smirnoff To: Julian Elischer Message-ID: <20040607074037.GB18232@cell.sick.ru> References: <20040607071701.GC17986@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: FreeBSD current users cc: net@freebsd.org Subject: Re: HEADSUP! netgraph Metadata changing. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 07:40:43 -0000 On Mon, Jun 07, 2004 at 12:35:56AM -0700, Julian Elischer wrote: J> > On Sun, Jun 06, 2004 at 06:35:51PM -0700, Julian Elischer wrote: J> > J> In addition the ng_ksocket node adds info into metadata and I suspect J> > J> there are people using that. J> > J> > Since ng_ksocket tags packets for itself only, we can safely change it. J> J> Since I did not add that code I am not very familiar with it or who uses J> it. (or why) J> J> if this is true than yes we can do this.. It is used only on UDP connection, to send replies back to where the original packets came from. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 08:21:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9F2816A4CE for ; Mon, 7 Jun 2004 08:21:17 +0000 (GMT) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.145.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45AF243D48 for ; Mon, 7 Jun 2004 08:21:17 +0000 (GMT) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id EDED24EFCD3; Mon, 7 Jun 2004 16:21:05 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id E68154EFCCF for ; Mon, 7 Jun 2004 16:21:05 +0800 (CST) Date: Mon, 7 Jun 2004 16:21:05 +0800 (CST) From: Tai-hwa Liang To: freebsd-current@freebsd.org Message-ID: <040607143347F.86443@www.mmlab.cse.yzu.edu.tw> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: T40 panics at usb_get_next_event() when ACPI is disabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 08:21:18 -0000 Hello, Recent -CURRENT(cvsup'ed on May-26-2004) kernel panics when the rc script is trying to invoke /usr/sbin/usbd. It's 100% reproducible on my Thinkpad T40 when the USB optical mouse is attached and the ACPI is disabled(option 2 in the boot menu). I've tried to comment out the #ifdef DIAGNOSTIC statement around sys/dev/usb/usb.c:752; however, it seems that the extra NULL check on ue doesn't help in this case: The system still panics at the same place.... With ACPI enabled(or the USB mouse detached) during booting, the usbd would start successfully. Is there any T40 user running into the same problem on your -CURRENT? The GENERIC kernel came from 5.2.1-RELEASE doesn't seem to have this problem. For complete dmesg, please consult: http://www.mmlab.cse.yzu.edu.tw/~avatar/dmesg-noacpi.txt http://www.mmlab.cse.yzu.edu.tw/~avatar/dmesg-acpi.txt ------------------------ backtrace --------------------------- GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-undermydesk-freebsd"... panic: from debugger panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc074af0d stack pointer = 0x10:0xcdce59fc frame pointer = 0x10:0xcdce5a08 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 403 (usbd) kernel: type 12 trap, code=0 panic: from debugger at line 453 in file ../../../ddb/db_command.c Stack backtrace: Fatal trap 3: breakpoint instruction fault while in kernel mode instruction pointer = 0x8:0xc05a9f9d stack pointer = 0x10:0xcdce57dc frame pointer = 0x10:0xcdce57e0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = IOPL = 0 current process = 403 (usbd) panic: from debugger at line 453 in file ../../../ddb/db_command.cUptime: 15s Dumping 255 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 --- Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/md/md.ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/md/md.ko.debug Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/linux/linux.ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/linux/linux.ko.debug Reading symbols from /boot/kernel/if_em.ko...done. Loaded symbols for /boot/kernel/if_em.ko Reading symbols from /boot/kernel/if_wi.ko...done. Loaded symbols for /boot/kernel/if_wi.ko Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/wlan/wlan.ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/wlan/wlan.ko.debug Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/rc4/rc4.ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/rc4/rc4.ko.debug Reading symbols from /boot/kernel/snd_ich.ko...done. Loaded symbols for /boot/kernel/snd_ich.ko Reading symbols from /boot/kernel/snd_pcm.ko...done. Loaded symbols for /boot/kernel/snd_pcm.ko Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/ums/ums.ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/ums/ums.ko.debug Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/---Type to continue, or q to quit--- usb/usb.ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/usb/usb.ko.debug Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/umass/umass.ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/umass/umass.ko.debug Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/agp/agp.ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/agp/agp.ko.debug Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/random/random.ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/random/random.ko.debug Reading symbols from /boot/kernel/if_ath.ko...done. Loaded symbols for /boot/kernel/if_ath.ko Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/ath_hal/ath_hal.ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/ath_hal/ath_hal.ko.debug Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/smbfs/smbfs.ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/smbfs/smbfs.ko.debug Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/libmchain/libmchain.ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/libmchain/libmchain.ko.debug Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/libiconv/libiconv.ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/libiconv/libiconv.ko.debug Reading symbols from /boot/kernel/radeon.ko...done. Loaded symbols for /boot/kernel/radeon.ko Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/msdosfs/msdosfs.ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/msdosfs/msdosfs.ko.debug Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/msdosfs_iconv/msdosfs_iconv.ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/msdosfs_iconv/msdosfs_iconv.ko.debug Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/pseudofs/pseudofs.ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/pseudofs/pseudofs.ko.debug Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/procfs/procfs.ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/procfs/procfs.ko.debug #0 doadump () at ../../../kern/kern_shutdown.c:236 236 dumping++; (kgdb) where #0 doadump () at ../../../kern/kern_shutdown.c:236 #1 0xc04c88e7 in boot (howto=260) at ../../../kern/kern_shutdown.c:370 #2 0xc04c8bf9 in __panic () at ../../../kern/kern_shutdown.c:548 #3 0xc0450bdb in db_panic () at ../../../ddb/db_command.c:453 #4 0xc0450b68 in db_command (last_cmdp=0xc061fec0, cmd_table=0xc05fa760, aux_cmd_tablep=0xc05f4db4, aux_cmd_tablep_end=0xc05f4db8) at ../../../ddb/db_command.c:348 #5 0xc0450c48 in db_command_loop () at ../../../ddb/db_command.c:475 #6 0xc04533e5 in db_trap (type=12, code=0) at ../../../ddb/db_trap.c:73 #7 0xc05a9d2d in kdb_trap (type=12, code=0, regs=0xcdce59bc) at ../../../i386/i386/db_interface.c:159 #8 0xc05b8123 in trap_fatal (frame=0xcdce59bc, eva=0) at ../../../i386/i386/trap.c:810 #9 0xc05b7e8f in trap_pfault (frame=0xcdce59bc, usermode=0, eva=0) at ../../../i386/i386/trap.c:733 #10 0xc05b7ac9 in trap (frame= {tf_fs = 24, tf_es = -842137584, tf_ds = -1067909104, tf_edi = -842114540, tf_esi = 0, tf_ebp = -842114552, tf_isp = -842114584, tf_ebx = 0, tf_edx = 19, tf_ecx = 96, tf_eax = -842114540, tf_trapno = 12, tf_err = 0, tf_eip = -1066094835, tf_cs = 8, tf_eflags = 66050, tf_esp = 0, tf_ss = 983056}) at ../../../i386/i386/trap.c:420 #11 0xc074af0d in usb_get_next_event (ue=0xcdce5a14) at /usr/src/sys/dev/usb/usb.c:752 #12 0xc074ab24 in usbread (dev=0xc062632c, uio=0xcdce5c88, flag=983056) at /usr/src/sys/dev/usb/usb.c:510 #13 0xc0490e90 in spec_read (ap=0xcdce5c18) at ../../../fs/specfs/spec_vnops.c:273 #14 0xc04909d7 in spec_vnoperate (ap=0x0) at ../../../fs/specfs/spec_vnops.c:118 #15 0xc052250d in vn_read (fp=0xc2c7d088, uio=0xcdce5c88, active_cred=0xc14f3e00, flags=0, td=0xc2afd930) at vnode_if.h:398 #16 0xc04eac8f in dofileread (td=0xc2afd930, fp=0xc2c7d088, fd=7, buf=0xbfbfeb60, nbyte=0, offset=0, flags=0) at ../../../sys/file.h:233 #17 0xc04eab83 in read (td=0xc2afd930, uap=0xcdce5d14) at ../../../kern/sys_generic.c:107 #18 0xc05b842b in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077940696, tf_esi = -1077941416, tf_ebp = -1077941016, tf_isp = -842113676, tf_ebx = 7, tf_edx = 20, tf_ecx = -1077941584, tf_eax = 3, tf_trapno = 12, tf_err = 2, tf_eip = 671899255, tf_cs = 31, tf_eflags = 658, tf_esp = -1077941444, tf_ss = 47}) at ../../../i386/i386/trap.c:1004 #19 0x280c5e77 in ?? () ---Can't read userspace from dump, or kernel process--- (kgdb) set print pretty (kgdb) f 11 #11 0xc074af0d in usb_get_next_event (ue=0xcdce5a14) at /usr/src/sys/dev/usb/usb.c:752 752 *ue = ueq->ue; (kgdb) print ueq $1 = (struct usb_event_q *) 0x0 (kgdb) print ue $2 = (struct usb_event *) 0xcdce5a14 (kgdb) From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 08:58:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C543A16A4D0 for ; Mon, 7 Jun 2004 08:58:25 +0000 (GMT) Received: from sbk-gw.sibnet.ru (sbk-gw.sibnet.ru [217.70.96.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5C2D43D58 for ; Mon, 7 Jun 2004 08:58:23 +0000 (GMT) (envelope-from stranger@sberbank.sibnet.ru) Received: from sbk-gw.sibnet.ru (localhost [127.0.0.1]) by sbk-gw.sibnet.ru (8.12.10/8.12.10) with ESMTP id i578w9nv062276 for ; Mon, 7 Jun 2004 15:58:09 +0700 (NOVST) (envelope-from stranger@sberbank.sibnet.ru) Received: from localhost (stranger@localhost)i578w9kL062273 for ; Mon, 7 Jun 2004 15:58:09 +0700 (NOVST) (envelope-from stranger@sberbank.sibnet.ru) X-Authentication-Warning: sbk-gw.sibnet.ru: stranger owned process doing -bs Date: Mon, 7 Jun 2004 15:58:08 +0700 (NOVST) From: "Maxim M. Kazachek" X-X-Sender: stranger@sbk-gw.sibnet.ru To: freebsd-current@freebsd.org Message-ID: <20040607155608.H62250@sbk-gw.sibnet.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.2 required=7.5 tests=AWL,BAYES_10 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on sbk-gw.sibnet.ru Subject: Type in i81x agp driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 08:58:25 -0000 pcicons -lv shows that I have 82815/EM/EP/P 815/EM/EP/P (Solano) Interal GUI Accelerator ^^^^^^^ Sincerely, Maxim M. Kazachek mailto:stranger@sberbank.sibnet.ru mailto:stranger@fpm.ami.nstu.ru From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 09:11:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A937E16A4CE for ; Mon, 7 Jun 2004 09:11:10 +0000 (GMT) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83ABE43D58 for ; Mon, 7 Jun 2004 09:11:09 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from ns0.nlsystems.com (ns0.nlsystems.com [80.177.232.243]) by itchy.rabson.org (8.12.11/8.12.11) with ESMTP id i5796iFs016661 for ; Mon, 7 Jun 2004 10:06:44 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: freebsd-current@freebsd.org Date: Mon, 7 Jun 2004 10:11:01 +0100 User-Agent: KMail/1.6.1 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406071011.01370.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on itchy.rabson.org X-Virus-Scanned: clamd / ClamAV version 0.71, clamav-milter version 0.71 X-Virus-Status: Clean Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 09:11:10 -0000 On Sunday 06 June 2004 20:55, Daniel Eischen wrote: > On Sun, 6 Jun 2004, Scott Long wrote: > > All, > > > > We are about 4-6 weeks away from starting the 5.3 release cycle. > > As it stands, KSE still only works reliably on i386. There are > > reports of significant instability on amd64, and it doesn't work at > > all on alpha and sparc64. I'm willing to drop the alpha > > requirement and maybe even the sparc64 requirement, but there > > absolutely will not be a 5.3 until amd64 is solid. Please contact > > myself, Dan Eischen, and David Xu if you are interested in helping > > out. > > amd64 looks to be a problem in readline which doesn't seem > to redispatch signal handlers with SA_SIGINFO arguments. > > David also has patches for debugging support at: > > http://people.freebsd.org/~davidxu/kse/dbg/ > > Doug Rabson also has basic TLS support working in perforce. > It'd be nice to get TLS and debugging in before 5.3-release. I'll probably try to commit some kind of TLS support into current in the next couple of weeks. Its likely to only support i386 and will be stubbed out for other platforms. Right now, I'm just waiting for some kind of feedback from an nvidia developer whos testing it. From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 09:14:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 971F016A4CE for ; Mon, 7 Jun 2004 09:14:29 +0000 (GMT) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF4A143D58 for ; Mon, 7 Jun 2004 09:14:28 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from ns0.nlsystems.com (ns0.nlsystems.com [80.177.232.243]) by itchy.rabson.org (8.12.11/8.12.11) with ESMTP id i579A4n8016672 for ; Mon, 7 Jun 2004 10:10:04 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: freebsd-current@freebsd.org Date: Mon, 7 Jun 2004 10:14:21 +0100 User-Agent: KMail/1.6.1 References: <40C37E1C.4000402@freebsd.org> <20040606204817.GB96607@dhcp50.pn.xcllnt.net> In-Reply-To: <20040606204817.GB96607@dhcp50.pn.xcllnt.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406071014.21707.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on itchy.rabson.org X-Virus-Scanned: clamd / ClamAV version 0.71, clamav-milter version 0.71 X-Virus-Status: Clean Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 09:14:29 -0000 On Sunday 06 June 2004 21:48, Marcel Moolenaar wrote: > On Sun, Jun 06, 2004 at 02:27:08PM -0600, Scott Long wrote: > > >Doug Rabson also has basic TLS support working in perforce. > > > > What platforms? My understanding was that new binutils and gcc was > > needed for sparc64 at a minimum. > > Yes. It's i386 only and not even close to being complete. In fact, > there has been discussions that the thread pointer on i386 needs to > change. Whether that's the case or not, it's likely that TLS will > complicate matters way too much to for it to ever work in 5.3. Actually its a bit better than that. It works for most use cases right now on i386 but would get confused on dlclose. I'll fix that before I move it into current. As far as the thread pointer issue goes, it turns out that our current compiler will always evaluate %gs:0 first which is fine for libpthread. I looked at gcc-3.4 sources and it can also be configured to always evaluate %gs:0 (this is the default for non-linux platforms). From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 09:17:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 769DC16A4CE; Mon, 7 Jun 2004 09:17:32 +0000 (GMT) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.145.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF4D343D39; Mon, 7 Jun 2004 09:17:31 +0000 (GMT) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id A2F4D4EFCD9; Mon, 7 Jun 2004 17:17:25 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 9D0E64EFCD8; Mon, 7 Jun 2004 17:17:25 +0800 (CST) Date: Mon, 7 Jun 2004 17:17:25 +0800 (CST) From: Tai-hwa Liang To: Don Lewis In-Reply-To: <200406070448.i574mTpP009303@gw.catspoiler.org> Message-ID: <04060713321212.86443@www.mmlab.cse.yzu.edu.tw> References: <200406070448.i574mTpP009303@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@FreeBSD.org cc: dl@leo.org Subject: Re: LOR No 9 and strange other kernel messages X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 09:17:32 -0000 On Sun, 6 Jun 2004, Don Lewis wrote: > On 7 Jun, Tai-hwa Liang wrote: > > On Sun, 6 Jun 2004, Don Lewis wrote: > > [...] > >> >> Maybe your sound client software (or something else on the system) is > >> >> querying for the number of vchans. Even "sysctl -a" will invoke the > >> >> handler. > >> > > >> > I'm using the stock mpg123 0.59r to play MP3 files. Since I've never read > >> > the source before, I'm not sure whether it utilised vchan related sysctls > >> > or not. > >> > >> The code that calls pcm_inprog() and prints the "x: 2" debug message > >> appears to be an attempt at implementing a reader/writer lock. I'm > >> pretty sure the failure that triggers the debug message is harmless, > >> other than causing the sysctl() call to return EWOULDBLOCK. > > > > I'm glad to know that the message is harmless. However, the "x: %d" is > > a little too obscured to endusers IMHO. Shouldn't that be protected by > > #ifdef DIAGNOSTIC or something like PCM_DEBUG? > > This diagnotic message should probably just go away. Also the locking > should be fixed to avoid the EWOULDBLOCK error. Should I file a PR or just forward the thread to the pcm maintainer? (to be honest, I have no idea about who he/she is, luigi@ / cg@ / ?) > > >> The most likely trigger for this event is if the client software is > >> writing data to sound device and is blocked in the write() syscall when > >> another thread calls sysctl(). You could find out which process is > >> calling sysctl() by printing curproc->p_pid in place of or in addition > >> to x. > > > > Ah, that explained everything. I've added the diagnostic code in > > sys/dev/sound/pcm/sound.c, and can 100% trigger this while mpg123 is > > playing and having a "sysctl -a" running in another xterm at the same time. > > > > x: 2, current pid: 39234 (sysctl) > > x: 2, current pid: 39234 (sysctl) > > > > It also looks like gcc will use sysctl() to retrieve physical memory size > > before compilation. I guess the "x: 2" I ran into was just a result of > > running gcc too frequently(make buildworld buildkernel). > > Gcc only looks up hw.physmem and hw.usermem, so it shouldn't trigger > this message. Weird.... now it's fairly difficult to reproduce that without "sysctl -a" (even buildworld/build mozilla/mpg123 at the same time). > [...] > >> > Whoops! My first trial on booting without ACPI -- kernel panic in > >> > usb_get_next_event(). Apparently I have to disconnect the USB mouse > >> > prior to kernel booting. See final section for the backtrace. > >> > >> Sounds like bug #3. > > > > Any idea about how bug #3 can happen? I've tried to comment out the > > #ifdef DIAGNOSTIC code around sys/dev/usb/usb.c:752 to see if the extra > > checking for NULL ue helps. Unfortunately that didn't work for me: the > > kernel always panic at usb_get_next_event+0x5e after starting usbd. > > I'd recommend posting a separate message about this panic. That way you > are more likely to catch the attention of a USB expert. Understood. I just finished my posting. Hope that any USB guru would be interested in it.... > >> > And, yes, the em0 didn't hang after booting to the non-ACPI environment. > >> > However, there're still something weird happening at that moment: > >> > > >> > 1. There're still a couple of "x: 2" dumped on console. Test case: > >> > "make buildworld buildkernel -DNOCLEAN" in one xterm, mpg123 in > >> > another xterm, and providing file downloading to another Windoze > >> > box. > >> > > >> > 2. While the remote box was downloading(Intel eepro 100/VE) files, > >> > the number of interrupt on em0 was dramatically reduced to 300 ~ 500+ > >> > per second. It was 3000+ when ACPI was enabled(no device polling in > >> > kernel). > >> > > >> > 3. The system average load is surprising low(I'm using SCHED_4BSD), > >> > about 0.06 ~ 0.30; however, the download was awfully slooowwwww. > >> > It took my brother's Windoze XP about 25 minutes to complete the > >> > whole downloading(3 ISO files, about 2GB in total). I'm pretty sure > >> > that the mediaopt on em0 was 100baseTX + full-duplex. > >> > >> I wonder if the em0 interrupt is not getting enabled or is getting > >> misrouted and the em0 interrupt service routing is getting triggered by > >> another interrupt source that is happening at a lower rate. Print out > >> the irq mapping with ACPI disabled to see what em0 is sharing its irq > >> with. This is probably something that jhb and njl will need to look at. > > > > Oops, it looks like I accidentally enabled the DEVICE_POLLING in kernel > > configuration file and forgot to turn kern.polling.enable on. > > > > After disabling DEVICE_POLLING and booting w/o ACPI, I can get rid of > > the aforementioned em0 sluggish problem. The interrupt rate on em0 is > > now 5700 ~ 7200 per second while downloading a couple of files from this > > laptop, and the average speed is 10+ MBytes. > > > > Hmm... it seems that I have to disable USB mouse and ACPI to get em0 > > back to work at this moment. > > > > I'm not quite sure about where the "IRQ mapping" you're talking about to > > retrieve from; therefore, I assume that came from dmesg: > > > > Found $PIR table, 15 entries at 0xc00fdea0 > > PCI-Only Interrupts: none [...] > > For the complete dmesg, please consult: > > > > http://www.mmlab.cse.yzu.edu.tw/~avatar/dmesg-noacpi.txt > > http://www.mmlab.cse.yzu.edu.tw/~avatar/dmesg-acpi.txt > > Wierd ... in the ACPI case, em0 gets attached, gets detached, and then > gets attached again. [...] > em0: Speed:N/A Duplex:N/A > em0: Link is up 100 Mbps Full Duplex > > It looks like em0 shares irq 4 with the exact same set of devices in > both cases. It does seem strange to me that it is sharing irq 4 with > sio0. Typically the sio ports get exclusive use of irqs. Perhaps this is related to the new interrupt routing algorithm that jhb@ is working on. Without backing sys/dev/acpica/acpi_pci_link.c to 1.14, my T40 locked up after probing sio0. I'll try to tweak the IRQ settings in BIOS to see whether it would help or not. > The whole part of the dmesg starting with "em0: detached" and "pci0: > driver added" is something that I haven't seen before, but I'm not > running bleeding edge -CURRENT at the moment. The detach/re-attach message was came from another test: "kldunload if_em" and kldload it again to see whether it helps to the interrupt lockup symptom or not. Sorry for the inconvenience, you can just simply ignore them. > > I'd recommend starting a separate thread to discuss your em0 problem. I did it on May but haven't receive any reply, yet: http://lists.freebsd.org/pipermail/freebsd-current/2004-May/027225.html Anyway, I'll start another thread later. Hope I get better luck this time.... Thanks a lot for your help, Mr. Lewis! From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 09:38:14 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 83E3216A4CE for ; Mon, 7 Jun 2004 09:38:14 +0000 (GMT) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.145.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5334643D2F for ; Mon, 7 Jun 2004 09:38:14 +0000 (GMT) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id 130A74EFCD9; Mon, 7 Jun 2004 17:38:00 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 0926E4EFCD8 for ; Mon, 7 Jun 2004 17:38:00 +0800 (CST) Date: Mon, 7 Jun 2004 17:37:59 +0800 (CST) From: Tai-hwa Liang To: freebsd-current@freebsd.org Message-ID: <040607172005C.88581@www.mmlab.cse.yzu.edu.tw> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: if_em locked up under high network load in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 09:38:14 -0000 Greetings, It seems that recent kernel changes breaks the em driver when the network load is high enough(rsync a directory contains +150MB files). The onboard Intel PRO/1000 just doesn't respond to network request such like ping or DHCP lease renewal -- all interrupt related to em0 was stopped since the lockup took place. However, the system is still workable(can compile/edit code, only em0 hangs) at this moment. Manually unload/reload the if_em kernel module doesn't solve this problem. Last known good kernel was cvsup'ed on Apr-28-2004, the problem occurred since May-09-2004(cvsup/kernel build on a weekly basis, not sure about whether it worked between Apr-28 and May-09 or not). Since booting w/o ACPI support solved this problem, I'm wondering about whether recent PCI/ACPI changes correlated to this lockup. The module was built without polling support; however, the lockup always happens disregarding device polling support is compiled in or not. ---------------------- vmstat -i ---------------------------- interrupt total rate irq0: clk 93968 99 irq1: atkbd0 4227 4 irq4: cbb0 em0++ 166447 176 irq6: cbb1 pcm0 133702 41 irq7: ppc0 1 0 irq8: rtc 120281 127 irq9: acpi0 301 0 irq10: uhci1 200 0 irq11: ath0 uhci2+ 2 0 irq12: psm0 21 0 irq13: npx0 1 0 irq14: ata0 7425 7 irq15: ata1 55 0 Total 392929 417 For complete dmesg of this Thinkpad T40, please consult: http://www.mmlab.cse.yzu.edu.tw/~avatar/dmesg-noacpi.txt http://www.mmlab.cse.yzu.edu.tw/~avatar/dmesg-acpi.txt (the reason why em0 was detached and re-attached twice is that I've tried to see whether kldunload/kldload if_em again can workaround this problem without rebooting.) From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 09:41:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41C4616A4CE for ; Mon, 7 Jun 2004 09:41:58 +0000 (GMT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2668A43D45 for ; Mon, 7 Jun 2004 09:41:58 +0000 (GMT) (envelope-from burpmaster@truffula.net) Received: from [192.168.0.2] (c-67-169-200-31.client.comcast.net[67.169.200.31]) by comcast.net (rwcrmhc11) with ESMTP id <2004060709413701300cni6ie>; Mon, 7 Jun 2004 09:41:37 +0000 Message-ID: <40C43851.1080000@truffula.net> Date: Mon, 07 Jun 2004 02:41:37 -0700 From: Brian Rogers User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8a2) Gecko/20040605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <40B94AFB.3010209@truffula.net> <20040530151912.GA60571@troutmask.apl.washington.edu> In-Reply-To: <20040530151912.GA60571@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Attache USB flash drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 09:41:58 -0000 Steve Kargl wrote: >On Sun, May 30, 2004 at 12:01:50AM -0700, Brian Rogers wrote: > > >>Rob wrote: >> >> >>>Brian Rogers wrote: >>> >>> >>>>umass0: PNY Attache 2.0, rev 2.00/2.00, addr 2 >>>>umass0: BBB reset failed, TIMEOUT >>>>umass0: BBB bulk-in clear stall failed, TIMEOUT >>>>umass0: BBB bulk-out clear stall failed, TIMEOUT >>>> >>>> >These look familiar. > > >>I just tried booting off the FreeBSD 5.2 install disc on my system. No >>crash on removal, but I do get the same three repeating error messages >>and still no device appears in /dev. Then I tried this boot disc on an >>Intel (440BX) machine. No error messages, but still no /dev entry. I >> >> >camcontrol rescan 0 > > The process usually hangs for a while, and when/if it does complete, there is still no device to mount. I guess I'll wait and watch out for any changes to the umass and USB drivers to test again with. I actually don't have much need to use this thing at home, fortunately. From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 09:45:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7739F16A4CE for ; Mon, 7 Jun 2004 09:45:10 +0000 (GMT) Received: from itesec.hsc.fr (itesec.hsc.fr [192.70.106.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC3CB43D5C for ; Mon, 7 Jun 2004 09:45:09 +0000 (GMT) (envelope-from yb@sainte-barbe.org) Received: from taz.hsc.fr (taz.hsc.fr [192.70.106.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "taz.hsc.fr", Issuer "HSC CA" (verified OK)) by itesec.hsc.fr (Postfix) with ESMTP id 16CB320F44 for ; Mon, 7 Jun 2004 11:45:04 +0200 (CEST) Received: by taz.hsc.fr (Postfix, from userid 1001) id 79A514659; Mon, 7 Jun 2004 11:45:08 +0200 (CEST) Date: Mon, 7 Jun 2004 11:45:08 +0200 From: Yann Berthier To: freebsd-current@freebsd.org Message-ID: <20040607094508.GA740@hsc.fr> Mail-Followup-To: freebsd-current@freebsd.org References: <20040604122041.GB84468@shiva.int.ipv42.net> <20040604183553.8997916A4CF@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040604183553.8997916A4CF@hub.freebsd.org> X-Organization: Herve Schauer Consultants X-Web: http://www.hsc.fr/ X-Operating-System: FreeBSD 5.2-CURRENT User-Agent: Mutt/1.5.6i Subject: Re: 802.11g/GPRS broadcom cardbus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 09:45:10 -0000 Hello, [Nicolas and I are coworkers] On Fri, 04 Jun 2004, Bill Paul wrote: > Hm. In theory, I think it's possible to make the whole thing work. > The only tricky part is that they've combined two functions on the > same device. The 802.11g wireless function should work fine using > the NDISulator and the supplied Windows driver (check the CD that > came with it: there's probably a bcmwl5.sys and bcmwl5.inf file on > it somewhere). But the probe routine in if_ndis_pci.c only selects > devices based on the PCI vendor and device ID. If the two functions > appear to have unique device IDs, then you should be ok. If not, the > probe routine might try to claim both the wireless function and > the serial function. > > If it turns out both functions have the same vendor/device ID, this > shouldn't be too hard to deal with: the probe routine can additionally > check the PCI device type code and reject anything that isn't 'network' > or 'wireless.' We have not tested the ndis part yet. > As for the serial interface, assuming it behaves like a normal > COM port, I expect you can get it to work by adding the PCI vendor/device > ID to the PCI attachment of the sio driver. Then it will get attached > as an sio device. Indeed it works, all it takes is to add { 0x432214e4, "Broadcom 802.11g/GPRS CardBus (Serial)", 0x10 }, In /usr/src/sys/dev/sio/sio_pci.c Do we need to submit a PR ? From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 09:49:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8171C16A4CE; Mon, 7 Jun 2004 09:49:47 +0000 (GMT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 971D943D39; Mon, 7 Jun 2004 09:49:46 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 7 Jun 2004 10:49:40 +0100 (BST) Date: Mon, 7 Jun 2004 10:49:40 +0100 From: David Malone To: "Maxim M. Kazachek" Message-ID: <20040607094940.GA32276@walton.maths.tcd.ie> References: <20040607155608.H62250@sbk-gw.sibnet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040607155608.H62250@sbk-gw.sibnet.ru> User-Agent: Mutt/1.5.3i Sender: dwmalone@maths.tcd.ie cc: freebsd-current@freebsd.org cc: sheldonh@freebsd.org Subject: Re: Type in i81x agp driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 09:49:47 -0000 On Mon, Jun 07, 2004 at 03:58:08PM +0700, Maxim M. Kazachek wrote: > pcicons -lv shows that I have > 82815/EM/EP/P 815/EM/EP/P (Solano) Interal GUI Accelerator > ^^^^^^^ It is actually a typo in /usr/share/misc/pci_vendors - this file is actually assembeled from information from various vendors/web sites, so it is possible that it is a typo in one of these sources. David. From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 09:54:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD4D516A4CE; Mon, 7 Jun 2004 09:54:46 +0000 (GMT) Received: from TRANG.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F07943D2D; Mon, 7 Jun 2004 09:54:46 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by TRANG.nuxi.com (8.12.11/8.12.10) with ESMTP id i579sgdY030086; Mon, 7 Jun 2004 02:54:42 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.11/8.12.11/Submit) id i579sfDj030085; Mon, 7 Jun 2004 02:54:41 -0700 (PDT) (envelope-from obrien) Date: Mon, 7 Jun 2004 02:54:41 -0700 From: "David O'Brien" To: Daniel Eischen Message-ID: <20040607095441.GC29340@dragon.nuxi.com> Mail-Followup-To: David O'Brien , Daniel Eischen , Scott Long , hackers@FreeBSD.org, current@FreeBSD.org References: <40C36D31.4010003@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: hackers@FreeBSD.org cc: Scott Long cc: current@FreeBSD.org Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 09:54:46 -0000 On Sun, Jun 06, 2004 at 03:55:23PM -0400, Daniel Eischen wrote: > David also has patches for debugging support at: > http://people.freebsd.org/~davidxu/kse/dbg/ Unless David Xu completes full FSF paper work, we can't use his patches. Using them tants us forever in getting stock GDB to support our threading. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 09:56:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4CED16A4CE; Mon, 7 Jun 2004 09:56:10 +0000 (GMT) Received: from TRANG.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8ED6E43D48; Mon, 7 Jun 2004 09:56:10 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by TRANG.nuxi.com (8.12.11/8.12.10) with ESMTP id i579u49R030161; Mon, 7 Jun 2004 02:56:04 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.11/8.12.11/Submit) id i579u354030160; Mon, 7 Jun 2004 02:56:03 -0700 (PDT) (envelope-from obrien) Date: Mon, 7 Jun 2004 02:56:02 -0700 From: "David O'Brien" To: Marcel Moolenaar Message-ID: <20040607095602.GD29340@dragon.nuxi.com> Mail-Followup-To: David O'Brien , Marcel Moolenaar , Scott Long , hackers@freebsd.org, current@freebsd.org References: <40C37E1C.4000402@freebsd.org> <20040606204817.GB96607@dhcp50.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040606204817.GB96607@dhcp50.pn.xcllnt.net> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: hackers@freebsd.org cc: current@freebsd.org Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 09:56:10 -0000 On Sun, Jun 06, 2004 at 01:48:17PM -0700, Marcel Moolenaar wrote: > On Sun, Jun 06, 2004 at 02:27:08PM -0600, Scott Long wrote: > > > > > >Doug Rabson also has basic TLS support working in perforce. > > > > What platforms? My understanding was that new binutils and gcc was > > needed for sparc64 at a minimum. > > Yes. It's i386 only and not even close to being complete. In fact, > there has been discussions that the thread pointer on i386 needs to > change. Whether that's the case or not, it's likely that TLS will > complicate matters way too much to for it to ever work in 5.3. > > > >It'd be nice to get TLS and debugging in before 5.3-release. > > > > > > > Yes. Be aware that there is a serious effort to get GDB 6.x into the > > tree for 5.3. > > I just asked cvs@ and core@ to advice about importing gdb 6.1 into > src/contrib/gdb6. We need to break this vicious circle of people > waiting on each other. This came up before and you were already asked not to import into src/contrib/gdb6 (and what email would be sent to Core if you did). Any GDB imports need to go into src/contrib/gdb/. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 10:01:40 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C529A16A4CE for ; Mon, 7 Jun 2004 10:01:40 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D14943D45 for ; Mon, 7 Jun 2004 10:01:40 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i57A1RYv010876; Mon, 7 Jun 2004 03:01:35 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200406071001.i57A1RYv010876@gw.catspoiler.org> Date: Mon, 7 Jun 2004 03:01:26 -0700 (PDT) From: Don Lewis To: avatar@mmlab.cse.yzu.edu.tw In-Reply-To: <04060713321212.86443@www.mmlab.cse.yzu.edu.tw> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-current@FreeBSD.org cc: dl@leo.org Subject: Re: LOR No 9 and strange other kernel messages X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 10:01:40 -0000 On 7 Jun, Tai-hwa Liang wrote: > On Sun, 6 Jun 2004, Don Lewis wrote: >> On 7 Jun, Tai-hwa Liang wrote: >> > On Sun, 6 Jun 2004, Don Lewis wrote: >> >> The code that calls pcm_inprog() and prints the "x: 2" debug message >> >> appears to be an attempt at implementing a reader/writer lock. I'm >> >> pretty sure the failure that triggers the debug message is harmless, >> >> other than causing the sysctl() call to return EWOULDBLOCK. >> > >> > I'm glad to know that the message is harmless. However, the "x: %d" is >> > a little too obscured to endusers IMHO. Shouldn't that be protected by >> > #ifdef DIAGNOSTIC or something like PCM_DEBUG? >> >> This diagnotic message should probably just go away. Also the locking >> should be fixed to avoid the EWOULDBLOCK error. > > Should I file a PR or just forward the thread to the pcm maintainer? > (to be honest, I have no idea about who he/she is, luigi@ / cg@ / ?) I can take care of it, since I'm one of the last people to touch the pcm stuff. Fixing up the locking problems in the pcm code is also on my TODO list, but I haven't had time to work on it and I wouldn't complain if someone else committed proper fixes. From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 10:06:36 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0EFD816A4CE; Mon, 7 Jun 2004 10:06:36 +0000 (GMT) Received: from TRANG.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id E76E143D41; Mon, 7 Jun 2004 10:06:35 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by TRANG.nuxi.com (8.12.11/8.12.10) with ESMTP id i57A6G4A030465; Mon, 7 Jun 2004 03:06:17 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.11/8.12.11/Submit) id i57A6GlG030464; Mon, 7 Jun 2004 03:06:16 -0700 (PDT) (envelope-from obrien) Date: Mon, 7 Jun 2004 03:06:16 -0700 From: "David O'Brien" To: Ruslan Ermilov Message-ID: <20040607100616.GE29340@dragon.nuxi.com> Mail-Followup-To: David O'Brien , Ruslan Ermilov , current@FreeBSD.org References: <20040604092313.GA12314@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040604092313.GA12314@ip.net.ua> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.2-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: current@FreeBSD.org Subject: Re: Can the disklabel(8) link go now? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 10:06:36 -0000 On Fri, Jun 04, 2004 at 12:23:13PM +0300, Ruslan Ermilov wrote: > Gang, > > I'd like to remove the old compatibility link from bsdlabel(8) > to disklabel(8). I think the dust has settled enough to allow > this to be done now (and before 5.3-RELEASE): NO. We've been thru this not that long ago. We should leave the disklable symlink forever -- it gives us a consistant command interface across all our platforms. I've found NetBSD very anonying in the past that the labeling command has a different name across different platforms. The symlink causes no harm. Why are you on such a war path to kill it?? -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 10:31:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EAE6F16A4CE; Mon, 7 Jun 2004 10:31:50 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0707943D49; Mon, 7 Jun 2004 10:31:50 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i57Abiws019650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jun 2004 13:37:46 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i57AVPt9001397; Mon, 7 Jun 2004 13:31:25 +0300 (EEST) (envelope-from ru) Date: Mon, 7 Jun 2004 13:31:25 +0300 From: Ruslan Ermilov To: "David O'Brien" , current@FreeBSD.org Message-ID: <20040607103125.GA1352@ip.net.ua> References: <20040604092313.GA12314@ip.net.ua> <20040607100616.GE29340@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline In-Reply-To: <20040607100616.GE29340@dragon.nuxi.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Subject: Re: Can the disklabel(8) link go now? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 10:31:51 -0000 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 07, 2004 at 03:06:16AM -0700, David O'Brien wrote: > On Fri, Jun 04, 2004 at 12:23:13PM +0300, Ruslan Ermilov wrote: > > I'd like to remove the old compatibility link from bsdlabel(8) > > to disklabel(8). I think the dust has settled enough to allow > > this to be done now (and before 5.3-RELEASE): >=20 > NO. We've been thru this not that long ago. >=20 > We should leave the disklable symlink forever -- it gives us a consistant > command interface across all our platforms. I've found NetBSD very > anonying in the past that the labeling command has a different name > across different platforms. The symlink causes no harm. Why are you on > such a war path to kill it?? >=20 I've just been wading through my old local diffs, and wanted to finally nail this thing down. Now that it is clear that the minimal consensus is to keep this (hard) link for at least a few more years, I've reverted this diff locally, and quickly started to forget about it. ;) Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAxEP9qRfpzJluFF4RAgIeAKCelHehzbLfkIaylwiS3uDqqGWIFQCgjomE L4Vx5lo4OrRghM7lMXQEJFY= =Dm50 -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 11:00:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30E9A16A4CE for ; Mon, 7 Jun 2004 11:00:19 +0000 (GMT) Received: from hetzner.co.za (lfw.hetzner.co.za [196.7.18.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CAEE43D1F for ; Mon, 7 Jun 2004 11:00:18 +0000 (GMT) (envelope-from ianf@hetzner.co.za) Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 3.36 #1) id 1BXHrQ-00019t-00 for freebsd-current@freebsd.org; Mon, 07 Jun 2004 13:00:12 +0200 To: John Baldwin From: Ian FREISLICH In-reply-to: Your message of "Fri, 04 Jun 2004 14:34:32 -0400." <200406041434.32193.jhb@FreeBSD.org> X-Attribution: BOFH Date: Sat, 05 Jun 2004 23:44:09 +0200 Sender: ianf@hetzner.co.za Resent-To: freebsd-current@freebsd.org Resent-Date: Mon, 07 Jun 2004 13:00:12 +0200 Resent-From: Ian FREISLICH Resent-Message-Id: cc: freebsd-current@freebsd.org Subject: Re: It's happening again (panic early in boot) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 11:00:19 -0000 John Baldwin wrote: > On Friday 04 June 2004 11:14 am, Ian FREISLICH wrote: > > John Baldwin wrote: > > > On Friday 04 June 2004 06:45 am, Ian FREISLICH wrote: > > > > Hi > > > > > > > > Every month or so after it started working I get this panic. > > > > The panic then goes away after a month or two, with no > > > > explanation. During the existence of the panic I try new kernel > > > > source once a day. > > > > > > > > This is an SMP machine. Using the same source UP kernels work > > > > fine, SMP kernels don't. The last SMP kernel that worked is > > > > circa May 17. > > > > > > grr, I still don't know why this happens. One thing though is > > > that if we can fix the nested panic we might can work on the first > > > one. > > > > If you want access to the box in question, I can arrange that. > > > > > > Booting [/boot/kernel/kernel]... > > > > /boot/kernel/acpi.ko text=0x3a0e4 data=0x19e4+0x11ac > > > > syms=[0x4+0x6860+0x4+0x8a87 ] > > > > Copyright (c) 1992-2004 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.2-CURRENT #15: Fri Jun 4 10:23:23 SAST 2004 > > > > > > > > ianf@brane-dead.freislich.nom.za:/usr/src/sys/i386/compile/BRANE-DEAD > > > > Preloaded elf kernel "/boot/kernel/kernel" at 0xc0728000. > > > > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0728244. > > > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > > > CPU: Pentium II/Pentium II Xeon/Celeron (267.27-MHz 686-class CPU) > > > > Origin = "GenuineIntel" Id = 0x634 Stepping = 4 > > > > > > > > Features=0x80fbff > > >MCA, CMO V,MMX> > > > > real memory = 201261056 (191 MB) > > > > avail memory = 191311872 (182 MB) > > > > MPTable: > > > > kernel trap 12 with interrupts disabled > > > > > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > > cpuid = 0; apic id = 00 > > > > fault virtual address = 0x1c > > > > fault code = supervisor write, page not present > > > > instruction pointer = 0x8:0xc058d98e > > > > > > Can you do a gdb -k on kernel.debug and do 'l *' on this address? That > > > might let us fix the panic in vm_fault(). > > > > Is this what you're after? > > > > (kgdb) l * 0xc058d98e > > 0xc058d98e is in vm_fault (machine/atomic.h:154). > > 149 static __inline int > > 150 atomic_cmpset_int(volatile u_int *dst, u_int exp, u_int src) > > 151 { > > 152 int res = exp; > > 153 > > 154 __asm __volatile ( > > 155 " " __XSTRING(MPLOCKED) " " > > 156 " cmpxchgl %1,%2 ; " > > 157 " setz %%al ; " > > 158 " movzbl %%al,%0 ; " > > > > Ian > > Hmm, darn inlines. :) Can you compile the kernel with either > INVARIANTS or MUTEX_NOINLINE so that mutex ops aren't inlined, > reproduce the panic and then do the same lookup using the new faulting > IP? (kgdb) l * 0xc04b9828 0xc04b9828 is in _mtx_lock_flags (../../../kern/kern_mutex.c:247). 242 void 243 _mtx_lock_flags(struct mtx *m, int opts, const char *file, int line) 244 { 245 246 MPASS(curthread != NULL); 247 KASSERT(m->mtx_object.lo_class == &lock_class_mtx_sleep, 248 ("mtx_lock() of spin mutex %s @ %s:%d", m->mtx_object.lo_name, 249 file, line)); 250 WITNESS_CHECKORDER(&m->mtx_object, opts | LOP_NEWORDER | LOP_EXCLUSIVE, 251 file, line); Interstingly with INVARIENTS, the panic is exactly the same except for this (new) text at the end of the multiple panic: panic: page fault at line 815 in file ../../../i386/i386/trap.ccpuid = 0; Uptime: 1s panic: _mtx_lock_sleep: recursed on non-recursive mutex system map @ ../../../vm/vm_map.c:2876 at line 437 in file ../../../kern/kern_mutex.ccpuid = 0; Uptime: 1s panic: _mtx_lock_sleep: recursed on non-rep Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 11:03:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8307F16A4D1 for ; Mon, 7 Jun 2004 11:03:07 +0000 (GMT) Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA13543D2D for ; Mon, 7 Jun 2004 11:03:06 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd02.aul.t-online.de by mailout08.sul.t-online.com with smtp id 1BXHuD-0005Ac-00; Mon, 07 Jun 2004 13:03:05 +0200 Received: from Andro-Beta.Leidinger.net (EXrKycZ6Qe3QHOzAjqDPDO3uXXXtqG8xUsIFNcxyjeljt3mHywMTgy@[80.131.123.52]) by fmrl02.sul.t-online.com with esmtp id 1BXHtz-0yg26K0; Mon, 7 Jun 2004 13:02:51 +0200 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) i57B36mr098821; Mon, 7 Jun 2004 13:03:06 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Mon, 7 Jun 2004 13:04:30 +0200 From: Alexander Leidinger To: Alan Cox Message-Id: <20040607130430.0ebbbb8e@Magellan.Leidinger.net> In-Reply-To: <20040606201249.GH24461@cs.rice.edu> References: <20040606142446.2900a97e@Magellan.Leidinger.net> <20040606201249.GH24461@cs.rice.edu> X-Mailer: Sylpheed version 0.9.11claws (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Seen: false X-ID: EXrKycZ6Qe3QHOzAjqDPDO3uXXXtqG8xUsIFNcxyjeljt3mHywMTgy@t-dialin.net cc: current@freebsd.org Subject: Re: comments in the page coloring options in /sys/conf/NOTES X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 11:03:07 -0000 On Sun, 6 Jun 2004 15:12:49 -0500 Alan Cox wrote: > My recent commit fixed a "syntax" error in the comments, specifically, > a reference to a missing macro. The comments are, however, still > "semantically" broken: > > 1. Cache size alone does not correctly determine the number of colors, > except for direct map caches. The correct formula is > > (cache size in bytes / page size in bytes) / degree of cache associativity > > Thus, the comments would lead one to configure his/her system with too > many colors. (Relative to configuring a system with too few colors, > this is not so bad.) vm_page.h contains: ---snip--- #if PQ_CACHESIZE >= 1024 #define PQ_PRIME1 31 /* Prime number somewhat less than PQ_HASH_SIZE */ #define PQ_PRIME2 23 /* Prime number somewhat less than PQ_HASH_SIZE */ #define PQ_L2_SIZE 256 /* A number of colors opt for 1M cache */ ---snip--- The three defines seem to be the tunables for the page coloring, but neither of them seem to be near cache_size/page_size. So even for the direct mapped case this doesn't seem to fit your explanation. Is it as easy as using appropriate values for those defines at boot time or is there more work involved for auto-tuning version? Is there a way to determine the size of the L2 cache and the associativity at run time in the kernel or are these properties which we have to obtain from a table (which we have to write and maintain for automatic tuning)? > 2. The references to L1 should be removed. They are historical > leftovers. cut&paste: ---snip--- Index: sys/conf/NOTES =================================================================== RCS file: /big/FreeBSD-CVS/src/sys/conf/NOTES,v retrieving revision 1.1227 diff -u -r1.1227 NOTES --- sys/conf/NOTES 1 Jun 2004 06:22:56 -0000 1.1227 +++ sys/conf/NOTES 7 Jun 2004 10:07:16 -0000 @@ -103,13 +103,13 @@ # Options for the VM subsystem # L2 cache size (in KB) can be specified in PQ_CACHESIZE -options PQ_CACHESIZE=512 # color for 512k/16k cache +options PQ_CACHESIZE=512 # color for 512k cache # Deprecated options supported for backwards compatibility #options PQ_NOOPT # No coloring -#options PQ_LARGECACHE # color for 512k/16k cache -#options PQ_HUGECACHE # color for 1024k/16k cache -#options PQ_MEDIUMCACHE # color for 256k/16k cache -#options PQ_NORMALCACHE # color for 64k/16k cache +#options PQ_LARGECACHE # color for 512k cache +#options PQ_HUGECACHE # color for 1024k cache +#options PQ_MEDIUMCACHE # color for 256k cache +#options PQ_NORMALCACHE # color for 64k cache # This allows you to actually store this configuration file into # the kernel binary itself, where it may be later read by saying: Index: sys/vm/vm_pageq.c =================================================================== RCS file: /big/FreeBSD-CVS/src/sys/vm/vm_pageq.c,v retrieving revision 1.13 diff -u -r1.13 vm_pageq.c --- sys/vm/vm_pageq.c 30 May 2004 00:42:38 -0000 1.13 +++ sys/vm/vm_pageq.c 7 Jun 2004 10:38:31 -0000 @@ -176,8 +176,8 @@ * * The page coloring optimization attempts to locate a page * that does not overload other nearby pages in the object in - * the cpu's L1 or L2 caches. We need this optimization because - * cpu caches tend to be physical caches, while object spaces tend + * the cpu's L2 cache. We need this optimization because cpu + * caches tend to be physical caches, while object spaces tend * to be virtual. * * This routine must be called at splvm(). ---snip--- I think the comment with the reference to L1 in sys/vm/vm_zeroidle.c is ok. If this is ok, do I have your approval to commit it? Bye, Alexander. -- I'm available to get hired (preferred in .lu). http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 11:22:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62C5316A4CE for ; Mon, 7 Jun 2004 11:22:51 +0000 (GMT) Received: from mail.dt.e-technik.uni-dortmund.de (krusty.dt.e-technik.Uni-Dortmund.DE [129.217.163.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97EED43D1F for ; Mon, 7 Jun 2004 11:22:50 +0000 (GMT) (envelope-from ma@dt.e-technik.uni-dortmund.de) Received: from m2a2.dyndns.org (krusty.dt.e-technik.uni-dortmund.de [129.217.163.1])C508A2F045 for ; Mon, 7 Jun 2004 13:22:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id C690FC196C; Mon, 7 Jun 2004 13:22:46 +0200 (CEST) Received: from merlin.emma.line.org ([127.0.0.1]) by localhost (m2a2.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 02688-06-2; Mon, 7 Jun 2004 13:22:44 +0200 (CEST) Received: by merlin.emma.line.org (Postfix, from userid 500) id 66B78C190F; Mon, 7 Jun 2004 13:22:44 +0200 (CEST) To: Matthias Andree In-Reply-To: (Matthias Andree's message of "Sun, 06 Jun 2004 14:13:49 +0200") References: From: Matthias Andree Date: Mon, 07 Jun 2004 13:22:44 +0200 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new at m2a2.dyndns.org cc: freebsd-current@freebsd.org Subject: Re: xl(4) watchdog timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 11:22:51 -0000 Matthias Andree writes: > I have CVSupped my -CURRENT i386 machine (CPUTYPE=athlon-xp) and > rebooted and found the network non-functional, I get a message "xl0: > watchdog timeout" (or similar) every couple of seconds. The card in use > is a 3C900Combo, with the 10Base2/BNC port configured in /etc/rc.conf > and that is fine with older -CURRENT kernels (that are still younger > than 5.2.1-RELEASE). I received a mail off-list that suggested to not load ACPI. Booting without ACPI makes the problem go away. -- Matthias Andree Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 11:12:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7106E16A4CE for ; Sun, 6 Jun 2004 11:12:11 -0700 (PDT) Received: from web41111.mail.yahoo.com (web41111.mail.yahoo.com [66.218.93.27]) by mx1.FreeBSD.org (Postfix) with SMTP id 496A043D1F for ; Sun, 6 Jun 2004 11:12:09 -0700 (PDT) (envelope-from jmkatcher@yahoo.com) Message-ID: <20040606181203.45983.qmail@web41111.mail.yahoo.com> Received: from [24.18.54.216] by web41111.mail.yahoo.com via HTTP; Sun, 06 Jun 2004 11:12:03 PDT Date: Sun, 6 Jun 2004 11:12:03 -0700 (PDT) From: Jeffrey Katcher To: freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Mon, 07 Jun 2004 11:37:07 +0000 Subject: Atheros support no longer works on -CURRENT (kldload, possibly ACPI?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 18:12:11 -0000 Hardware: IBM Thinkpad T40, IBM Atheros A/B card Software: -CURRENT as of 6/5/04, but older 5/25 kernel still shows problem Symptoms: I don't use it very frequently, so I kldload if_ath as necessary. Previously, it was load, config, and go, now... I see: pci0: Failed to set ACPI power state D3 on (null): AE_BAD_PARAMETER before the usual (and correct) ath0 status messages When I "up" the interface, I see: ath0: hardware error; resetting in a continuous parade scrolling up the screen I tried setting hw.ath.debug, but the dump scrolls off faster than I can see it. The system has no serial port to capture from... This could be an ACPI issue instead, but I don't see anything like this for the compiled-in set of drivers. Jeff Katcher __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 14:35:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AED716A4CE; Sun, 6 Jun 2004 14:35:22 -0700 (PDT) Received: from mail.elvandar.org (cust.94.120.adsl.cistron.nl [195.64.94.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B7F643D46; Sun, 6 Jun 2004 14:35:21 -0700 (PDT) (envelope-from remko@elvandar.org) Received: from [10.0.3.124] (aragorn.lan.elvandar.intranet [10.0.3.124]) by mail.elvandar.org (Postfix) with ESMTP id 54D1110685E; Sun, 6 Jun 2004 23:35:11 +0200 (CEST) Message-ID: <40C38E11.601@elvandar.org> Date: Sun, 06 Jun 2004 23:35:13 +0200 From: Remko Lodder X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at elvandar.org X-Mailman-Approved-At: Mon, 07 Jun 2004 11:37:07 +0000 cc: hackers@freebsd.org cc: current@freebsd.org cc: Marcel Moolenaar Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 21:35:22 -0000 Hey all, Daniel Eischen wrote: > On Sun, 6 Jun 2004, Marcel Moolenaar wrote: > > >>On Sun, Jun 06, 2004 at 02:31:56PM -0600, Scott Long wrote: >> >> > > > Not to take away from the tremendous effort that jake had done for > sparc64, but it should really take more than one or two supporting > developers to obtain tier 1 support. People come and go, and > tierness should take that into account. > > We shouldn't keep an arch at tier 1 just to save face. Better to just > lower it to tier 2 and be done with it. My $.02, FWIW. > I agree with Daniel, although i am not developping for freebsd (lack of knowledge). I think that what Daniel says is true, you cannot say that you support a product in a tier 1 status, while you have way to less people to resolve things. In my opinion it's also better to lower it then, and perhaps upgrade it again when more supporters are available to resolve issues. It takes more time to recover from "failed support" then by honestly saying that you don't have the manpower to support it in a tier 1 branch. Besides that i can understand that this will hit certain people, depending on the sparc64 tier 1 status, but perhaps they can support as well.. We need to resolve this with all of us, and if we cannot find enough people to help , then it should -sadly enough- be degraded in tier status. my $0.02 :) -- Kind regards, Remko Lodder Elvandar.org/DSINet.org www.mostly-harmless.nl Dutch community for helping newcomers on the hackerscene From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 14:51:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3E6B16A4CE for ; Sun, 6 Jun 2004 14:51:54 -0700 (PDT) Received: from wireless.blueboard.cz (wireless.blueboard.cz [82.208.31.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDC7F43D1F for ; Sun, 6 Jun 2004 14:51:52 -0700 (PDT) (envelope-from lists@hosting50.cz) Received: (qmail 62432 invoked by uid 1003); 6 Jun 2004 21:51:42 -0000 Received: from lists@hosting50.cz by wireless.blueboard.cz by uid 89 with qmail-scanner-1.20 Clear:RC:0(10.15.141.2):SA:0(0.5/5.0):. Processed in 3.881067 secs); 06 Jun 2004 21:51:42 -0000 X-Spam-Status: No, hits=0.5 required=5.0 Received: from unknown (HELO ?10.15.141.2?) (lists@hosting50.cz@10.15.141.2) by ares.kosire.net with AES256-SHA encrypted SMTP; 6 Jun 2004 21:51:38 -0000 From: Tomas Randa To: freebsd-current@freebsd.org Message-Id: <1086565906.775.54.camel@ares.internetservice.cz> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 06 Jun 2004 23:51:46 +0000 X-Mailman-Approved-At: Mon, 07 Jun 2004 11:37:07 +0000 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: hostap TX patch in 5.x for 11Mbps speed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2004 21:51:54 -0000 Hi All, is now available patch to correct hostap for WI driver? I tried a hack from James Bowman, but unsuccessfully Thanks a lot. -- Tomas Randa From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 11:45:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12DA916A4CE; Mon, 7 Jun 2004 11:45:08 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3F7C43D46; Mon, 7 Jun 2004 11:45:07 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id B128DACAE6; Mon, 7 Jun 2004 13:45:05 +0200 (CEST) Date: Mon, 7 Jun 2004 13:45:05 +0200 From: Pawel Jakub Dawidek To: "Bjoern A. Zeeb" Message-ID: <20040607114505.GQ12007@darkness.comp.waw.pl> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3gk1bTGVZuaU9V5/" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: alfred@freebsd.org cc: FreeBSD current mailing list Subject: Re: vfs_syscalls / fhstatfs / suser() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 11:45:08 -0000 --3gk1bTGVZuaU9V5/ Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 06, 2004 at 07:38:14PM +0000, Bjoern A. Zeeb wrote: +> Hi, +>=20 +> if I am not wrong the part removed by the atatched diff is not +> needed because at the very beginning of the function there is a +>=20 +> error =3D suser(td); +> if (error) +> return (error); +>=20 +> so a second check should never become true again (if threads cannot be +> move in and out of jails). +>=20 +> please correct me if I am wrong. +>=20 +>=20 +> --- ./vfs_syscalls.c.orig Sun Jun 6 19:32:23 2004 +> +++ ./vfs_syscalls.c Sun Jun 6 19:33:12 2004 +> @@ -4128,11 +4128,6 @@ fhstatfs(td, uap) +> sp->f_flags =3D mp->mnt_flag & MNT_VISFLAGMASK; +> if ((error =3D VFS_STATFS(mp, sp, td)) !=3D 0) +> return (error); +> - if (suser(td)) { +> - bcopy(sp, &sb, sizeof(sb)); +> - sb.f_fsid.val[0] =3D sb.f_fsid.val[1] =3D 0; +> - sp =3D &sb; +> - } +> return (copyout(sp, uap->buf, sizeof(*sp))); +> } I'm not sure what the intention was, but I think we should probably change first suser() to suser_cred(td->td_ucred, PRISON_ROOT) as leave second one. PS. I'm CCing this to alfred@ who bring it from NetBSD. --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --3gk1bTGVZuaU9V5/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAxFVBForvXbEpPzQRAslhAKCZQ5Hw8y3s+yTSMTmN9snpY/fgmQCgpckH lFlK/aj1iN2Oojucd+u+DhM= =4aNv -----END PGP SIGNATURE----- --3gk1bTGVZuaU9V5/-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 11:48:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8188A16A4CE for ; Mon, 7 Jun 2004 11:48:48 +0000 (GMT) Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AA6243D2D for ; Mon, 7 Jun 2004 11:48:48 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd04.aul.t-online.de by mailout02.sul.t-online.com with smtp id 1BXIcO-0005Wt-04; Mon, 07 Jun 2004 13:48:44 +0200 Received: from Andro-Beta.Leidinger.net (rSeeDEZageRPclZaLSrWerQe7NDDdoWUmZRlXuKCEl1Ym0S+EQ7VrF@[84.128.197.114]) by fmrl04.sul.t-online.com with esmtp id 1BXIc9-1fn8Wu0; Mon, 7 Jun 2004 13:48:29 +0200 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) i57BmeTw005433; Mon, 7 Jun 2004 13:48:40 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Mon, 7 Jun 2004 13:50:04 +0200 From: Alexander Leidinger To: Maxim Sobolev Message-Id: <20040607135004.24050449@Magellan.Leidinger.net> In-Reply-To: <40C3CC0A.2030300@portaone.com> References: <40C3CC0A.2030300@portaone.com> X-Mailer: Sylpheed version 0.9.11claws (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Seen: false X-ID: rSeeDEZageRPclZaLSrWerQe7NDDdoWUmZRlXuKCEl1Ym0S+EQ7VrF@t-dialin.net cc: current@freebsd.org Subject: Re: Project Evil & ACX100-based cards (D-Link DWL-520+) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 11:48:48 -0000 On Mon, 07 Jun 2004 04:59:38 +0300 Maxim Sobolev wrote: > Hi Bill, > > I'm trying to make my D-Link DWL-520+ card working with if_ndis, but no > luck yet. The card is correctly detected, driver attaches to it. If I > configure it in the adhoc mode it is seen from the nearby machine and > connected to, but traffic doesn't flow. :-( > > Any ideas? Please let me know if more information is necessary. Have you tried the FreeBSD native KLD (wlan.kewl.org)? I've installed it on my brother's system and on a system of a friend. Both don't complain, so I assume it works for them (you may perhaps need to do a "ifconfig acx0 down; sleep 5; ifconfig acx0 up" after booting, but then it should negotiate with an AP). Bye, Alexander. -- I'm available to get hired (preferred in .lu). http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 12:06:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 23D4716A4D0 for ; Mon, 7 Jun 2004 12:06:26 +0000 (GMT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0444543D53 for ; Mon, 7 Jun 2004 12:06:26 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 20922 invoked from network); 7 Jun 2004 12:06:22 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 7 Jun 2004 12:06:21 -0000 Received: from slimer.baldwin.cx (slimer.baldwin.cx [192.168.0.16]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i57C6JT3002223; Mon, 7 Jun 2004 08:06:19 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Mon, 7 Jun 2004 08:07:13 -0400 User-Agent: KMail/1.6 References: <40BF38B4.6090208@gmx.net> <200406041521.34813.jhb@FreeBSD.org> <40C0FEFB.8050605@gmx.net> In-Reply-To: <40C0FEFB.8050605@gmx.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406070807.13562.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Andreas Moeller Subject: Re: fxp(4) device timeouts ACPI related? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 12:06:26 -0000 On Friday 04 June 2004 07:00 pm, Andreas Moeller wrote: > >>>>The ACPI updates predating last weekend seem to have broken my fxp(4) > >>>>card (Intel PRO/100 S, Intel 82550 chip). Without disabling ACPI at the > >>>>loader prompt (set hint.acpi.0.disabled=1) I get the consecutive > >>>> message of the device timing out and network is unusable. > >>>> > >>>>Perhaps this is useful information for everybody desiring to workaround > >>>>the problem or even some developer to have a closer look at it. If a > >>>>more detailed description of my setup is needed, just let me know. > >>> > >>>Can you get before and after dmesg's and post a diff? > >> > >>Of course. diff is attached, the kernel is an unmodified GENERIC. > > > > Looks like !ACPI gives IRQ 11 to everyone and ACPI gives some devices IRQ > > 5 and some IRQ 11. Can you get a dmesg from the older kernel with ACPI > > enabled and generate a diff of that dmesg against the current kernel with > > ACPI? > > Attached. I had to get some older sources and build the kernel since I > didn't keep an old enough kernel around. The sources used date to May > 28th, 2:50am (UTC) and network works with ACPI enabled. > > I'm by no means an expert but I don't see any new insight revealed by > the diff between those two dmesgs. How about a dmesg from a boot -v with the new kernel? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 12:10:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26D8616A4D0 for ; Mon, 7 Jun 2004 12:10:13 +0000 (GMT) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id D716B43D2F for ; Mon, 7 Jun 2004 12:10:12 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 13889 invoked from network); 7 Jun 2004 12:10:01 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 7 Jun 2004 12:10:00 -0000 Received: from slimer.baldwin.cx (slimer.baldwin.cx [192.168.0.16]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i57C9sEg002234; Mon, 7 Jun 2004 08:09:54 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Mon, 7 Jun 2004 08:10:49 -0400 User-Agent: KMail/1.6 References: <200406051220.56698.msch@snafu.de> <20040605192018.GB42830@dan.emsphone.com> In-Reply-To: <20040605192018.GB42830@dan.emsphone.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406070810.49096.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Matthias Schuendehuette cc: Dan Nelson Subject: Re: IRQ-Routing Problems (ShowStopper) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 12:10:13 -0000 On Saturday 05 June 2004 03:20 pm, Dan Nelson wrote: > In the last episode (Jun 05), Matthias Schuendehuette said: > > I have still IRQ-Problems on my machine which seem to be ACPI related > > (i.e. which don't occur without ACPI) but seem to have a different > > source than the last shutdown/reboot issue. > > > > The last working kernel is from May 22, after the new ACPI-Code no > > kernel boots with ACPI enabled any more. > > > > The core problem is the handling of IRQ 10 on my machine. This IRQ is > > marked as 'Legacy/ISA' in my BIOS-Settings and is used for my ISA > > "Teles S0/16.3"-ISDN-Card. > > I'm having similar problems with IRQs. I haven't reserved any IRQs in > my BIOS (no ISA cards), but with ACPI enabled, my SCSI card doesn't > seem to be getting interrupts, and my soundcard gets probed as pcm2 > instead of pcm0. > > --- /tmp/dmesg.noacpi > +++ /tmp/dmesg.acpi > -$PIR: 0:7 INTD routed to irq 9 > -$PIR: 0:11 INTA routed to irq 3 > -$PIR: 0:13 INTA routed to irq 11 > -$PIR: 0:14 INTA routed to irq 9 > -$PIR: 1:0 INTA routed to irq 11 > +pcib0: slot 7 INTD is routed to irq 5 > +pcib0: slot 11 INTA is routed to irq 11 > +pcib0: slot 13 INTA is routed to irq 10 > +pcib0: slot 14 INTA is routed to irq 9 > +pcib0: slot 1 INTA is routed to irq 10 > +pcib1: slot 0 INTA is routed to irq 10 > > Full dmesgs attached. ACPI's pci_link driver doesn't use the same algorithm as the $PIR code (i.e., only use known-good IRQs that the BIOS has already used). I am working on updating the pci_link code to do that which should fix problems with ACPI IRQ routing when not using APIC. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 12:10:27 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B7E516A4D1; Mon, 7 Jun 2004 12:10:27 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id F27C843D45; Mon, 7 Jun 2004 12:10:26 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 474BDACAF1; Mon, 7 Jun 2004 14:10:16 +0200 (CEST) Date: Mon, 7 Jun 2004 14:10:16 +0200 From: Pawel Jakub Dawidek To: "Bjoern A. Zeeb" Message-ID: <20040607121016.GR12007@darkness.comp.waw.pl> References: <20040607114505.GQ12007@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f0Ums9VvOMUG7syy" Content-Disposition: inline In-Reply-To: <20040607114505.GQ12007@darkness.comp.waw.pl> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: alfred@freebsd.org cc: FreeBSD current mailing list Subject: Re: vfs_syscalls / fhstatfs / suser() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 12:10:27 -0000 --f0Ums9VvOMUG7syy Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 07, 2004 at 01:45:05PM +0200, Pawel Jakub Dawidek wrote: +> I'm not sure what the intention was, but I think we should probably +> change first suser() to suser_cred(td->td_ucred, PRISON_ROOT) as leave +> second one. +>=20 +> PS. I'm CCing this to alfred@ who bring it from NetBSD. Ok, it looks it was just copied from statfs(2) and it is not needed here. I'm going to remove it, thanks. --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --f0Ums9VvOMUG7syy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAxFsoForvXbEpPzQRAlKxAJ9IflhqMJtAa7bv/WrpPFYoqD+eTwCgy+d2 XyPHj2wsveZtBUPbCOts8Lo= =kRg3 -----END PGP SIGNATURE----- --f0Ums9VvOMUG7syy-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 12:39:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 070AF16A4CE; Mon, 7 Jun 2004 12:39:06 +0000 (GMT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32FA343D2D; Mon, 7 Jun 2004 12:39:05 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.9/8.12.9) with ESMTP id i57CcpkM059220; Mon, 7 Jun 2004 13:38:55 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) i57CcXON079354; Mon, 7 Jun 2004 13:38:37 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: John Baldwin In-Reply-To: <200406070810.49096.jhb@FreeBSD.org> References: <200406051220.56698.msch@snafu.de> <20040605192018.GB42830@dan.emsphone.com> <200406070810.49096.jhb@FreeBSD.org> Content-Type: text/plain Message-Id: <1086611912.10911.14.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 07 Jun 2004 13:38:33 +0100 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: Matthias Schuendehuette cc: freebsd-current@freebsd.org cc: Dan Nelson Subject: Re: IRQ-Routing Problems (ShowStopper) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 12:39:06 -0000 On Mon, 2004-06-07 at 13:10, John Baldwin wrote: > On Saturday 05 June 2004 03:20 pm, Dan Nelson wrote: > > In the last episode (Jun 05), Matthias Schuendehuette said: > > > I have still IRQ-Problems on my machine which seem to be ACPI related > > > (i.e. which don't occur without ACPI) but seem to have a different > > > source than the last shutdown/reboot issue. > > > > > > The last working kernel is from May 22, after the new ACPI-Code no > > > kernel boots with ACPI enabled any more. > > > > > > The core problem is the handling of IRQ 10 on my machine. This IRQ is > > > marked as 'Legacy/ISA' in my BIOS-Settings and is used for my ISA > > > "Teles S0/16.3"-ISDN-Card. > > > > I'm having similar problems with IRQs. I haven't reserved any IRQs in > > my BIOS (no ISA cards), but with ACPI enabled, my SCSI card doesn't > > seem to be getting interrupts, and my soundcard gets probed as pcm2 > > instead of pcm0. > > > > --- /tmp/dmesg.noacpi > > +++ /tmp/dmesg.acpi > > -$PIR: 0:7 INTD routed to irq 9 > > -$PIR: 0:11 INTA routed to irq 3 > > -$PIR: 0:13 INTA routed to irq 11 > > -$PIR: 0:14 INTA routed to irq 9 > > -$PIR: 1:0 INTA routed to irq 11 > > +pcib0: slot 7 INTD is routed to irq 5 > > +pcib0: slot 11 INTA is routed to irq 11 > > +pcib0: slot 13 INTA is routed to irq 10 > > +pcib0: slot 14 INTA is routed to irq 9 > > +pcib0: slot 1 INTA is routed to irq 10 > > +pcib1: slot 0 INTA is routed to irq 10 > > > > Full dmesgs attached. > > ACPI's pci_link driver doesn't use the same algorithm as the $PIR code (i.e., > only use known-good IRQs that the BIOS has already used). I am working on > updating the pci_link code to do that which should fix problems with ACPI IRQ > routing when not using APIC. I have similar problems with an Epia CL10000 board. ACPI doesn't route the interrupts properly for one of its ethernet ports. I'll supply more details on request but currently this board is running very nicely without acpi as my home gateway and my partner gets irritated if I reboot it too often... From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 12:57:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FBE616A4CE; Mon, 7 Jun 2004 12:57:50 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10B9943D1D; Mon, 7 Jun 2004 12:57:45 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id i57CvMRs091708; Mon, 7 Jun 2004 22:27:24 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Mon, 7 Jun 2004 22:27:20 +0930 User-Agent: KMail/1.6.2 References: <200406051220.56698.msch@snafu.de> <20040605192018.GB42830@dan.emsphone.com> <200406070810.49096.jhb@FreeBSD.org> In-Reply-To: <200406070810.49096.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200406072227.20123.doconnor@gsoft.com.au> X-Spam-Score: -5.2 () CARRIAGE_RETURNS,IN_REP_TO,PGP_SIGNATURE,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_KMAIL X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: Matthias Schuendehuette cc: Dan Nelson Subject: Re: IRQ-Routing Problems (ShowStopper) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 12:57:50 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 7 Jun 2004 21:40, John Baldwin wrote: > ACPI's pci_link driver doesn't use the same algorithm as the $PIR code > (i.e., only use known-good IRQs that the BIOS has already used). I am > working on updating the pci_link code to do that which should fix problems > with ACPI IRQ routing when not using APIC. Let me know if you need a patch tester. I have an Inspiron 8600 which gets bfe timeouts with the new ACPI code (wel= l=20 I'm pretty sure that's the cause) =2D --=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAxGYw5ZPcIHs/zowRAnThAJ9e8/sYBTa3jezqERIVp/J7ula/FACeLMzC 86l8Xz9+1fQxWs+aVPHRJM4=3D =3DzXrz =2D----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 13:12:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71BB916A4CE for ; Mon, 7 Jun 2004 13:12:12 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9472643D41 for ; Mon, 7 Jun 2004 13:12:11 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id i57DBpc3091949; Mon, 7 Jun 2004 22:41:52 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Mon, 7 Jun 2004 22:41:50 +0930 User-Agent: KMail/1.6.2 References: <20040606181203.45983.qmail@web41111.mail.yahoo.com> In-Reply-To: <20040606181203.45983.qmail@web41111.mail.yahoo.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200406072241.50507.doconnor@gsoft.com.au> X-Spam-Score: -4.1 () CARRIAGE_RETURNS,IN_REP_TO,PGP_SIGNATURE,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_KMAIL X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: Jeffrey Katcher Subject: Re: Atheros support no longer works on -CURRENT (kldload, possibly ACPI?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 13:12:12 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 7 Jun 2004 03:42, Jeffrey Katcher wrote: > I tried setting hw.ath.debug, but the dump scrolls off faster than I can > see it. The system has no serial port to capture from... > > This could be an ACPI issue instead, but I don't see anything like this f= or > the compiled-in set of drivers. Try disabling APCI - the new code does interrupt routing differently which= =20 seems to break a few things. A fix is in the pipeline. The last good kernel I have for my Inspiron is made with 2004.05.27.14.30.0= 0=20 sources. =2D --=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAxGmW5ZPcIHs/zowRAk70AKCaft3AxK2icaYU0rX5TaXSuQ9DEACdHo2E jv7l1uuI+F/B+g21C9bDiZw=3D =3D3HNc =2D----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 13:14:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 326F616A4CE for ; Mon, 7 Jun 2004 13:14:55 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC42543D54 for ; Mon, 7 Jun 2004 13:14:54 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i57DEktD008667; Mon, 7 Jun 2004 09:14:46 -0400 (EDT) Date: Mon, 7 Jun 2004 09:14:46 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Doug Rabson In-Reply-To: <200406071011.01370.dfr@nlsystems.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 13:14:55 -0000 On Mon, 7 Jun 2004, Doug Rabson wrote: > On Sunday 06 June 2004 20:55, Daniel Eischen wrote: > > On Sun, 6 Jun 2004, Scott Long wrote: > > > All, > > > > > > We are about 4-6 weeks away from starting the 5.3 release cycle. > > > As it stands, KSE still only works reliably on i386. There are > > > reports of significant instability on amd64, and it doesn't work at > > > all on alpha and sparc64. I'm willing to drop the alpha > > > requirement and maybe even the sparc64 requirement, but there > > > absolutely will not be a 5.3 until amd64 is solid. Please contact > > > myself, Dan Eischen, and David Xu if you are interested in helping > > > out. > > > > amd64 looks to be a problem in readline which doesn't seem > > to redispatch signal handlers with SA_SIGINFO arguments. > > > > David also has patches for debugging support at: > > > > http://people.freebsd.org/~davidxu/kse/dbg/ > > > > Doug Rabson also has basic TLS support working in perforce. > > It'd be nice to get TLS and debugging in before 5.3-release. > > I'll probably try to commit some kind of TLS support into current in the > next couple of weeks. Its likely to only support i386 and will be > stubbed out for other platforms. Right now, I'm just waiting for some > kind of feedback from an nvidia developer whos testing it. Are you using the extra (*(%gs)->tls) to get TLS? -- Dan Eischen From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 13:31:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3828316A513 for ; Mon, 7 Jun 2004 13:31:12 +0000 (GMT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id B03B243D66 for ; Mon, 7 Jun 2004 13:31:11 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.9/8.12.9) with ESMTP id i57DUukM060910; Mon, 7 Jun 2004 14:30:56 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) i57DUtON080229; Mon, 7 Jun 2004 14:30:55 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086615054.10911.17.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 07 Jun 2004 14:30:55 +0100 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: freebsd-current@freebsd.org Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 13:31:12 -0000 On Mon, 2004-06-07 at 14:14, Daniel Eischen wrote: > On Mon, 7 Jun 2004, Doug Rabson wrote: > > > On Sunday 06 June 2004 20:55, Daniel Eischen wrote: > > > On Sun, 6 Jun 2004, Scott Long wrote: > > > > All, > > > > > > > > We are about 4-6 weeks away from starting the 5.3 release cycle. > > > > As it stands, KSE still only works reliably on i386. There are > > > > reports of significant instability on amd64, and it doesn't work at > > > > all on alpha and sparc64. I'm willing to drop the alpha > > > > requirement and maybe even the sparc64 requirement, but there > > > > absolutely will not be a 5.3 until amd64 is solid. Please contact > > > > myself, Dan Eischen, and David Xu if you are interested in helping > > > > out. > > > > > > amd64 looks to be a problem in readline which doesn't seem > > > to redispatch signal handlers with SA_SIGINFO arguments. > > > > > > David also has patches for debugging support at: > > > > > > http://people.freebsd.org/~davidxu/kse/dbg/ > > > > > > Doug Rabson also has basic TLS support working in perforce. > > > It'd be nice to get TLS and debugging in before 5.3-release. > > > > I'll probably try to commit some kind of TLS support into current in the > > next couple of weeks. Its likely to only support i386 and will be > > stubbed out for other platforms. Right now, I'm just waiting for some > > kind of feedback from an nvidia developer whos testing it. > > Are you using the extra (*(%gs)->tls) to get TLS? Yes. Our compiler always generates code like this: movl %gs:0,%eax movl 1234,%ntpoff(foo)(%eax) From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 14:11:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAB2F16A4CE for ; Mon, 7 Jun 2004 14:11:38 +0000 (GMT) Received: from dsl-mail.kamp.net (mail.kamp-dsl.de [195.62.99.42]) by mx1.FreeBSD.org (Postfix) with SMTP id 38C9143D1D for ; Mon, 7 Jun 2004 14:11:38 +0000 (GMT) (envelope-from root@pukruppa.de) Received: (qmail 32454 invoked by uid 513); 7 Jun 2004 14:14:32 -0000 Received: from root@pukruppa.de by dsl-mail by uid 89 with qmail-scanner-1.21 Clear:RC:1(213.146.114.24):SA:0(-4.9/5.0):. Processed in 0.666893 secs); 07 Jun 2004 14:14:32 -0000 X-Spam-Status: No, hits=-4.9 required=5.0 Received: from unknown (HELO reverse-213-146-114-24.dialin.kamp-dsl.de) (213.146.114.24) by dsl-mail.kamp.net with SMTP; 7 Jun 2004 14:14:31 -0000 Date: Mon, 7 Jun 2004 16:11:47 +0200 (CEST) From: Peter Ulrich Kruppa X-X-Sender: root@pukruppa.net To: Julian Elischer In-Reply-To: Message-ID: <20040607160206.G854@pukruppa.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: FreeBSD current users cc: net@freebsd.org Subject: Re: HEADSUP! netgraph Metadata changing. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 14:11:39 -0000 Hi! Sorry for topposting, but I don't know if this has got something to do with your changes: I am trying to rebuild my -CURRENT system now for some days and keep receiving panic messages from ng_ppoe like this panic NG_MKMESSAGE() with how=M_DONTWAIT(1) at line 913 in file /usr/src/sys/netgraph/ng_pppoe.c ... netgraph/pppoe is used by ppp to connect to my ISP . My last working kernel was built on May 31 . Thanks, if you know how to repair this. Uli. On Sun, 6 Jun 2004, Julian Elischer wrote: > > If you don't know or care about netgraph metadata (e.g. packet priority) > then this shouldn't worry you. > > We are changing the netgraph metadata facility (in which arbitrary > metadata can be sent with a packet through processing) to use > the mbuf TAG facility that has been imported by sam. > > Netgraph tags will use different cookies to the standard set of > tags imported with the code, so they will live in a separate namespace, > however they will be handled during GC and manipulation by the standard > tag handling code (Thanks to Sam for giving us the cookie facility). > > In the checked in code there are only a couple of users of metadata, but > there may be 3rd parties out there that use it. If so the authors should > contact me as soon as possible to co-ordinate the changeover. > > For example the BW_MAN bandwith manager uses metadata to tag > packets selected by its ipfw netgraph node. > > Currently the biggest user of metadata is the frame relay LMI > node that tags LMI packets with a higher priority in order to meet > timing constraints given by the standards. > > In addition the ng_ksocket node adds info into metadata and I suspect > there are people using that. > > > julian > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > +---------------------------+ | Peter Ulrich Kruppa | | Wuppertal | | Germany | +---------------------------+ From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 14:44:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 104D216A4CE for ; Mon, 7 Jun 2004 14:44:09 +0000 (GMT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CE4943D46 for ; Mon, 7 Jun 2004 14:44:08 +0000 (GMT) (envelope-from ahoff@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2657.72) id ; Mon, 7 Jun 2004 10:43:59 -0400 Message-ID: From: Alex Hoff To: "'freebsd-current@freebsd.org'" Date: Mon, 7 Jun 2004 10:43:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: Sysinstall & labels/fdisk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 14:44:09 -0000 Hi I have run in to an odd problem that on a freebsd 5.2 current system after running fdisk and disklabel the initial time on install, i am never allowed to do it again. What I have tried on many different systems, is to run sysinstall, and either run fdisk or label. After making a change and trying to write the changes, it will fail. Even if you dont make a change, and just try to write the current settings to the disk, it will fail. The following error comes up "ERROR: Unable to write data to disk ad0" (if also tried different types of disk devices - da/aacd). Ktrace shows the error as "errno 1 Operation not permitted" Anyone have any ideas or input? Thanks From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 14:48:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C87616A4D0 for ; Mon, 7 Jun 2004 14:48:09 +0000 (GMT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 82BC943D31 for ; Mon, 7 Jun 2004 14:48:08 +0000 (GMT) (envelope-from tmoestl@gmx.net) Received: (qmail 26186 invoked by uid 65534); 7 Jun 2004 14:48:05 -0000 Received: from p50907740.dip.t-dialin.net (EHLO timesink.dyndns.org) (80.144.119.64) by mail.gmx.net (mp025) with SMTP; 07 Jun 2004 16:48:05 +0200 X-Authenticated: #5374206 Received: by raven (Postfix, from userid 1001) id AFFFEBC; Mon, 7 Jun 2004 16:48:04 +0200 (CEST) Date: Mon, 7 Jun 2004 16:48:04 +0200 From: Thomas Moestl To: Kris Kennaway Message-ID: <20040607144804.GA1594@timesink.dyndns.org> References: <40C36D31.4010003@freebsd.org> <20040606193510.GA95886@dhcp50.pn.xcllnt.net> <40C37F3C.1050602@freebsd.org> <20040606211249.GC96607@dhcp50.pn.xcllnt.net> <20040606214228.GA44280@freebie.xs4all.nl> <40C39159.1030102@freebsd.org> <20040606215921.GA96205@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040606215921.GA96205@xor.obsecurity.org> User-Agent: Mutt/1.5.6i cc: hackers@freebsd.org cc: current@freebsd.org cc: peter@freebsd.org Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 14:48:09 -0000 On Sun, 2004/06/06 at 14:59:21 -0700, Kris Kennaway wrote: > On Sun, Jun 06, 2004 at 03:49:13PM -0600, Scott Long wrote: > > amd64 is approaching critical mass for tier-1. There are a number of > > developers that own amd64 hardware now, and a number of users who are > > asking about it on the mailing lists. Peter is finishing up the last > > blocking item for it (kld's) not including the observed KSE problems. > > It's very close and I _will_ hold up the release for it to get done. > > amd64 is the future of commodity computing and we aren't going to > > ignore it for 5-STABLE. > > amd64 has a bug with swapping - when something begins to access swap, > the entire system becomes almost entirely unresponsive (e.g. no mouse > response for up to 10 seconds) until it stops. Peter has some ideas > about it, but it's a serious enough bug that it forced me to stop > using amd64 as my desktop machine (hello, kde!). Hmmm, I have encountered a similar problem on sparc64 once; the reason was that vm_pageout_map_deactivate_pages() calls pmap_remove() for the range from the start to the end of the process's vm_map when a process is swapped out. Start and end are VM_MIN_ADDRESS and VM_MAXUSER_ADDRESS respectively, and on 64-bit architectures, that range is very large (128TB on ia64 if I'm not mistaken), so the iteration in pmap_remove() must be carefully designed to make as large steps as possible to avoid long run times (or to not iterate over the range at all if it becomes too large, which we did on sparc64). It seems that the amd64 version of pmap_remove() will essentially always iterate in 2MB (level 2 page table) steps, regardless of whether there is mapping for the respective level 2 table in the table levels above; that means that in the previously mentioned case, the outer loop will usually run for about 67 million iterations (the resident count guard may not be of much use here if a stack page is left at the very end of the address space). Since there are a few memory accesses needed in each iterations, that may already be the cause of such a delay. I have no hardware to test this, so all of the above is just a wild- assed guess; but maybe it is of use (and sorry for the spam if it is not). - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ "I realized that the purpose of writing is to inflate weak ideas, obscure poor reasoning, and inhibit clarity." -- Calvin and Hobbes From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 14:57:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82D9216A4CE; Mon, 7 Jun 2004 14:57:51 +0000 (GMT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75A0043D2D; Mon, 7 Jun 2004 14:57:51 +0000 (GMT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id A7E0F5C82D; Mon, 7 Jun 2004 07:57:50 -0700 (PDT) Date: Mon, 7 Jun 2004 07:57:50 -0700 From: Alfred Perlstein To: Pawel Jakub Dawidek Message-ID: <20040607145750.GB90021@elvis.mu.org> References: <20040607114505.GQ12007@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040607114505.GQ12007@darkness.comp.waw.pl> User-Agent: Mutt/1.4.2.1i cc: "Bjoern A. Zeeb" cc: FreeBSD current mailing list Subject: Re: vfs_syscalls / fhstatfs / suser() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 14:57:51 -0000 * Pawel Jakub Dawidek [040607 04:45] wrote: > +> > +> > +> --- ./vfs_syscalls.c.orig Sun Jun 6 19:32:23 2004 > +> +++ ./vfs_syscalls.c Sun Jun 6 19:33:12 2004 > +> @@ -4128,11 +4128,6 @@ fhstatfs(td, uap) > +> sp->f_flags = mp->mnt_flag & MNT_VISFLAGMASK; > +> if ((error = VFS_STATFS(mp, sp, td)) != 0) > +> return (error); > +> - if (suser(td)) { > +> - bcopy(sp, &sb, sizeof(sb)); > +> - sb.f_fsid.val[0] = sb.f_fsid.val[1] = 0; > +> - sp = &sb; > +> - } > +> return (copyout(sp, uap->buf, sizeof(*sp))); > +> } > > I'm not sure what the intention was, but I think we should probably > change first suser() to suser_cred(td->td_ucred, PRISON_ROOT) as leave > second one. > > PS. I'm CCing this to alfred@ who bring it from NetBSD. That sounds right. -- - Alfred Perlstein - Research Engineering Development Inc. - email: bright@mu.org cell: 408-480-4684 From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 15:09:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9F0F16A4CE for ; Mon, 7 Jun 2004 15:09:57 +0000 (GMT) Received: from parts-unknown.org (dsl093-170-248.sfo4.dsl.speakeasy.net [66.93.170.248]) by mx1.FreeBSD.org (Postfix) with SMTP id 6C4F143D4C for ; Mon, 7 Jun 2004 15:09:57 +0000 (GMT) (envelope-from benfell@parts-unknown.org) Received: (qmail 7094 invoked by alias); 7 Jun 2004 15:09:56 -0000 Date: Mon, 7 Jun 2004 08:09:56 -0700 From: "David A. Benfell" To: current@freebsd.org Message-ID: <20040607150956.GA7084@parts-unknown.org> Mail-Followup-To: current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-stardate: [-29]2233.08 X-moon: The Moon is Waning Gibbous (74% of Full) User-Agent: Mutt/1.5.6i Subject: file descripter leak in current with Qmail? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 15:09:57 -0000 Hello all, I'm running current, with qmail and spamassassin. Having finally caught on to the new kernel build process (ahem), I'm now having problems with the qmail UIDs (mostly for qmaild but occasionally qmails) exceeding the openfiles limit. When I used sysctl to interrogate kern.openfiles, it said 1836. I have not altered the default maximum. When I shut down qmail, it promptly dropped to something like 180. When I restarted qmail, it went back up to something like 194 but system responsiveness dropped through the floor. In basically the time it's taken me to write this much, kern.openfiles has climbed to something like 261. So I guess I have a couple of idiot questions to ask here: Is the kern.openfiles limit something (relatively) new? I was running current before on this box but hadn't gotten through a build because I hadn't caught on to the new kernel build process since before 5.2 was released. Qmail was not a problem before. Is the correct response to this problem to raise the limit? If so, I presume this would be done in rc.conf; what would be the corresponding variable in rc.conf? In the time I've composed this far, system responsiveness seems to have returned to normal and kern.openfiles has dropped to something like 221. So I assume the responsiveness issue had to do with qmail trying to catch up. I'm in between quarters in school right now, so I have a little time to play with this if needed. -- David Benfell, LCP benfell@parts-unknown.org --- Resume available at http://www.parts-unknown.org/resume.html From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 15:31:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FCCE16A4CE for ; Mon, 7 Jun 2004 15:31:22 +0000 (GMT) Received: from thought.holo.org (h-68-166-32-19.snvacaid.covad.net [68.166.32.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id B018243D5A for ; Mon, 7 Jun 2004 15:31:21 +0000 (GMT) (envelope-from bwb@holo.org) Received: from localhost (localhost [127.0.0.1]) by thought.holo.org (8.12.11/8.12.11) with ESMTP id i57FVIin065236; Mon, 7 Jun 2004 08:31:19 -0700 (PDT) (envelope-from bwb@holo.org) Date: Mon, 7 Jun 2004 08:31:18 -0700 (PDT) From: Brian Buchanan To: Tai-hwa Liang In-Reply-To: <040607143347F.86443@www.mmlab.cse.yzu.edu.tw> Message-ID: <20040607082413.U93758-100000@thought.holo.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: T40 panics at usb_get_next_event() when ACPI is disabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 15:31:22 -0000 Yes, I see this too on my T40p, but only when booting with the mouse plugged into the laptop through a USB hub connected to the docking station. If the mouse is plugged in directly to the laptop (I haven't tried plugging the USB hub directly into the laptop) or not plugged in, the problem does not occur. My hypothesis is that because a certain event list entry is being overwritten, the USB event list only grows long enough to use this area of memory in this configuration. I wrote a function to perform a sanity check on the event list and determined that the list is not corrupt after all the USB boot-time events have been queued. The list becomes corrupted some time between then and when usbd attempts to read the event queue. One of the events, the same one every time, is overwritten with something like 0x01000010 (I don't have a log of the actual bit pattern). Since it's happening to the same object every time, the next step would be to set a watch point in the debugger. I'll probably give this a try once I have a chance to consult with someone who knows more about kernel debugging. I did experiment with rolling back some usb commits, but it does not appear that a change to the usb subsystem is what caused this breakage. I think something else in the system is misbehaving and overwriting memory. - Brian -- Brian Buchanan, CISSP bwb@holo.org -------------------------------------------------------------------------- FreeBSD - The Power to Serve http://www.freebsd.org On Mon, 7 Jun 2004, Tai-hwa Liang wrote: > Hello, > > Recent -CURRENT(cvsup'ed on May-26-2004) kernel panics when the rc script > is trying to invoke /usr/sbin/usbd. It's 100% reproducible on my Thinkpad T40 > when the USB optical mouse is attached and the ACPI is disabled(option 2 in > the boot menu). > > I've tried to comment out the #ifdef DIAGNOSTIC statement around > sys/dev/usb/usb.c:752; however, it seems that the extra NULL check on ue > doesn't help in this case: The system still panics at the same place.... > With ACPI enabled(or the USB mouse detached) during booting, the usbd > would start successfully. > > Is there any T40 user running into the same problem on your -CURRENT? > The GENERIC kernel came from 5.2.1-RELEASE doesn't seem to have this > problem. > > For complete dmesg, please consult: > > http://www.mmlab.cse.yzu.edu.tw/~avatar/dmesg-noacpi.txt > http://www.mmlab.cse.yzu.edu.tw/~avatar/dmesg-acpi.txt > > ------------------------ backtrace --------------------------- > GNU gdb 5.2.1 (FreeBSD) > Copyright 2002 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-undermydesk-freebsd"... > panic: from debugger > panic messages: > --- > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc074af0d > stack pointer = 0x10:0xcdce59fc > frame pointer = 0x10:0xcdce5a08 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 403 (usbd) > kernel: type 12 trap, code=0 > panic: from debugger > at line 453 in file ../../../ddb/db_command.c > Stack backtrace: > > > Fatal trap 3: breakpoint instruction fault while in kernel mode > instruction pointer = 0x8:0xc05a9f9d > stack pointer = 0x10:0xcdce57dc > frame pointer = 0x10:0xcdce57e0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = IOPL = 0 > current process = 403 (usbd) > panic: from debugger > at line 453 in file ../../../ddb/db_command.cUptime: 15s > Dumping 255 MB > 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 > --- > Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/md/md.ko.debug...done. > Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/md/md.ko.debug > Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/linux/linux.ko.debug...done. > Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/linux/linux.ko.debug > Reading symbols from /boot/kernel/if_em.ko...done. > Loaded symbols for /boot/kernel/if_em.ko > Reading symbols from /boot/kernel/if_wi.ko...done. > Loaded symbols for /boot/kernel/if_wi.ko > Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/wlan/wlan.ko.debug...done. > Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/wlan/wlan.ko.debug > Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/rc4/rc4.ko.debug...done. > Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/rc4/rc4.ko.debug > Reading symbols from /boot/kernel/snd_ich.ko...done. > Loaded symbols for /boot/kernel/snd_ich.ko > Reading symbols from /boot/kernel/snd_pcm.ko...done. > Loaded symbols for /boot/kernel/snd_pcm.ko > Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/ums/ums.ko.debug...done. > Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/ums/ums.ko.debug > Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/---Type to continue, or q to quit--- > usb/usb.ko.debug...done. > Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/usb/usb.ko.debug > Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/umass/umass.ko.debug...done. > Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/umass/umass.ko.debug > Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/agp/agp.ko.debug...done. > Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/agp/agp.ko.debug > Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/random/random.ko.debug...done. > Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/random/random.ko.debug > Reading symbols from /boot/kernel/if_ath.ko...done. > Loaded symbols for /boot/kernel/if_ath.ko > Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/ath_hal/ath_hal.ko.debug...done. > Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/ath_hal/ath_hal.ko.debug > Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/smbfs/smbfs.ko.debug...done. > Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/smbfs/smbfs.ko.debug > Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/libmchain/libmchain.ko.debug...done. > Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/libmchain/libmchain.ko.debug > Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/libiconv/libiconv.ko.debug...done. > Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/libiconv/libiconv.ko.debug > Reading symbols from /boot/kernel/radeon.ko...done. > Loaded symbols for /boot/kernel/radeon.ko > Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/msdosfs/msdosfs.ko.debug...done. > Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/msdosfs/msdosfs.ko.debug > Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/msdosfs_iconv/msdosfs_iconv.ko.debug...done. > Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/msdosfs_iconv/msdosfs_iconv.ko.debug > Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug...done. > Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/linprocfs/linprocfs.ko.debug > Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/pseudofs/pseudofs.ko.debug...done. > Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/pseudofs/pseudofs.ko.debug > Reading symbols from /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/procfs/procfs.ko.debug...done. > Loaded symbols for /usr/src/sys/i386/compile/rtfm/modules/usr/src/sys/modules/procfs/procfs.ko.debug > #0 doadump () at ../../../kern/kern_shutdown.c:236 > 236 dumping++; > (kgdb) where > #0 doadump () at ../../../kern/kern_shutdown.c:236 > #1 0xc04c88e7 in boot (howto=260) at ../../../kern/kern_shutdown.c:370 > #2 0xc04c8bf9 in __panic () at ../../../kern/kern_shutdown.c:548 > #3 0xc0450bdb in db_panic () at ../../../ddb/db_command.c:453 > #4 0xc0450b68 in db_command (last_cmdp=0xc061fec0, cmd_table=0xc05fa760, > aux_cmd_tablep=0xc05f4db4, aux_cmd_tablep_end=0xc05f4db8) > at ../../../ddb/db_command.c:348 > #5 0xc0450c48 in db_command_loop () at ../../../ddb/db_command.c:475 > #6 0xc04533e5 in db_trap (type=12, code=0) at ../../../ddb/db_trap.c:73 > #7 0xc05a9d2d in kdb_trap (type=12, code=0, regs=0xcdce59bc) > at ../../../i386/i386/db_interface.c:159 > #8 0xc05b8123 in trap_fatal (frame=0xcdce59bc, eva=0) > at ../../../i386/i386/trap.c:810 > #9 0xc05b7e8f in trap_pfault (frame=0xcdce59bc, usermode=0, eva=0) > at ../../../i386/i386/trap.c:733 > #10 0xc05b7ac9 in trap (frame= > {tf_fs = 24, tf_es = -842137584, tf_ds = -1067909104, tf_edi = -842114540, tf_esi = 0, tf_ebp = -842114552, tf_isp = -842114584, tf_ebx = 0, tf_edx = 19, tf_ecx = 96, tf_eax = -842114540, tf_trapno = 12, tf_err = 0, tf_eip = -1066094835, tf_cs = 8, tf_eflags = 66050, tf_esp = 0, tf_ss = 983056}) > at ../../../i386/i386/trap.c:420 > #11 0xc074af0d in usb_get_next_event (ue=0xcdce5a14) > at /usr/src/sys/dev/usb/usb.c:752 > #12 0xc074ab24 in usbread (dev=0xc062632c, uio=0xcdce5c88, flag=983056) > at /usr/src/sys/dev/usb/usb.c:510 > #13 0xc0490e90 in spec_read (ap=0xcdce5c18) > at ../../../fs/specfs/spec_vnops.c:273 > #14 0xc04909d7 in spec_vnoperate (ap=0x0) > at ../../../fs/specfs/spec_vnops.c:118 > #15 0xc052250d in vn_read (fp=0xc2c7d088, uio=0xcdce5c88, > active_cred=0xc14f3e00, flags=0, td=0xc2afd930) at vnode_if.h:398 > #16 0xc04eac8f in dofileread (td=0xc2afd930, fp=0xc2c7d088, fd=7, > buf=0xbfbfeb60, nbyte=0, offset=0, flags=0) at ../../../sys/file.h:233 > #17 0xc04eab83 in read (td=0xc2afd930, uap=0xcdce5d14) > at ../../../kern/sys_generic.c:107 > #18 0xc05b842b in syscall (frame= > {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077940696, tf_esi = -1077941416, tf_ebp = -1077941016, tf_isp = -842113676, tf_ebx = 7, tf_edx = 20, tf_ecx = -1077941584, tf_eax = 3, tf_trapno = 12, tf_err = 2, tf_eip = 671899255, tf_cs = 31, tf_eflags = 658, tf_esp = -1077941444, tf_ss = 47}) > at ../../../i386/i386/trap.c:1004 > #19 0x280c5e77 in ?? () > ---Can't read userspace from dump, or kernel process--- > > (kgdb) set print pretty > (kgdb) f 11 > #11 0xc074af0d in usb_get_next_event (ue=0xcdce5a14) > at /usr/src/sys/dev/usb/usb.c:752 > 752 *ue = ueq->ue; > (kgdb) print ueq > $1 = (struct usb_event_q *) 0x0 > (kgdb) print ue > $2 = (struct usb_event *) 0xcdce5a14 > (kgdb) > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > !DSPAM:40c4258d639762113816006! > > From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 15:33:42 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A9E516A4CE for ; Mon, 7 Jun 2004 15:33:42 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0713E43D5A for ; Mon, 7 Jun 2004 15:33:42 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from freebsd.org (junior-wifi.samsco.home [192.168.0.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i57FfDEn048686; Mon, 7 Jun 2004 09:41:13 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <40C48AB3.50705@freebsd.org> Date: Mon, 07 Jun 2004 09:33:07 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Rabson References: <200406071011.01370.dfr@nlsystems.com> In-Reply-To: <200406071011.01370.dfr@nlsystems.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-current@freebsd.org Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 15:33:42 -0000 Doug Rabson wrote: > On Sunday 06 June 2004 20:55, Daniel Eischen wrote: > >>On Sun, 6 Jun 2004, Scott Long wrote: >> >>>All, >>> >>>We are about 4-6 weeks away from starting the 5.3 release cycle. >>>As it stands, KSE still only works reliably on i386. There are >>>reports of significant instability on amd64, and it doesn't work at >>>all on alpha and sparc64. I'm willing to drop the alpha >>>requirement and maybe even the sparc64 requirement, but there >>>absolutely will not be a 5.3 until amd64 is solid. Please contact >>>myself, Dan Eischen, and David Xu if you are interested in helping >>>out. >> >>amd64 looks to be a problem in readline which doesn't seem >>to redispatch signal handlers with SA_SIGINFO arguments. >> >>David also has patches for debugging support at: >> >> http://people.freebsd.org/~davidxu/kse/dbg/ >> >>Doug Rabson also has basic TLS support working in perforce. >>It'd be nice to get TLS and debugging in before 5.3-release. > > > I'll probably try to commit some kind of TLS support into current in the > next couple of weeks. Its likely to only support i386 and will be > stubbed out for other platforms. Right now, I'm just waiting for some > kind of feedback from an nvidia developer whos testing it. I'm happy to see that it's gotten this far along, but it needs to be available on all tier-1 platforms when it goes in. For the sake of argument, we'll call that amd64 and possibly sparc64. My understanding is that amd64 should be very similar to i386, yes? Please let me know what kind of help you need with getting this done. Scott From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 15:48:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A0C1916A4CE; Mon, 7 Jun 2004 15:48:33 +0000 (GMT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id A47FD43D39; Mon, 7 Jun 2004 15:48:32 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.9/8.12.9) with ESMTP id i57FmQkM064791; Mon, 7 Jun 2004 16:48:26 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) i57FmPON082812; Mon, 7 Jun 2004 16:48:26 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Scott Long In-Reply-To: <40C48AB3.50705@freebsd.org> References: <200406071011.01370.dfr@nlsystems.com> <40C48AB3.50705@freebsd.org> Content-Type: text/plain Message-Id: <1086623305.10911.30.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 07 Jun 2004 16:48:25 +0100 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: freebsd-current@freebsd.org Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 15:48:33 -0000 On Mon, 2004-06-07 at 16:33, Scott Long wrote: > Doug Rabson wrote: > > On Sunday 06 June 2004 20:55, Daniel Eischen wrote: > > > >>On Sun, 6 Jun 2004, Scott Long wrote: > >> > >>>All, > >>> > >>>We are about 4-6 weeks away from starting the 5.3 release cycle. > >>>As it stands, KSE still only works reliably on i386. There are > >>>reports of significant instability on amd64, and it doesn't work at > >>>all on alpha and sparc64. I'm willing to drop the alpha > >>>requirement and maybe even the sparc64 requirement, but there > >>>absolutely will not be a 5.3 until amd64 is solid. Please contact > >>>myself, Dan Eischen, and David Xu if you are interested in helping > >>>out. > >> > >>amd64 looks to be a problem in readline which doesn't seem > >>to redispatch signal handlers with SA_SIGINFO arguments. > >> > >>David also has patches for debugging support at: > >> > >> http://people.freebsd.org/~davidxu/kse/dbg/ > >> > >>Doug Rabson also has basic TLS support working in perforce. > >>It'd be nice to get TLS and debugging in before 5.3-release. > > > > > > I'll probably try to commit some kind of TLS support into current in the > > next couple of weeks. Its likely to only support i386 and will be > > stubbed out for other platforms. Right now, I'm just waiting for some > > kind of feedback from an nvidia developer whos testing it. > > I'm happy to see that it's gotten this far along, but it needs to be > available on all tier-1 platforms when it goes in. For the sake of > argument, we'll call that amd64 and possibly sparc64. My understanding > is that amd64 should be very similar to i386, yes? Please let me know > what kind of help you need with getting this done. Well I'm not so sure that it does need to be supported on all tier 1 platforms. If a given tier 1 platform has a TLS-capable toolchain then sure - its only about a hundred lines of code to add support once the toolchain support is there. Currently our toolchain only supports TLS on i386 and ia64. I think that a binutils upgrade might fix amd64 but the rest need a new compiler. Right now, there is only one real application which absolutely needs TLS and that is the NVidia OpenGL driver on i386. It looks like the DRM people will start using TLS at some point but they aren't using it now. If we reach 5.3 without any new toolchain support for TLS, I think we should ship with TLS support on only i386 and ia64. It seems silly to not support TLS on i386 (which people are begging for) because we can't do it on sparc64 (which no-one needs). From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 15:56:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D2DB16A4CE for ; Mon, 7 Jun 2004 15:56:48 +0000 (GMT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F70643D48 for ; Mon, 7 Jun 2004 15:56:48 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from dhcp50.pn.xcllnt.net (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.12.11/8.12.11) with ESMTP id i57FujQu009565; Mon, 7 Jun 2004 08:56:46 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp50.pn.xcllnt.net (localhost [127.0.0.1]) i57FujYx066997; Mon, 7 Jun 2004 08:56:45 -0700 (PDT) (envelope-from marcel@dhcp50.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp50.pn.xcllnt.net (8.12.11/8.12.11/Submit) id i57FujWi066996; Mon, 7 Jun 2004 08:56:45 -0700 (PDT) (envelope-from marcel) Date: Mon, 7 Jun 2004 08:56:45 -0700 From: Marcel Moolenaar To: Doug Rabson Message-ID: <20040607155645.GB66937@dhcp50.pn.xcllnt.net> References: <40C37E1C.4000402@freebsd.org> <20040606204817.GB96607@dhcp50.pn.xcllnt.net> <200406071014.21707.dfr@nlsystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406071014.21707.dfr@nlsystems.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 15:56:48 -0000 On Mon, Jun 07, 2004 at 10:14:21AM +0100, Doug Rabson wrote: > On Sunday 06 June 2004 21:48, Marcel Moolenaar wrote: > > On Sun, Jun 06, 2004 at 02:27:08PM -0600, Scott Long wrote: > > > >Doug Rabson also has basic TLS support working in perforce. > > > > > > What platforms? My understanding was that new binutils and gcc was > > > needed for sparc64 at a minimum. > > > > Yes. It's i386 only and not even close to being complete. In fact, > > there has been discussions that the thread pointer on i386 needs to > > change. Whether that's the case or not, it's likely that TLS will > > complicate matters way too much to for it to ever work in 5.3. > > Actually its a bit better than that. It works for most use cases right > now on i386 but would get confused on dlclose. I'll fix that before I > move it into current. Does it work on static bound executables? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 16:00:42 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CA5416A4D1 for ; Mon, 7 Jun 2004 16:00:42 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2E1943D41 for ; Mon, 7 Jun 2004 16:00:41 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from freebsd.org (junior-wifi.samsco.home [192.168.0.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i57G8DSD048841; Mon, 7 Jun 2004 10:08:13 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <40C49107.8010800@freebsd.org> Date: Mon, 07 Jun 2004 10:00:07 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Rabson References: <200406071011.01370.dfr@nlsystems.com> <40C48AB3.50705@freebsd.org> <1086623305.10911.30.camel@builder02.qubesoft.com> In-Reply-To: <1086623305.10911.30.camel@builder02.qubesoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-current@freebsd.org Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 16:00:42 -0000 Doug Rabson wrote: > On Mon, 2004-06-07 at 16:33, Scott Long wrote: > >>Doug Rabson wrote: >> >>>On Sunday 06 June 2004 20:55, Daniel Eischen wrote: >>> >>> >>>>On Sun, 6 Jun 2004, Scott Long wrote: >>>> >>>> >>>>>All, >>>>> >>>>>We are about 4-6 weeks away from starting the 5.3 release cycle. >>>>>As it stands, KSE still only works reliably on i386. There are >>>>>reports of significant instability on amd64, and it doesn't work at >>>>>all on alpha and sparc64. I'm willing to drop the alpha >>>>>requirement and maybe even the sparc64 requirement, but there >>>>>absolutely will not be a 5.3 until amd64 is solid. Please contact >>>>>myself, Dan Eischen, and David Xu if you are interested in helping >>>>>out. >>>> >>>>amd64 looks to be a problem in readline which doesn't seem >>>>to redispatch signal handlers with SA_SIGINFO arguments. >>>> >>>>David also has patches for debugging support at: >>>> >>>> http://people.freebsd.org/~davidxu/kse/dbg/ >>>> >>>>Doug Rabson also has basic TLS support working in perforce. >>>>It'd be nice to get TLS and debugging in before 5.3-release. >>> >>> >>>I'll probably try to commit some kind of TLS support into current in the >>>next couple of weeks. Its likely to only support i386 and will be >>>stubbed out for other platforms. Right now, I'm just waiting for some >>>kind of feedback from an nvidia developer whos testing it. >> >>I'm happy to see that it's gotten this far along, but it needs to be >>available on all tier-1 platforms when it goes in. For the sake of >>argument, we'll call that amd64 and possibly sparc64. My understanding >>is that amd64 should be very similar to i386, yes? Please let me know >>what kind of help you need with getting this done. > > > Well I'm not so sure that it does need to be supported on all tier 1 > platforms. If a given tier 1 platform has a TLS-capable toolchain then > sure - its only about a hundred lines of code to add support once the > toolchain support is there. Currently our toolchain only supports TLS on > i386 and ia64. I think that a binutils upgrade might fix amd64 but the > rest need a new compiler. > > Right now, there is only one real application which absolutely needs TLS > and that is the NVidia OpenGL driver on i386. It looks like the DRM > people will start using TLS at some point but they aren't using it now. > If we reach 5.3 without any new toolchain support for TLS, I think we > should ship with TLS support on only i386 and ia64. It seems silly to > not support TLS on i386 (which people are begging for) because we can't > do it on sparc64 (which no-one needs). > > I agree completely. I forgot to stress in the previous mail that there is a strong push at the moment to get in gcc34 and binutils 2.15(?), which should make TLS infrastructure available to amd64 and sparc64. I don't think that sparc64 should be a hard requirement, but it should at least be looked at and documented so that someone else can come along and do the work. Scott From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 16:22:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A39516A4CE for ; Mon, 7 Jun 2004 16:22:38 +0000 (GMT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id A135743D5C for ; Mon, 7 Jun 2004 16:22:37 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.9/8.12.9) with ESMTP id i57GMakM065857; Mon, 7 Jun 2004 17:22:36 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) i57GMZON083283; Mon, 7 Jun 2004 17:22:35 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Marcel Moolenaar In-Reply-To: <20040607155645.GB66937@dhcp50.pn.xcllnt.net> References: <40C37E1C.4000402@freebsd.org> <20040606204817.GB96607@dhcp50.pn.xcllnt.net> <200406071014.21707.dfr@nlsystems.com> <20040607155645.GB66937@dhcp50.pn.xcllnt.net> Content-Type: text/plain Message-Id: <1086625355.10911.39.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 07 Jun 2004 17:22:35 +0100 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.65', clamav-milter version '0.60p' cc: freebsd-current@freebsd.org Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 16:22:38 -0000 On Mon, 2004-06-07 at 16:56, Marcel Moolenaar wrote: > On Mon, Jun 07, 2004 at 10:14:21AM +0100, Doug Rabson wrote: > > On Sunday 06 June 2004 21:48, Marcel Moolenaar wrote: > > > On Sun, Jun 06, 2004 at 02:27:08PM -0600, Scott Long wrote: > > > > >Doug Rabson also has basic TLS support working in perforce. > > > > > > > > What platforms? My understanding was that new binutils and gcc was > > > > needed for sparc64 at a minimum. > > > > > > Yes. It's i386 only and not even close to being complete. In fact, > > > there has been discussions that the thread pointer on i386 needs to > > > change. Whether that's the case or not, it's likely that TLS will > > > complicate matters way too much to for it to ever work in 5.3. > > > > Actually its a bit better than that. It works for most use cases right > > now on i386 but would get confused on dlclose. I'll fix that before I > > move it into current. > > Does it work on static bound executables? Which one is static bound? It should work for General Dynamic, Local Dynamic, Initial Exec and Local Exec models as described in Ulrich Drepper's paper, "ELF Handling For Thread-Local Storage". From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 16:26:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7517716A4CE; Mon, 7 Jun 2004 16:26:19 +0000 (GMT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 576C443D66; Mon, 7 Jun 2004 16:26:19 +0000 (GMT) (envelope-from peter@evilpete.dyndns.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id CFA4F2A7EA; Mon, 7 Jun 2004 09:26:18 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 0BF0EE29E; Mon, 7 Jun 2004 09:26:17 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.12.11/8.12.11) with ESMTP id i57GQHVY022152; Mon, 7 Jun 2004 09:26:17 -0700 (PDT) (envelope-from peter@overcee.wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.12.11/8.12.11/Submit) id i57GQBKJ022151; Mon, 7 Jun 2004 09:26:11 -0700 (PDT) (envelope-from peter) From: Peter Wemm To: Thomas Moestl Date: Mon, 7 Jun 2004 09:26:11 -0700 User-Agent: KMail/1.6.1 References: <40C36D31.4010003@freebsd.org> <20040606215921.GA96205@xor.obsecurity.org> <20040607143332.GA1311@timesink.dyndns.org> In-Reply-To: <20040607143332.GA1311@timesink.dyndns.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406070926.11289.peter@wemm.org> cc: hackers@freebsd.org cc: current@freebsd.org cc: peter@freebsd.org cc: Kris Kennaway Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 16:26:19 -0000 On Monday 07 June 2004 07:33 am, Thomas Moestl wrote: > On Sun, 2004/06/06 at 14:59:21 -0700, Kris Kennaway wrote: > > On Sun, Jun 06, 2004 at 03:49:13PM -0600, Scott Long wrote: > > > amd64 is approaching critical mass for tier-1. There are a > > > number of developers that own amd64 hardware now, and a number of > > > users who are asking about it on the mailing lists. Peter is > > > finishing up the last blocking item for it (kld's) not including > > > the observed KSE problems. It's very close and I _will_ hold up > > > the release for it to get done. amd64 is the future of commodity > > > computing and we aren't going to ignore it for 5-STABLE. > > > > amd64 has a bug with swapping - when something begins to access > > swap, the entire system becomes almost entirely unresponsive (e.g. > > no mouse response for up to 10 seconds) until it stops. Peter has > > some ideas about it, but it's a serious enough bug that it forced > > me to stop using amd64 as my desktop machine (hello, kde!). > > Hmmm, I have encountered a similar problem on sparc64 once; the > reason was that vm_pageout_map_deactivate_pages() calls > pmap_remove() for the range from the start to the end of the > process's vm_map when a process is swapped out. Start and end > are VM_MIN_ADDRESS and VM_MAXUSER_ADDRESS respectively, and on > 64-bit architectures, that range is very large (128TB on ia64 > if I'm not mistaken), so the iteration in pmap_remove() must > be carefully designed to make as large steps as possible to > avoid long run times (or to not iterate over the range at all > if it becomes too large, which we did on sparc64). > > It seems that the amd64 version of pmap_remove() will essentially > always iterate in 2MB (level 2 page table) steps, regardless of > whether there is mapping for the respective level 2 table in the > table levels above; that means that in the previously mentioned case, > the outer loop will usually run for about 67 million iterations (the > resident count guard may not be of much use here if a stack page is > left at the very end of the address space). Since there are a few > memory accesses needed in each iterations, that may already be the > cause of such a delay. You know, this sounds spot-on! Thanks for the tip! -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 16:28:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 3CED016A4D0; Mon, 7 Jun 2004 16:28:54 +0000 (GMT) In-Reply-To: <20040607135004.24050449@Magellan.Leidinger.net> from Alexander Leidinger at "Jun 7, 2004 01:50:04 pm" To: Alexander@Leidinger.net (Alexander Leidinger) Date: Mon, 7 Jun 2004 16:28:54 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20040607162854.3CED016A4D0@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) cc: sobomax@portaone.com cc: freebsd-current@freebsd.org Subject: Re: Project Evil & ACX100-based cards (D-Link DWL-520+) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 16:28:54 -0000 > On Mon, 07 Jun 2004 04:59:38 +0300 > Maxim Sobolev wrote: > > > Hi Bill, > > > > I'm trying to make my D-Link DWL-520+ card working with if_ndis, but no > > luck yet. The card is correctly detected, driver attaches to it. If I > > configure it in the adhoc mode it is seen from the nearby machine and > > connected to, but traffic doesn't flow. :-( > > > > Any ideas? Please let me know if more information is necessary. > > Have you tried the FreeBSD native KLD (wlan.kewl.org)? I've installed it > on my brother's system and on a system of a friend. Both don't complain, > so I assume it works for them (you may perhaps need to do a "ifconfig > acx0 down; sleep 5; ifconfig acx0 up" after booting, but then it should > negotiate with an AP). I can probably get this card to work, but as I told Maxim directly, I refuse to do debugging via e-mail. (I'm sorry, but it's just too goddamn frustrating: what could take me an hour or two to fix on my own can take weeks when I have to give a crash course in network debugging to someone half a planet away.) What I really need is a sample NIC with the Texas Instruments chip on it. It can be any form factor (PCI, miniPCI or cardbus). Anyone want to step forward and help Project Evil Labs take yet another stride towards world domination? Anyone? Anyone? Beuler? -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose ============================================================================= From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 16:36:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 1957916A4D0; Mon, 7 Jun 2004 16:36:16 +0000 (GMT) In-Reply-To: <20040607094508.GA740@hsc.fr> from Yann Berthier at "Jun 7, 2004 11:45:08 am" To: yb@sainte-barbe.org (Yann Berthier) Date: Mon, 7 Jun 2004 16:36:16 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20040607163616.1957916A4D0@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) cc: freebsd-current@freebsd.org Subject: Re: 802.11g/GPRS broadcom cardbus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 16:36:16 -0000 > > Hello, > > [Nicolas and I are coworkers] > > On Fri, 04 Jun 2004, Bill Paul wrote: > > > Hm. In theory, I think it's possible to make the whole thing work. > > The only tricky part is that they've combined two functions on the > > same device. The 802.11g wireless function should work fine using > > the NDISulator and the supplied Windows driver (check the CD that > > came with it: there's probably a bcmwl5.sys and bcmwl5.inf file on > > it somewhere). But the probe routine in if_ndis_pci.c only selects > > devices based on the PCI vendor and device ID. If the two functions > > appear to have unique device IDs, then you should be ok. If not, the > > probe routine might try to claim both the wireless function and > > the serial function. > > > > If it turns out both functions have the same vendor/device ID, this > > shouldn't be too hard to deal with: the probe routine can additionally > > check the PCI device type code and reject anything that isn't 'network' > > or 'wireless.' > > We have not tested the ndis part yet. I hope you will soon. :) > > As for the serial interface, assuming it behaves like a normal > > COM port, I expect you can get it to work by adding the PCI vendor/device > > ID to the PCI attachment of the sio driver. Then it will get attached > > as an sio device. > > Indeed it works, all it takes is to add > { 0x432214e4, "Broadcom 802.11g/GPRS CardBus (Serial)", 0x10 }, > > In /usr/src/sys/dev/sio/sio_pci.c > > Do we need to submit a PR ? No, I have just added the entry to sio_pci.c in -current. Can you run "pciconf -lv" with the card inserted and post the results? I'm curious to see what it looks like. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose ============================================================================= From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 16:54:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE2CD16A4CE; Mon, 7 Jun 2004 16:54:16 +0000 (GMT) Received: from dd2626.kasserver.com (dd2626.kasserver.com [81.209.184.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DB5143D53; Mon, 7 Jun 2004 16:54:16 +0000 (GMT) (envelope-from outi@bytephobia.de) Received: from duality.bytephobia.de (pD958E31C.dip.t-dialin.net [217.88.227.28]) by dd2626.kasserver.com (Postfix) with SMTP id 4827F1D354; Mon, 7 Jun 2004 18:53:57 +0200 (CEST) Date: Mon, 7 Jun 2004 18:55:54 +0200 From: Patrick Hurrelmann To: freebsd-current@freebsd.org, freebsd-hardware@freebsd.org Message-Id: <20040607185554.1e0ab5ee@duality.bytephobia.de> Organization: private X-Mailer: Sylpheed version 0.9.11claws (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Experiences with 3Ware 9500-Series and 5.2 CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: outi@bytephobia.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 16:54:17 -0000 Hi there, i just sold my Promsie FastTrak S150 SX4 due to missing Raid 5 support of ataraid. I really wanted to get it running with FreeBSD 5.2 CURRENT, but the wait was too long :( I thank Soeren Schmidt for his work and patience. Now I know want to buy a 3Ware 9500S-4LP. My desired configuration will be a Dual-Athlon on a Asus A7M266-D with 4x 120gb, 7200 rpm, 8mb cache (western digital). - Does anybody use such a controller and in what configuration? - How stable is the current twa? - Do the CLI and 3DM Tools work? Thanks! Patrick From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 17:07:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 919DE16A4CE for ; Mon, 7 Jun 2004 17:07:46 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27E9143D53 for ; Mon, 7 Jun 2004 17:07:46 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i57H6nwT084379; Mon, 7 Jun 2004 13:06:50 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i57H6nND084376; Mon, 7 Jun 2004 13:06:49 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 7 Jun 2004 13:06:49 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: "David A. Benfell" In-Reply-To: <20040607150956.GA7084@parts-unknown.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: file descripter leak in current with Qmail? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 17:07:46 -0000 On Mon, 7 Jun 2004, David A. Benfell wrote: > I'm running current, with qmail and spamassassin. > > Having finally caught on to the new kernel build process (ahem), I'm now > having problems with the qmail UIDs (mostly for qmaild but occasionally > qmails) exceeding the openfiles limit. > > When I used sysctl to interrogate kern.openfiles, it said 1836. I have > not altered the default maximum. When I shut down qmail, it promptly > dropped to something like 180. When I restarted qmail, it went back up > to something like 194 but system responsiveness dropped through the > floor. In basically the time it's taken me to write this much, > kern.openfiles has climbed to something like 261. > > So I guess I have a couple of idiot questions to ask here: > > Is the kern.openfiles limit something (relatively) new? I was running > current before on this box but hadn't gotten through a build because I > hadn't caught on to the new kernel build process since before 5.2 was > released. Qmail was not a problem before. > > Is the correct response to this problem to raise the limit? If so, I > presume this would be done in rc.conf; what would be the corresponding > variable in rc.conf? > > In the time I've composed this far, system responsiveness seems to have > returned to normal and kern.openfiles has dropped to something like 221. > So I assume the responsiveness issue had to do with qmail trying to > catch up. > > I'm in between quarters in school right now, so I have a little time to > play with this if needed. Just to make sure we're clear on terminology, kern.openfiles is the number of open file descriptors in the system. Several resource limits impact the ability to allocate new file descriptors: - kern.maxfiles, the global maximum number of open file descriptors permitted. - Resource limits, which are per-process, and can be viewed for the current process using the "limits" command (or some variation depending on shell). - Real system memory constraints, which can result in allocation failures, etc, if exceeded. All of these limits have existed for quite a while, but typically aren't run into since the default limits typically are pretty high for normal application use. If necessary, you can raise the limit by tweaking the global maximum using kern.maxfiles (either as a tunable or sysctl), and then as needed adjusting the resource limits that qmail runs with. However, I think the more serious element here is the reason why you reach the limit: this happens "naturally" under some workloads simply because of large numbers of open files and network connections. However, in some workloads, it's a symptom of a system or application bug, such as a resource leak. Because the resources were returned when qmail was killed, that largely eliminates the possibility of a kernel resource leak (not entirely, but largely), as most kernel resource leaks involving file descriptors have the symptom that even after the process exits, the resources aren't release (i.e., a reference counting bug or race). This suggests a user space issue -- that doesn't eliminate a system bug, as it could be a bug in a library that manages descriptors, but it also suggests the possibility of an application bug, or at least, a poor application interaction with a system bug. Occasionally, we've seen bugs in the threading libraries that result in leaked descriptors, but my recollection is that qmail doesn't use threads. So that suggests either a support library (perhaps crypto or the like), or qmail itself. Or that you just hit an extremely high load. :-) In terms of debugging it: your first task it to identify if there's one process that's holding all the fd's, or if it is distributed over many proceses. After that, you want to track down what kind of fd is being left open, which may help you track down why it's left open... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 17:17:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0ED416A4CE for ; Mon, 7 Jun 2004 17:17:00 +0000 (GMT) Received: from grummit.biaix.org (86.Red-213-97-212.pooles.rima-tde.net [213.97.212.86]) by mx1.FreeBSD.org (Postfix) with SMTP id 45B0E43D1D for ; Mon, 7 Jun 2004 17:16:59 +0000 (GMT) (envelope-from lists-freebsd-current@biaix.org) Received: (qmail 86960 invoked by uid 1000); 7 Jun 2004 17:16:12 -0000 Date: Mon, 7 Jun 2004 19:16:12 +0200 From: Joan Picanyol To: "'freebsd-current@freebsd.org'" Message-ID: <20040607171612.GA86565@grummit.biaix.org> Mail-Followup-To: "'freebsd-current@freebsd.org'" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Subject: Re: Sysinstall & labels/fdisk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 17:17:00 -0000 * Alex Hoff [20040607 16:47]: > I have run in to an odd problem that on a freebsd 5.2 current system after > running fdisk and disklabel the initial time on install, i am never allowed > to do it again. > > What I have tried on many different systems, is to run sysinstall, and > either run fdisk or label. After making a change and trying to write the > changes, it will fail. Even if you dont make a change, and just try to write > the current settings to the disk, it will fail. The following error comes up > "ERROR: Unable to write data to disk ad0" (if also tried different types of > disk devices - da/aacd). Ktrace shows the error as "errno 1 Operation not > permitted" GEOM won't let you touch MBR/slices/partitions on used devices. For it to allow footshooting you should set kern.geom.debugflags=16 qvb -- pica From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 17:21:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6284516A4CE; Mon, 7 Jun 2004 17:21:49 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8AB9743D5A; Mon, 7 Jun 2004 17:21:48 +0000 (GMT) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i57HLYvw022790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jun 2004 21:21:34 +0400 (MSD) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i57HLXTA022789; Mon, 7 Jun 2004 21:21:33 +0400 (MSD) Date: Mon, 7 Jun 2004 21:21:32 +0400 From: Gleb Smirnoff To: Peter Ulrich Kruppa , Bosko Milekic Message-ID: <20040607172132.GA22717@cell.sick.ru> References: <20040607160206.G854@pukruppa.net> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040607160206.G854@pukruppa.net> User-Agent: Mutt/1.5.6i cc: net@FreeBSD.org cc: Julian Elischer cc: FreeBSD current users Subject: Re: HEADSUP! netgraph Metadata changing. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 17:21:49 -0000 On Mon, Jun 07, 2004 at 04:11:47PM +0200, Peter Ulrich Kruppa wrote: P> Sorry for topposting, but I don't know if this has got something P> to do with your changes: P> I am trying to rebuild my -CURRENT system now for some days and P> keep receiving panic messages from ng_ppoe P> like this P> P> panic NG_MKMESSAGE() with how=M_DONTWAIT(1) P> at line 913 in file /usr/src/sys/netgraph/ng_pppoe.c P> ... P> P> netgraph/pppoe is used by ppp to connect to my ISP . P> My last working kernel was built on May 31 . P> P> Thanks, if you know how to repair this. Seems like you problem is caused (indirectly) by mbuma import. See http://lists.freebsd.org/pipermail/freebsd-current/2004-June/028153.html Perhaps Bosko has more comments. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 17:24:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 8671A16A4CE; Mon, 7 Jun 2004 17:24:33 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.12.11/8.12.11) with ESMTP id i57HOWqR020208; Mon, 7 Jun 2004 13:24:32 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.12.11/8.12.11/Submit) id i57HOWrc020207; Mon, 7 Jun 2004 13:24:32 -0400 (EDT) (envelope-from green) Date: Mon, 7 Jun 2004 13:24:31 -0400 From: Brian Feldman To: Stefan Ehmann Message-ID: <20040607172431.GA19790@green.homeunix.org> References: <1086511629.1509.13.camel@taxman> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1086511629.1509.13.camel@taxman> User-Agent: Mutt/1.5.6i cc: current@freebsd.org Subject: Re: esd leaking file descriptors X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 17:24:33 -0000 On Sun, Jun 06, 2004 at 10:47:09AM +0200, Stefan Ehmann wrote: > When i run mpg321 -o esd foo.mp3 (or any other player that uses esd as > output) lsof shows an increasing number of open files. It increases at a > rate of about 50 files per second. System will run out of file > descriptor eventually. > > I run CURRENT from yesterday. > esound-0.2.34 A sound library for enlightenment package > > The same version of esound runs fine on another pc running an older > current. So this seems to be a problem of current rather than esd. Check if esd is encountering exceptional conditions with the ktrace facility. You will wnat to run esd with ktrace(1) and then use kdump(1) to view the log of system calls. The other PC probably also doesn't have the same hardware, so it's not so easy to see if it's just a bug in -CURRENT. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 17:46:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55ABF16A4CE for ; Mon, 7 Jun 2004 17:46:48 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40BE943D45 for ; Mon, 7 Jun 2004 17:46:48 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 336FF72DF2; Mon, 7 Jun 2004 10:46:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 2E4DD72DB5; Mon, 7 Jun 2004 10:46:48 -0700 (PDT) Date: Mon, 7 Jun 2004 10:46:48 -0700 (PDT) From: Doug White To: Joan Picanyol In-Reply-To: <20040607171612.GA86565@grummit.biaix.org> Message-ID: <20040607104535.T19466@carver.gumbysoft.com> References: <20040607171612.GA86565@grummit.biaix.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "'freebsd-current@freebsd.org'" Subject: Re: Sysinstall & labels/fdisk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 17:46:48 -0000 On Mon, 7 Jun 2004, Joan Picanyol wrote: > * Alex Hoff [20040607 16:47]: > > I have run in to an odd problem that on a freebsd 5.2 current system after > > running fdisk and disklabel the initial time on install, i am never allowed > > to do it again. > > > > What I have tried on many different systems, is to run sysinstall, and > > either run fdisk or label. After making a change and trying to write the > > changes, it will fail. Even if you dont make a change, and just try to write > > the current settings to the disk, it will fail. The following error comes up > > "ERROR: Unable to write data to disk ad0" (if also tried different types of > > disk devices - da/aacd). Ktrace shows the error as "errno 1 Operation not > > permitted" > > GEOM won't let you touch MBR/slices/partitions on used devices. For it > to allow footshooting you should set kern.geom.debugflags=16 Be REALLY careful with this! I have a documented case of te device entries getting confused and blowing away the wrong partition. I STRONGLY recommend AGAINST using this flag. Make backups, we are not responsible, etc. etc. etc. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 17:49:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98C4B16A4CE for ; Mon, 7 Jun 2004 17:49:34 +0000 (GMT) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E77843D54 for ; Mon, 7 Jun 2004 17:49:34 +0000 (GMT) (envelope-from alc@cs.rice.edu) Received: from localhost (calypso.cs.rice.edu [128.42.1.127]) by cs.rice.edu (Postfix) with ESMTP id B8F604AA85; Mon, 7 Jun 2004 12:49:33 -0500 (CDT) Received: from cs.rice.edu ([128.42.1.30]) by localhost (calypso.cs.rice.edu [128.42.1.127]) (amavisd-new, port 10024) with LMTP id 08248-01-56; Mon, 7 Jun 2004 12:49:33 -0500 (CDT) Received: by cs.rice.edu (Postfix, from userid 19572) id 599754AA50; Mon, 7 Jun 2004 12:49:33 -0500 (CDT) Date: Mon, 7 Jun 2004 12:49:33 -0500 From: Alan Cox To: Alexander Leidinger Message-ID: <20040607174933.GK24461@cs.rice.edu> References: <20040606142446.2900a97e@Magellan.Leidinger.net> <20040606201249.GH24461@cs.rice.edu> <20040607130430.0ebbbb8e@Magellan.Leidinger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040607130430.0ebbbb8e@Magellan.Leidinger.net> User-Agent: Mutt/1.4.2i X-Virus-Scanned: by amavis-20030616-p7 at cs.rice.edu cc: current@freebsd.org Subject: Re: comments in the page coloring options in /sys/conf/NOTES X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 17:49:34 -0000 On Mon, Jun 07, 2004 at 01:04:30PM +0200, Alexander Leidinger wrote: > On Sun, 6 Jun 2004 15:12:49 -0500 > Alan Cox wrote: > > > My recent commit fixed a "syntax" error in the comments, specifically, > > a reference to a missing macro. The comments are, however, still > > "semantically" broken: > > > > 1. Cache size alone does not correctly determine the number of colors, > > except for direct map caches. The correct formula is > > > > (cache size in bytes / page size in bytes) / degree of cache associativity > > > > Thus, the comments would lead one to configure his/her system with too > > many colors. (Relative to configuring a system with too few colors, > > this is not so bad.) > > vm_page.h contains: > ---snip--- > #if PQ_CACHESIZE >= 1024 > #define PQ_PRIME1 31 /* Prime number somewhat less than PQ_HASH_SIZE */ > #define PQ_PRIME2 23 /* Prime number somewhat less than PQ_HASH_SIZE */ > #define PQ_L2_SIZE 256 /* A number of colors opt for 1M cache */ > ---snip--- > > The three defines seem to be the tunables for the page coloring, but > neither of them seem to be near cache_size/page_size. So even for the > direct mapped case this doesn't seem to fit your explanation. Actually, it does. Divide 1MB (the cache size) by 4KB (the page size) and you get 256, the appropriate number of colors for a 1MB direct- mapped cache. Despite its name, PQ_L2_SIZE, is not the L2 cache size. As the comment suggests, it is the number of colors. > ... Is it as > easy as using appropriate values for those defines at boot time or is > there more work involved for auto-tuning version? At boot time. > Is there a way to determine the size of the L2 cache and the > associativity at run time in the kernel or are these properties which we > have to obtain from a table (which we have to write and maintain for > automatic tuning)? On modern amd64 and i386 CPUs, yes. I would be surprised if ia64 didn't provide the information. Run a "boot -v" and look carefully at the information. It describes the cache structure. > > 2. The references to L1 should be removed. They are historical > > leftovers. > > cut&paste: > ---snip--- > Index: sys/conf/NOTES > =================================================================== > RCS file: /big/FreeBSD-CVS/src/sys/conf/NOTES,v > retrieving revision 1.1227 > diff -u -r1.1227 NOTES > --- sys/conf/NOTES 1 Jun 2004 06:22:56 -0000 1.1227 > +++ sys/conf/NOTES 7 Jun 2004 10:07:16 -0000 > @@ -103,13 +103,13 @@ > > # Options for the VM subsystem > # L2 cache size (in KB) can be specified in PQ_CACHESIZE > -options PQ_CACHESIZE=512 # color for 512k/16k cache > +options PQ_CACHESIZE=512 # color for 512k cache > # Deprecated options supported for backwards compatibility > #options PQ_NOOPT # No coloring > -#options PQ_LARGECACHE # color for 512k/16k cache > -#options PQ_HUGECACHE # color for 1024k/16k cache > -#options PQ_MEDIUMCACHE # color for 256k/16k cache > -#options PQ_NORMALCACHE # color for 64k/16k cache > +#options PQ_LARGECACHE # color for 512k cache > +#options PQ_HUGECACHE # color for 1024k cache > +#options PQ_MEDIUMCACHE # color for 256k cache > +#options PQ_NORMALCACHE # color for 64k cache > > # This allows you to actually store this configuration file into > # the kernel binary itself, where it may be later read by saying: > Index: sys/vm/vm_pageq.c > =================================================================== > RCS file: /big/FreeBSD-CVS/src/sys/vm/vm_pageq.c,v > retrieving revision 1.13 > diff -u -r1.13 vm_pageq.c > --- sys/vm/vm_pageq.c 30 May 2004 00:42:38 -0000 1.13 > +++ sys/vm/vm_pageq.c 7 Jun 2004 10:38:31 -0000 > @@ -176,8 +176,8 @@ > * > * The page coloring optimization attempts to locate a page > * that does not overload other nearby pages in the object in > - * the cpu's L1 or L2 caches. We need this optimization because > - * cpu caches tend to be physical caches, while object spaces tend > + * the cpu's L2 cache. We need this optimization because cpu > + * caches tend to be physical caches, while object spaces tend > * to be virtual. > * > * This routine must be called at splvm(). > ---snip--- > > I think the comment with the reference to L1 in sys/vm/vm_zeroidle.c is > ok. Correct. (In fact, on newer generation CPUs, we use non-temporal, i.e., non-cached, stores to zero pages in the idle loop. So, there is no inteference with the cache.) > If this is ok, do I have your approval to commit it? Yes, please commit it. Regards, Alan From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 17:51:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A81E16A4D0; Mon, 7 Jun 2004 17:51:03 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C02743D4C; Mon, 7 Jun 2004 17:51:03 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id DAC2272DF2; Mon, 7 Jun 2004 10:51:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id D877872DB5; Mon, 7 Jun 2004 10:51:00 -0700 (PDT) Date: Mon, 7 Jun 2004 10:51:00 -0700 (PDT) From: Doug White To: Robert Watson In-Reply-To: Message-ID: <20040607104903.U19466@carver.gumbysoft.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org cc: "David A. Benfell" Subject: Re: file descripter leak in current with Qmail? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 17:51:03 -0000 On Mon, 7 Jun 2004, Robert Watson wrote: > - kern.maxfiles, the global maximum number of open file descriptors > permitted. > > - Resource limits, which are per-process, and can be viewed for the > current process using the "limits" command (or some variation depending > on shell). Also kern.maxfilesperproc, which is the hard limit for the per-process limits (which defaults to =kern.maxfiles). -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 17:58:27 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A58F816A4D0; Mon, 7 Jun 2004 17:58:27 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94A2743D4C; Mon, 7 Jun 2004 17:58:27 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 7E00072DF2; Mon, 7 Jun 2004 10:58:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 795E072DB5; Mon, 7 Jun 2004 10:58:27 -0700 (PDT) Date: Mon, 7 Jun 2004 10:58:27 -0700 (PDT) From: Doug White To: Patrick Hurrelmann In-Reply-To: <20040607185554.1e0ab5ee@duality.bytephobia.de> Message-ID: <20040607105744.D19466@carver.gumbysoft.com> References: <20040607185554.1e0ab5ee@duality.bytephobia.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: freebsd-hardware@freebsd.org Subject: Re: Experiences with 3Ware 9500-Series and 5.2 CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 17:58:27 -0000 On Mon, 7 Jun 2004, Patrick Hurrelmann wrote: > Hi there, > > i just sold my Promsie FastTrak S150 SX4 due to missing Raid 5 support of ataraid. I really wanted to get it running with FreeBSD 5.2 CURRENT, but the wait was too long :( > I thank Soeren Schmidt for his work and patience. > > Now I know want to buy a 3Ware 9500S-4LP. > > My desired configuration will be a Dual-Athlon on a Asus A7M266-D with 4x 120gb, 7200 rpm, 8mb cache (western digital). > > - Does anybody use such a controller and in what configuration? Its a pretty new controller; I haven't heard of anyone using it yet. > - How stable is the current twa? It was just committed, so you'd be in the "early adopter" phase :) -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 18:18:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC8BB16A4CE for ; Mon, 7 Jun 2004 18:18:45 +0000 (GMT) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4F7743D45 for ; Mon, 7 Jun 2004 18:18:45 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from mailnull by anduin.net with spam-scanned (Exim 4.34; FreeBSD) id 1BXOhd-0002in-G4 for current@freebsd.org; Mon, 07 Jun 2004 20:18:37 +0200 Received: from [217.8.136.185] (helo=[192.168.1.10]) by anduin.net with esmtp (Exim 4.34; FreeBSD) id 1BXOhX-0002ia-Ct; Mon, 07 Jun 2004 20:18:27 +0200 Message-ID: <40C4B16B.5070509@anduin.net> Date: Mon, 07 Jun 2004 20:18:19 +0200 From: Eirik Oeverby User-Agent: Mozilla Thunderbird 0.6 (X11/20040504) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Marc G. Fournier" References: <40BEC4D7.8070804@anduin.net> <20040606172659.T88480@ganymede.hub.org> In-Reply-To: <20040606172659.T88480@ganymede.hub.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on anduin.net X-Spam-Status: No, hits=0.0 required=7.5 tests=none autolearn=no version=2.63 X-Spam-Level: cc: current@freebsd.org Subject: Re: unionfs issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 18:18:46 -0000 Hi, To start off, I don't have any DEBUG stuff enabled at all. This is a production server that I can't really do such things to, and I can't afford more than one amd64 machine at this point ;) However what I can tell you is what I am trying to do: Replace mount_null. There doesn't seem to be a mount_null (not mount_nullfs, which is different) in -CURRENT. The idea is to be able to share some directories among jails and between host and jails. Homes come to mind, as do ports, source tree, etc. THe particular operationg that caused the panic was my attempt to mount homedirs into jails, and then performing some file copy operations (copying maildirs around) from within the jail. My ISP simply told me 'your box paniced in unionfs, we booted it'. That's pretty much all I can do in terms of debugging ... I might just want to wait for it all to settle and become more stable on amd64.. Thanks anyway, /Eirik Marc G. Fournier wrote: > > Eirik ... can you provide some details on exactly what you are trying to > do? For instance, as Dave posts in a follow up, there are several known > conditions that will cause a system to panic ... > > Now, in your case, you say it panic's ... do you have DEBUG enabled and > core dumping? That would help to narrow down if its a "known condition" > or something new ... > > On Thu, 3 Jun 2004, Eirik Oeverby wrote: > >> Hi, >> >> Recently (3 days ago) I upgraded my main server with 5.2.1, and then >> cvsupped to latest current in order to solve some problems in 5.2.1. >> Among those was the fact that unionfs was non-functional in the release. >> After cvsupping it seemed to work, but when doing some heavy file >> copying operations inside a mountpoint the box paniced. >> >> Problem is - the box is headless, 1000kms away, and with no serial >> access. So I'll just ask if this is expected behaviour at the current >> state of source, or if those in the know can say anything more about why >> this happened and if it has already been fixed. >> >> I apologise for the vague description of this problem - I know I'm >> probably reaching for straws here. >> >> Wbr., >> /Eirik >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" >> > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 > > From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 18:27:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B6CB16A4CE for ; Mon, 7 Jun 2004 18:27:07 +0000 (GMT) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 661A843D39 for ; Mon, 7 Jun 2004 18:27:07 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from mailnull by anduin.net with spam-scanned (Exim 4.34; FreeBSD) id 1BXOpg-0002q4-T0 for current@freebsd.org; Mon, 07 Jun 2004 20:26:56 +0200 Received: from [217.8.136.185] (helo=[192.168.1.10]) by anduin.net with esmtp (Exim 4.34; FreeBSD) id 1BXOpg-0002q1-L3 for current@freebsd.org; Mon, 07 Jun 2004 20:26:52 +0200 Message-ID: <40C4B365.4090001@anduin.net> Date: Mon, 07 Jun 2004 20:26:45 +0200 From: Eirik Oeverby User-Agent: Mozilla Thunderbird 0.6 (X11/20040504) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on anduin.net X-Spam-Status: No, hits=0.0 required=7.5 tests=none autolearn=no version=2.63 X-Spam-Level: Subject: Java/Diablo on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 18:27:07 -0000 Hi folks, does anyone here run Java in any shape or form on -CURRENT/amd64? In that case, which one, and how on earth did you get it running? What about linux emulation? Anyone hacked together an amd64 port of the linux emulation stuff yet? Java in some form would make it possible to run apache/tomcat, making the amd64 port viable for work (my day-job, that is) aswell, not just semi-play.. Anyone? /Eirik From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 18:37:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 485BC16A4CE for ; Mon, 7 Jun 2004 18:37:10 +0000 (GMT) Received: from email11.aon.at (WARSL402PIP7.highway.telekom.at [195.3.96.94]) by mx1.FreeBSD.org (Postfix) with SMTP id E38EB43D58 for ; Mon, 7 Jun 2004 18:37:08 +0000 (GMT) (envelope-from shoesoft@gmx.net) Received: (qmail 459076 invoked from network); 7 Jun 2004 18:37:07 -0000 Received: from n754p010.dipool.highway.telekom.at (HELO ?212.183.104.42?) ([212.183.104.42]) (envelope-sender ) by qmail2rs.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 7 Jun 2004 18:37:07 -0000 From: Stefan Ehmann To: Brian Feldman In-Reply-To: <20040607172431.GA19790@green.homeunix.org> References: <1086511629.1509.13.camel@taxman> <20040607172431.GA19790@green.homeunix.org> Content-Type: text/plain Message-Id: <1086633425.1020.15.camel@taxman> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 07 Jun 2004 20:37:05 +0200 Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: esd leaking file descriptors X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 18:37:10 -0000 On Mon, 2004-06-07 at 19:24, Brian Feldman wrote: > On Sun, Jun 06, 2004 at 10:47:09AM +0200, Stefan Ehmann wrote: > > When i run mpg321 -o esd foo.mp3 (or any other player that uses esd as > > output) lsof shows an increasing number of open files. It increases at a > > rate of about 50 files per second. System will run out of file > > descriptor eventually. > > > Check if esd is encountering exceptional conditions with the ktrace > facility. You will wnat to run esd with ktrace(1) and then use > kdump(1) to view the log of system calls. The other PC probably > also doesn't have the same hardware, so it's not so easy to see if > it's just a bug in -CURRENT. I just tried a kernel from June, 1st: esd doesn't leak any file descriptors. So it's definitely a CURRENT problem. I couldn't spot anything suspicous using ktrace (That is no notable difference compared to the other machine). Here are two excerpts from kdump output that basically repeat all the time: 1262 esd RET read 4096/0x1000 1262 esd CALL write(0x8,0x8059000,0x1000) 1262 esd GIO fd 8 wrote 4096 bytes ... 1262 esd RET write 4096/0x1000 1262 esd CALL gettimeofday(0xbfbfe598,0) 1262 esd RET gettimeofday 0 1262 esd CALL select(0xa,0xbfbfe510,0,0,0xbfbfe508) 1262 esd RET select 1 1262 esd CALL accept(0x7,0xbfbfe580,0xbfbfe528) 1262 esd RET accept -1 errno 35 Resource temporarily unavailable 1262 esd CALL select(0xa,0xbfbfe4f0,0,0,0xbfbfe478) 1262 esd RET select 1 1262 esd CALL read(0x9,0x805c000,0x1000) 1262 esd GIO fd 9 read 4096 bytes From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 18:46:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B3F6216A4CE for ; Mon, 7 Jun 2004 18:46:03 +0000 (GMT) Received: from parts-unknown.org (dsl093-170-248.sfo4.dsl.speakeasy.net [66.93.170.248]) by mx1.FreeBSD.org (Postfix) with SMTP id 6B59243D1D for ; Mon, 7 Jun 2004 18:46:03 +0000 (GMT) (envelope-from benfell@parts-unknown.org) Received: (qmail 13822 invoked by alias); 7 Jun 2004 18:45:52 -0000 Date: Mon, 7 Jun 2004 11:45:51 -0700 From: "David A. Benfell" To: current@freebsd.org Message-ID: <20040607184551.GA13787@parts-unknown.org> Mail-Followup-To: current@freebsd.org References: <20040607150956.GA7084@parts-unknown.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-stardate: [-29]2233.82 X-moon: The Moon is Waning Gibbous (72% of Full) User-Agent: Mutt/1.5.6i Subject: Re: file descripter leak in current with Qmail? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 18:46:03 -0000 On Mon, 07 Jun 2004 13:06:49 -0400, Robert Watson wrote: > > All of these limits have existed for quite a while, but typically aren't > run into since the default limits typically are pretty high for normal > application use. If necessary, you can raise the limit by tweaking the > global maximum using kern.maxfiles (either as a tunable or sysctl), and > then as needed adjusting the resource limits that qmail runs with. > Okay, so as a temporary measure, I've raised kern.maxfiles to 20000. I'm concerned about doing this; what I'm seeing suggests that system performance gets really ugly as the number of open files increases, even when it's still well below the old limit. > However, I think the more serious element here is the reason why you reach > the limit: this happens "naturally" under some workloads simply because of > large numbers of open files and network connections. However, in some > workloads, it's a symptom of a system or application bug, such as a > resource leak. The part that has me worried is that I'm hitting the limit now, when I wasn't before. Unfortunately, I haven't been keeping track of my upgrades in -CURRENT, so I can't really put a timeframe on when the problem arose, except that I didn't have the problem before my most recent upgrade a couple days ago. > > Because the resources were returned when qmail was killed, that largely > eliminates the possibility of a kernel resource leak (not entirely, but > largely), as most kernel resource leaks involving file descriptors have > the symptom that even after the process exits, the resources aren't > release (i.e., a reference counting bug or race). This suggests a user > space issue -- that doesn't eliminate a system bug, as it could be a bug > in a library that manages descriptors, but it also suggests the > possibility of an application bug, or at least, a poor application > interaction with a system bug. Occasionally, we've seen bugs in the > threading libraries that result in leaked descriptors, but my recollection > is that qmail doesn't use threads. So that suggests either a support > library (perhaps crypto or the like), or qmail itself. Or that you just > hit an extremely high load. :-) > > In terms of debugging it: your first task it to identify if there's one > process that's holding all the fd's, or if it is distributed over many > proceses. After that, you want to track down what kind of fd is being > left open, which may help you track down why it's left open... > I'm going to have to take this to the qmail list; people there might be able to track this down. Thanks! -- David Benfell, LCP benfell@parts-unknown.org --- Resume available at http://www.parts-unknown.org/resume.html From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 19:02:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 798B616A4CE for ; Mon, 7 Jun 2004 19:02:33 +0000 (GMT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08DFB43D46 for ; Mon, 7 Jun 2004 19:02:33 +0000 (GMT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc12) with ESMTP id <2004060719023201400i1paqe>; Mon, 7 Jun 2004 19:02:32 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA27483 for ; Mon, 7 Jun 2004 12:02:31 -0700 (PDT) Date: Mon, 7 Jun 2004 12:02:29 -0700 (PDT) From: Julian Elischer To: FreeBSD current users Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: beware.. need to run 'config' again before your next kernel compile X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 19:02:33 -0000 Splitting kern_thread.c into kern_thread.c and kern_kse.c means that the makefile will be wrong until you re-run config.. Julian From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 19:02:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 640FF16A4CE for ; Mon, 7 Jun 2004 19:02:43 +0000 (GMT) Received: from relay.macomnet.ru (relay.macomnet.ru [195.128.64.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6961343D31 for ; Mon, 7 Jun 2004 19:02:42 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from mp3 (d0snjwf1@mp3files.int.ru [195.128.64.20]) by relay.macomnet.ru (8.12.10/8.12.10) with ESMTP id i57J2eu515856000; Mon, 7 Jun 2004 23:02:40 +0400 (MSD) Date: Mon, 7 Jun 2004 23:02:40 +0400 (MSD) From: Maxim Konovalov To: Gleb Smirnoff In-Reply-To: <20040530100739.GA58477@cell.sick.ru> Message-ID: <20040607224538.L2382@mp3files.int.ru> References: <20040530100739.GA58477@cell.sick.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: incorrect connect() behavior X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 19:02:43 -0000 [ Change CC: in hope to reach a wide audience. ] On Sun, 30 May 2004, 14:07+0400, Gleb Smirnoff wrote: > Dear networkers, > > there is a problem in connect() syscall, which can be reproduced > on a box running without default route. > > According to POSIX, connect() must return if ENETUNREACH, if a route to > destination was not found. > > http://www.opengroup.org/onlinepubs/000095399/functions/connect.html > > In case of SOCK_STREAM it works this way. But in case of Yep, the absence of the route is discovered in ip_output() and EHOSTUNREACH returned. > SOCK_DGRAM connect() does not return error. And it picks up first > available local IP address for local side of socket. In some cases > this address may appear to be 127.0.0.1. Later, when a route to > destination shows up, datagrams will fail to send, since 127.0.0.1 > can not appear on wire. > > Affected installations are: > - BGP routers without default route > - localnet routers running some IGP > > Affected applications are: > > - ntpd. ntpd starts before routing daemon have established all > adjacencies, connect() binds to 127.0.0.1. Later when routing show > up, ntpd fails to send dgrams to server. > - net-snmpd. It is difficult to reproduce, but after some route > flapping snmpd hangs, and does not respond to requests. This can > be workarounded with a static route to source of queries. > - ng_ksocket. If node is of type inet/dgram/udp and a connect > message is sent to it, it does not return an error. Later it fails > to send packets withEPERM. > > Here is attached a test case for this problem no-route-test.c. To > test, one needs to delete default route, compile no-route-test and > run it. If connect() picks up non-localhost address, then you are > lucky :), some of your interfaces was ifconfiged before lo0. To > reproduce problem with 100 % guarantee, one needs to have lo0 first > one in list ${network_interfaces} var in /etc/rc.conf. Then you > should add default route, and look into what is typed by > no-route-test, which was started before this route was added. Someone can use udpcliserv/udpcli09.c from UNPv1 as well. > I have written two patches to deal with this problem. The first one > clings to POSIX behavior - it returns ENETUNREACH. I have tested > ntpd with it - it works well. But there is no guarantee that > anything else would be broken. The second patch is a POLA-patch, it > makes connect() to take first non-localhost address for local side > of socket. Code was obtained directly from NetBSD. This patch is > considered not to break anything. Both patches are attached. I prefer the former: return ENETUNREACH as soon as we detect we do not have a route to the net. Btw, Solaris 8 and Linux 2.4.x work this way. Discuss the issue with NetBSD people is a good idea too. %%% Index: in_pcb.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/in_pcb.c,v retrieving revision 1.147 diff -u -r1.147 in_pcb.c --- in_pcb.c 20 May 2004 06:35:02 -0000 1.147 +++ in_pcb.c 29 May 2004 21:12:40 -0000 @@ -612,9 +612,7 @@ if (ia == 0) ia = ifatoia(ifa_ifwithnet(sintosa(&sa))); if (ia == 0) - ia = TAILQ_FIRST(&in_ifaddrhead); - if (ia == 0) - return (EADDRNOTAVAIL); + return (ENETUNREACH); } /* * If the destination address is multicast and an outgoing %%% Any comments? -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 19:13:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5765416A4CE for ; Mon, 7 Jun 2004 19:13:57 +0000 (GMT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4784643D1F for ; Mon, 7 Jun 2004 19:13:57 +0000 (GMT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc11) with ESMTP id <2004060719135201300cm6bje>; Mon, 7 Jun 2004 19:13:53 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA27598; Mon, 7 Jun 2004 12:13:52 -0700 (PDT) Date: Mon, 7 Jun 2004 12:13:51 -0700 (PDT) From: Julian Elischer To: "David A. Benfell" In-Reply-To: <20040607184551.GA13787@parts-unknown.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: file descripter leak in current with Qmail? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 19:13:57 -0000 On Mon, 7 Jun 2004, David A. Benfell wrote: > On Mon, 07 Jun 2004 13:06:49 -0400, Robert Watson wrote: > > > > > > In terms of debugging it: your first task it to identify if there's one > > process that's holding all the fd's, or if it is distributed over many > > proceses. After that, you want to track down what kind of fd is being > > left open, which may help you track down why it's left open... fstat(1) is your friend.. > > > I'm going to have to take this to the qmail list; people there might > be able to track this down. From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 19:28:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEAD616A4CE for ; Mon, 7 Jun 2004 19:28:45 +0000 (GMT) Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.com [194.25.134.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 780C043D2D for ; Mon, 7 Jun 2004 19:28:45 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd04.aul.t-online.de by mailout07.sul.t-online.com with smtp id 1BXPnY-0003O3-00; Mon, 07 Jun 2004 21:28:44 +0200 Received: from Andro-Beta.Leidinger.net (G-6SC2ZZreLlKDB4RptbHpPu+fuGRRwDmPPedvhxwjEj29AV0ocf0S@[84.128.197.114]) by fmrl04.sul.t-online.com with esmtp id 1BXPnF-0cjyCm0; Mon, 7 Jun 2004 21:28:25 +0200 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) i57JSPTX070577; Mon, 7 Jun 2004 21:28:25 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Mon, 7 Jun 2004 21:29:49 +0200 From: Alexander Leidinger To: Alan Cox Message-Id: <20040607212949.2f7997d9@Magellan.Leidinger.net> In-Reply-To: <20040607174933.GK24461@cs.rice.edu> References: <20040606142446.2900a97e@Magellan.Leidinger.net> <20040606201249.GH24461@cs.rice.edu> <20040607130430.0ebbbb8e@Magellan.Leidinger.net> <20040607174933.GK24461@cs.rice.edu> X-Mailer: Sylpheed version 0.9.11claws (GTK+ 1.2.10; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Seen: false X-ID: G-6SC2ZZreLlKDB4RptbHpPu+fuGRRwDmPPedvhxwjEj29AV0ocf0S@t-dialin.net cc: current@freebsd.org Subject: Re: comments in the page coloring options in /sys/conf/NOTES X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 19:28:46 -0000 On Mon, 7 Jun 2004 12:49:33 -0500 Alan Cox wrote: > > vm_page.h contains: > > ---snip--- > > #if PQ_CACHESIZE >= 1024 > > #define PQ_PRIME1 31 /* Prime number somewhat less than PQ_HASH_SIZE */ > > #define PQ_PRIME2 23 /* Prime number somewhat less than PQ_HASH_SIZE */ > > #define PQ_L2_SIZE 256 /* A number of colors opt for 1M cache */ > > ---snip--- > > > > The three defines seem to be the tunables for the page coloring, but > > neither of them seem to be near cache_size/page_size. So even for the > > direct mapped case this doesn't seem to fit your explanation. > > Actually, it does. Divide 1MB (the cache size) by 4KB (the page size) Ooops... I had a different number for the page size in my mind... > > ... Is it as > > easy as using appropriate values for those defines at boot time or is > > there more work involved for auto-tuning version? > > At boot time. That was not my the question...: Do we need to change only places where those defines are used or are other changes required too? Bye, Alexander. -- I'm available to get hired (preferred in .lu). http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 19:29:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 2B1F116A4CE; Mon, 7 Jun 2004 19:29:20 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.12.11/8.12.11) with ESMTP id i57JTJWo020870; Mon, 7 Jun 2004 15:29:19 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.12.11/8.12.11/Submit) id i57JTJ5N020869; Mon, 7 Jun 2004 15:29:19 -0400 (EDT) (envelope-from green) Date: Mon, 7 Jun 2004 15:29:18 -0400 From: Brian Feldman To: Stefan Ehmann Message-ID: <20040607192918.GA20308@green.homeunix.org> References: <1086511629.1509.13.camel@taxman> <20040607172431.GA19790@green.homeunix.org> <1086633425.1020.15.camel@taxman> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1086633425.1020.15.camel@taxman> User-Agent: Mutt/1.5.6i cc: rwatson@freebsd.org cc: current@freebsd.org Subject: Re: esd leaking file descriptors X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 19:29:20 -0000 On Mon, Jun 07, 2004 at 08:37:05PM +0200, Stefan Ehmann wrote: > On Mon, 2004-06-07 at 19:24, Brian Feldman wrote: > > On Sun, Jun 06, 2004 at 10:47:09AM +0200, Stefan Ehmann wrote: > > > When i run mpg321 -o esd foo.mp3 (or any other player that uses esd as > > > output) lsof shows an increasing number of open files. It increases at a > > > rate of about 50 files per second. System will run out of file > > > descriptor eventually. > > > > > Check if esd is encountering exceptional conditions with the ktrace > > facility. You will wnat to run esd with ktrace(1) and then use > > kdump(1) to view the log of system calls. The other PC probably > > also doesn't have the same hardware, so it's not so easy to see if > > it's just a bug in -CURRENT. > > I just tried a kernel from June, 1st: esd doesn't leak any file > descriptors. So it's definitely a CURRENT problem. > > I couldn't spot anything suspicous using ktrace (That is no notable > difference compared to the other machine). > > Here are two excerpts from kdump output that basically repeat all the > time: I see a lot of accept(2) there... I think it's a good possibility Robert accidentally broke accept[1]()'s error cleanup. It seems that the file is dropped but the fd is left sitting around in a half-allocated state. Many of those 'goto done;'s should be 'goto noconnection;'s, I believe. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 19:31:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E0E116A4FD for ; Mon, 7 Jun 2004 19:31:22 +0000 (GMT) Received: from winston.piwebs.com (217-19-20-178.dsl.cambrium.nl [217.19.20.178]) by mx1.FreeBSD.org (Postfix) with SMTP id 4E04A43D4C for ; Mon, 7 Jun 2004 19:31:21 +0000 (GMT) (envelope-from avleeuwen@piwebs.com) Received: (qmail 28039 invoked from network); 7 Jun 2004 19:31:11 -0000 Received: from vincent.piwebs.com (192.168.0.84) by winston.piwebs.com with SMTP; 7 Jun 2004 19:31:11 -0000 From: Arjan van Leeuwen To: freebsd-current@freebsd.org Date: Mon, 7 Jun 2004 21:31:12 +0200 User-Agent: KMail/1.6.2 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_CKMxApEJAcbkiOp"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406072131.14477.avleeuwen@piwebs.com> cc: Robert Watson cc: current@freebsd.org cc: "David A. Benfell" Subject: Re: file descripter leak in current with Qmail? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: avleeuwen@piwebs.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 19:31:22 -0000 --Boundary-02=_CKMxApEJAcbkiOp Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, On Monday 07 June 2004 19:06, Robert Watson wrote: > On Mon, 7 Jun 2004, David A. Benfell wrote: (...) > > However, I think the more serious element here is the reason why you reach > the limit: this happens "naturally" under some workloads simply because of > large numbers of open files and network connections. However, in some > workloads, it's a symptom of a system or application bug, such as a > resource leak. > > Because the resources were returned when qmail was killed, that largely > eliminates the possibility of a kernel resource leak (not entirely, but > largely), as most kernel resource leaks involving file descriptors have > the symptom that even after the process exits, the resources aren't > release (i.e., a reference counting bug or race). This suggests a user > space issue -- that doesn't eliminate a system bug, as it could be a bug > in a library that manages descriptors, but it also suggests the > possibility of an application bug, or at least, a poor application > interaction with a system bug. Occasionally, we've seen bugs in the > threading libraries that result in leaked descriptors, but my recollection > is that qmail doesn't use threads. So that suggests either a support > library (perhaps crypto or the like), or qmail itself. Or that you just > hit an extremely high load. :-) > > In terms of debugging it: your first task it to identify if there's one > process that's holding all the fd's, or if it is distributed over many > proceses. After that, you want to track down what kind of fd is being > left open, which may help you track down why it's left open... Just as I'm reading this, I'm seeing the same thing on my -CURRENT server,= =20 which has a _very_ low load (atm, it's only routing the internet traffic fo= r=20 3 users and serving SMTP for 2 of them). I'm also running qmail. The kernel= =20 is from June 6. How do I go about investigating this further? Best regards, Arjan van Leeuwen --Boundary-02=_CKMxApEJAcbkiOp Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAxMKC3Ym57eNCXiERAgr6AKCpCl1RBjeRiFRLyIsAVcD+FNmXGACggU5Q 2FGfMyXMcSZbNRAjBAuntdk= =bOOd -----END PGP SIGNATURE----- --Boundary-02=_CKMxApEJAcbkiOp-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 19:31:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7212316A500 for ; Mon, 7 Jun 2004 19:31:22 +0000 (GMT) Received: from winston.piwebs.com (217-19-20-178.dsl.cambrium.nl [217.19.20.178]) by mx1.FreeBSD.org (Postfix) with SMTP id 463AA43D48 for ; Mon, 7 Jun 2004 19:31:21 +0000 (GMT) (envelope-from avleeuwen@piwebs.com) Received: (qmail 28039 invoked from network); 7 Jun 2004 19:31:11 -0000 Received: from vincent.piwebs.com (192.168.0.84) by winston.piwebs.com with SMTP; 7 Jun 2004 19:31:11 -0000 From: Arjan van Leeuwen To: freebsd-current@freebsd.org Date: Mon, 7 Jun 2004 21:31:12 +0200 User-Agent: KMail/1.6.2 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_CKMxApEJAcbkiOp"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406072131.14477.avleeuwen@piwebs.com> cc: Robert Watson cc: current@freebsd.org cc: "David A. Benfell" Subject: Re: file descripter leak in current with Qmail? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: avleeuwen@piwebs.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 19:31:22 -0000 --Boundary-02=_CKMxApEJAcbkiOp Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, On Monday 07 June 2004 19:06, Robert Watson wrote: > On Mon, 7 Jun 2004, David A. Benfell wrote: (...) > > However, I think the more serious element here is the reason why you reach > the limit: this happens "naturally" under some workloads simply because of > large numbers of open files and network connections. However, in some > workloads, it's a symptom of a system or application bug, such as a > resource leak. > > Because the resources were returned when qmail was killed, that largely > eliminates the possibility of a kernel resource leak (not entirely, but > largely), as most kernel resource leaks involving file descriptors have > the symptom that even after the process exits, the resources aren't > release (i.e., a reference counting bug or race). This suggests a user > space issue -- that doesn't eliminate a system bug, as it could be a bug > in a library that manages descriptors, but it also suggests the > possibility of an application bug, or at least, a poor application > interaction with a system bug. Occasionally, we've seen bugs in the > threading libraries that result in leaked descriptors, but my recollection > is that qmail doesn't use threads. So that suggests either a support > library (perhaps crypto or the like), or qmail itself. Or that you just > hit an extremely high load. :-) > > In terms of debugging it: your first task it to identify if there's one > process that's holding all the fd's, or if it is distributed over many > proceses. After that, you want to track down what kind of fd is being > left open, which may help you track down why it's left open... Just as I'm reading this, I'm seeing the same thing on my -CURRENT server,= =20 which has a _very_ low load (atm, it's only routing the internet traffic fo= r=20 3 users and serving SMTP for 2 of them). I'm also running qmail. The kernel= =20 is from June 6. How do I go about investigating this further? Best regards, Arjan van Leeuwen --Boundary-02=_CKMxApEJAcbkiOp Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAxMKC3Ym57eNCXiERAgr6AKCpCl1RBjeRiFRLyIsAVcD+FNmXGACggU5Q 2FGfMyXMcSZbNRAjBAuntdk= =bOOd -----END PGP SIGNATURE----- --Boundary-02=_CKMxApEJAcbkiOp-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 19:41:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4526C16A4CE for ; Mon, 7 Jun 2004 19:41:08 +0000 (GMT) Received: from winston.piwebs.com (217-19-20-178.dsl.cambrium.nl [217.19.20.178]) by mx1.FreeBSD.org (Postfix) with SMTP id 6EDD943D1F for ; Mon, 7 Jun 2004 19:41:07 +0000 (GMT) (envelope-from avleeuwen@piwebs.com) Received: (qmail 28274 invoked from network); 7 Jun 2004 19:41:06 -0000 Received: from vincent.piwebs.com (192.168.0.84) by winston.piwebs.com with SMTP; 7 Jun 2004 19:41:06 -0000 From: Arjan van Leeuwen To: freebsd-current@freebsd.org Date: Mon, 7 Jun 2004 21:41:09 +0200 User-Agent: KMail/1.6.2 References: <200406072131.14477.avleeuwen@piwebs.com> In-Reply-To: <200406072131.14477.avleeuwen@piwebs.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_VTMxAdVGLtWPts9"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406072141.09413.avleeuwen@piwebs.com> cc: Robert Watson cc: "David A. Benfell" Subject: Re: file descripter leak in current with Qmail? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: avleeuwen@piwebs.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 19:41:08 -0000 --Boundary-02=_VTMxAdVGLtWPts9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Monday 07 June 2004 21:31, Arjan van Leeuwen wrote: > Hi, > > On Monday 07 June 2004 19:06, Robert Watson wrote: > > On Mon, 7 Jun 2004, David A. Benfell wrote: > > (...) > > > However, I think the more serious element here is the reason why you > > reach the limit: this happens "naturally" under some workloads simply > > because of large numbers of open files and network connections. However, > > in some workloads, it's a symptom of a system or application bug, such as > > a resource leak. > > > > Because the resources were returned when qmail was killed, that largely > > eliminates the possibility of a kernel resource leak (not entirely, but > > largely), as most kernel resource leaks involving file descriptors have > > the symptom that even after the process exits, the resources aren't > > release (i.e., a reference counting bug or race). This suggests a user > > space issue -- that doesn't eliminate a system bug, as it could be a bug > > in a library that manages descriptors, but it also suggests the > > possibility of an application bug, or at least, a poor application > > interaction with a system bug. Occasionally, we've seen bugs in the > > threading libraries that result in leaked descriptors, but my > > recollection is that qmail doesn't use threads. So that suggests either > > a support library (perhaps crypto or the like), or qmail itself. Or that > > you just hit an extremely high load. :-) > > > > In terms of debugging it: your first task it to identify if there's one > > process that's holding all the fd's, or if it is distributed over many > > proceses. After that, you want to track down what kind of fd is being > > left open, which may help you track down why it's left open... > > Just as I'm reading this, I'm seeing the same thing on my -CURRENT server, > which has a _very_ low load (atm, it's only routing the internet traffic > for 3 users and serving SMTP for 2 of them). I'm also running qmail. The > kernel is from June 6. How do I go about investigating this further? Replying to myself - fstat shows all open files evenly distributed among the running processes. Arjan --Boundary-02=_VTMxAdVGLtWPts9 Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAxMTV3Ym57eNCXiERAm1eAKCeSrhJTmgBVNOQKzf6hqsvAJKuCwCgpXvW JKjUX5D8nOsGGmp1/TSWZz4= =m+Ni -----END PGP SIGNATURE----- --Boundary-02=_VTMxAdVGLtWPts9-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 19:41:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9D0516A4D1; Mon, 7 Jun 2004 19:41:41 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E7B243D46; Mon, 7 Jun 2004 19:41:41 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i57JeiFe013263; Mon, 7 Jun 2004 15:40:44 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i57Jeiwf013260; Mon, 7 Jun 2004 15:40:44 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 7 Jun 2004 15:40:44 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Brian Feldman In-Reply-To: <20040607192918.GA20308@green.homeunix.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org cc: Stefan Ehmann Subject: Re: esd leaking file descriptors X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 19:41:41 -0000 On Mon, 7 Jun 2004, Brian Feldman wrote: > > I just tried a kernel from June, 1st: esd doesn't leak any file > > descriptors. So it's definitely a CURRENT problem. > > > > I couldn't spot anything suspicous using ktrace (That is no notable > > difference compared to the other machine). > > > > Here are two excerpts from kdump output that basically repeat all the > > time: > > I see a lot of accept(2) there... I think it's a good possibility Robert > accidentally broke accept[1]()'s error cleanup. It seems that the file > is dropped but the fd is left sitting around in a half-allocated state. > Many of those 'goto done;'s should be 'goto noconnection;'s, I believe. That's what I was wondering -- it looks like the 'goto done's following falloc()'s failure check should be "goto noconnection". Here's a patch that cleans that up, but may not be perfect. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research Index: uipc_syscalls.c =================================================================== RCS file: /data/ncvs/src/sys/kern/uipc_syscalls.c,v retrieving revision 1.187 diff -u -r1.187 uipc_syscalls.c --- uipc_syscalls.c 7 Jun 2004 09:59:50 -0000 1.187 +++ uipc_syscalls.c 7 Jun 2004 19:38:39 -0000 @@ -285,7 +285,7 @@ if ((head->so_state & SS_NBIO) && TAILQ_EMPTY(&head->so_comp)) { ACCEPT_UNLOCK(); error = EWOULDBLOCK; - goto done; + goto noconnection; } while (TAILQ_EMPTY(&head->so_comp) && head->so_error == 0) { if (head->so_state & SS_CANTRCVMORE) { @@ -296,14 +296,14 @@ "accept", 0); if (error) { ACCEPT_UNLOCK(); - goto done; + goto noconnection; } } if (head->so_error) { error = head->so_error; head->so_error = 0; ACCEPT_UNLOCK(); - goto done; + goto noconnection; } so = TAILQ_FIRST(&head->so_comp); KASSERT(!(so->so_qstate & SQ_INCOMP), ("accept1: so SQ_INCOMP")); From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 19:42:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE7EE16A4CE for ; Mon, 7 Jun 2004 19:42:54 +0000 (GMT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81D1C43D45 for ; Mon, 7 Jun 2004 19:42:54 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (localhost [127.0.0.1]) by ns1.xcllnt.net (8.12.11/8.12.11) with ESMTP id i57JgbOl010451; Mon, 7 Jun 2004 12:42:37 -0700 (PDT) (envelope-from marcel@ns1.xcllnt.net) Received: (from marcel@localhost) by ns1.xcllnt.net (8.12.11/8.12.11/Submit) id i57JgbAU010450; Mon, 7 Jun 2004 12:42:37 -0700 (PDT) (envelope-from marcel) Date: Mon, 7 Jun 2004 12:42:37 -0700 From: Marcel Moolenaar To: Doug Rabson Message-ID: <20040607194237.GA10406@ns1.xcllnt.net> References: <40C37E1C.4000402@freebsd.org> <20040606204817.GB96607@dhcp50.pn.xcllnt.net> <200406071014.21707.dfr@nlsystems.com> <20040607155645.GB66937@dhcp50.pn.xcllnt.net> <1086625355.10911.39.camel@builder02.qubesoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1086625355.10911.39.camel@builder02.qubesoft.com> User-Agent: Mutt/1.5.5.1i cc: freebsd-current@freebsd.org Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 19:42:55 -0000 On Mon, Jun 07, 2004 at 05:22:35PM +0100, Doug Rabson wrote: > > > > > > Actually its a bit better than that. It works for most use cases right > > > now on i386 but would get confused on dlclose. I'll fix that before I > > > move it into current. > > > > Does it work on static bound executables? > > Which one is static bound The executable; you know, no rtld. What I call complete executable to distinguish it from static TLS on my page. Does static TLS work? See also: http://wiki.daemon.li/index.pl?ThreadLocalStorage -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 19:43:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FB3516A4CE for ; Mon, 7 Jun 2004 19:43:41 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A98B843D39 for ; Mon, 7 Jun 2004 19:43:40 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i57JgXeT013412; Mon, 7 Jun 2004 15:42:33 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i57JgXkK013409; Mon, 7 Jun 2004 15:42:33 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 7 Jun 2004 15:42:33 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Arjan van Leeuwen In-Reply-To: <200406072141.09413.avleeuwen@piwebs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: "David A. Benfell" Subject: Re: file descripter leak in current with Qmail? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 19:43:41 -0000 On Mon, 7 Jun 2004, Arjan van Leeuwen wrote: > > > In terms of debugging it: your first task it to identify if there's one > > > process that's holding all the fd's, or if it is distributed over many > > > proceses. After that, you want to track down what kind of fd is being > > > left open, which may help you track down why it's left open... > > > > Just as I'm reading this, I'm seeing the same thing on my -CURRENT server, > > which has a _very_ low load (atm, it's only routing the internet traffic > > for 3 users and serving SMTP for 2 of them). I'm also running qmail. The > > kernel is from June 6. How do I go about investigating this further? > > Replying to myself - > fstat shows all open files evenly distributed among the running processes. It could be that this is related to the esd file descriptor leak problem also being reported. You might also try the attached patch. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research Index: uipc_syscalls.c =================================================================== RCS file: /data/ncvs/src/sys/kern/uipc_syscalls.c,v retrieving revision 1.187 diff -u -r1.187 uipc_syscalls.c --- uipc_syscalls.c 7 Jun 2004 09:59:50 -0000 1.187 +++ uipc_syscalls.c 7 Jun 2004 19:38:39 -0000 @@ -285,7 +285,7 @@ if ((head->so_state & SS_NBIO) && TAILQ_EMPTY(&head->so_comp)) { ACCEPT_UNLOCK(); error = EWOULDBLOCK; - goto done; + goto noconnection; } while (TAILQ_EMPTY(&head->so_comp) && head->so_error == 0) { if (head->so_state & SS_CANTRCVMORE) { @@ -296,14 +296,14 @@ "accept", 0); if (error) { ACCEPT_UNLOCK(); - goto done; + goto noconnection; } } if (head->so_error) { error = head->so_error; head->so_error = 0; ACCEPT_UNLOCK(); - goto done; + goto noconnection; } so = TAILQ_FIRST(&head->so_comp); KASSERT(!(so->so_qstate & SQ_INCOMP), ("accept1: so SQ_INCOMP")); From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 19:47:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8844216A4CE; Mon, 7 Jun 2004 19:47:34 +0000 (GMT) Received: from tensor.xs4all.nl (tensor.xs4all.nl [194.109.160.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id F050143D1D; Mon, 7 Jun 2004 19:47:33 +0000 (GMT) (envelope-from dimitry@andric.com) Received: from kilgore.dim (kilgore.dim [192.168.0.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.xs4all.nl (Postfix) with ESMTP id AE14622827; Mon, 7 Jun 2004 21:47:31 +0200 (CEST) Date: Mon, 7 Jun 2004 21:47:19 +0200 From: Dimitry Andric X-Mailer: The Bat! (v2.11.02) Business X-Priority: 3 (Normal) Message-ID: <239341455.20040607214719@andric.com> To: Brian Feldman In-Reply-To: <20040607192918.GA20308@green.homeunix.org> References: <1086511629.1509.13.camel@taxman> <20040607172431.GA19790@green.homeunix.org> <1086633425.1020.15.camel@taxman> <20040607192918.GA20308@green.homeunix.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="----------111EDD6F092F48" cc: rwatson@freebsd.org cc: current@freebsd.org cc: Stefan Ehmann Subject: Re: esd leaking file descriptors X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 19:47:34 -0000 ------------111EDD6F092F48 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On 2004-06-07 at 21:29:18 Brian Feldman wrote: >> Here are two excerpts from kdump output that basically repeat all the >> time: > I see a lot of accept(2) there... I think it's a good possibility > Robert accidentally broke accept[1]()'s error cleanup. Hmm, I'm starting to think that this is why I ran into a similar problem with Squid yesterday; it ran out of file descriptors, started spamming the console, and made the machine quite inaccessible. :) (Luckily there's a serial console.) I've run Squid on FreeBSD for years now, without ever encountering something like this! I then unthinkingly bumped kern.maxfiles to 8192, but it's probably better if I try Robert's patch too. ------------111EDD6F092F48 Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: GnuPG v1.2.4 (MingW32) iD8DBQFAxMZHsF6jCi4glqMRAjlXAKDs3fMCQJDNO5oAs6wvjBx14DWzfgCglej3 6mh7ljQmcmESOkneMg/rgSQ= =3l0l -----END PGP MESSAGE----- ------------111EDD6F092F48-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 20:00:40 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4ABCF16A4CE; Mon, 7 Jun 2004 20:00:40 +0000 (GMT) Received: from gamera.svk.isite.net (mail.isite.net [205.217.158.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id F125743D2D; Mon, 7 Jun 2004 20:00:39 +0000 (GMT) (envelope-from jrhett@isite.net) Received: from anubis.svk.isite.net (anubis.svk.isite.net [205.217.158.5]) by gamera.svk.isite.net (8.12.10/8.12.9) with ESMTP id i57K0Tqa002570 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 7 Jun 2004 13:00:29 -0700 (PDT) Received: from anubis.svk.isite.net (localhost [127.0.0.1]) i57K0SZ8023414; Mon, 7 Jun 2004 13:00:28 -0700 (PDT) Received: (from jrhett@localhost)i57K0Srv023413; Mon, 7 Jun 2004 13:00:28 -0700 (PDT) Date: Mon, 7 Jun 2004 13:00:28 -0700 From: Joe Rhett To: Pav Lucistnik Message-ID: <20040607200028.GA22403@isite.net> References: <20040603035617.GA1349@green.homeunix.org> <1086260563.96671.23.camel@pav.hide.vol.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1086260563.96671.23.camel@pav.hide.vol.cz> User-Agent: Mutt/1.4.2i Organization: Isite Services, Inc. cc: current@freebsd.org cc: hardware@freebsd.org Subject: Re: ata(4) locks up system -- for too many reasons X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 20:00:40 -0000 Actually, the atapi support in general seems to require reboots far too often. Acer CD-ROM units work fine in DMA but are broken in PIO mode. But once you get the BIG_READ errors, you have to reboot to clean it up. Then I also found that if a CD has an error on it (or dust) it can cause the same problem. This is a fairly serious problem that really needs to be addressed. I don't reboot machines, ever. For years at a time anyway. Having to reboot freebsd almost hourly during the diagnosis of this made me cringe. -- Joe Rhett Chief Geek JRhett@Isite.Net Isite Services, Inc. From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 20:16:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5E7C16A4CE for ; Mon, 7 Jun 2004 20:16:28 +0000 (GMT) Received: from winston.piwebs.com (217-19-20-178.dsl.cambrium.nl [217.19.20.178]) by mx1.FreeBSD.org (Postfix) with SMTP id 0798743D58 for ; Mon, 7 Jun 2004 20:16:28 +0000 (GMT) (envelope-from avleeuwen@piwebs.com) Received: (qmail 817 invoked from network); 7 Jun 2004 20:16:21 -0000 Received: from vincent.piwebs.com (192.168.0.84) by winston.piwebs.com with SMTP; 7 Jun 2004 20:16:21 -0000 From: Arjan van Leeuwen To: Robert Watson Date: Mon, 7 Jun 2004 22:16:24 +0200 User-Agent: KMail/1.6.2 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_d0MxAuVjRZMafXQ"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406072216.29044.avleeuwen@piwebs.com> cc: freebsd-current@freebsd.org cc: "David A. Benfell" Subject: Re: file descripter leak in current with Qmail? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: avleeuwen@piwebs.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 20:16:29 -0000 --Boundary-02=_d0MxAuVjRZMafXQ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 07 June 2004 21:42, you wrote: > On Mon, 7 Jun 2004, Arjan van Leeuwen wrote: > > > > In terms of debugging it: your first task it to identify if there's > > > > one process that's holding all the fd's, or if it is distributed ov= er > > > > many proceses. After that, you want to track down what kind of fd = is > > > > being left open, which may help you track down why it's left open... > > > > > > Just as I'm reading this, I'm seeing the same thing on my -CURRENT > > > server, which has a _very_ low load (atm, it's only routing the > > > internet traffic for 3 users and serving SMTP for 2 of them). I'm also > > > running qmail. The kernel is from June 6. How do I go about > > > investigating this further? > > > > Replying to myself - > > fstat shows all open files evenly distributed among the running > > processes. > > It could be that this is related to the esd file descriptor leak problem > also being reported. You might also try the attached patch. I get a panic (address not allocated) when using the patch. I can't write d= own=20 any useful details about it right now, because although the server has only= 3=20 users, they're very disconcerned when I disrupt their internet traffic :). Best regards, Arjan > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Senior Research Scientist, McAfee Research > > Index: uipc_syscalls.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /data/ncvs/src/sys/kern/uipc_syscalls.c,v > retrieving revision 1.187 > diff -u -r1.187 uipc_syscalls.c > --- uipc_syscalls.c 7 Jun 2004 09:59:50 -0000 1.187 > +++ uipc_syscalls.c 7 Jun 2004 19:38:39 -0000 > @@ -285,7 +285,7 @@ > if ((head->so_state & SS_NBIO) && TAILQ_EMPTY(&head->so_comp)) { > ACCEPT_UNLOCK(); > error =3D EWOULDBLOCK; > - goto done; > + goto noconnection; > } > while (TAILQ_EMPTY(&head->so_comp) && head->so_error =3D=3D 0) { > if (head->so_state & SS_CANTRCVMORE) { > @@ -296,14 +296,14 @@ > "accept", 0); > if (error) { > ACCEPT_UNLOCK(); > - goto done; > + goto noconnection; > } > } > if (head->so_error) { > error =3D head->so_error; > head->so_error =3D 0; > ACCEPT_UNLOCK(); > - goto done; > + goto noconnection; > } > so =3D TAILQ_FIRST(&head->so_comp); > KASSERT(!(so->so_qstate & SQ_INCOMP), ("accept1: so SQ_INCOMP")); > > > > !DSPAM:40c4c5b6283404763116770! --Boundary-02=_d0MxAuVjRZMafXQ Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAxM0d3Ym57eNCXiERAjnQAJ9kvpK+myUOOLehWoymlWBtVkA3FgCeM0XR gex5oXPPS28XDdrCvlwtqgg= =jM/Y -----END PGP SIGNATURE----- --Boundary-02=_d0MxAuVjRZMafXQ-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 20:22:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA82216A4CE for ; Mon, 7 Jun 2004 20:22:18 +0000 (GMT) Received: from email07.aon.at (WARSL402PIP8.highway.telekom.at [195.3.96.97]) by mx1.FreeBSD.org (Postfix) with SMTP id 1E7F143D49 for ; Mon, 7 Jun 2004 20:22:18 +0000 (GMT) (envelope-from shoesoft@gmx.net) Received: (qmail 636654 invoked from network); 7 Jun 2004 20:07:44 -0000 Received: from m106p004.dipool.highway.telekom.at (HELO ?62.46.3.36?) ([62.46.3.36]) (envelope-sender ) by 172.18.5.236 (qmail-ldap-1.03) with SMTP for ; 7 Jun 2004 20:07:44 -0000 From: Stefan Ehmann To: Robert Watson In-Reply-To: References: Content-Type: text/plain Message-Id: <1086638862.724.2.camel@taxman> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 07 Jun 2004 22:07:42 +0200 Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: esd leaking file descriptors X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 20:22:19 -0000 On Mon, 2004-06-07 at 21:40, Robert Watson wrote: > On Mon, 7 Jun 2004, Brian Feldman wrote: > > > > I just tried a kernel from June, 1st: esd doesn't leak any file > > > descriptors. So it's definitely a CURRENT problem. > > > > > > I couldn't spot anything suspicous using ktrace (That is no notable > > > difference compared to the other machine). > > > > > > Here are two excerpts from kdump output that basically repeat all the > > > time: > > > > I see a lot of accept(2) there... I think it's a good possibility Robert > > accidentally broke accept[1]()'s error cleanup. It seems that the file > > is dropped but the fd is left sitting around in a half-allocated state. > > Many of those 'goto done;'s should be 'goto noconnection;'s, I believe. > > That's what I was wondering -- it looks like the 'goto done's following > falloc()'s failure check should be "goto noconnection". Here's a patch > that cleans that up, but may not be perfect. I get a panic when trying to access esd now: panic: free address has not been allocated From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 20:24:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 092FB16A4CE for ; Mon, 7 Jun 2004 20:24:49 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E56543D31 for ; Mon, 7 Jun 2004 20:24:48 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i57KNpip020599; Mon, 7 Jun 2004 16:23:51 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i57KNpQq020596; Mon, 7 Jun 2004 16:23:51 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 7 Jun 2004 16:23:51 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Arjan van Leeuwen In-Reply-To: <200406072216.29044.avleeuwen@piwebs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: "David A. Benfell" Subject: Re: file descripter leak in current with Qmail? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 20:24:49 -0000 On Mon, 7 Jun 2004, Arjan van Leeuwen wrote: > > It could be that this is related to the esd file descriptor leak problem > > also being reported. You might also try the attached patch. > > I get a panic (address not allocated) when using the patch. I can't > write down any useful details about it right now, because although the > server has only 3 users, they're very disconcerned when I disrupt their > internet traffic :). Just ran into that myself once the build finished -- looks like 'sa' isn't being initialized to NULL. I'll send a follow-up patch shortly. > > Best regards, > > Arjan > > > > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > > robert@fledge.watson.org Senior Research Scientist, McAfee Research > > > > Index: uipc_syscalls.c > > =================================================================== > > RCS file: /data/ncvs/src/sys/kern/uipc_syscalls.c,v > > retrieving revision 1.187 > > diff -u -r1.187 uipc_syscalls.c > > --- uipc_syscalls.c 7 Jun 2004 09:59:50 -0000 1.187 > > +++ uipc_syscalls.c 7 Jun 2004 19:38:39 -0000 > > @@ -285,7 +285,7 @@ > > if ((head->so_state & SS_NBIO) && TAILQ_EMPTY(&head->so_comp)) { > > ACCEPT_UNLOCK(); > > error = EWOULDBLOCK; > > - goto done; > > + goto noconnection; > > } > > while (TAILQ_EMPTY(&head->so_comp) && head->so_error == 0) { > > if (head->so_state & SS_CANTRCVMORE) { > > @@ -296,14 +296,14 @@ > > "accept", 0); > > if (error) { > > ACCEPT_UNLOCK(); > > - goto done; > > + goto noconnection; > > } > > } > > if (head->so_error) { > > error = head->so_error; > > head->so_error = 0; > > ACCEPT_UNLOCK(); > > - goto done; > > + goto noconnection; > > } > > so = TAILQ_FIRST(&head->so_comp); > > KASSERT(!(so->so_qstate & SQ_INCOMP), ("accept1: so SQ_INCOMP")); > > > > > > > > !DSPAM:40c4c5b6283404763116770! > From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 20:39:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 777E816A4CE for ; Mon, 7 Jun 2004 20:39:18 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DB0943D54 for ; Mon, 7 Jun 2004 20:39:18 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i57KcLRf023579; Mon, 7 Jun 2004 16:38:21 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i57KcL4i023576; Mon, 7 Jun 2004 16:38:21 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 7 Jun 2004 16:38:21 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Arjan van Leeuwen In-Reply-To: <200406072216.29044.avleeuwen@piwebs.com> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-840199968-1086640701=:88690" cc: freebsd-current@freebsd.org cc: "David A. Benfell" Subject: Re: file descripter leak in current with Qmail? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 20:39:18 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-840199968-1086640701=:88690 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 7 Jun 2004, Arjan van Leeuwen wrote: > On Monday 07 June 2004 21:42, you wrote: > > On Mon, 7 Jun 2004, Arjan van Leeuwen wrote: > > > > > In terms of debugging it: your first task it to identify if there's > > > > > one process that's holding all the fd's, or if it is distributed over > > > > > many proceses. After that, you want to track down what kind of fd is > > > > > being left open, which may help you track down why it's left open... > > > > > > > > Just as I'm reading this, I'm seeing the same thing on my -CURRENT > > > > server, which has a _very_ low load (atm, it's only routing the > > > > internet traffic for 3 users and serving SMTP for 2 of them). I'm also > > > > running qmail. The kernel is from June 6. How do I go about > > > > investigating this further? > > > > > > Replying to myself - > > > fstat shows all open files evenly distributed among the running > > > processes. > > > > It could be that this is related to the esd file descriptor leak problem > > also being reported. You might also try the attached patch. > > I get a panic (address not allocated) when using the patch. I can't > write down any useful details about it right now, because although the > server has only 3 users, they're very disconcerned when I disrupt their > internet traffic :). Doh. Sorry about that. Revised patch attached. I'm able to test the leak with the attached C file, and on my test box (now that it doesn't panic), the leak appears fixed for non-blocking accepts. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research Index: uipc_syscalls.c =================================================================== RCS file: /data/ncvs/src/sys/kern/uipc_syscalls.c,v retrieving revision 1.187 diff -u -r1.187 uipc_syscalls.c --- uipc_syscalls.c 7 Jun 2004 09:59:50 -0000 1.187 +++ uipc_syscalls.c 7 Jun 2004 20:21:30 -0000 @@ -253,7 +253,7 @@ { struct filedesc *fdp; struct file *nfp = NULL; - struct sockaddr *sa; + struct sockaddr *sa = NULL; socklen_t namelen; int error; struct socket *head, *so; @@ -285,7 +285,7 @@ if ((head->so_state & SS_NBIO) && TAILQ_EMPTY(&head->so_comp)) { ACCEPT_UNLOCK(); error = EWOULDBLOCK; - goto done; + goto noconnection; } while (TAILQ_EMPTY(&head->so_comp) && head->so_error == 0) { if (head->so_state & SS_CANTRCVMORE) { @@ -296,14 +296,14 @@ "accept", 0); if (error) { ACCEPT_UNLOCK(); - goto done; + goto noconnection; } } if (head->so_error) { error = head->so_error; head->so_error = 0; ACCEPT_UNLOCK(); - goto done; + goto noconnection; } so = TAILQ_FIRST(&head->so_comp); KASSERT(!(so->so_qstate & SQ_INCOMP), ("accept1: so SQ_INCOMP")); --0-840199968-1086640701=:88690 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="accept_test.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: I2luY2x1ZGUgPHN5cy90eXBlcy5oPg0KI2luY2x1ZGUgPHN5cy9zb2NrZXQu aD4NCg0KI2luY2x1ZGUgPG5ldGluZXQvaW4uaD4NCg0KI2luY2x1ZGUgPGZj bnRsLmg+DQojaW5jbHVkZSA8c3RkaW8uaD4NCiNpbmNsdWRlIDxzdGRsaWIu aD4NCiNpbmNsdWRlIDxzdHJpbmcuaD4NCg0KaW50DQptYWluKGludCBhcmdj LCBjaGFyICphcmd2W10pDQp7DQoJc3RydWN0IHNvY2thZGRyX2luIHNpbjsN Cglzb2NrbGVuX3Qgc2l6ZTsNCglpbnQgaSwgczsNCg0KCXMgPSBzb2NrZXQo UEZfSU5FVCwgU09DS19TVFJFQU0sIDApOw0KCWlmIChzID09IC0xKSB7DQoJ CXBlcnJvcigic29ja2V0Iik7DQoJCWV4aXQoLTEpOw0KCX0NCg0KCWJ6ZXJv KCZzaW4sIHNpemVvZihzaW4pKTsNCglzaW4uc2luX2xlbiA9IHNpemVvZihz aW4pOw0KCXNpbi5zaW5fZmFtaWx5ID0gQUZfSU5FVDsNCglzaW4uc2luX2Fk ZHIuc19hZGRyID0gSU5BRERSX0FOWTsNCglzaW4uc2luX3BvcnQgPSBodG9u cyg4MDgwKTsNCg0KCWlmIChiaW5kKHMsIChzdHJ1Y3Qgc29ja2FkZHIgKikg JnNpbiwgc2l6ZW9mKHNpbikpICE9IDApIHsNCgkJcGVycm9yKCJiaW5kIik7 DQoJCWV4aXQoLTEpOw0KCX0NCg0KCWlmIChsaXN0ZW4ocywgLTEpICE9IDAp IHsNCgkJcGVycm9yKCJsaXN0ZW4iKTsNCgkJZXhpdCgtMSk7DQoJfQ0KDQoJ aSA9IDE7DQoJaWYgKGZjbnRsKHMsIE9fTk9OQkxPQ0ssICZpKSAhPSAwKSB7 DQoJCXBlcnJvcigiT19OT05CTE9DSyIpOw0KCQlleGl0KC0xKTsNCgl9DQoN Cglmb3IgKGkgPSAwOyBpIDwgMTAwMDsgaSsrKQ0KCQlhY2NlcHQocywgKHN0 cnVjdCBzb2NrYWRkciAqKSZzaW4sICZzaXplKTsNCg0KCXByaW50ZigiZmQg cmV0dXJuZWQgYnkgb3BlbigvZGV2L251bGwpID0gJWRcbiIsDQoJICAgb3Bl bigiL2Rldi9udWxsIiwgT19SRE9OTFkpKTsNCg0KCXJldHVybiAoMCk7DQp9 DQo= --0-840199968-1086640701=:88690-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 20:51:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF1B116A4CE for ; Mon, 7 Jun 2004 20:51:28 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 018C743D58 for ; Mon, 7 Jun 2004 20:51:28 +0000 (GMT) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i57KpPvw023787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jun 2004 00:51:25 +0400 (MSD) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i57KpO8Q023786; Tue, 8 Jun 2004 00:51:25 +0400 (MSD) Date: Tue, 8 Jun 2004 00:51:24 +0400 From: Gleb Smirnoff To: Maxim Konovalov Message-ID: <20040607205124.GB23669@cell.sick.ru> References: <20040530100739.GA58477@cell.sick.ru> <20040607224538.L2382@mp3files.int.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040607224538.L2382@mp3files.int.ru> User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org Subject: Re: incorrect connect() behavior X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 20:51:28 -0000 On Mon, Jun 07, 2004 at 11:02:40PM +0400, Maxim Konovalov wrote: M> Any comments? I'm agree. I prefer POSIX behavior, too. It should not break any cross-OS contributed software, or software from ports, because it expects ENETUNREACH (e.g. ntpd does not breaks). It may break only BSD specific applications, and if it does we have to fix them. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 20:52:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71C6816A4D0 for ; Mon, 7 Jun 2004 20:52:47 +0000 (GMT) Received: from gamera.svk.isite.net (mail.isite.net [205.217.158.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5951543D5E for ; Mon, 7 Jun 2004 20:52:47 +0000 (GMT) (envelope-from jrhett@isite.net) Received: from anubis.svk.isite.net (anubis.svk.isite.net [205.217.158.5]) by gamera.svk.isite.net (8.12.10/8.12.9) with ESMTP id i57Kqjqa003839 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 7 Jun 2004 13:52:45 -0700 (PDT) Received: from anubis.svk.isite.net (localhost [127.0.0.1]) i57KqjZ8026789; Mon, 7 Jun 2004 13:52:45 -0700 (PDT) Received: (from jrhett@localhost)i57KqiNp026788; Mon, 7 Jun 2004 13:52:44 -0700 (PDT) Date: Mon, 7 Jun 2004 13:52:44 -0700 From: Joe Rhett To: freebsd-current@davehart.net Message-ID: <20040607205244.GD22403@isite.net> Mail-Followup-To: freebsd-current@davehart.net, freebsd-current@freebsd.org References: <255A839665EA24408EB27A6AAE15518E27AB98@europa.ad.hartbrothers.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <255A839665EA24408EB27A6AAE15518E27AB98@europa.ad.hartbrothers.com> User-Agent: Mutt/1.4.2i Organization: Isite Services, Inc. cc: freebsd-current@freebsd.org Subject: Re: Project Evil APs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 20:52:47 -0000 On Sun, May 30, 2004 at 12:19:52PM -0000, freebsd-current@davehart.net wrote: > Bill Paul suggested: > > > > You want to use ad-hoc mode. You don't want to bother me with > > silly questions about hostap mode because it doesn't really > > let you do anything you can't do with ad-hoc mode anyway. > > You haven't really experienced 802.11 wireless joy until you've survived an AP > firmware upgrade reboot because you have multiple overlapping APs servicing > the same WLAN and seamless roaming between them. Can one roam uninterrupted > between different APs in an ad-hoc configuration? There is no AP in ad-hoc mode. It's point to point. So nothing can help you if the other side reboots. -- Joe Rhett Chief Geek JRhett@Isite.Net Isite Services, Inc. From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 20:58:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id C585616A4CE; Mon, 7 Jun 2004 20:58:28 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.12.11/8.12.11) with ESMTP id i57KwS0V021444; Mon, 7 Jun 2004 16:58:28 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.12.11/8.12.11/Submit) id i57KwRe3021443; Mon, 7 Jun 2004 16:58:27 -0400 (EDT) (envelope-from green) Date: Mon, 7 Jun 2004 16:58:27 -0400 From: Brian Feldman To: Gleb Smirnoff Message-ID: <20040607205827.GD20308@green.homeunix.org> References: <20040607160206.G854@pukruppa.net> <20040607172132.GA22717@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040607172132.GA22717@cell.sick.ru> User-Agent: Mutt/1.5.6i cc: Julian Elischer cc: Peter Ulrich Kruppa cc: FreeBSD current users cc: Bosko Milekic cc: net@FreeBSD.org Subject: Re: HEADSUP! netgraph Metadata changing. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 20:58:29 -0000 On Mon, Jun 07, 2004 at 09:21:32PM +0400, Gleb Smirnoff wrote: > On Mon, Jun 07, 2004 at 04:11:47PM +0200, Peter Ulrich Kruppa wrote: > P> Sorry for topposting, but I don't know if this has got something > P> to do with your changes: > P> I am trying to rebuild my -CURRENT system now for some days and > P> keep receiving panic messages from ng_ppoe > P> like this > P> > P> panic NG_MKMESSAGE() with how=M_DONTWAIT(1) > P> at line 913 in file /usr/src/sys/netgraph/ng_pppoe.c > P> ... > P> > P> netgraph/pppoe is used by ppp to connect to my ISP . > P> My last working kernel was built on May 31 . > P> > P> Thanks, if you know how to repair this. > > Seems like you problem is caused (indirectly) by mbuma import. See > > http://lists.freebsd.org/pipermail/freebsd-current/2004-June/028153.html > > Perhaps Bosko has more comments. Please try removing both KASSERT() calls from NG_MKMESSAGE() in src/sys/sys/ng_message.h, and then rebuild (and unload and reload) all netgraph modules. The KASSERT() lines appear to be entirely bogus now. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 21:07:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7460816A4DB for ; Mon, 7 Jun 2004 21:07:46 +0000 (GMT) Received: from email07.aon.at (WARSL402PIP8.highway.telekom.at [195.3.96.97]) by mx1.FreeBSD.org (Postfix) with SMTP id CD65943D49 for ; Mon, 7 Jun 2004 21:07:45 +0000 (GMT) (envelope-from shoesoft@gmx.net) Received: (qmail 306920 invoked from network); 7 Jun 2004 21:05:52 -0000 Received: from n755p013.dipool.highway.telekom.at (HELO ?212.183.104.77?) ([212.183.104.77]) (envelope-sender ) by 172.18.5.236 (qmail-ldap-1.03) with SMTP for ; 7 Jun 2004 21:05:52 -0000 From: Stefan Ehmann To: Robert Watson In-Reply-To: References: Content-Type: text/plain Message-Id: <1086642350.827.1.camel@taxman> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 07 Jun 2004 23:05:51 +0200 Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: file descripter leak in current with Qmail? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 21:07:46 -0000 On Mon, 2004-06-07 at 22:38, Robert Watson wrote: > On Mon, 7 Jun 2004, Arjan van Leeuwen wrote: > > I get a panic (address not allocated) when using the patch. I can't > > write down any useful details about it right now, because although the > > server has only 3 users, they're very disconcerned when I disrupt their > > internet traffic :). > > Doh. Sorry about that. Revised patch attached. I'm able to test the > leak with the attached C file, and on my test box (now that it doesn't > panic), the leak appears fixed for non-blocking accepts. Thanks, that fixed it here too. From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 21:10:04 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93AE316A5A3; Mon, 7 Jun 2004 21:10:04 +0000 (GMT) Received: from fep01-mail.bloor.is.net.cable.rogers.com (fep01-mail.bloor.is.net.cable.rogers.com [66.185.86.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF17143D46; Mon, 7 Jun 2004 21:10:03 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from [192.168.0.1] ([69.193.41.53]) by fep01-mail.bloor.is.net.cable.rogers.comESMTP <20040607210944.GDFT3107.fep01-mail.bloor.is.net.cable.rogers.com@[192.168.0.1]>; Mon, 7 Jun 2004 17:09:44 -0400 Received: from 192.168.0.200 (SquirrelMail authenticated user mikej); by 192.168.0.1 with HTTP; Mon, 7 Jun 2004 17:10:01 -0400 (EDT) Message-ID: <1962.192.168.0.200.1086642601.squirrel@192.168.0.200> Date: Mon, 7 Jun 2004 17:10:01 -0400 (EDT) From: "Mike Jakubik" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep01-mail.bloor.is.net.cable.rogers.com from [69.193.41.53] using ID at Mon, 7 Jun 2004 17:09:44 -0400 cc: x11@freebsd.org Subject: XFree86 4.4? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 21:10:04 -0000 Hello, I was curious if anyone is working on porting XFree86 4.4 to FreeBSD. It would be nice to have the extra graphics chip support, specially for 5.3. Thanks. From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 21:19:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0265B16A4CE for ; Mon, 7 Jun 2004 21:19:08 +0000 (GMT) Received: from zeus.nfy.ca (zeus.nfy.ca [204.244.63.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43BF643D1D for ; Mon, 7 Jun 2004 21:19:07 +0000 (GMT) (envelope-from mayo@mayo.sk) Received: from [209.87.56.128] (unknown [209.87.56.128]) by zeus.nfy.ca (Postfix) with ESMTP id BE1CB20B2CC; Mon, 7 Jun 2004 14:19:06 -0700 (PDT) In-Reply-To: <1962.192.168.0.200.1086642601.squirrel@192.168.0.200> References: <1962.192.168.0.200.1086642601.squirrel@192.168.0.200> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-961758882" Message-Id: <4BCF8FCC-B8C8-11D8-A192-000A9597E310@mayo.sk> Content-Transfer-Encoding: 7bit From: Mayo Date: Mon, 7 Jun 2004 14:19:01 -0700 To: freebsd-current@freebsd.org X-Pgp-Agent: GPGMail 1.0.1 (v33, 10.3) X-Mailer: Apple Mail (2.618) cc: Mike Jakubik Subject: Re: XFree86 4.4? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 21:19:08 -0000 --Apple-Mail-1-961758882 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed I found the xorg server and libs work very well (I just pkg_delete the XFree ones, isntalled xorg ones, and fixed dependencies). No problems so far. xorg-clients is the last one to get going, but there are some compile errors in there (http://www.freebsd.org/cgi/query-pr.cgi?pr=67649). I'm currently using the XFree clients that I had installed from before (from Xfree 4.3). mayo On Jun 7, 2004, at 14:10, Mike Jakubik wrote: > Hello, > > I was curious if anyone is working on porting XFree86 4.4 to FreeBSD. > It > would be nice to have the extra graphics chip support, specially for > 5.3. > > Thanks. > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" --Apple-Mail-1-961758882 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFAxNvL3IqYlN3K/uYRAmx2AKDjLM5FdoF0g1eObL5Md9ABAtb9XgCcDL6f sjMX8ItvmZpLzGWfO0rlrdI= =GiuF -----END PGP SIGNATURE----- --Apple-Mail-1-961758882-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 21:23:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA2D116A4CE for ; Mon, 7 Jun 2004 21:23:09 +0000 (GMT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16D4F43D58 for ; Mon, 7 Jun 2004 21:23:05 +0000 (GMT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc13) with ESMTP id <2004060721230001500moocde>; Mon, 7 Jun 2004 21:23:01 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA29362; Mon, 7 Jun 2004 14:23:00 -0700 (PDT) Date: Mon, 7 Jun 2004 14:22:58 -0700 (PDT) From: Julian Elischer To: Marcel Moolenaar In-Reply-To: <20040607194237.GA10406@ns1.xcllnt.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 21:23:09 -0000 On Mon, 7 Jun 2004, Marcel Moolenaar wrote: > On Mon, Jun 07, 2004 at 05:22:35PM +0100, Doug Rabson wrote: > > > > > > > > Actually its a bit better than that. It works for most use cases right > > > > now on i386 but would get confused on dlclose. I'll fix that before I > > > > move it into current. > > > > > > Does it work on static bound executables? > > > > Which one is static bound > > The executable; you know, no rtld. What I call complete executable to > distinguish it from static TLS on my page. Does static TLS work? > > See also: http://wiki.daemon.li/index.pl?ThreadLocalStorage good move > > -- > Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 21:29:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61DD016A4CE for ; Mon, 7 Jun 2004 21:29:24 +0000 (GMT) Received: from cmsrelay02.mx.net (cmsrelay02.mx.net [165.212.11.111]) by mx1.FreeBSD.org (Postfix) with SMTP id E3B5743D55 for ; Mon, 7 Jun 2004 21:29:19 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: from uadvg131.cms.usa.net (165.212.11.131) by cmsoutbound.mx.net with SMTP; 7 Jun 2004 21:29:19 -0000 Received: from optimator.noacks.org [70.240.196.83] by uadvg131.cms.usa.net (ASMTP/noackjr@usa.net) via mtad (C8.MAIN.3.13N) with ESMTP id 788iFgVdP0127M31; Mon, 07 Jun 2004 21:29:15 GMT X-USANET-Auth: 70.240.196.83 AUTH noackjr@usa.net optimator.noacks.org Received: from localhost (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id 9436C6134; Mon, 7 Jun 2004 16:29:14 -0500 (CDT) Received: from optimator.noacks.org ([127.0.0.1]) by localhost (optimator.noacks.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03354-06; Mon, 7 Jun 2004 16:29:13 -0500 (CDT) Received: from compgeek.noacks.org (compgeek [192.168.1.10]) by optimator.noacks.org (Postfix) with ESMTP id F135B6111; Mon, 7 Jun 2004 16:29:12 -0500 (CDT) Received: from [127.0.0.1] (localhost.noacks.org [127.0.0.1]) by compgeek.noacks.org (8.12.11/8.12.11) with ESMTP id i57LTCtS000787; Mon, 7 Jun 2004 16:29:12 -0500 (CDT) (envelope-from noackjr@alumni.rice.edu) Message-ID: <40C4DE28.1000401@alumni.rice.edu> Date: Mon, 07 Jun 2004 16:29:12 -0500 From: Jon Noack User-Agent: Mozilla Thunderbird 0.6 (X11/20040531) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Jakubik References: <1962.192.168.0.200.1086642601.squirrel@192.168.0.200> In-Reply-To: <1962.192.168.0.200.1086642601.squirrel@192.168.0.200> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at noacks.org cc: freebsd-current@freebsd.org cc: x11@freebsd.org Subject: Re: XFree86 4.4? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: noackjr@alumni.rice.edu List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 21:29:24 -0000 On 06/07/04 16:10, Mike Jakubik wrote: > I was curious if anyone is working on porting XFree86 4.4 to FreeBSD. It > would be nice to have the extra graphics chip support, specially for 5.3. Please don't cross post -- I think this is an obvious case where freebsd-x11@ is the place to ask. If you were unable to get an answer there, then you could think about asking elsewhere. Read the archives of the freebsd-x11@ list (http://lists.freebsd.org/pipermail/freebsd-x11/). There has been extensive discussion on this topic. xorg ports are being added while trying not to break XFree86 ports. This is currently being held up by an update to imake; once that is completed XFree86 4.4 should go in and it looks like we should have a full xorg port shortly afterward. The specific message where much of this info was obtained: http://lists.freebsd.org/pipermail/freebsd-x11/2004-June/000406.html Jon Noack From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 21:31:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 665EA16A4CE for ; Mon, 7 Jun 2004 21:31:51 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2622543D41 for ; Mon, 7 Jun 2004 21:31:51 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 27737 invoked from network); 7 Jun 2004 21:31:50 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 7 Jun 2004 21:31:50 -0000 Received: from 10.50.41.233 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i57LVkT0005420; Mon, 7 Jun 2004 17:31:47 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Andreas Moeller Date: Mon, 7 Jun 2004 17:32:33 -0400 User-Agent: KMail/1.6 References: <40BF38B4.6090208@gmx.net> <200406070807.13562.jhb@FreeBSD.org> <40C4CA71.5010800@gmx.net> In-Reply-To: <40C4CA71.5010800@gmx.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406071732.33715.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: current@FreeBSD.org Subject: Re: fxp(4) device timeouts ACPI related? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 21:31:51 -0000 On Monday 07 June 2004 04:05 pm, Andreas Moeller wrote: > >>>>>>The ACPI updates predating last weekend seem to have broken my fxp(4) > >>>>>>card (Intel PRO/100 S, Intel 82550 chip). Without disabling ACPI at > >>>>>> the loader prompt (set hint.acpi.0.disabled=1) I get the consecutive > >>>>>> message of the device timing out and network is unusable. > >>>>>> > >>>>>>Perhaps this is useful information for everybody desiring to > >>>>>> workaround the problem or even some developer to have a closer look > >>>>>> at it. If a more detailed description of my setup is needed, just > >>>>>> let me know. > >>>>> > >>>>>Can you get before and after dmesg's and post a diff? > >>>> > >>>>Of course. diff is attached, the kernel is an unmodified GENERIC. > >>> > >>>Looks like !ACPI gives IRQ 11 to everyone and ACPI gives some devices > >>> IRQ 5 and some IRQ 11. Can you get a dmesg from the older kernel with > >>> ACPI enabled and generate a diff of that dmesg against the current > >>> kernel with ACPI? > >> > >>Attached. I had to get some older sources and build the kernel since I > >>didn't keep an old enough kernel around. The sources used date to May > >>28th, 2:50am (UTC) and network works with ACPI enabled. > >> > >>I'm by no means an expert but I don't see any new insight revealed by > >>the diff between those two dmesgs. > > > > How about a dmesg from a boot -v with the new kernel? > > Find the dmesg aswell as the diff to the old kernel attached. Grr, ok. It's going to require better acpi_pci_link support which is still being worked on. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 21:36:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DB9A16A4CE for ; Mon, 7 Jun 2004 21:36:41 +0000 (GMT) Received: from winston.piwebs.com (217-19-20-178.dsl.cambrium.nl [217.19.20.178]) by mx1.FreeBSD.org (Postfix) with SMTP id 9AB2D43D4C for ; Mon, 7 Jun 2004 21:36:40 +0000 (GMT) (envelope-from avleeuwen@piwebs.com) Received: (qmail 828 invoked from network); 7 Jun 2004 21:36:38 -0000 Received: from vincent.piwebs.com (192.168.0.84) by winston.piwebs.com with SMTP; 7 Jun 2004 21:36:38 -0000 From: Arjan van Leeuwen To: Robert Watson Date: Mon, 7 Jun 2004 23:36:39 +0200 User-Agent: KMail/1.6.2 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_q/NxAVpj2Vo26Kq"; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200406072336.42196.avleeuwen@piwebs.com> cc: freebsd-current@freebsd.org cc: "David A. Benfell" Subject: Re: file descripter leak in current with Qmail? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: avleeuwen@piwebs.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 21:36:41 -0000 --Boundary-02=_q/NxAVpj2Vo26Kq Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Monday 07 June 2004 22:38, Robert Watson wrote: > On Mon, 7 Jun 2004, Arjan van Leeuwen wrote: > > On Monday 07 June 2004 21:42, you wrote: > > > On Mon, 7 Jun 2004, Arjan van Leeuwen wrote: > > > > > > In terms of debugging it: your first task it to identify if > > > > > > there's one process that's holding all the fd's, or if it is > > > > > > distributed over many proceses. After that, you want to track > > > > > > down what kind of fd is being left open, which may help you track > > > > > > down why it's left open... > > > > > > > > > > Just as I'm reading this, I'm seeing the same thing on my -CURRENT > > > > > server, which has a _very_ low load (atm, it's only routing the > > > > > internet traffic for 3 users and serving SMTP for 2 of them). I'm > > > > > also running qmail. The kernel is from June 6. How do I go about > > > > > investigating this further? > > > > > > > > Replying to myself - > > > > fstat shows all open files evenly distributed among the running > > > > processes. > > > > > > It could be that this is related to the esd file descriptor leak > > > problem also being reported. You might also try the attached patch. > > > > I get a panic (address not allocated) when using the patch. I can't > > write down any useful details about it right now, because although the > > server has only 3 users, they're very disconcerned when I disrupt their > > internet traffic :). > > Doh. Sorry about that. Revised patch attached. I'm able to test the > leak with the attached C file, and on my test box (now that it doesn't > panic), the leak appears fixed for non-blocking accepts. No problem, this patch works like a charm. Thanks! Arjan > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Senior Research Scientist, McAfee Research > > Index: uipc_syscalls.c > =================================================================== > RCS file: /data/ncvs/src/sys/kern/uipc_syscalls.c,v > retrieving revision 1.187 > diff -u -r1.187 uipc_syscalls.c > --- uipc_syscalls.c 7 Jun 2004 09:59:50 -0000 1.187 > +++ uipc_syscalls.c 7 Jun 2004 20:21:30 -0000 > @@ -253,7 +253,7 @@ > { > struct filedesc *fdp; > struct file *nfp = NULL; > - struct sockaddr *sa; > + struct sockaddr *sa = NULL; > socklen_t namelen; > int error; > struct socket *head, *so; > @@ -285,7 +285,7 @@ > if ((head->so_state & SS_NBIO) && TAILQ_EMPTY(&head->so_comp)) { > ACCEPT_UNLOCK(); > error = EWOULDBLOCK; > - goto done; > + goto noconnection; > } > while (TAILQ_EMPTY(&head->so_comp) && head->so_error == 0) { > if (head->so_state & SS_CANTRCVMORE) { > @@ -296,14 +296,14 @@ > "accept", 0); > if (error) { > ACCEPT_UNLOCK(); > - goto done; > + goto noconnection; > } > } > if (head->so_error) { > error = head->so_error; > head->so_error = 0; > ACCEPT_UNLOCK(); > - goto done; > + goto noconnection; > } > so = TAILQ_FIRST(&head->so_comp); > KASSERT(!(so->so_qstate & SQ_INCOMP), ("accept1: so SQ_INCOMP")); > > > > !DSPAM:40c4d2d111291897510869! --Boundary-02=_q/NxAVpj2Vo26Kq Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAxN/q3Ym57eNCXiERAugaAJ9/7S+U+VknATFRaCRBaaSdcMJWwQCeJXaH Kef5mH/bJuHrmrc6nrf2rxE= =/P6F -----END PGP SIGNATURE----- --Boundary-02=_q/NxAVpj2Vo26Kq-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 21:42:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BB7B16A4CE for ; Mon, 7 Jun 2004 21:42:24 +0000 (GMT) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F9E143D4C for ; Mon, 7 Jun 2004 21:42:21 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from ns0.nlsystems.com (ns0.nlsystems.com [80.177.232.243]) by itchy.rabson.org (8.12.11/8.12.11) with ESMTP id i57Lbq9n001938; Mon, 7 Jun 2004 22:37:52 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Marcel Moolenaar Date: Mon, 7 Jun 2004 22:42:13 +0100 User-Agent: KMail/1.6.1 References: <1086625355.10911.39.camel@builder02.qubesoft.com> <20040607194237.GA10406@ns1.xcllnt.net> In-Reply-To: <20040607194237.GA10406@ns1.xcllnt.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406072242.13393.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on itchy.rabson.org X-Virus-Scanned: clamd / ClamAV version 0.71, clamav-milter version 0.71 X-Virus-Status: Clean cc: freebsd-current@freebsd.org Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 21:42:24 -0000 On Monday 07 June 2004 20:42, Marcel Moolenaar wrote: > On Mon, Jun 07, 2004 at 05:22:35PM +0100, Doug Rabson wrote: > > > > Actually its a bit better than that. It works for most use > > > > cases right now on i386 but would get confused on dlclose. I'll > > > > fix that before I move it into current. > > > > > > Does it work on static bound executables? > > > > Which one is static bound > > The executable; you know, no rtld. What I call complete executable to > distinguish it from static TLS on my page. Does static TLS work? > > See also: http://wiki.daemon.li/index.pl?ThreadLocalStorage No, this one is not yet supported. I think I can deal with this inside libc with some small support from the kernel (probably just to provide details of the TLS segment size etc.) From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 21:45:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA6A116A4CE; Mon, 7 Jun 2004 21:45:21 +0000 (GMT) Received: from crumpet.united-ware.com (ddsl-66-42-172-210.fuse.net [66.42.172.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id D085D43D4C; Mon, 7 Jun 2004 21:45:20 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.0.6] (ppp-67-38-164-15.dsl.wotnoh.ameritech.net [67.38.164.15]) (authenticated bits=0)i57LcKQr042367 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 7 Jun 2004 17:38:56 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: freebsd-current@freebsd.org Date: Mon, 7 Jun 2004 17:45:02 -0400 User-Agent: KMail/1.6.2 References: <40BF38B4.6090208@gmx.net> <40C4CA71.5010800@gmx.net> <200406071732.33715.jhb@FreeBSD.org> In-Reply-To: <200406071732.33715.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200406071745.04697.mistry.7@osu.edu> X-Spam-Status: No, hits=-3.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE, QUOTED_EMAIL_TEXT,RCVD_IN_NJABL,RCVD_IN_ORBS,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_KMAIL,X_NJABL_DIALUP version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Subject: Re: fxp(4) device timeouts ACPI related? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 21:45:21 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 07 June 2004 05:32 pm, John Baldwin wrote: > On Monday 07 June 2004 04:05 pm, Andreas Moeller wrote: > > >>>>>>The ACPI updates predating last weekend seem to have broken my > > >>>>>> fxp(4) card (Intel PRO/100 S, Intel 82550 chip). Without disabli= ng > > >>>>>> ACPI at the loader prompt (set hint.acpi.0.disabled=3D1) I get t= he > > >>>>>> consecutive message of the device timing out and network is > > >>>>>> unusable. > > >>>>>> > > >>>>>>Perhaps this is useful information for everybody desiring to > > >>>>>> workaround the problem or even some developer to have a closer > > >>>>>> look at it. If a more detailed description of my setup is needed, > > >>>>>> just let me know. > > >>>>> > > >>>>>Can you get before and after dmesg's and post a diff? > > >>>> > > >>>>Of course. diff is attached, the kernel is an unmodified GENERIC. > > >>> > > >>>Looks like !ACPI gives IRQ 11 to everyone and ACPI gives some devices > > >>> IRQ 5 and some IRQ 11. Can you get a dmesg from the older kernel > > >>> with ACPI enabled and generate a diff of that dmesg against the > > >>> current kernel with ACPI? > > >> > > >>Attached. I had to get some older sources and build the kernel since I > > >>didn't keep an old enough kernel around. The sources used date to May > > >>28th, 2:50am (UTC) and network works with ACPI enabled. > > >> > > >>I'm by no means an expert but I don't see any new insight revealed by > > >>the diff between those two dmesgs. > > > > > > How about a dmesg from a boot -v with the new kernel? > > > > Find the dmesg aswell as the diff to the old kernel attached. > > Grr, ok. It's going to require better acpi_pci_link support which is sti= ll > being worked on. I'm getting this too: rl0: watchdog timeout Would another dmesg be useful? =2D --=20 Anish Mistry =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAxOHexqA5ziudZT0RAoCnAJ0dHrIXHHSk0UQS1tDed3mz4uFu5wCbBOel Xi6F/t5GfnML0JbnvQhCb1U=3D =3DFiqu =2D----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 21:47:02 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0364116A4D1; Mon, 7 Jun 2004 21:47:02 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37CF743D1D; Mon, 7 Jun 2004 21:47:01 +0000 (GMT) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i57LkRvw024407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jun 2004 01:46:28 +0400 (MSD) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i57LkRYo024406; Tue, 8 Jun 2004 01:46:27 +0400 (MSD) Date: Tue, 8 Jun 2004 01:46:27 +0400 From: Gleb Smirnoff To: Brian Feldman , Julian Elischer Message-ID: <20040607214627.GA24142@cell.sick.ru> References: <20040607160206.G854@pukruppa.net> <20040607172132.GA22717@cell.sick.ru> <20040607205827.GD20308@green.homeunix.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ZPt4rx8FFjLCG7dd" Content-Disposition: inline In-Reply-To: <20040607205827.GD20308@green.homeunix.org> User-Agent: Mutt/1.5.6i cc: Peter Ulrich Kruppa cc: FreeBSD current users cc: Bosko Milekic cc: net@FreeBSD.org Subject: check for M_DONTWAIT in NG_MKMESSAGE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 21:47:02 -0000 --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=koi8-r Content-Disposition: inline On Mon, Jun 07, 2004 at 04:58:27PM -0400, Brian Feldman wrote: B> > Seems like you problem is caused (indirectly) by mbuma import. See B> > B> > http://lists.freebsd.org/pipermail/freebsd-current/2004-June/028153.html B> > B> > Perhaps Bosko has more comments. B> B> Please try removing both KASSERT() calls from NG_MKMESSAGE() in B> src/sys/sys/ng_message.h, and then rebuild (and unload and reload) B> all netgraph modules. The KASSERT() lines appear to be entirely B> bogus now. Agreed. After mbuma import the first KASSERT() definitely must be removed. Julian, take a look at this. It must be fixed ASAP. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="ng_message.h.diff" Index: ng_message.h =================================================================== RCS file: /home/ncvs/src/sys/netgraph/ng_message.h,v retrieving revision 1.22 diff -u -r1.22 ng_message.h --- ng_message.h 26 Jan 2004 14:05:31 -0000 1.22 +++ ng_message.h 7 Jun 2004 21:45:06 -0000 @@ -371,8 +371,6 @@ */ #define NG_MKMESSAGE(msg, cookie, cmdid, len, how) \ do { \ - KASSERT(!(how & M_DONTWAIT), \ - ("NG_MKMESSAGE() with how=M_DONTWAIT (%d)\n", how)); \ KASSERT(!(how & M_TRYWAIT), \ ("NG_MKMESSAGE() with how=M_TRYWAIT (%d)\n", how)); \ MALLOC((msg), struct ng_mesg *, sizeof(struct ng_mesg) \ --ZPt4rx8FFjLCG7dd-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 21:51:40 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE53216A4CE; Mon, 7 Jun 2004 21:51:40 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AC8E43D1F; Mon, 7 Jun 2004 21:51:40 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i57Lohhc037919; Mon, 7 Jun 2004 17:50:43 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i57Lohph037916; Mon, 7 Jun 2004 17:50:43 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 7 Jun 2004 17:50:43 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Stefan Ehmann , Arjan van Leeuwen In-Reply-To: <1086642350.827.1.camel@taxman> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: file descripter leak in current with Qmail? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 21:51:40 -0000 On Mon, 7 Jun 2004, Stefan Ehmann wrote: > On Mon, 2004-06-07 at 22:38, Robert Watson wrote: > > On Mon, 7 Jun 2004, Arjan van Leeuwen wrote: > > > I get a panic (address not allocated) when using the patch. I can't > > > write down any useful details about it right now, because although the > > > server has only 3 users, they're very disconcerned when I disrupt their > > > internet traffic :). > > > > Doh. Sorry about that. Revised patch attached. I'm able to test the > > leak with the attached C file, and on my test box (now that it doesn't > > panic), the leak appears fixed for non-blocking accepts. > > Thanks, that fixed it here too. Ok, I've gone ahead and merged the fix. Thanks for the bug report, and thanks to Brian for the pointer at the accept() change. The reason I became involved in the thread in the first place was that I was worried it might be something like this, and indeed, it was. Let me know if you have any further problems of this sort. There will probably be some more nits like this as more locking is merged -- hence merging it in small functional changes in as much as is possible, allowing each change to shake out some before the next batch. Thanks! Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 21:57:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD3A616A4CE; Mon, 7 Jun 2004 21:57:33 +0000 (GMT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9900B43D31; Mon, 7 Jun 2004 21:57:33 +0000 (GMT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc13) with ESMTP id <2004060721572901500mn9r8e>; Mon, 7 Jun 2004 21:57:31 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA30085; Mon, 7 Jun 2004 14:57:30 -0700 (PDT) Date: Mon, 7 Jun 2004 14:57:29 -0700 (PDT) From: Julian Elischer To: Gleb Smirnoff In-Reply-To: <20040607214627.GA24142@cell.sick.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Brian Feldman cc: Peter Ulrich Kruppa cc: FreeBSD current users cc: Bosko Milekic cc: net@FreeBSD.org Subject: Re: check for M_DONTWAIT in NG_MKMESSAGE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 21:57:33 -0000 On Tue, 8 Jun 2004, Gleb Smirnoff wrote: > On Mon, Jun 07, 2004 at 04:58:27PM -0400, Brian Feldman wrote: > B> > Seems like you problem is caused (indirectly) by mbuma import. See > B> > > B> > http://lists.freebsd.org/pipermail/freebsd-current/2004-June/028153.html > B> > > B> > Perhaps Bosko has more comments. > B> > B> Please try removing both KASSERT() calls from NG_MKMESSAGE() in > B> src/sys/sys/ng_message.h, and then rebuild (and unload and reload) > B> all netgraph modules. The KASSERT() lines appear to be entirely > B> bogus now. > > Agreed. After mbuma import the first KASSERT() definitely must be removed. > Julian, take a look at this. It must be fixed ASAP. Messages never were done by mbuf so it's a bit puzzling what mbuma has to do with it.. however, removing the KASSERT seems appropriate. > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE > From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 22:12:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAA0616A4CE; Mon, 7 Jun 2004 22:12:24 +0000 (GMT) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5735643D2D; Mon, 7 Jun 2004 22:12:24 +0000 (GMT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc13) with ESMTP id <20040607221215016000kcjce>; Mon, 7 Jun 2004 22:12:21 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA30273; Mon, 7 Jun 2004 15:12:16 -0700 (PDT) Date: Mon, 7 Jun 2004 15:12:15 -0700 (PDT) From: Julian Elischer To: Gleb Smirnoff In-Reply-To: <20040607214627.GA24142@cell.sick.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Brian Feldman cc: Peter Ulrich Kruppa cc: FreeBSD current users cc: Bosko Milekic cc: net@FreeBSD.org Subject: Re: check for M_DONTWAIT in NG_MKMESSAGE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 22:12:24 -0000 On Tue, 8 Jun 2004, Gleb Smirnoff wrote: > On Mon, Jun 07, 2004 at 04:58:27PM -0400, Brian Feldman wrote: > B> > Seems like you problem is caused (indirectly) by mbuma import. See > B> > > B> > http://lists.freebsd.org/pipermail/freebsd-current/2004-June/028153.html > B> > > B> > Perhaps Bosko has more comments. > B> > B> Please try removing both KASSERT() calls from NG_MKMESSAGE() in > B> src/sys/sys/ng_message.h, and then rebuild (and unload and reload) > B> all netgraph modules. The KASSERT() lines appear to be entirely > B> bogus now. > > Agreed. After mbuma import the first KASSERT() definitely must be removed. > Julian, take a look at this. It must be fixed ASAP. committed.. removed both KASSERTS > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE > From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 22:55:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74A6B16A4CE for ; Mon, 7 Jun 2004 22:55:00 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 214DA43D54 for ; Mon, 7 Jun 2004 22:55:00 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i57Msr4N012366 for ; Mon, 7 Jun 2004 15:54:57 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200406072254.i57Msr4N012366@gw.catspoiler.org> Date: Mon, 7 Jun 2004 15:54:53 -0700 (PDT) From: Don Lewis To: current@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Subject: hang after "Shutting down ACPI" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 22:55:00 -0000 I just upgraded my Thinkpad R40 to a few hour old version of -CURRENT from something a few weeks older. Now when I reboot, the machine hangs after printing "Shutting down ACPI" and I have to resort to the power button. In an interesting twist, "shutdown -p" works properly. From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 23:10:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2328616A4D0 for ; Mon, 7 Jun 2004 23:10:21 +0000 (GMT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27BFC43D64 for ; Mon, 7 Jun 2004 23:10:13 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (localhost [127.0.0.1]) by ns1.xcllnt.net (8.12.11/8.12.11) with ESMTP id i57NACM4011392; Mon, 7 Jun 2004 16:10:12 -0700 (PDT) (envelope-from marcel@ns1.xcllnt.net) Received: (from marcel@localhost) by ns1.xcllnt.net (8.12.11/8.12.11/Submit) id i57NACkK011391; Mon, 7 Jun 2004 16:10:12 -0700 (PDT) (envelope-from marcel) Date: Mon, 7 Jun 2004 16:10:12 -0700 From: Marcel Moolenaar To: Doug Rabson Message-ID: <20040607231012.GB11313@ns1.xcllnt.net> References: <1086625355.10911.39.camel@builder02.qubesoft.com> <20040607194237.GA10406@ns1.xcllnt.net> <200406072242.13393.dfr@nlsystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406072242.13393.dfr@nlsystems.com> User-Agent: Mutt/1.5.5.1i cc: freebsd-current@freebsd.org Subject: Re: HEADS UP! KSE needs more attention X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 23:10:21 -0000 On Mon, Jun 07, 2004 at 10:42:13PM +0100, Doug Rabson wrote: > On Monday 07 June 2004 20:42, Marcel Moolenaar wrote: > > On Mon, Jun 07, 2004 at 05:22:35PM +0100, Doug Rabson wrote: > > > > > Actually its a bit better than that. It works for most use > > > > > cases right now on i386 but would get confused on dlclose. I'll > > > > > fix that before I move it into current. > > > > > > > > Does it work on static bound executables? > > > > > > Which one is static bound > > > > The executable; you know, no rtld. What I call complete executable to > > distinguish it from static TLS on my page. Does static TLS work? > > > > See also: http://wiki.daemon.li/index.pl?ThreadLocalStorage > > No, this one is not yet supported. I think I can deal with this inside > libc with some small support from the kernel (probably just to provide > details of the TLS segment size etc.) Ok, thanks. BTW, I was thinking along the same lines, although it looks from your description that I probably wanted to put more of the meat in the kernel to avoid making the startup code complex and possibly pessimizing non-TLS processes. Anyway: From my PoV, static TLS is not critical enough to force it in 5.3, but it is important enough to have soon after that. FYI, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Tue Jun 8 01:50:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B77A16A4CE for ; Tue, 8 Jun 2004 01:50:09 +0000 (GMT) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.145.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4635E43D4C for ; Tue, 8 Jun 2004 01:50:09 +0000 (GMT) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id 3FC9B4EFCD8; Tue, 8 Jun 2004 09:50:08 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 3539C4EFCD7; Tue, 8 Jun 2004 09:50:08 +0800 (CST) Date: Tue, 8 Jun 2004 09:50:08 +0800 (CST) From: Tai-hwa Liang To: Jeffrey Katcher In-Reply-To: <20040606181203.45983.qmail@web41111.mail.yahoo.com> Message-ID: <0406080934431.98630@www.mmlab.cse.yzu.edu.tw> References: <20040606181203.45983.qmail@web41111.mail.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@FreeBSD.org Subject: Re: Atheros support no longer works on -CURRENT (kldload, possibly ACPI?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 01:50:09 -0000 On Sun, 6 Jun 2004, Jeffrey Katcher wrote: > Hardware: IBM Thinkpad T40, IBM Atheros A/B card > Software: -CURRENT as of 6/5/04, but older 5/25 kernel still shows problem My T40 with IBM Atheros A/B/G miniPCI works well with 5/25 kernel. However, I have to backout sys/dev/acpica/acpi_cpu.c to 1.38 and sys/dev/acpica/acpi_pci_link.c to 1.14 such that it would not lockup at booting after sio0 probing. > > Symptoms: I don't use it very frequently, so I kldload if_ath as necessary. > Previously, it was load, config, and go, now... > > I see: > pci0: Failed to set ACPI power state D3 on (null): AE_BAD_PARAMETER > before the usual (and correct) ath0 status messages Did you try the latest source committed by njl@(about 3 hours ago)? I can't test it unless backing to home; however, they seemed to be able to eliminate the BAD_PARAMETER error under some circumstances: sys/dev/acpica/acpi_pci.c:1.18 sys/dev/acpica/acpi_powerres.c:1.23 > When I "up" the interface, I see: > ath0: hardware error; resetting > in a continuous parade scrolling up the screen I always put "if_ath_load=YES" in /boot/loader.conf. It works for me since the first time I purchased this card. Perhaps you would like to give it a try. > I tried setting hw.ath.debug, but the dump scrolls off faster than I can see > it. The system has no serial port to capture from... Will those lines captured by syslogd? > This could be an ACPI issue instead, but I don't see anything like this for > the compiled-in set of drivers. The last resort: reboot with ACPI disabled. At least this saved me from troubles(if_em locks up) with recent -CURRENT. From owner-freebsd-current@FreeBSD.ORG Tue Jun 8 02:25:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBB1F16A4CE for ; Tue, 8 Jun 2004 02:25:52 +0000 (GMT) Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11A0B43D31 for ; Tue, 8 Jun 2004 02:25:52 +0000 (GMT) (envelope-from j.e.drews@att.net) Received: from 204.127.135.40 ([204.127.135.40]) by worldnet.att.net (mtiwmhc13) with SMTP id <20040608022545113001or1qe>; Tue, 8 Jun 2004 02:25:45 +0000 Received: from [64.105.56.145] by 204.127.135.40; Tue, 08 Jun 2004 02:25:44 +0000 From: j.e.drews@att.net To: current@freebsd.org Date: Tue, 08 Jun 2004 02:25:44 +0000 Message-Id: <060820040225.26052.40C523A7000B9FD0000065C421602807489C990A9D0BD20AD206@att.net> X-Mailer: AT&T Message Center Version 1 (May 27 2004) X-Authenticated-Sender: ai5lLmRyZXdzQGF0dC5uZXQ= Subject: Re: ACPI Error: [FIXED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 02:25:52 -0000 FreeBSD 5.2-CURRENT #0: Mon Jun 7 19:56:17 CDT 2004 OK Nate and others. This is now fixed. http://www.silbsd.org/bugreports/acpi.dmesg3.txt > On Mon, 7 Jun 2004 j.e.drews@att.net wrote: > > Hi: > > > > When I was shutting down I got this output from tty0: > > evregion-0502: *** Error: Handler for [EmbeddedControl] returned > AE_NO_HARDWARE_ > > RESPONSE > > > > **** Exception AE_NO_HARDWARE_RESPONSE during execution of method > [\_TZ_.THRM._T > > MP] (Node 0xc1a777a8) > > > > Method Execution Stack: > > Method [_TMP] executing: 7 # 70 Store (\_SB.PCI0.LPCB.EC0.CTMP, > Local1) > > It's the same problem. Giant contention. > > -Nate > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Jun 8 02:42:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B569C16A4CE for ; Tue, 8 Jun 2004 02:42:38 +0000 (GMT) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.145.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 800FA43D1D for ; Tue, 8 Jun 2004 02:42:38 +0000 (GMT) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id CF0E34EFCD6; Tue, 8 Jun 2004 10:42:37 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id C66A14EFCD3; Tue, 8 Jun 2004 10:42:37 +0800 (CST) Date: Tue, 8 Jun 2004 10:42:37 +0800 (CST) From: Tai-hwa Liang To: Brian Buchanan In-Reply-To: <20040607082413.U93758-100000@thought.holo.org> Message-ID: <04060810273710.99104@www.mmlab.cse.yzu.edu.tw> References: <20040607082413.U93758-100000@thought.holo.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: T40 panics at usb_get_next_event() when ACPI is disabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 02:42:38 -0000 On Mon, 7 Jun 2004, Brian Buchanan wrote: > Yes, I see this too on my T40p, but only when booting with the mouse > plugged into the laptop through a USB hub connected to the docking > station. If the mouse is plugged in directly to the laptop (I haven't > tried plugging the USB hub directly into the laptop) or not plugged in, The problem always occurs on my T40 when the USB mouse is directly plugged into the laptop. > the problem does not occur. My hypothesis is that because a certain > event list entry is being overwritten, the USB event list only grows long > enough to use this area of memory in this configuration. Interesting hypothesis. What really bothers me is that the extra "if (ueq != NULL)" checks didn't catch the NULL ueq case. According to the backtrace, it crashed at "*ue = ueq->ue," where ueq is NULL at that moment. > I wrote a function to perform a sanity check on the event list and > determined that the list is not corrupt after all the USB boot-time events > have been queued. The list becomes corrupted some time between then and I'm curious about the sanity check function you've written. Would you mind to post it? > when usbd attempts to read the event queue. One of the events, the same > one every time, is overwritten with something like 0x01000010 (I don't > have a log of the actual bit pattern). Since it's happening to the same > object every time, the next step would be to set a watch point in the > debugger. I'll probably give this a try once I have a chance to consult > with someone who knows more about kernel debugging. Did you try to extract the backtrace from the core file? It helps for further analysis: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-gdb.html Or you'd like to use DDB to do the online kernel debugging: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-ddb.html > I did experiment with rolling back some usb commits, but it does not > appear that a change to the usb subsystem is what caused this breakage. I > think something else in the system is misbehaving and overwriting memory. Perhaps, since the enqueuing/dequeuing of usb_event supposed to be protected by splusb(), there shouldn't be race here unless there's something wrong in the interrupt priority(shared with splnet/splnet/splbio?) settings. From owner-freebsd-current@FreeBSD.ORG Tue Jun 8 02:47:05 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB1F016A4D0 for ; Tue, 8 Jun 2004 02:47:05 +0000 (GMT) Received: from lerami.lerctr.org (lerami.lerctr.org [192.147.25.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 841F443D2F for ; Tue, 8 Jun 2004 02:47:05 +0000 (GMT) (envelope-from ler@lerctr.org) Received: from lerami.lerctr.org ([192.147.25.11]) by lerami.lerctr.org with esmtp (Exim 4.34) id 1BXWdk-0003I8-2n for freebsd-current@freebsd.org; Mon, 07 Jun 2004 21:47:04 -0500 Date: Mon, 7 Jun 2004 21:47:03 -0500 (CDT) From: Larry Rosenman To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: RADEON IGP 345m X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 02:47:05 -0000 I know XFree86 4.4.0 supports the ATI RADEON IGP 345M. Have we imported that version to Ports yet? (or am I on the bleeding edge here)? I just replaced my laptop, and this new one has the above chip. The old one had an I845, so I know I need to adjust my config. Any pointers appreciated. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 From owner-freebsd-current@FreeBSD.ORG Tue Jun 8 02:57:42 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D31516A4CE; Tue, 8 Jun 2004 02:57:42 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0164A43D4C; Tue, 8 Jun 2004 02:57:39 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 401CBFD06C; Mon, 7 Jun 2004 19:57:38 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00675-03; Mon, 7 Jun 2004 19:57:36 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 0B19DFD03A; Mon, 7 Jun 2004 19:57:36 -0700 (PDT) From: Sean McNeil To: freebsd-amd64@freebsd.org, freebsd-threads@freebsd.org, freebsd-current@freebsd.org, freebsd-gnome@freebsd.org Content-Type: text/plain Message-Id: <1086663455.1258.79.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 07 Jun 2004 19:57:35 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com Subject: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 02:57:42 -0000 Up front, I'd like to make a few apologies: 1) I am sorry for the length of this email. 2) Although some very valid opinions have been expressed, I respectfully have to disagree. This email will hopefully strengthen my position. The problem: (If you just want kse threads to work for you properly, just apply the patch at the end of this email and try it out). kse threads on amd64 doesn't work with gnome. It crashes applications here and there. gnome-terminal is essentially unusable. I strongly believe this to be a binding issue. I've examined rtld and I'm satisfied that it is behaving appropriately, so I took a long hard look at how FreeBSD has implemented the pthread interface, how it is being used, and how people expect it to behave. FreeBSD pthread interface: I have no idea why, but on FreeBSD all the pthread functions are weak symbols. I have not beed given a very satisfactory answer though I have tried to understand and continue to look for enlightenment. To me, this means that there is no authorative answer to "who is the primary provider" of the weak symbols in libc. It is instead the first occurrence of the weak symbol that takes precedence. This means that if the program itself doesn't link with the pthread library yet some other library uses it then you are pretty much hosed. I've seen just this happen with plenty of gnome applications. It also means that there is an ordering dependency that I'm not sure is reasonable to enforce. Other pthread interfaces: I don't know what Linux does now, but when we first built pthreads for Linux we made the pthread library symbols definitive. They always were the overriding authority. It was modelled after what I saw in Solaris. So, taking select as an example, libc.so - internal select called something else with a weak reference to used symbol. libpthread.so - select essentially provided directly in the library or is a strong reference to an internal version. i.e. libc weak, libpthread strong. This allows for any ordering of libraries during linking. Very good (IMHO) and has other benifits as well - like security. Application issues: As mentioned above, gnome is not very usable as things stand. I had to move to libc_r to get any stability at all. Besides gnome, I have found issues with apache2/php4, wine, and bash with nss_ldap to name a few. Security: Actually, having an authorative provider of core libc functions would be very helpful to eliminating a potential security risk. An application that is linked with libpthread wouldn't be able to dlopen some other library that could potentially take over libc weak functionality. Additionally, some sort of non-threaded library could be created that blocked a program from overriding libc routines with thread versions whenever it was linked directly to the main application. Proof is in the pudding: What can I say? Some people will insist that the gnome applications are broken somehow or that what I'm saying doesn't conform to their view as how the thread libraries should work. I admit I do not fully understand the dogma behind making them all weak symbols, but so far nothing I've heard trumps the fact that doing this makes everything work. Since applying the patch below, my amd64 system has worked flawlessly with gnome and libpthread.so.1. It has not shown any of the problems that have been haunting me since I switched over from running in i386 mode. The patch: A patch to apply in /usr/src/lib/libpthread is included at the end of this email. I haven't bothered doing it for libc_r even though it should be done. Apache2/php4 would have issues, for instance, with libc_r without making the symbols strong references. Anyone else that wants to use gnome right now under amd64 might want to try out this patch. Cheers, Sean diff -c3pr thread.orig/thr_accept.c thread/thr_accept.c *** thread.orig/thr_accept.c Tue Dec 9 15:40:27 2003 --- thread/thr_accept.c Mon Jun 7 17:48:59 2004 *************** __FBSDID("$FreeBSD: src/lib/libpthread/t *** 32,39 **** #include #include "thr_private.h" - __weak_reference(__accept, accept); - int __accept(int s, struct sockaddr *addr, socklen_t *addrlen) { --- 32,37 ---- *************** __accept(int s, struct sockaddr *addr, s *** 47,49 **** --- 45,49 ---- return (ret); } + + __strong_reference(__accept, accept); diff -c3pr thread.orig/thr_aio_suspend.c thread/thr_aio_suspend.c *** thread.orig/thr_aio_suspend.c Mon Dec 8 18:20:56 2003 --- thread/thr_aio_suspend.c Mon Jun 7 17:49:10 2004 *************** *** 33,40 **** #include #include "thr_private.h" - __weak_reference(_aio_suspend, aio_suspend); - int _aio_suspend(const struct aiocb * const iocbs[], int niocb, const struct timespec *timeout) --- 33,38 ---- *************** _aio_suspend(const struct aiocb * const *** 49,51 **** --- 47,50 ---- return (ret); } + __strong_reference(_aio_suspend, aio_suspend); diff -c3pr thread.orig/thr_atfork.c thread/thr_atfork.c *** thread.orig/thr_atfork.c Tue Nov 4 19:42:10 2003 --- thread/thr_atfork.c Mon Jun 7 17:49:21 2004 *************** *** 31,38 **** #include #include "thr_private.h" - __weak_reference(_pthread_atfork, pthread_atfork); - int _pthread_atfork(void (*prepare)(void), void (*parent)(void), void (*child)(void)) --- 31,36 ---- *************** _pthread_atfork(void (*prepare)(void), v *** 54,56 **** --- 52,55 ---- return (0); } + __strong_reference(_pthread_atfork, pthread_atfork); diff -c3pr thread.orig/thr_attr_destroy.c thread/thr_attr_destroy.c *** thread.orig/thr_attr_destroy.c Mon Sep 16 01:45:33 2002 --- thread/thr_attr_destroy.c Mon Jun 7 17:49:31 2004 *************** *** 36,43 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_destroy, pthread_attr_destroy); - int _pthread_attr_destroy(pthread_attr_t *attr) { --- 36,41 ---- *************** _pthread_attr_destroy(pthread_attr_t *at *** 60,62 **** --- 58,62 ---- } return(ret); } + + __strong_reference(_pthread_attr_destroy, pthread_attr_destroy); diff -c3pr thread.orig/thr_attr_get_np.c thread/thr_attr_get_np.c *** thread.orig/thr_attr_get_np.c Sun Jul 6 21:28:23 2003 --- thread/thr_attr_get_np.c Mon Jun 7 17:49:41 2004 *************** *** 31,38 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_get_np, pthread_attr_get_np); - int _pthread_attr_get_np(pthread_t pid, pthread_attr_t *dst) { --- 31,36 ---- *************** _pthread_attr_get_np(pthread_t pid, pthr *** 52,54 **** --- 50,54 ---- return (0); } + + __strong_reference(_pthread_attr_get_np, pthread_attr_get_np); diff -c3pr thread.orig/thr_attr_getdetachstate.c thread/thr_attr_getdetachstate.c *** thread.orig/thr_attr_getdetachstate.c Mon Sep 16 01:45:33 2002 --- thread/thr_attr_getdetachstate.c Mon Jun 7 17:49:50 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_getdetachstate, pthread_attr_getdetachstate); - int _pthread_attr_getdetachstate(const pthread_attr_t *attr, int *detachstate) { --- 35,40 ---- *************** _pthread_attr_getdetachstate(const pthre *** 57,59 **** --- 55,59 ---- } return(ret); } + + __strong_reference(_pthread_attr_getdetachstate, pthread_attr_getdetachstate); diff -c3pr thread.orig/thr_attr_getguardsize.c thread/thr_attr_getguardsize.c *** thread.orig/thr_attr_getguardsize.c Mon Sep 16 01:45:33 2002 --- thread/thr_attr_getguardsize.c Mon Jun 7 17:50:04 2004 *************** *** 33,40 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_getguardsize, pthread_attr_getguardsize); - int _pthread_attr_getguardsize(const pthread_attr_t *attr, size_t *guardsize) { --- 33,38 ---- *************** _pthread_attr_getguardsize(const pthread *** 50,52 **** --- 48,52 ---- } return(ret); } + + __strong_reference(_pthread_attr_getguardsize, pthread_attr_getguardsize); diff -c3pr thread.orig/thr_attr_getinheritsched.c thread/thr_attr_getinheritsched.c *** thread.orig/thr_attr_getinheritsched.c Mon Sep 16 01:45:33 2002 --- thread/thr_attr_getinheritsched.c Mon Jun 7 17:50:13 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_getinheritsched, pthread_attr_getinheritsched); - int _pthread_attr_getinheritsched(const pthread_attr_t *attr, int *sched_inherit) { --- 35,40 ---- *************** _pthread_attr_getinheritsched(const pthr *** 49,51 **** --- 47,51 ---- return(ret); } + + __strong_reference(_pthread_attr_getinheritsched, pthread_attr_getinheritsched); diff -c3pr thread.orig/thr_attr_getschedparam.c thread/thr_attr_getschedparam.c *** thread.orig/thr_attr_getschedparam.c Mon Sep 16 01:45:33 2002 --- thread/thr_attr_getschedparam.c Mon Jun 7 17:50:21 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_getschedparam, pthread_attr_getschedparam); - int _pthread_attr_getschedparam(const pthread_attr_t *attr, struct sched_param *param) { --- 35,40 ---- *************** _pthread_attr_getschedparam(const pthrea *** 49,51 **** --- 47,51 ---- return(ret); } + + __strong_reference(_pthread_attr_getschedparam, pthread_attr_getschedparam); diff -c3pr thread.orig/thr_attr_getschedpolicy.c thread/thr_attr_getschedpolicy.c *** thread.orig/thr_attr_getschedpolicy.c Mon Sep 16 01:45:33 2002 --- thread/thr_attr_getschedpolicy.c Mon Jun 7 17:50:29 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_getschedpolicy, pthread_attr_getschedpolicy); - int _pthread_attr_getschedpolicy(const pthread_attr_t *attr, int *policy) { --- 35,40 ---- *************** _pthread_attr_getschedpolicy(const pthre *** 49,51 **** --- 47,51 ---- return(ret); } + + __strong_reference(_pthread_attr_getschedpolicy, pthread_attr_getschedpolicy); diff -c3pr thread.orig/thr_attr_getscope.c thread/thr_attr_getscope.c *** thread.orig/thr_attr_getscope.c Mon Sep 16 01:45:33 2002 --- thread/thr_attr_getscope.c Mon Jun 7 17:50:38 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_getscope, pthread_attr_getscope); - int _pthread_attr_getscope(const pthread_attr_t *attr, int *contentionscope) { --- 35,40 ---- *************** _pthread_attr_getscope(const pthread_att *** 52,54 **** --- 50,54 ---- return(ret); } + + __strong_reference(_pthread_attr_getscope, pthread_attr_getscope); diff -c3pr thread.orig/thr_attr_getstack.c thread/thr_attr_getstack.c *** thread.orig/thr_attr_getstack.c Mon Feb 10 00:48:03 2003 --- thread/thr_attr_getstack.c Mon Jun 7 17:50:46 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_getstack, pthread_attr_getstack); - int _pthread_attr_getstack(const pthread_attr_t * __restrict attr, void ** __restrict stackaddr, --- 35,40 ---- *************** _pthread_attr_getstack(const pthread_att *** 57,59 **** --- 55,58 ---- return(ret); } + __strong_reference(_pthread_attr_getstack, pthread_attr_getstack); diff -c3pr thread.orig/thr_attr_getstackaddr.c thread/thr_attr_getstackaddr.c *** thread.orig/thr_attr_getstackaddr.c Mon Sep 16 01:45:34 2002 --- thread/thr_attr_getstackaddr.c Mon Jun 7 17:50:54 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_getstackaddr, pthread_attr_getstackaddr); - int _pthread_attr_getstackaddr(const pthread_attr_t *attr, void **stackaddr) { --- 35,40 ---- *************** _pthread_attr_getstackaddr(const pthread *** 52,54 **** --- 50,54 ---- } return(ret); } + + __strong_reference(_pthread_attr_getstackaddr, pthread_attr_getstackaddr); diff -c3pr thread.orig/thr_attr_getstacksize.c thread/thr_attr_getstacksize.c *** thread.orig/thr_attr_getstacksize.c Mon Sep 16 01:45:34 2002 --- thread/thr_attr_getstacksize.c Mon Jun 7 17:51:02 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_getstacksize, pthread_attr_getstacksize); - int _pthread_attr_getstacksize(const pthread_attr_t *attr, size_t *stacksize) { --- 35,40 ---- *************** _pthread_attr_getstacksize(const pthread *** 52,54 **** --- 50,54 ---- } return(ret); } + + __strong_reference(_pthread_attr_getstacksize, pthread_attr_getstacksize); diff -c3pr thread.orig/thr_attr_init.c thread/thr_attr_init.c *** thread.orig/thr_attr_init.c Thu Jul 17 19:46:55 2003 --- thread/thr_attr_init.c Mon Jun 7 17:51:11 2004 *************** *** 37,44 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_init, pthread_attr_init); - int _pthread_attr_init(pthread_attr_t *attr) { --- 37,42 ---- *************** _pthread_attr_init(pthread_attr_t *attr) *** 61,63 **** --- 59,63 ---- } return(ret); } + + __strong_reference(_pthread_attr_init, pthread_attr_init); diff -c3pr thread.orig/thr_attr_setcreatesuspend_np.c thread/thr_attr_setcreatesuspend_np.c *** thread.orig/thr_attr_setcreatesuspend_np.c Thu Sep 25 06:53:49 2003 --- thread/thr_attr_setcreatesuspend_np.c Mon Jun 7 17:51:20 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_setcreatesuspend_np, pthread_attr_setcreatesuspend_np); - int _pthread_attr_setcreatesuspend_np(pthread_attr_t *attr) { --- 35,40 ---- *************** _pthread_attr_setcreatesuspend_np(pthrea *** 50,52 **** --- 48,52 ---- } return(ret); } + + __strong_reference(_pthread_attr_setcreatesuspend_np, pthread_attr_setcreatesuspend_np); diff -c3pr thread.orig/thr_attr_setdetachstate.c thread/thr_attr_setdetachstate.c *** thread.orig/thr_attr_setdetachstate.c Mon Sep 16 01:45:34 2002 --- thread/thr_attr_setdetachstate.c Mon Jun 7 17:51:28 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_setdetachstate, pthread_attr_setdetachstate); - int _pthread_attr_setdetachstate(pthread_attr_t *attr, int detachstate) { --- 35,40 ---- *************** _pthread_attr_setdetachstate(pthread_att *** 59,61 **** --- 57,61 ---- } return(ret); } + + __strong_reference(_pthread_attr_setdetachstate, pthread_attr_setdetachstate); diff -c3pr thread.orig/thr_attr_setguardsize.c thread/thr_attr_setguardsize.c *** thread.orig/thr_attr_setguardsize.c Sun Sep 14 15:39:44 2003 --- thread/thr_attr_setguardsize.c Mon Jun 7 17:51:39 2004 *************** *** 34,41 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_setguardsize, pthread_attr_setguardsize); - int _pthread_attr_setguardsize(pthread_attr_t *attr, size_t guardsize) { --- 34,39 ---- *************** _pthread_attr_setguardsize(pthread_attr_ *** 51,53 **** --- 49,53 ---- } return(ret); } + + __strong_reference(_pthread_attr_setguardsize, pthread_attr_setguardsize); diff -c3pr thread.orig/thr_attr_setinheritsched.c thread/thr_attr_setinheritsched.c *** thread.orig/thr_attr_setinheritsched.c Sun Sep 14 15:28:13 2003 --- thread/thr_attr_setinheritsched.c Mon Jun 7 17:51:48 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_setinheritsched, pthread_attr_setinheritsched); - int _pthread_attr_setinheritsched(pthread_attr_t *attr, int sched_inherit) { --- 35,40 ---- *************** _pthread_attr_setinheritsched(pthread_at *** 52,54 **** --- 50,54 ---- return(ret); } + + __strong_reference(_pthread_attr_setinheritsched, pthread_attr_setinheritsched); diff -c3pr thread.orig/thr_attr_setschedparam.c thread/thr_attr_setschedparam.c *** thread.orig/thr_attr_setschedparam.c Thu Apr 17 22:04:15 2003 --- thread/thr_attr_setschedparam.c Mon Jun 7 17:51:58 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_setschedparam, pthread_attr_setschedparam); - int _pthread_attr_setschedparam(pthread_attr_t *attr, const struct sched_param *param) { --- 35,40 ---- *************** _pthread_attr_setschedparam(pthread_attr *** 55,57 **** --- 53,57 ---- return(ret); } + + __strong_reference(_pthread_attr_setschedparam, pthread_attr_setschedparam); diff -c3pr thread.orig/thr_attr_setschedpolicy.c thread/thr_attr_setschedpolicy.c *** thread.orig/thr_attr_setschedpolicy.c Mon Sep 16 01:45:34 2002 --- thread/thr_attr_setschedpolicy.c Mon Jun 7 17:52:13 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_setschedpolicy, pthread_attr_setschedpolicy); - int _pthread_attr_setschedpolicy(pthread_attr_t *attr, int policy) { --- 35,40 ---- *************** _pthread_attr_setschedpolicy(pthread_att *** 51,53 **** --- 49,53 ---- return(ret); } + + __strong_reference(_pthread_attr_setschedpolicy, pthread_attr_setschedpolicy); diff -c3pr thread.orig/thr_attr_setscope.c thread/thr_attr_setscope.c *** thread.orig/thr_attr_setscope.c Sun Sep 14 15:32:28 2003 --- thread/thr_attr_setscope.c Mon Jun 7 17:52:24 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_setscope, pthread_attr_setscope); - int _pthread_attr_setscope(pthread_attr_t *attr, int contentionscope) { --- 35,40 ---- *************** _pthread_attr_setscope(pthread_attr_t *a *** 55,57 **** --- 53,57 ---- } return (ret); } + + __strong_reference(_pthread_attr_setscope, pthread_attr_setscope); diff -c3pr thread.orig/thr_attr_setstack.c thread/thr_attr_setstack.c *** thread.orig/thr_attr_setstack.c Mon Feb 10 00:48:03 2003 --- thread/thr_attr_setstack.c Mon Jun 7 17:52:33 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_setstack, pthread_attr_setstack); - int _pthread_attr_setstack(pthread_attr_t *attr, void *stackaddr, size_t stacksize) --- 35,40 ---- *************** _pthread_attr_setstack(pthread_attr_t *a *** 56,58 **** --- 54,57 ---- return(ret); } + __strong_reference(_pthread_attr_setstack, pthread_attr_setstack); diff -c3pr thread.orig/thr_attr_setstackaddr.c thread/thr_attr_setstackaddr.c *** thread.orig/thr_attr_setstackaddr.c Mon Sep 16 01:45:34 2002 --- thread/thr_attr_setstackaddr.c Mon Jun 7 17:52:47 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_setstackaddr, pthread_attr_setstackaddr); - int _pthread_attr_setstackaddr(pthread_attr_t *attr, void *stackaddr) { --- 35,40 ---- *************** _pthread_attr_setstackaddr(pthread_attr_ *** 52,54 **** --- 50,54 ---- } return(ret); } + + __strong_reference(_pthread_attr_setstackaddr, pthread_attr_setstackaddr); diff -c3pr thread.orig/thr_attr_setstacksize.c thread/thr_attr_setstacksize.c *** thread.orig/thr_attr_setstacksize.c Mon Sep 16 01:45:34 2002 --- thread/thr_attr_setstacksize.c Mon Jun 7 17:52:55 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_attr_setstacksize, pthread_attr_setstacksize); - int _pthread_attr_setstacksize(pthread_attr_t *attr, size_t stacksize) { --- 35,40 ---- *************** _pthread_attr_setstacksize(pthread_attr_ *** 52,54 **** --- 50,54 ---- } return(ret); } + + __strong_reference(_pthread_attr_setstacksize, pthread_attr_setstacksize); diff -c3pr thread.orig/thr_barrier.c thread/thr_barrier.c *** thread.orig/thr_barrier.c Thu Sep 4 07:06:43 2003 --- thread/thr_barrier.c Mon Jun 7 18:08:22 2004 *************** *** 33,42 **** #include "un-namespace.h" #include "thr_private.h" - __weak_reference(_pthread_barrier_init, pthread_barrier_init); - __weak_reference(_pthread_barrier_wait, pthread_barrier_wait); - __weak_reference(_pthread_barrier_destroy, pthread_barrier_destroy); - int _pthread_barrier_destroy(pthread_barrier_t *barrier) { --- 33,38 ---- *************** _pthread_barrier_destroy(pthread_barrier *** 58,64 **** int _pthread_barrier_init(pthread_barrier_t *barrier, ! const pthread_barrierattr_t *attr, int count) { pthread_barrier_t bar; int ret; --- 54,60 ---- int _pthread_barrier_init(pthread_barrier_t *barrier, ! const pthread_barrierattr_t *attr, unsigned count) { pthread_barrier_t bar; int ret; *************** _pthread_barrier_wait(pthread_barrier_t *** 120,122 **** --- 116,122 ---- _pthread_mutex_unlock(&bar->b_lock); return (ret); } + + __strong_reference(_pthread_barrier_init, pthread_barrier_init); + __strong_reference(_pthread_barrier_wait, pthread_barrier_wait); + __strong_reference(_pthread_barrier_destroy, pthread_barrier_destroy); diff -c3pr thread.orig/thr_barrierattr.c thread/thr_barrierattr.c *** thread.orig/thr_barrierattr.c Thu Sep 4 07:06:43 2003 --- thread/thr_barrierattr.c Mon Jun 7 17:53:46 2004 *************** *** 33,45 **** #include #include "thr_private.h" - __weak_reference(_pthread_barrierattr_destroy, pthread_barrierattr_destroy); - __weak_reference(_pthread_barrierattr_init, pthread_barrierattr_init); - __weak_reference(_pthread_barrierattr_setpshared, - pthread_barrierattr_setpshared); - __weak_reference(_pthread_barrierattr_getpshared, - pthread_barrierattr_getpshared); - int _pthread_barrierattr_destroy(pthread_barrierattr_t *attr) { --- 33,38 ---- *************** _pthread_barrierattr_setpshared(pthread_ *** 91,93 **** --- 84,93 ---- (*attr)->pshared = pshared; return (0); } + + __strong_reference(_pthread_barrierattr_destroy, pthread_barrierattr_destroy); + __strong_reference(_pthread_barrierattr_init, pthread_barrierattr_init); + __strong_reference(_pthread_barrierattr_setpshared, + pthread_barrierattr_setpshared); + __strong_reference(_pthread_barrierattr_getpshared, + pthread_barrierattr_getpshared); diff -c3pr thread.orig/thr_cancel.c thread/thr_cancel.c *** thread.orig/thr_cancel.c Mon Dec 8 18:20:56 2003 --- thread/thr_cancel.c Mon Jun 7 17:54:07 2004 *************** *** 6,16 **** #include #include "thr_private.h" - __weak_reference(_pthread_cancel, pthread_cancel); - __weak_reference(_pthread_setcancelstate, pthread_setcancelstate); - __weak_reference(_pthread_setcanceltype, pthread_setcanceltype); - __weak_reference(_pthread_testcancel, pthread_testcancel); - static inline int checkcancel(struct pthread *curthread) { --- 6,11 ---- *************** _thr_finish_cancellation(void *arg) *** 292,294 **** --- 287,294 ---- } THR_THREAD_UNLOCK(curthread, curthread); } + + __strong_reference(_pthread_cancel, pthread_cancel); + __strong_reference(_pthread_setcancelstate, pthread_setcancelstate); + __strong_reference(_pthread_setcanceltype, pthread_setcanceltype); + __strong_reference(_pthread_testcancel, pthread_testcancel); diff -c3pr thread.orig/thr_clean.c thread/thr_clean.c *** thread.orig/thr_clean.c Thu Apr 17 22:04:15 2003 --- thread/thr_clean.c Mon Jun 7 17:54:19 2004 *************** *** 37,45 **** #include #include "thr_private.h" - __weak_reference(_pthread_cleanup_push, pthread_cleanup_push); - __weak_reference(_pthread_cleanup_pop, pthread_cleanup_pop); - void _pthread_cleanup_push(void (*routine) (void *), void *routine_arg) { --- 37,42 ---- *************** _pthread_cleanup_pop(int execute) *** 70,72 **** --- 67,72 ---- free(old); } } + + __strong_reference(_pthread_cleanup_push, pthread_cleanup_push); + __strong_reference(_pthread_cleanup_pop, pthread_cleanup_pop); diff -c3pr thread.orig/thr_close.c thread/thr_close.c *** thread.orig/thr_close.c Mon Dec 8 18:20:56 2003 --- thread/thr_close.c Mon Jun 7 17:54:27 2004 *************** *** 39,46 **** #include #include "thr_private.h" - __weak_reference(__close, close); - int __close(int fd) { --- 39,44 ---- *************** __close(int fd) *** 53,55 **** --- 51,55 ---- return (ret); } + + __strong_reference(__close, close); diff -c3pr thread.orig/thr_concurrency.c thread/thr_concurrency.c *** thread.orig/thr_concurrency.c Sat Mar 13 21:24:27 2004 --- thread/thr_concurrency.c Mon Jun 7 17:54:39 2004 *************** *** 42,50 **** static int level = 0; - __weak_reference(_pthread_getconcurrency, pthread_getconcurrency); - __weak_reference(_pthread_setconcurrency, pthread_setconcurrency); - int _pthread_getconcurrency(void) { --- 42,47 ---- *************** _thr_setmaxconcurrency(void) *** 163,165 **** --- 160,164 ---- return (ret); } + __strong_reference(_pthread_getconcurrency, pthread_getconcurrency); + __strong_reference(_pthread_setconcurrency, pthread_setconcurrency); diff -c3pr thread.orig/thr_cond.c thread/thr_cond.c *** thread.orig/thr_cond.c Mon Dec 8 18:20:56 2003 --- thread/thr_cond.c Mon Jun 7 17:55:06 2004 *************** static inline void cond_queue_enq(pthre *** 53,66 **** * versions are not and are provided for libc internal usage (which * shouldn't introduce cancellation points). */ - __weak_reference(__pthread_cond_wait, pthread_cond_wait); - __weak_reference(__pthread_cond_timedwait, pthread_cond_timedwait); - - __weak_reference(_pthread_cond_init, pthread_cond_init); - __weak_reference(_pthread_cond_destroy, pthread_cond_destroy); - __weak_reference(_pthread_cond_signal, pthread_cond_signal); - __weak_reference(_pthread_cond_broadcast, pthread_cond_broadcast); - int _pthread_cond_init(pthread_cond_t *cond, const pthread_condattr_t *cond_attr) --- 53,58 ---- *************** cond_queue_enq(pthread_cond_t cond, stru *** 814,816 **** --- 806,816 ---- THR_CONDQ_SET(pthread); pthread->data.cond = cond; } + + __strong_reference(__pthread_cond_wait, pthread_cond_wait); + __strong_reference(__pthread_cond_timedwait, pthread_cond_timedwait); + + __strong_reference(_pthread_cond_init, pthread_cond_init); + __strong_reference(_pthread_cond_destroy, pthread_cond_destroy); + __strong_reference(_pthread_cond_signal, pthread_cond_signal); + __strong_reference(_pthread_cond_broadcast, pthread_cond_broadcast); diff -c3pr thread.orig/thr_condattr_destroy.c thread/thr_condattr_destroy.c *** thread.orig/thr_condattr_destroy.c Mon Sep 16 01:45:34 2002 --- thread/thr_condattr_destroy.c Mon Jun 7 17:55:17 2004 *************** *** 36,43 **** #include #include "thr_private.h" - __weak_reference(_pthread_condattr_destroy, pthread_condattr_destroy); - int _pthread_condattr_destroy(pthread_condattr_t *attr) { --- 36,41 ---- *************** _pthread_condattr_destroy(pthread_condat *** 51,53 **** --- 49,53 ---- } return(ret); } + + __strong_reference(_pthread_condattr_destroy, pthread_condattr_destroy); diff -c3pr thread.orig/thr_condattr_init.c thread/thr_condattr_init.c *** thread.orig/thr_condattr_init.c Thu Apr 17 22:04:15 2003 --- thread/thr_condattr_init.c Mon Jun 7 17:55:25 2004 *************** *** 37,44 **** #include #include "thr_private.h" - __weak_reference(_pthread_condattr_init, pthread_condattr_init); - int _pthread_condattr_init(pthread_condattr_t *attr) { --- 37,42 ---- *************** _pthread_condattr_init(pthread_condattr_ *** 56,58 **** --- 54,58 ---- } return (ret); } + + __strong_reference(_pthread_condattr_init, pthread_condattr_init); diff -c3pr thread.orig/thr_connect.c thread/thr_connect.c *** thread.orig/thr_connect.c Tue Dec 9 15:40:27 2003 --- thread/thr_connect.c Mon Jun 7 17:55:33 2004 *************** __FBSDID("$FreeBSD: src/lib/libpthread/t *** 32,39 **** #include #include "thr_private.h" - __weak_reference(__connect, connect); - int __connect(int fd, const struct sockaddr *name, socklen_t namelen) { --- 32,37 ---- *************** __connect(int fd, const struct sockaddr *** 47,49 **** --- 45,49 ---- return (ret); } + + __strong_reference(__connect, connect); diff -c3pr thread.orig/thr_creat.c thread/thr_creat.c *** thread.orig/thr_creat.c Mon Dec 8 18:20:56 2003 --- thread/thr_creat.c Mon Jun 7 17:55:46 2004 *************** *** 35,42 **** extern int __creat(const char *, mode_t); - __weak_reference(___creat, creat); - int ___creat(const char *path, mode_t mode) { --- 35,40 ---- *************** ___creat(const char *path, mode_t mode) *** 53,55 **** --- 51,55 ---- return ret; } + + __strong_reference(___creat, creat); diff -c3pr thread.orig/thr_create.c thread/thr_create.c *** thread.orig/thr_create.c Thu Jan 8 07:37:09 2004 --- thread/thr_create.c Mon Jun 7 17:55:55 2004 *************** static void free_stack(struct pthread_at *** 64,71 **** static void thread_start(struct pthread *curthread, void *(*start_routine) (void *), void *arg); - __weak_reference(_pthread_create, pthread_create); - /* * Some notes on new thread creation and first time initializion * to enable multi-threading. --- 64,69 ---- *************** thread_start(struct pthread *curthread, *** 355,357 **** --- 353,357 ---- /* This point should never be reached. */ PANIC("Thread has resumed after exit"); } + + __strong_reference(_pthread_create, pthread_create); diff -c3pr thread.orig/thr_detach.c thread/thr_detach.c *** thread.orig/thr_detach.c Tue Jul 22 19:11:07 2003 --- thread/thr_detach.c Mon Jun 7 17:56:04 2004 *************** *** 37,44 **** #include #include "thr_private.h" - __weak_reference(_pthread_detach, pthread_detach); - int _pthread_detach(pthread_t pthread) { --- 37,42 ---- *************** _pthread_detach(pthread_t pthread) *** 115,117 **** --- 113,117 ---- /* Return the completion status: */ return (rval); } + + __strong_reference(_pthread_detach, pthread_detach); diff -c3pr thread.orig/thr_equal.c thread/thr_equal.c *** thread.orig/thr_equal.c Mon Sep 16 01:45:34 2002 --- thread/thr_equal.c Mon Jun 7 17:56:11 2004 *************** *** 34,44 **** #include #include "thr_private.h" - __weak_reference(_pthread_equal, pthread_equal); - int _pthread_equal(pthread_t t1, pthread_t t2) { /* Compare the two thread pointers: */ return (t1 == t2); } --- 34,44 ---- #include #include "thr_private.h" int _pthread_equal(pthread_t t1, pthread_t t2) { /* Compare the two thread pointers: */ return (t1 == t2); } + + __strong_reference(_pthread_equal, pthread_equal); diff -c3pr thread.orig/thr_exit.c thread/thr_exit.c *** thread.orig/thr_exit.c Sun Sep 14 15:52:16 2003 --- thread/thr_exit.c Mon Jun 7 17:56:20 2004 *************** *** 42,49 **** void _pthread_exit(void *status); - __weak_reference(_pthread_exit, pthread_exit); - void _thr_exit(char *fname, int lineno, char *msg) { --- 42,47 ---- *************** _pthread_exit(void *status) *** 147,149 **** --- 145,149 ---- /* This point should not be reached. */ PANIC("Dead thread has resumed"); } + + __strong_reference(_pthread_exit, pthread_exit); diff -c3pr thread.orig/thr_fcntl.c thread/thr_fcntl.c *** thread.orig/thr_fcntl.c Mon Dec 8 18:20:56 2003 --- thread/thr_fcntl.c Mon Jun 7 17:56:29 2004 *************** *** 38,45 **** #include #include "thr_private.h" - __weak_reference(__fcntl, fcntl); - int __fcntl(int fd, int cmd,...) { --- 38,43 ---- *************** __fcntl(int fd, int cmd,...) *** 76,78 **** --- 74,78 ---- return (ret); } + + __strong_reference(__fcntl, fcntl); diff -c3pr thread.orig/thr_fork.c thread/thr_fork.c *** thread.orig/thr_fork.c Wed Nov 5 10:18:45 2003 --- thread/thr_fork.c Mon Jun 7 17:56:39 2004 *************** *** 49,56 **** */ #pragma weak __malloc_lock - __weak_reference(_fork, fork); - pid_t _fork(void) { --- 49,54 ---- *************** _fork(void) *** 122,124 **** --- 120,124 ---- /* Return the process ID: */ return (ret); } + + __strong_reference(_fork, fork); diff -c3pr thread.orig/thr_fsync.c thread/thr_fsync.c *** thread.orig/thr_fsync.c Mon Dec 8 18:20:56 2003 --- thread/thr_fsync.c Mon Jun 7 17:56:47 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(__fsync, fsync); - int __fsync(int fd) { --- 35,40 ---- *************** __fsync(int fd) *** 49,51 **** --- 47,51 ---- return (ret); } + + __strong_reference(__fsync, fsync); diff -c3pr thread.orig/thr_getprio.c thread/thr_getprio.c *** thread.orig/thr_getprio.c Mon Sep 16 01:45:34 2002 --- thread/thr_getprio.c Mon Jun 7 17:56:56 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_getprio, pthread_getprio); - int _pthread_getprio(pthread_t pthread) { --- 35,40 ---- *************** _pthread_getprio(pthread_t pthread) *** 54,56 **** --- 52,56 ---- /* Return the thread priority or an error status: */ return (ret); } + + __strong_reference(_pthread_getprio, pthread_getprio); diff -c3pr thread.orig/thr_getschedparam.c thread/thr_getschedparam.c *** thread.orig/thr_getschedparam.c Sun Jul 6 21:28:23 2003 --- thread/thr_getschedparam.c Mon Jun 7 17:57:03 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_getschedparam, pthread_getschedparam); - int _pthread_getschedparam(pthread_t pthread, int *policy, struct sched_param *param) --- 35,40 ---- *************** _pthread_getschedparam(pthread_t pthread *** 73,75 **** --- 71,75 ---- } return (ret); } + + __strong_reference(_pthread_getschedparam, pthread_getschedparam); diff -c3pr thread.orig/thr_info.c thread/thr_info.c *** thread.orig/thr_info.c Sun Sep 21 17:40:23 2003 --- thread/thr_info.c Mon Jun 7 18:08:53 2004 *************** *** 46,53 **** static void dump_thread(int fd, pthread_t pthread, int long_version); - __weak_reference(_pthread_set_name_np, pthread_set_name_np); - struct s_thread_info { enum pthread_state state; char *name; --- 46,51 ---- *************** dump_thread(int fd, pthread_t pthread, i *** 212,218 **** /* Set the thread name for debug: */ void ! _pthread_set_name_np(pthread_t thread, char *name) { /* Check if the caller has specified a valid thread: */ if (thread != NULL && thread->magic == THR_MAGIC) { --- 210,216 ---- /* Set the thread name for debug: */ void ! _pthread_set_name_np(pthread_t thread, const char *name) { /* Check if the caller has specified a valid thread: */ if (thread != NULL && thread->magic == THR_MAGIC) { *************** _pthread_set_name_np(pthread_t thread, c *** 223,225 **** --- 221,225 ---- thread->name = strdup(name); } } + + __strong_reference(_pthread_set_name_np, pthread_set_name_np); diff -c3pr thread.orig/thr_join.c thread/thr_join.c *** thread.orig/thr_join.c Mon Dec 8 18:20:56 2003 --- thread/thr_join.c Mon Jun 7 17:57:21 2004 *************** *** 35,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_join, pthread_join); - int _pthread_join(pthread_t pthread, void **thread_return) { --- 35,40 ---- *************** _pthread_join(pthread_t pthread, void ** *** 160,162 **** --- 158,162 ---- /* Return the completion status: */ return (ret); } + + __strong_reference(_pthread_join, pthread_join); diff -c3pr thread.orig/thr_kill.c thread/thr_kill.c *** thread.orig/thr_kill.c Sat Jun 28 02:55:02 2003 --- thread/thr_kill.c Mon Jun 7 17:57:29 2004 *************** *** 36,43 **** #include #include "thr_private.h" - __weak_reference(_pthread_kill, pthread_kill); - int _pthread_kill(pthread_t pthread, int sig) { --- 36,41 ---- *************** _pthread_kill(pthread_t pthread, int sig *** 64,66 **** --- 62,66 ---- /* Return the completion status: */ return (ret); } + + __strong_reference(_pthread_kill, pthread_kill); diff -c3pr thread.orig/thr_main_np.c thread/thr_main_np.c *** thread.orig/thr_main_np.c Thu Apr 17 22:04:16 2003 --- thread/thr_main_np.c Mon Jun 7 17:57:41 2004 *************** *** 31,38 **** #include #include "thr_private.h" - __weak_reference(_pthread_main_np, pthread_main_np); - /* * Provide the equivelant to Solaris thr_main() function */ --- 31,36 ---- *************** _pthread_main_np() *** 45,47 **** --- 43,47 ---- else return (pthread_equal(pthread_self(), _thr_initial) ? 1 : 0); } + + __strong_reference(_pthread_main_np, pthread_main_np); diff -c3pr thread.orig/thr_mattr_init.c thread/thr_mattr_init.c *** thread.orig/thr_mattr_init.c Thu Apr 17 22:04:16 2003 --- thread/thr_mattr_init.c Mon Jun 7 17:57:51 2004 *************** *** 37,44 **** #include #include "thr_private.h" - __weak_reference(_pthread_mutexattr_init, pthread_mutexattr_init); - int _pthread_mutexattr_init(pthread_mutexattr_t *attr) { --- 37,42 ---- *************** _pthread_mutexattr_init(pthread_mutexatt *** 56,58 **** --- 54,58 ---- } return (ret); } + + __strong_reference(_pthread_mutexattr_init, pthread_mutexattr_init); diff -c3pr thread.orig/thr_mattr_kind_np.c thread/thr_mattr_kind_np.c *** thread.orig/thr_mattr_kind_np.c Mon Sep 16 01:45:35 2002 --- thread/thr_mattr_kind_np.c Mon Jun 7 17:58:11 2004 *************** *** 35,45 **** #include #include "thr_private.h" - __weak_reference(_pthread_mutexattr_setkind_np, pthread_mutexattr_setkind_np); - __weak_reference(_pthread_mutexattr_getkind_np, pthread_mutexattr_getkind_np); - __weak_reference(_pthread_mutexattr_gettype, pthread_mutexattr_gettype); - __weak_reference(_pthread_mutexattr_settype, pthread_mutexattr_settype); - int _pthread_mutexattr_setkind_np(pthread_mutexattr_t *attr, int kind) { --- 35,40 ---- *************** _pthread_mutexattr_gettype(pthread_mutex *** 95,97 **** --- 90,97 ---- } return ret; } + + __strong_reference(_pthread_mutexattr_setkind_np, pthread_mutexattr_setkind_np); + __strong_reference(_pthread_mutexattr_getkind_np, pthread_mutexattr_getkind_np); + __strong_reference(_pthread_mutexattr_gettype, pthread_mutexattr_gettype); + __strong_reference(_pthread_mutexattr_settype, pthread_mutexattr_settype); diff -c3pr thread.orig/thr_msync.c thread/thr_msync.c *** thread.orig/thr_msync.c Mon Dec 8 18:20:56 2003 --- thread/thr_msync.c Mon Jun 7 17:58:24 2004 *************** *** 11,18 **** #include #include "thr_private.h" - __weak_reference(__msync, msync); - int __msync(void *addr, size_t len, int flags) { --- 11,16 ---- *************** __msync(void *addr, size_t len, int flag *** 31,33 **** --- 29,33 ---- return ret; } + + __strong_reference(__msync, msync); diff -c3pr thread.orig/thr_multi_np.c thread/thr_multi_np.c *** thread.orig/thr_multi_np.c Thu May 23 21:32:28 2002 --- thread/thr_multi_np.c Mon Jun 7 17:58:35 2004 *************** *** 34,41 **** #include #include - __weak_reference(_pthread_multi_np, pthread_multi_np); - int _pthread_multi_np() { --- 34,39 ---- *************** _pthread_multi_np() *** 48,50 **** --- 46,50 ---- pthread_resume_all_np(); return (0); } + + __strong_reference(_pthread_multi_np, pthread_multi_np); diff -c3pr thread.orig/thr_mutex.c thread/thr_mutex.c *** thread.orig/thr_mutex.c Fri Jan 16 19:09:57 2004 --- thread/thr_mutex.c Mon Jun 7 17:59:07 2004 *************** static struct pthread_mutex_attr static_ *** 91,108 **** PTHREAD_MUTEXATTR_STATIC_INITIALIZER; static pthread_mutexattr_t static_mattr = &static_mutex_attr; - /* Single underscore versions provided for libc internal usage: */ - __weak_reference(__pthread_mutex_lock, pthread_mutex_lock); - __weak_reference(__pthread_mutex_timedlock, pthread_mutex_timedlock); - __weak_reference(__pthread_mutex_trylock, pthread_mutex_trylock); - - /* No difference between libc and application usage of these: */ - __weak_reference(_pthread_mutex_init, pthread_mutex_init); - __weak_reference(_pthread_mutex_destroy, pthread_mutex_destroy); - __weak_reference(_pthread_mutex_unlock, pthread_mutex_unlock); - - - int _pthread_mutex_init(pthread_mutex_t *mutex, const pthread_mutexattr_t *mutex_attr) --- 91,96 ---- *************** mutex_queue_enq(pthread_mutex_t mutex, p *** 1756,1758 **** --- 1744,1756 ---- } pthread->sflags |= THR_FLAGS_IN_SYNCQ; } + + /* Single underscore versions provided for libc internal usage: */ + __strong_reference(__pthread_mutex_lock, pthread_mutex_lock); + __strong_reference(__pthread_mutex_timedlock, pthread_mutex_timedlock); + __strong_reference(__pthread_mutex_trylock, pthread_mutex_trylock); + + /* No difference between libc and application usage of these: */ + __strong_reference(_pthread_mutex_init, pthread_mutex_init); + __strong_reference(_pthread_mutex_destroy, pthread_mutex_destroy); + __strong_reference(_pthread_mutex_unlock, pthread_mutex_unlock); diff -c3pr thread.orig/thr_mutex_prioceiling.c thread/thr_mutex_prioceiling.c *** thread.orig/thr_mutex_prioceiling.c Sun Jul 6 21:28:23 2003 --- thread/thr_mutex_prioceiling.c Mon Jun 7 17:59:30 2004 *************** *** 37,47 **** #include #include "thr_private.h" - __weak_reference(_pthread_mutexattr_getprioceiling, pthread_mutexattr_getprioceiling); - __weak_reference(_pthread_mutexattr_setprioceiling, pthread_mutexattr_setprioceiling); - __weak_reference(_pthread_mutex_getprioceiling, pthread_mutex_getprioceiling); - __weak_reference(_pthread_mutex_setprioceiling, pthread_mutex_setprioceiling); - int _pthread_mutexattr_getprioceiling(pthread_mutexattr_t *mattr, int *prioceiling) { --- 37,42 ---- *************** _pthread_mutex_setprioceiling(pthread_mu *** 113,115 **** --- 108,115 ---- } return(ret); } + + __strong_reference(_pthread_mutexattr_getprioceiling, pthread_mutexattr_getprioceiling); + __strong_reference(_pthread_mutexattr_setprioceiling, pthread_mutexattr_setprioceiling); + __strong_reference(_pthread_mutex_getprioceiling, pthread_mutex_getprioceiling); + __strong_reference(_pthread_mutex_setprioceiling, pthread_mutex_setprioceiling); diff -c3pr thread.orig/thr_mutex_protocol.c thread/thr_mutex_protocol.c *** thread.orig/thr_mutex_protocol.c Thu Apr 17 22:04:16 2003 --- thread/thr_mutex_protocol.c Mon Jun 7 17:59:53 2004 *************** *** 37,45 **** #include #include "thr_private.h" - __weak_reference(_pthread_mutexattr_getprotocol, pthread_mutexattr_getprotocol); - __weak_reference(_pthread_mutexattr_setprotocol, pthread_mutexattr_setprotocol); - int _pthread_mutexattr_getprotocol(pthread_mutexattr_t *mattr, int *protocol) { --- 37,42 ---- *************** _pthread_mutexattr_setprotocol(pthread_m *** 68,70 **** --- 65,69 ---- return(ret); } + __strong_reference(_pthread_mutexattr_getprotocol, pthread_mutexattr_getprotocol); + __strong_reference(_pthread_mutexattr_setprotocol, pthread_mutexattr_setprotocol); diff -c3pr thread.orig/thr_mutexattr_destroy.c thread/thr_mutexattr_destroy.c *** thread.orig/thr_mutexattr_destroy.c Mon Sep 16 01:45:35 2002 --- thread/thr_mutexattr_destroy.c Mon Jun 7 18:00:04 2004 *************** *** 36,43 **** #include #include "thr_private.h" - __weak_reference(_pthread_mutexattr_destroy, pthread_mutexattr_destroy); - int _pthread_mutexattr_destroy(pthread_mutexattr_t *attr) { --- 36,41 ---- *************** _pthread_mutexattr_destroy(pthread_mutex *** 51,53 **** --- 49,53 ---- } return(ret); } + + __strong_reference(_pthread_mutexattr_destroy, pthread_mutexattr_destroy); diff -c3pr thread.orig/thr_nanosleep.c thread/thr_nanosleep.c *** thread.orig/thr_nanosleep.c Mon Dec 8 18:20:56 2003 --- thread/thr_nanosleep.c Mon Jun 7 18:00:12 2004 *************** *** 36,43 **** #include #include "thr_private.h" - __weak_reference(__nanosleep, nanosleep); - int _nanosleep(const struct timespec *time_to_sleep, struct timespec *time_remaining) --- 36,41 ---- *************** __nanosleep(const struct timespec *time_ *** 127,129 **** --- 125,129 ---- return (ret); } + + __strong_reference(__nanosleep, nanosleep); diff -c3pr thread.orig/thr_once.c thread/thr_once.c *** thread.orig/thr_once.c Tue Sep 9 15:38:12 2003 --- thread/thr_once.c Mon Jun 7 18:00:24 2004 *************** *** 36,43 **** #include "un-namespace.h" #include "thr_private.h" - __weak_reference(_pthread_once, pthread_once); - #define ONCE_NEVER_DONE PTHREAD_NEEDS_INIT #define ONCE_DONE PTHREAD_DONE_INIT #define ONCE_IN_PROGRESS 0x02 --- 36,41 ---- *************** _pthread_once(pthread_once_t *once_contr *** 94,96 **** --- 92,95 ---- return (0); } + __strong_reference(_pthread_once, pthread_once); diff -c3pr thread.orig/thr_open.c thread/thr_open.c *** thread.orig/thr_open.c Mon Dec 8 18:20:56 2003 --- thread/thr_open.c Mon Jun 7 18:00:32 2004 *************** *** 40,47 **** #include #include "thr_private.h" - __weak_reference(__open, open); - int __open(const char *path, int flags,...) { --- 40,45 ---- *************** __open(const char *path, int flags,...) *** 69,71 **** --- 67,71 ---- return ret; } + + __strong_reference(__open, open); diff -c3pr thread.orig/thr_pause.c thread/thr_pause.c *** thread.orig/thr_pause.c Mon Dec 8 18:20:56 2003 --- thread/thr_pause.c Mon Jun 7 18:00:43 2004 *************** *** 35,42 **** extern int __pause(void); - __weak_reference(_pause, pause); - int _pause(void) { --- 35,40 ---- *************** _pause(void) *** 49,51 **** --- 47,51 ---- return ret; } + + __strong_reference(_pause, pause); diff -c3pr thread.orig/thr_poll.c thread/thr_poll.c *** thread.orig/thr_poll.c Mon Dec 8 18:20:56 2003 --- thread/thr_poll.c Mon Jun 7 18:00:57 2004 *************** *** 41,47 **** #include #include "thr_private.h" - __weak_reference(__poll, poll); int __poll(struct pollfd *fds, unsigned int nfds, int timeout) --- 41,46 ---- *************** __poll(struct pollfd *fds, unsigned int *** 55,57 **** --- 54,58 ---- return ret; } + + __strong_reference(__poll, poll); diff -c3pr thread.orig/thr_pselect.c thread/thr_pselect.c *** thread.orig/thr_pselect.c Mon Dec 8 18:20:56 2003 --- thread/thr_pselect.c Mon Jun 7 18:01:06 2004 *************** __FBSDID("$FreeBSD: src/lib/libpthread/t *** 40,47 **** extern int __pselect(int count, fd_set *rfds, fd_set *wfds, fd_set *efds, const struct timespec *timo, const sigset_t *mask); - __weak_reference(_pselect, pselect); - int _pselect(int count, fd_set *rfds, fd_set *wfds, fd_set *efds, const struct timespec *timo, const sigset_t *mask) --- 40,45 ---- *************** _pselect(int count, fd_set *rfds, fd_set *** 55,57 **** --- 53,57 ---- return (ret); } + + __strong_reference(_pselect, pselect); diff -c3pr thread.orig/thr_pspinlock.c thread/thr_pspinlock.c *** thread.orig/thr_pspinlock.c Tue Nov 4 11:56:12 2003 --- thread/thr_pspinlock.c Mon Jun 7 18:01:16 2004 *************** *** 34,45 **** #define SPIN_COUNT 10000 - __weak_reference(_pthread_spin_init, pthread_spin_init); - __weak_reference(_pthread_spin_destroy, pthread_spin_destroy); - __weak_reference(_pthread_spin_trylock, pthread_spin_trylock); - __weak_reference(_pthread_spin_lock, pthread_spin_lock); - __weak_reference(_pthread_spin_unlock, pthread_spin_unlock); - int _pthread_spin_init(pthread_spinlock_t *lock, int pshared) { --- 34,39 ---- *************** _pthread_spin_unlock(pthread_spinlock_t *** 158,160 **** --- 152,159 ---- return (ret); } + __strong_reference(_pthread_spin_init, pthread_spin_init); + __strong_reference(_pthread_spin_destroy, pthread_spin_destroy); + __strong_reference(_pthread_spin_trylock, pthread_spin_trylock); + __strong_reference(_pthread_spin_lock, pthread_spin_lock); + __strong_reference(_pthread_spin_unlock, pthread_spin_unlock); diff -c3pr thread.orig/thr_raise.c thread/thr_raise.c *** thread.orig/thr_raise.c Fri Jul 18 22:25:49 2003 --- thread/thr_raise.c Mon Jun 7 18:01:27 2004 *************** *** 33,40 **** #include #include "thr_private.h" - __weak_reference(_raise, raise); - int _raise(int sig) { --- 33,38 ---- *************** _raise(int sig) *** 51,53 **** --- 49,53 ---- } return (ret); } + + __strong_reference(_raise, raise); diff -c3pr thread.orig/thr_read.c thread/thr_read.c *** thread.orig/thr_read.c Mon Dec 8 18:20:56 2003 --- thread/thr_read.c Mon Jun 7 18:01:40 2004 *************** *** 40,47 **** #include #include "thr_private.h" - __weak_reference(__read, read); - ssize_t __read(int fd, void *buf, size_t nbytes) { --- 40,45 ---- *************** __read(int fd, void *buf, size_t nbytes) *** 54,56 **** --- 52,56 ---- return ret; } + + __strong_reference(__read, read); diff -c3pr thread.orig/thr_readv.c thread/thr_readv.c *** thread.orig/thr_readv.c Mon Dec 8 18:20:56 2003 --- thread/thr_readv.c Mon Jun 7 18:01:57 2004 *************** *** 40,47 **** #include #include "thr_private.h" - __weak_reference(__readv, readv); - ssize_t __readv(int fd, const struct iovec *iov, int iovcnt) { --- 40,45 ---- *************** __readv(int fd, const struct iovec *iov, *** 54,56 **** --- 52,56 ---- return ret; } + + __strong_reference(__readv, readv); diff -c3pr thread.orig/thr_resume_np.c thread/thr_resume_np.c *** thread.orig/thr_resume_np.c Tue Jul 22 19:11:07 2003 --- thread/thr_resume_np.c Mon Jun 7 18:02:16 2004 *************** *** 37,46 **** static struct kse_mailbox *resume_common(struct pthread *); - __weak_reference(_pthread_resume_np, pthread_resume_np); - __weak_reference(_pthread_resume_all_np, pthread_resume_all_np); - - /* Resume a thread: */ int _pthread_resume_np(pthread_t thread) --- 37,42 ---- *************** resume_common(struct pthread *thread) *** 105,107 **** --- 101,106 ---- else return (NULL); } + + __strong_reference(_pthread_resume_np, pthread_resume_np); + __strong_reference(_pthread_resume_all_np, pthread_resume_all_np); diff -c3pr thread.orig/thr_rwlock.c thread/thr_rwlock.c *** thread.orig/thr_rwlock.c Thu Jan 8 07:37:09 2004 --- thread/thr_rwlock.c Mon Jun 7 18:02:29 2004 *************** *** 38,53 **** /* maximum number of times a read lock may be obtained */ #define MAX_READ_LOCKS (INT_MAX - 1) - __weak_reference(_pthread_rwlock_destroy, pthread_rwlock_destroy); - __weak_reference(_pthread_rwlock_init, pthread_rwlock_init); - __weak_reference(_pthread_rwlock_rdlock, pthread_rwlock_rdlock); - __weak_reference(_pthread_rwlock_timedrdlock, pthread_rwlock_timedrdlock); - __weak_reference(_pthread_rwlock_tryrdlock, pthread_rwlock_tryrdlock); - __weak_reference(_pthread_rwlock_trywrlock, pthread_rwlock_trywrlock); - __weak_reference(_pthread_rwlock_unlock, pthread_rwlock_unlock); - __weak_reference(_pthread_rwlock_wrlock, pthread_rwlock_wrlock); - __weak_reference(_pthread_rwlock_timedwrlock, pthread_rwlock_timedwrlock); - /* * Prototypes */ --- 38,43 ---- *************** _pthread_rwlock_timedwrlock (pthread_rwl *** 417,419 **** --- 407,419 ---- { return (rwlock_wrlock_common (rwlock, abstime)); } + + __strong_reference(_pthread_rwlock_destroy, pthread_rwlock_destroy); + __strong_reference(_pthread_rwlock_init, pthread_rwlock_init); + __strong_reference(_pthread_rwlock_rdlock, pthread_rwlock_rdlock); + __strong_reference(_pthread_rwlock_timedrdlock, pthread_rwlock_timedrdlock); + __strong_reference(_pthread_rwlock_tryrdlock, pthread_rwlock_tryrdlock); + __strong_reference(_pthread_rwlock_trywrlock, pthread_rwlock_trywrlock); + __strong_reference(_pthread_rwlock_unlock, pthread_rwlock_unlock); + __strong_reference(_pthread_rwlock_wrlock, pthread_rwlock_wrlock); + __strong_reference(_pthread_rwlock_timedwrlock, pthread_rwlock_timedwrlock); diff -c3pr thread.orig/thr_rwlockattr.c thread/thr_rwlockattr.c *** thread.orig/thr_rwlockattr.c Mon Sep 16 01:45:35 2002 --- thread/thr_rwlockattr.c Mon Jun 7 18:02:44 2004 *************** *** 32,42 **** #include #include "thr_private.h" - __weak_reference(_pthread_rwlockattr_destroy, pthread_rwlockattr_destroy); - __weak_reference(_pthread_rwlockattr_getpshared, pthread_rwlockattr_getpshared); - __weak_reference(_pthread_rwlockattr_init, pthread_rwlockattr_init); - __weak_reference(_pthread_rwlockattr_setpshared, pthread_rwlockattr_setpshared); - int _pthread_rwlockattr_destroy(pthread_rwlockattr_t *rwlockattr) { --- 32,37 ---- *************** _pthread_rwlockattr_setpshared(pthread_r *** 96,98 **** --- 91,97 ---- return(0); } + __strong_reference(_pthread_rwlockattr_destroy, pthread_rwlockattr_destroy); + __strong_reference(_pthread_rwlockattr_getpshared, pthread_rwlockattr_getpshared); + __strong_reference(_pthread_rwlockattr_init, pthread_rwlockattr_init); + __strong_reference(_pthread_rwlockattr_setpshared, pthread_rwlockattr_setpshared); diff -c3pr thread.orig/thr_select.c thread/thr_select.c *** thread.orig/thr_select.c Mon Dec 8 18:20:56 2003 --- thread/thr_select.c Mon Jun 7 18:02:56 2004 *************** *** 43,50 **** #include #include "thr_private.h" - __weak_reference(__select, select); - int __select(int numfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout) --- 43,48 ---- *************** __select(int numfds, fd_set *readfds, fd *** 63,65 **** --- 61,65 ---- } return ret; } + + __strong_reference(__select, select); diff -c3pr thread.orig/thr_self.c thread/thr_self.c *** thread.orig/thr_self.c Thu Apr 17 22:04:16 2003 --- thread/thr_self.c Mon Jun 7 18:03:06 2004 *************** *** 34,41 **** #include #include "thr_private.h" - __weak_reference(_pthread_self, pthread_self); - pthread_t _pthread_self(void) { --- 34,39 ---- *************** _pthread_self(void) *** 45,47 **** --- 43,47 ---- /* Return the running thread pointer: */ return (_get_curthread()); } + + __strong_reference(_pthread_self, pthread_self); diff -c3pr thread.orig/thr_sem.c thread/thr_sem.c *** thread.orig/thr_sem.c Fri Feb 6 07:20:56 2004 --- thread/thr_sem.c Mon Jun 7 18:09:50 2004 *************** extern int pthread_cond_wait(pthread_con *** 47,58 **** extern int pthread_cond_timedwait(pthread_cond_t *, pthread_mutex_t *, struct timespec *); - __weak_reference(_sem_init, sem_init); - __weak_reference(_sem_wait, sem_wait); - __weak_reference(_sem_timedwait, sem_timedwait); - __weak_reference(_sem_post, sem_post); - - static inline int sem_check_validity(sem_t *sem) { --- 47,52 ---- *************** _sem_wait(sem_t *sem) *** 173,179 **** int _sem_timedwait(sem_t * __restrict sem, ! struct timespec * __restrict abs_timeout) { struct pthread *curthread; int retval; --- 167,173 ---- int _sem_timedwait(sem_t * __restrict sem, ! const struct timespec * __restrict abs_timeout) { struct pthread *curthread; int retval; *************** _sem_post(sem_t *sem) *** 260,262 **** --- 254,261 ---- return (retval); } + + __strong_reference(_sem_init, sem_init); + __strong_reference(_sem_wait, sem_wait); + __strong_reference(_sem_timedwait, sem_timedwait); + __strong_reference(_sem_post, sem_post); diff -c3pr thread.orig/thr_setprio.c thread/thr_setprio.c *** thread.orig/thr_setprio.c Mon Sep 16 01:45:36 2002 --- thread/thr_setprio.c Mon Jun 7 18:03:28 2004 *************** *** 34,41 **** #include #include "thr_private.h" - __weak_reference(_pthread_setprio, pthread_setprio); - int _pthread_setprio(pthread_t pthread, int prio) { --- 34,39 ---- *************** _pthread_setprio(pthread_t pthread, int *** 50,52 **** --- 48,52 ---- /* Return the error status: */ return (ret); } + + __strong_reference(_pthread_setprio, pthread_setprio); diff -c3pr thread.orig/thr_setschedparam.c thread/thr_setschedparam.c *** thread.orig/thr_setschedparam.c Sun Apr 20 21:02:56 2003 --- thread/thr_setschedparam.c Mon Jun 7 18:03:37 2004 *************** *** 36,43 **** #include #include "thr_private.h" - __weak_reference(_pthread_setschedparam, pthread_setschedparam); - int _pthread_setschedparam(pthread_t pthread, int policy, const struct sched_param *param) --- 36,41 ---- *************** _pthread_setschedparam(pthread_t pthread *** 134,136 **** --- 132,136 ---- } return (ret); } + + __strong_reference(_pthread_setschedparam, pthread_setschedparam); diff -c3pr thread.orig/thr_sigaction.c thread/thr_sigaction.c *** thread.orig/thr_sigaction.c Wed Sep 24 23:23:40 2003 --- thread/thr_sigaction.c Mon Jun 7 18:03:50 2004 *************** *** 36,43 **** #include #include "thr_private.h" - __weak_reference(_sigaction, sigaction); - int _sigaction(int sig, const struct sigaction * act, struct sigaction * oact) { --- 36,41 ---- *************** _sigaction(int sig, const struct sigacti *** 115,117 **** --- 113,117 ---- /* Return the completion status: */ return (ret); } + + __strong_reference(_sigaction, sigaction); diff -c3pr thread.orig/thr_sigaltstack.c thread/thr_sigaltstack.c *** thread.orig/thr_sigaltstack.c Thu Jan 1 16:38:42 2004 --- thread/thr_sigaltstack.c Mon Jun 7 18:10:59 2004 *************** __FBSDID("$FreeBSD: src/lib/libpthread/t *** 31,40 **** #include #include "thr_private.h" - __weak_reference(_sigaltstack, sigaltstack); - int ! _sigaltstack(stack_t *_ss, stack_t *_oss) { struct pthread *curthread = _get_curthread(); stack_t ss, oss; --- 31,38 ---- #include #include "thr_private.h" int ! _sigaltstack(const stack_t *_ss, stack_t *_oss) { struct pthread *curthread = _get_curthread(); stack_t ss, oss; *************** _thr_sigonstack(void *sp) *** 105,107 **** --- 103,106 ---- : 0); } + __strong_reference(_sigaltstack, sigaltstack); diff -c3pr thread.orig/thr_sigmask.c thread/thr_sigmask.c *** thread.orig/thr_sigmask.c Thu Sep 18 05:19:28 2003 --- thread/thr_sigmask.c Mon Jun 7 18:04:07 2004 *************** *** 40,47 **** #include #include "thr_private.h" - __weak_reference(_pthread_sigmask, pthread_sigmask); - int _pthread_sigmask(int how, const sigset_t *set, sigset_t *oset) { --- 40,45 ---- *************** _pthread_sigmask(int how, const sigset_t *** 111,113 **** --- 109,113 ---- *oset = oldset; return (ret); } + + __strong_reference(_pthread_sigmask, pthread_sigmask); diff -c3pr thread.orig/thr_sigpending.c thread/thr_sigpending.c *** thread.orig/thr_sigpending.c Sun Aug 17 20:58:29 2003 --- thread/thr_sigpending.c Mon Jun 7 18:04:15 2004 *************** *** 39,46 **** #include #include "thr_private.h" - __weak_reference(_sigpending, sigpending); - int _sigpending(sigset_t *set) { --- 39,44 ---- *************** _sigpending(sigset_t *set) *** 71,73 **** --- 69,73 ---- /* Return the completion status: */ return (ret); } + + __strong_reference(_sigpending, sigpending); diff -c3pr thread.orig/thr_sigprocmask.c thread/thr_sigprocmask.c *** thread.orig/thr_sigprocmask.c Sun Aug 17 20:58:29 2003 --- thread/thr_sigprocmask.c Mon Jun 7 18:04:24 2004 *************** *** 39,46 **** #include #include "thr_private.h" - __weak_reference(_sigprocmask, sigprocmask); - int _sigprocmask(int how, const sigset_t *set, sigset_t *oset) { --- 39,44 ---- *************** _sigprocmask(int how, const sigset_t *se *** 53,55 **** --- 51,55 ---- } return (ret); } + + __strong_reference(_sigprocmask, sigprocmask); diff -c3pr thread.orig/thr_sigsuspend.c thread/thr_sigsuspend.c *** thread.orig/thr_sigsuspend.c Mon Dec 8 18:20:56 2003 --- thread/thr_sigsuspend.c Mon Jun 7 18:04:32 2004 *************** *** 38,45 **** #include #include "thr_private.h" - __weak_reference(__sigsuspend, sigsuspend); - int _sigsuspend(const sigset_t *set) { --- 38,43 ---- *************** __sigsuspend(const sigset_t * set) *** 101,103 **** --- 99,103 ---- return (ret); } + + __strong_reference(__sigsuspend, sigsuspend); diff -c3pr thread.orig/thr_sigwait.c thread/thr_sigwait.c *** thread.orig/thr_sigwait.c Tue Mar 16 18:12:19 2004 --- thread/thr_sigwait.c Mon Jun 7 18:04:44 2004 *************** *** 39,48 **** #include #include "thr_private.h" - __weak_reference(__sigwait, sigwait); - __weak_reference(__sigtimedwait, sigtimedwait); - __weak_reference(__sigwaitinfo, sigwaitinfo); - static int lib_sigtimedwait(const sigset_t *set, siginfo_t *info, const struct timespec * timeout) --- 39,44 ---- *************** _sigwait(const sigset_t *set, int *sig) *** 200,202 **** --- 196,201 ---- return (ret); } + __strong_reference(__sigwait, sigwait); + __strong_reference(__sigtimedwait, sigtimedwait); + __strong_reference(__sigwaitinfo, sigwaitinfo); diff -c3pr thread.orig/thr_single_np.c thread/thr_single_np.c *** thread.orig/thr_single_np.c Thu May 23 21:32:28 2002 --- thread/thr_single_np.c Mon Jun 7 18:04:56 2004 *************** *** 34,41 **** #include #include - __weak_reference(_pthread_single_np, pthread_single_np); - int _pthread_single_np() { --- 34,39 ---- *************** int _pthread_single_np() *** 47,49 **** --- 45,49 ---- */ return (0); } + + __strong_reference(_pthread_single_np, pthread_single_np); diff -c3pr thread.orig/thr_sleep.c thread/thr_sleep.c *** thread.orig/thr_sleep.c Mon Dec 8 18:20:56 2003 --- thread/thr_sleep.c Mon Jun 7 18:05:04 2004 *************** *** 35,42 **** extern unsigned int __sleep(unsigned int); - __weak_reference(_sleep, sleep); - unsigned int _sleep(unsigned int seconds) { --- 35,40 ---- *************** _sleep(unsigned int seconds) *** 49,51 **** --- 47,51 ---- return (ret); } + + __strong_reference(_sleep, sleep); diff -c3pr thread.orig/thr_spec.c thread/thr_spec.c *** thread.orig/thr_spec.c Tue Aug 19 19:34:14 2003 --- thread/thr_spec.c Mon Jun 7 18:05:14 2004 *************** struct pthread_key { *** 48,59 **** /* Static variables: */ static struct pthread_key key_table[PTHREAD_KEYS_MAX]; - __weak_reference(_pthread_key_create, pthread_key_create); - __weak_reference(_pthread_key_delete, pthread_key_delete); - __weak_reference(_pthread_getspecific, pthread_getspecific); - __weak_reference(_pthread_setspecific, pthread_setspecific); - - int _pthread_key_create(pthread_key_t *key, void (*destructor) (void *)) { --- 48,53 ---- *************** _pthread_getspecific(pthread_key_t key) *** 232,234 **** --- 226,233 ---- data = NULL; return (data); } + + __strong_reference(_pthread_key_create, pthread_key_create); + __strong_reference(_pthread_key_delete, pthread_key_delete); + __strong_reference(_pthread_getspecific, pthread_getspecific); + __strong_reference(_pthread_setspecific, pthread_setspecific); diff -c3pr thread.orig/thr_suspend_np.c thread/thr_suspend_np.c *** thread.orig/thr_suspend_np.c Sun May 4 09:17:01 2003 --- thread/thr_suspend_np.c Mon Jun 7 18:05:26 2004 *************** *** 37,45 **** static void suspend_common(struct pthread *thread); - __weak_reference(_pthread_suspend_np, pthread_suspend_np); - __weak_reference(_pthread_suspend_all_np, pthread_suspend_all_np); - /* Suspend a thread: */ int _pthread_suspend_np(pthread_t thread) --- 37,42 ---- *************** suspend_common(struct pthread *thread) *** 107,109 **** --- 104,109 ---- #endif } } + + __strong_reference(_pthread_suspend_np, pthread_suspend_np); + __strong_reference(_pthread_suspend_all_np, pthread_suspend_all_np); diff -c3pr thread.orig/thr_switch_np.c thread/thr_switch_np.c *** thread.orig/thr_switch_np.c Thu Apr 17 22:04:16 2003 --- thread/thr_switch_np.c Mon Jun 7 18:05:36 2004 *************** *** 36,45 **** #include #include "thr_private.h" - - __weak_reference(_pthread_switch_add_np, pthread_switch_add_np); - __weak_reference(_pthread_switch_delete_np, pthread_switch_delete_np); - int _pthread_switch_add_np(pthread_switch_routine_t routine) { --- 36,41 ---- *************** _pthread_switch_delete_np(pthread_switch *** 51,53 **** --- 47,52 ---- { return (ENOTSUP); } + + __strong_reference(_pthread_switch_add_np, pthread_switch_add_np); + __strong_reference(_pthread_switch_delete_np, pthread_switch_delete_np); diff -c3pr thread.orig/thr_system.c thread/thr_system.c *** thread.orig/thr_system.c Mon Dec 8 18:20:56 2003 --- thread/thr_system.c Mon Jun 7 18:05:44 2004 *************** *** 35,42 **** extern int __system(const char *); - __weak_reference(_system, system); - int _system(const char *string) { --- 35,40 ---- *************** _system(const char *string) *** 49,51 **** --- 47,51 ---- return ret; } + + __strong_reference(_system, system); diff -c3pr thread.orig/thr_tcdrain.c thread/thr_tcdrain.c *** thread.orig/thr_tcdrain.c Mon Dec 8 18:20:56 2003 --- thread/thr_tcdrain.c Mon Jun 7 18:05:54 2004 *************** *** 35,42 **** extern int __tcdrain(int); - __weak_reference(_tcdrain, tcdrain); - int _tcdrain(int fd) { --- 35,40 ---- *************** _tcdrain(int fd) *** 49,51 **** --- 47,51 ---- return (ret); } + + __strong_reference(_tcdrain, tcdrain); diff -c3pr thread.orig/thr_vfork.c thread/thr_vfork.c *** thread.orig/thr_vfork.c Mon Apr 9 21:19:20 2001 --- thread/thr_vfork.c Mon Jun 7 18:06:04 2004 *************** *** 3,12 **** */ #include - __weak_reference(_vfork, vfork); - int _vfork(void) { return (fork()); } --- 3,12 ---- */ #include int _vfork(void) { return (fork()); } + + __strong_reference(_vfork, vfork); diff -c3pr thread.orig/thr_wait.c thread/thr_wait.c *** thread.orig/thr_wait.c Mon Dec 8 18:20:56 2003 --- thread/thr_wait.c Mon Jun 7 18:06:12 2004 *************** *** 34,41 **** extern int __wait(int *); - __weak_reference(_wait, wait); - pid_t _wait(int *istat) { --- 34,39 ---- *************** _wait(int *istat) *** 48,50 **** --- 46,50 ---- return ret; } + + __strong_reference(_wait, wait); diff -c3pr thread.orig/thr_wait4.c thread/thr_wait4.c *** thread.orig/thr_wait4.c Mon Dec 8 18:20:56 2003 --- thread/thr_wait4.c Mon Jun 7 18:06:20 2004 *************** *** 41,48 **** #include "thr_private.h" - __weak_reference(__wait4, wait4); - pid_t __wait4(pid_t pid, int *istat, int options, struct rusage *rusage) { --- 41,46 ---- *************** __wait4(pid_t pid, int *istat, int optio *** 55,57 **** --- 53,57 ---- return ret; } + + __strong_reference(__wait4, wait4); diff -c3pr thread.orig/thr_waitpid.c thread/thr_waitpid.c *** thread.orig/thr_waitpid.c Mon Dec 8 18:20:56 2003 --- thread/thr_waitpid.c Mon Jun 7 18:06:29 2004 *************** *** 36,43 **** extern int __waitpid(pid_t, int *, int); - __weak_reference(_waitpid, waitpid); - pid_t _waitpid(pid_t wpid, int *status, int options) { --- 36,41 ---- *************** _waitpid(pid_t wpid, int *status, int op *** 50,52 **** --- 48,52 ---- return ret; } + + __strong_reference(_waitpid, waitpid); diff -c3pr thread.orig/thr_write.c thread/thr_write.c *** thread.orig/thr_write.c Mon Dec 8 18:20:56 2003 --- thread/thr_write.c Mon Jun 7 18:06:37 2004 *************** *** 40,47 **** #include #include "thr_private.h" - __weak_reference(__write, write); - ssize_t __write(int fd, const void *buf, size_t nbytes) { --- 40,45 ---- *************** __write(int fd, const void *buf, size_t *** 54,56 **** --- 52,56 ---- return ret; } + + __strong_reference(__write, write); diff -c3pr thread.orig/thr_writev.c thread/thr_writev.c *** thread.orig/thr_writev.c Mon Dec 8 18:20:56 2003 --- thread/thr_writev.c Mon Jun 7 18:06:45 2004 *************** *** 42,49 **** #include #include "thr_private.h" - __weak_reference(__writev, writev); - ssize_t __writev(int fd, const struct iovec *iov, int iovcnt) { --- 42,47 ---- *************** __writev(int fd, const struct iovec *iov *** 56,58 **** --- 54,58 ---- return ret; } + + __strong_reference(__writev, writev); diff -c3pr thread.orig/thr_yield.c thread/thr_yield.c *** thread.orig/thr_yield.c Sun Aug 17 20:58:29 2003 --- thread/thr_yield.c Mon Jun 7 18:06:55 2004 *************** *** 34,42 **** #include #include "thr_private.h" - __weak_reference(_sched_yield, sched_yield); - __weak_reference(_pthread_yield, pthread_yield); - int _sched_yield(void) { --- 34,39 ---- *************** _pthread_yield(void) *** 71,73 **** --- 68,73 ---- /* Schedule the next thread: */ _thr_sched_switch(curthread); } + + __strong_reference(_sched_yield, sched_yield); + __strong_reference(_pthread_yield, pthread_yield); From owner-freebsd-current@FreeBSD.ORG Tue Jun 8 03:03:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F89916A4CE for ; Tue, 8 Jun 2004 03:03:28 +0000 (GMT) Received: from cmsrelay03.mx.net (cmsrelay03.mx.net [165.212.11.112]) by mx1.FreeBSD.org (Postfix) with SMTP id D696643D48 for ; Tue, 8 Jun 2004 03:03:27 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: from uadvg137.cms.usa.net (165.212.11.137) by cmsoutbound.mx.net with SMTP; 8 Jun 2004 03:03:27 -0000 Received: from optimator.noacks.org [70.240.196.83] by uadvg137.cms.usa.net (ASMTP/noackjr@usa.net) via mtad (C8.MAIN.3.13N) with ESMTP id 759iFHDDX0495M37; Tue, 08 Jun 2004 03:03:23 GMT X-USANET-Auth: 70.240.196.83 AUTH noackjr@usa.net optimator.noacks.org Received: from localhost (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id 70B5E6131; Mon, 7 Jun 2004 22:03:22 -0500 (CDT) Received: from optimator.noacks.org ([127.0.0.1]) by localhost (optimator.noacks.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 48049-06; Mon, 7 Jun 2004 22:03:20 -0500 (CDT) Received: from compgeek.noacks.org (compgeek [192.168.1.10]) by optimator.noacks.org (Postfix) with ESMTP id 80F676114; Mon, 7 Jun 2004 22:03:20 -0500 (CDT) Received: from [127.0.0.1] (localhost.noacks.org [127.0.0.1]) by compgeek.noacks.org (8.12.11/8.12.11) with ESMTP id i5833JBW088468; Mon, 7 Jun 2004 22:03:20 -0500 (CDT) (envelope-from noackjr@alumni.rice.edu) Message-ID: <40C52C77.4030407@alumni.rice.edu> Date: Mon, 07 Jun 2004 22:03:19 -0500 From: Jon Noack User-Agent: Mozilla Thunderbird 0.6 (X11/20040531) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Larry Rosenman References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at noacks.org cc: freebsd-current@freebsd.org Subject: Re: RADEON IGP 345m X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: noackjr@alumni.rice.edu List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 03:03:28 -0000 On 06/07/04 21:47, Larry Rosenman wrote: > I know XFree86 4.4.0 supports the ATI RADEON IGP 345M. Have we imported > that version to Ports yet? (or am I on the bleeding edge here)? First off, reading previous posts is always a good idea. The freebsd-x11@ archive (http://lists.freebsd.org/pipermail/freebsd-x11/) is the best resource for your question, but another person asked about XFree86 4.4 no more than 5.5 hours ago on this list and received an answer. In short, the update to 4.4 will happen Real Soon Now (tm). The longer version is that the 4.4 update is dependent on an update to imake, and the coordination between the XFree86 and xorg ports is slowing that down. The x11-servers/XFree86-4-Server-snap might support the IGP 345M (it's a snapshot of 4.4 from late in the development cycle -- it works fine on my Radeon 9800 Pro). Just replace x11-servers/XFree86-4-Server with it (using portupgrade: 'portupgrade -o x11-servers/XFree86-4-Server-snap x11-servers/XFree86-4-Server') and you should be good to go (may have to 'pkgdb -F' to clean up dependencies). Also, others have reported success with the x11-servers/xorg-server port. Jon Noack From owner-freebsd-current@FreeBSD.ORG Tue Jun 8 03:19:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE20F16A4CE; Tue, 8 Jun 2004 03:19:25 +0000 (GMT) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45EA743D2F; Tue, 8 Jun 2004 03:19:25 +0000 (GMT) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (210.50.40.174) by smtp01.syd.iprimus.net.au (7.0.024) id 40B7A0DA002EB19C; Tue, 8 Jun 2004 13:19:23 +1000 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id 567F841CE; Tue, 8 Jun 2004 13:21:11 +1000 (EST) Date: Tue, 8 Jun 2004 13:21:11 +1000 From: Tim Robbins To: Sean McNeil Message-ID: <20040608032111.GA43718@cat.robbins.dropbear.id.au> References: <1086663455.1258.79.camel@server.mcneil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1086663455.1258.79.camel@server.mcneil.com> User-Agent: Mutt/1.4.1i cc: freebsd-current@freebsd.org cc: freebsd-gnome@freebsd.org cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 03:19:26 -0000 On Mon, Jun 07, 2004 at 07:57:35PM -0700, Sean McNeil wrote: > > Up front, I'd like to make a few apologies: > > 1) I am sorry for the length of this email. > 2) Although some very valid opinions have been expressed, I respectfully > have to disagree. This email will hopefully strengthen my position. > > The problem: > > (If you just want kse threads to work for you properly, just apply the > patch at the end of this email and try it out). > > kse threads on amd64 doesn't work with gnome. It crashes applications > here and there. gnome-terminal is essentially unusable. > > I strongly believe this to be a binding issue. I've examined rtld and > I'm satisfied that it is behaving appropriately, so I took a long hard > look at how FreeBSD has implemented the pthread interface, how it is > being used, and how people expect it to behave. [...] Your patch looks useful in its own right, but GNOME, Firefox, Mozilla and XMMS have not crashed once for me since I fixed context restoring in libpthread on amd64. Strong references cannot possibly make the old version of context.S work correctly. I would be interested in hearing whether you still have problems with libpthread and GNOME after updating your system, both with and without nss_ldap. Tim From owner-freebsd-current@FreeBSD.ORG Tue Jun 8 03:33:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7783816A4CE; Tue, 8 Jun 2004 03:33:11 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B3FA43D53; Tue, 8 Jun 2004 03:33:11 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 0A710FD06C; Mon, 7 Jun 2004 20:33:11 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00675-05; Mon, 7 Jun 2004 20:33:10 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 90B6EFD01A; Mon, 7 Jun 2004 20:33:10 -0700 (PDT) From: Sean McNeil To: Tim Robbins In-Reply-To: <20040608032111.GA43718@cat.robbins.dropbear.id.au> References: <1086663455.1258.79.camel@server.mcneil.com> <20040608032111.GA43718@cat.robbins.dropbear.id.au> Content-Type: text/plain Message-Id: <1086665590.1817.3.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 07 Jun 2004 20:33:10 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-current@freebsd.org cc: freebsd-gnome@freebsd.org cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 03:33:11 -0000 On Mon, 2004-06-07 at 20:21, Tim Robbins wrote: > On Mon, Jun 07, 2004 at 07:57:35PM -0700, Sean McNeil wrote: > > > > > Up front, I'd like to make a few apologies: > > > > 1) I am sorry for the length of this email. > > 2) Although some very valid opinions have been expressed, I respectfully > > have to disagree. This email will hopefully strengthen my position. > > > > The problem: > > > > (If you just want kse threads to work for you properly, just apply the > > patch at the end of this email and try it out). > > > > kse threads on amd64 doesn't work with gnome. It crashes applications > > here and there. gnome-terminal is essentially unusable. > > > > I strongly believe this to be a binding issue. I've examined rtld and > > I'm satisfied that it is behaving appropriately, so I took a long hard > > look at how FreeBSD has implemented the pthread interface, how it is > > being used, and how people expect it to behave. > [...] > > Your patch looks useful in its own right, but GNOME, Firefox, Mozilla > and XMMS have not crashed once for me since I fixed context restoring in > libpthread on amd64. Strong references cannot possibly make the old > version of context.S work correctly. > > I would be interested in hearing whether you still have problems with > libpthread and GNOME after updating your system, both with and without > nss_ldap. Great, Tim! I did indeed get this fix when testing my changes. The patch I posted still has some redeeming value, but yours was the key to gnome stability for me as well. Sean From owner-freebsd-current@FreeBSD.ORG Tue Jun 8 03:48:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE14116A4CE for ; Tue, 8 Jun 2004 03:48:01 +0000 (GMT) Received: from dsl-mail.kamp.net (mail.kamp-dsl.de [195.62.99.42]) by mx1.FreeBSD.org (Postfix) with SMTP id BC25143D1F for ; Tue, 8 Jun 2004 03:48:00 +0000 (GMT) (envelope-from root@pukruppa.de) Received: (qmail 4363 invoked by uid 513); 8 Jun 2004 03:51:05 -0000 Received: from root@pukruppa.de by dsl-mail by uid 89 with qmail-scanner-1.21 Clear:RC:1(213.146.114.24):SA:0(-4.9/5.0):. Processed in 0.395539 secs); 08 Jun 2004 03:51:05 -0000 X-Spam-Status: No, hits=-4.9 required=5.0 Received: from unknown (HELO reverse-213-146-114-24.dialin.kamp-dsl.de) (213.146.114.24) by dsl-mail.kamp.net with SMTP; 8 Jun 2004 03:51:04 -0000 Date: Tue, 8 Jun 2004 05:48:53 +0200 (CEST) From: Peter Ulrich Kruppa X-X-Sender: root@pukruppa.net To: Brian Feldman In-Reply-To: <20040607205827.GD20308@green.homeunix.org> Message-ID: <20040608054738.B1838@pukruppa.net> References: <20040607160206.G854@pukruppa.net> <20040607172132.GA22717@cell.sick.ru> <20040607205827.GD20308@green.homeunix.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: Julian Elischer cc: Gleb Smirnoff cc: FreeBSD current users cc: Bosko Milekic cc: net@FreeBSD.org Subject: Re: HEADSUP! netgraph Metadata changing. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 03:48:01 -0000 On Mon, 7 Jun 2004, Brian Feldman wrote: > On Mon, Jun 07, 2004 at 09:21:32PM +0400, Gleb Smirnoff wrote: > > Please try removing both KASSERT() calls from NG_MKMESSAGE() in > src/sys/sys/ng_message.h, and then rebuild (and unload and reload) > all netgraph modules. The KASSERT() lines appear to be entirely > bogus now. Yes, they are. Thanks to everyone. Uli. +---------------------------+ | Peter Ulrich Kruppa | | Wuppertal | | Germany | +---------------------------+ From owner-freebsd-current@FreeBSD.ORG Tue Jun 8 03:56:44 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16DC816A4CE for ; Tue, 8 Jun 2004 03:56:44 +0000 (GMT) Received: from omoikane.mb.skyweb.ca (omoikane.mb.skyweb.ca [64.42.246.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E08143D48 for ; Tue, 8 Jun 2004 03:56:43 +0000 (GMT) (envelope-from mark@skyweb.ca) Received: by omoikane.mb.skyweb.ca (Postfix, from userid 1001) id B91F261D2E; Mon, 7 Jun 2004 22:56:43 -0500 (CDT) From: Mark Johnston To: current@freebsd.org Date: Mon, 7 Jun 2004 22:56:43 -0500 User-Agent: KMail/1.6.1 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200406072256.43420.mjohnston@skyweb.ca> Subject: cvs-src summary for May 31 - June 7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 03:56:44 -0000 FreeBSD cvs-src summary for 31/05/04 to 07/06/04 ++++++++++++++++++++++++++++++++++++++++++++++++ This is a regular weekly summary of FreeBSD's cutting-edge development. It is intended to help the FreeBSD community keep up with the fast-paced work going on in FreeBSD-CURRENT by distilling the deluge of data from the CVS mailing list into a (hopefully) easy-to-read newsletter. This newsletter is marked up in reStructuredText_, so any odd punctuation that you see is likely intended for the reST parser. .. _reStructuredText: http://docutils.sourceforge.net/rst.html You can get old summaries, and an HTML version of this one, at http://www.xl0.org/FreeBSD/. Please send any comments to Mark Johnston (mark at xl0.org). For Lukasz Dudek and Szymon Roczniak's Polish translations of these summaries, which may lag the English ones slightly, please see http://mocart.pinco.pl/FreeBSD/. .. contents:: ============ New features ============ New per-device sysctls being used --------------------------------- Dag-Erling Smorgrav (des) made several commits updating drivers to use the `new device-specific sysctl tree`_, named "dev". He first did the fxp driver for Intel Ethernet cards, then the ndis driver, for emulation of Windows's NDIS layer. .. _`new device-specific sysctl tree`: http://excel.xl0.org/FreeBSD/31-05-04.html#sysctl-subtrees-created-for-each-device http://www.freebsd.org/cgi/mid.cgi?200406041023.i54AN1V6015457 Major enhancements to sunlabel ------------------------------ Joerg Wunsch (joerg) committed several significant enhancements to sunlabel, which edits partitions on Sun disks. He added the -c option, to calculate sizes in cylinders and the -h option, to use human-readable numbers. He also implemented VTOC (volume table of contents), which allows sunlabel to achieve the full functionality of Solaris's format command, with some enhancements, like the ability to edit volume-manager-encapsulated labels. He also added a proper man page. http://www.freebsd.org/cgi/mid.cgi?200406012032.i51KWacs091996 accept locking added -------------------- Robert Watson (rwatson) added accept locking, which serializes access to a number of socket-related variables used by the accept system call. He also rewrote some of the socket code to correct locking problems and race conditions. http://www.freebsd.org/cgi/mid.cgi?200406020415.i524Fdp0016469 newsyslog gains D flag ---------------------- Garance A. Drosehn (gad) added a new flag, D, to newsyslog.conf. When the flag is specified on one of the entries, rotated log files will have the NODUMP flag set on them after they are created, to prevent their being backed up by dump. http://www.freebsd.org/cgi/mid.cgi?200406032341.i53NfnNk061252 arl driver MFC'ed ----------------- Max Khon merged the arl driver, for Aironet Arlan 655 wireless network adapters, to 4.x. He also merged the related arlcontrol utility. http://www.freebsd.org/cgi/mid.cgi?200406021906.i52J6dm6037848 =============== Notable changes =============== Outdated MIDI drivers and framework removed ------------------------------------------- Seigo Tanimura (tanimura) removed the MIDI drivers and framework, since they will soon be replaced with a new module-friendly MIDI implementation by Matthew Kanner (matk). http://www.freebsd.org/cgi/mid.cgi?200406010622.i516MxTj077527 tty code cleanup ---------------- Poul-Henning Kamp (phk) made some large cleanups to the tty code, with the goal of eliminating the ttyregister call in favor of ttymalloc, and using functions to manipulate tty objects instead of modifying the object directly. This will make it possible to add proper reference counting to the tty code. (many) arlconfig changed to arlcontrol ------------------------------- Max Khon (fjoe) renamed arlconfig, the tool for configurating the Aironet Arlan 655, to arlcontrol. http://www.freebsd.org/cgi/mid.cgi?200406010738.i517cBdv092921 ================= Discussion topics ================= Using the new device sysctl tree -------------------------------- Maxime Henrion (mux) changed the fxp driver to use the device sysctl tree, as mentioned `last week`_. This spawned a couple of related threads. First, Nate Lawson (njl) asked whether it's possible to suppress printing of the device-tree-specific nodes with % signs in them; Maxime didn't know of any way other than just using grep -v to filter them out. Scott Long (scottl) noted that the scheme Maxime had set up, using individual device names in the tree (like dev.fxp0), doesn't allow for global variables instead of per-interface ones. Maxime answered that the fxp driver's variables don't have to be global, but that the problem will probably come up in the future for drivers that use global settings. He speculated about a userland program to add the functionality; Scott pointed out that that won't work for settings needed to boot the system. .. _`last week`: http://excel.xl0.org/FreeBSD/31-05-04.html#sysctl-subtrees-created-for-each-device Dag-Erling Smorgrav (des) responded to Scott's suggestion of using dev.fxp.0.varname and dev.fxp.globalvarname to represent interface-specific vs. global values, saying it would be easy to do and that he would work on patches. M. Warner Losh (imp) asked how identical global and per-interface variables would be treated, and what API could be used to set the variables. Dag-Erling answered that it's up to the driver author to decide how global vs. per-interface variables will be treated, and also noted that he planned to use a scheme like dev.fxp.fxp0 instead of dev.fxp.0, in case there were multiple devices with the same number but different names. Warner answered that that should never happen, also asking about the API. Dag-Erling `explained the api`_ and decided to use the dev.fxp.0 scheme instead of dev.fxp.fxp0. He later `committed code`_ to implement this. .. _`explained the api`: http://www.freebsd.org/cgi/mid.cgi?xzp3c5c8i1w.fsf@dwp.des.no .. _`committed code`: http://www.freebsd.org/cgi/mid.cgi?200406041023.i54AN1V6015457 http://www.freebsd.org/cgi/mid.cgi?200406022252.i52MqJFp094240 bios_string function added -------------------------- Poul-Henning Kamp (phk) added a bios_string function, which searches a given range of the BIOS for the supplied string. The function is intended for looking for specific strings in the BIOS to identify a platform. Nate Lawson (njl) asked whether the need to align memory should be addressed in the function, and also asked about whether BIOS memory is all mapped into kernel memory, as Poul-Henning's code treats it to be. David Xu answered that 4 megabytes of the BIOS is mapped, and Poul-Henning said that it is all mapped, as far as he knows; he also suggested waiting on the alignment until it's shown to be needed. Nate responded that ACPI BIOS access must be 16-byte-aligned, and John Baldwin (jhb) added that the multiprocessor table, $PIR, _32_, and $PnP must also be 16-byte-aligned. John Baldwin asked whether Poul-Henning's code is very different from bios_sigsearch. Poul-Henning answered that bios_string allows you to search any range, as opposed to bios_sigsearch, which is limited. John suggested one could be implemented in terms of the other; Poul-Henning answered that he was not against merging them, but that it may not be needed, as the functions are small. David O'Brien (obrien) suggested that the function could go into a machine-independent file, since it's usable on amd64 as-is. John answered that he doesn't consider it machine-independent, but that it could go in a tree dedicated to x86 processors. David agreed. http://www.freebsd.org/cgi/mid.cgi?200406032236.i53MaOj5046199 =================== Important bug fixes =================== Routing table manipulation by jailed root fixed ----------------------------------------------- Colin Percival (cperciva) applied a patch to the jail code that prevents a jailed root user from manipulating the system's routing table. This issue was present in 4.8 and 4.9, but no 5.x releases, and is also fixed in 4.10-RELEASE. This bug is covered by `FreeBSD-SA-04:12.jailroute`_, which credits its discovery to Pawel Malachowski. .. _`FreeBSD-SA-04:12.jailroute`: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-04:12.jailroute.asc http://www.freebsd.org/cgi/mid.cgi?200406071742.i57HggwA076377 Core dumps over 2 GB fixed on 64-bit platforms ---------------------------------------------- Tim J. Robbins fixed a bug in the core dumping code that prevented it from dumping core files greater than 2 GB on 64-bit platforms. The bug was reported by Willem Jan Withagen in `PR 67546`_, but Tim used a different patch. .. _`PR 67546`: http://www.freebsd.org/cgi/query-pr.cgi?pr=67546 http://www.freebsd.org/cgi/mid.cgi?200406050218.i552ISvl057589 =============== Other bug fixes =============== Maxim Konovalov (maxim) merged a fix for a buffer overrun in the IP output code to 4.x. The bug was reported by Andrei Iltchenko. http://www.freebsd.org/cgi/mid.cgi?200406010738.i517cuit092996 John Baldwin (jhb) fixed a panic on systems with multiple PCI bridges and ACPI turned off. http://www.freebsd.org/cgi/mid.cgi?200406011951.i51JpTEM081637 John Baldwin (jhb) fixed a bug in 4.x that could cause divide-by-zero faults on machines without Hyperthreading. http://www.freebsd.org/cgi/mid.cgi?200406021442.i52Egxwe072518 Bill Paul (wpaul) fixed NDIS support for the Intel 2100 Centrino wireless driver. http://www.freebsd.org/cgi/mid.cgi?200406040443.i544haeR039396 Bruce Evans (bde) fixed several bugs in the floating-point math code that caused incorrect results. Some of the bugs were hidden on i386 systems by a precision-enhancing trick. http://www.freebsd.org/cgi/mid.cgi?200406011808.i51I8dCA053190 http://www.freebsd.org/cgi/mid.cgi?200406011903.i51J3VHL066311 http://www.freebsd.org/cgi/mid.cgi?200406021709.i52H95UO010571 David Schultz (das) fixed a bug in the math code for calculating tangents that affected precision. http://www.freebsd.org/cgi/mid.cgi?200406020439.i524dTSo020632 From owner-freebsd-current@FreeBSD.ORG Tue Jun 8 04:21:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8282D16A4D0 for ; Tue, 8 Jun 2004 04:21:19 +0000 (GMT) Received: from dsl-mail.kamp.net (mail.kamp-dsl.de [195.62.99.42]) by mx1.FreeBSD.org (Postfix) with SMTP id 74E7A43D5A for ; Tue, 8 Jun 2004 04:21:18 +0000 (GMT) (envelope-from root@pukruppa.de) Received: (qmail 23753 invoked by uid 513); 8 Jun 2004 04:24:10 -0000 Received: from root@pukruppa.de by dsl-mail by uid 89 with qmail-scanner-1.21 Clear:RC:1(213.146.114.24):SA:0(-4.9/5.0):. Processed in 0.526516 secs); 08 Jun 2004 04:24:10 -0000 X-Spam-Status: No, hits=-4.9 required=5.0 Received: from unknown (HELO reverse-213-146-114-24.dialin.kamp-dsl.de) (213.146.114.24) by dsl-mail.kamp.net with SMTP; 8 Jun 2004 04:24:10 -0000 Date: Tue, 8 Jun 2004 06:22:01 +0200 (CEST) From: Peter Ulrich Kruppa X-X-Sender: root@pukruppa.net To: Mayo In-Reply-To: <4BCF8FCC-B8C8-11D8-A192-000A9597E310@mayo.sk> Message-ID: <20040608061715.C64702@pukruppa.net> References: <1962.192.168.0.200.1086642601.squirrel@192.168.0.200> <4BCF8FCC-B8C8-11D8-A192-000A9597E310@mayo.sk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: Mike Jakubik cc: freebsd-current@freebsd.org Subject: Re: XFree86 4.4? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 04:21:19 -0000 On Mon, 7 Jun 2004, Mayo wrote: > I found the xorg server and libs work very well (I just pkg_delete the XFree > ones, isntalled xorg ones, and fixed dependencies). Actually there is only one thing I worry about: Does xorg use the same XF86Config file? (installing and deinstalling software is no problem, but it took me some days to work out a usable configuration) Uli. > > No problems so far. xorg-clients is the last one to get going, but there are > some compile errors in there > (http://www.freebsd.org/cgi/query-pr.cgi?pr=67649). I'm currently using the > XFree clients that I had installed from before (from Xfree 4.3). > > mayo > > > On Jun 7, 2004, at 14:10, Mike Jakubik wrote: > >> Hello, >> >> I was curious if anyone is working on porting XFree86 4.4 to FreeBSD. It >> would be nice to have the extra graphics chip support, specially for 5.3. >> >> Thanks. >> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > +---------------------------+ | Peter Ulrich Kruppa | | Wuppertal | | Germany | +---------------------------+ From owner-freebsd-current@FreeBSD.ORG Tue Jun 8 04:32:05 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 510A016A4CE; Tue, 8 Jun 2004 04:32:05 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBFA743D5C; Tue, 8 Jun 2004 04:32:04 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i584W1tD015956; Tue, 8 Jun 2004 00:32:04 -0400 (EDT) Date: Tue, 8 Jun 2004 00:32:01 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086663455.1258.79.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: freebsd-gnome@freebsd.org cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 04:32:05 -0000 On Mon, 7 Jun 2004, Sean McNeil wrote: > > Up front, I'd like to make a few apologies: > > 1) I am sorry for the length of this email. > 2) Although some very valid opinions have been expressed, I respectfully > have to disagree. This email will hopefully strengthen my position. Please stop spamming multiple lists. No, I don't want to litter all our thread libraries with strong references. As I've said before, build your shared libraries correctly so they don't bring in the threads library. -- Dan Eischen From owner-freebsd-current@FreeBSD.ORG Tue Jun 8 04:35:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C95516A4CE for ; Tue, 8 Jun 2004 04:35:00 +0000 (GMT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21A2543D31 for ; Tue, 8 Jun 2004 04:35:00 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from [192.168.0.103] (c-24-21-18-195.client.comcast.net[24.21.18.195]) by comcast.net (rwcrmhc11) with SMTP id <2004060804345201300crf3ie>; Tue, 8 Jun 2004 04:34:57 +0000 From: Eric Anholt To: Peter Ulrich Kruppa In-Reply-To: <20040608061715.C64702@pukruppa.net> References: <1962.192.168.0.200.1086642601.squirrel@192.168.0.200> <4BCF8FCC-B8C8-11D8-A192-000A9597E310@mayo.sk> <20040608061715.C64702@pukruppa.net> Content-Type: text/plain Message-Id: <1086669292.779.10.camel@leguin> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 07 Jun 2004 21:34:52 -0700 Content-Transfer-Encoding: 7bit cc: Mayo cc: freebsd-current@freebsd.org Subject: Re: XFree86 4.4? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 04:35:00 -0000 On Mon, 2004-06-07 at 21:22, Peter Ulrich Kruppa wrote: > On Mon, 7 Jun 2004, Mayo wrote: > > > I found the xorg server and libs work very well (I just pkg_delete the XFree > > ones, isntalled xorg ones, and fixed dependencies). > Actually there is only one thing I worry about: > Does xorg use the same XF86Config file? > (installing and deinstalling software is no problem, but it took > me some days to work out a usable configuration) Yes, though if it finds its own xorg.conf file it'll prefer that. -- Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Jun 8 04:48:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF95416A4D5; Tue, 8 Jun 2004 04:48:46 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0A3243D45; Tue, 8 Jun 2004 04:48:45 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.10/8.12.10) id i584mjND047596; Mon, 7 Jun 2004 23:48:45 -0500 (CDT) (envelope-from dan) Date: Mon, 7 Jun 2004 23:48:45 -0500 From: Dan Nelson To: Daniel Eischen Message-ID: <20040608044844.GA89198@dan.emsphone.com> References: <1086663455.1258.79.camel@server.mcneil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 5.2-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: freebsd-amd64@freebsd.org cc: freebsd-current@freebsd.org cc: Sean McNeil cc: freebsd-gnome@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 04:48:46 -0000 In the last episode (Jun 08), Daniel Eischen said: > No, I don't want to litter all our thread libraries with strong > references. As I've said before, build your shared libraries > correctly so they don't bring in the threads library. A good addition to bsd.port.mk, right next to the "possible network server" etc checks, might be to run ldd on all installed shared libraries and print a warning if any threads libraries show up. There are a huge number of ports that install shlibs linked to libpthreads. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Tue Jun 8 05:13:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D791F16A4D0; Tue, 8 Jun 2004 05:13:37 +0000 (GMT) Received: from creme-brulee.marcuscom.com (rrcs-midsouth-24-172-16-118.biz.rr.com [24.172.16.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3106143D46; Tue, 8 Jun 2004 05:13:37 +0000 (GMT) (envelope-from marcus@marcuscom.com) Received: from [192.168.1.4] (shumai.marcuscom.com [192.168.1.4]) i585CdRw096687; Tue, 8 Jun 2004 01:12:39 -0400 (EDT) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: Daniel Eischen In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-4faQEVN185PHyZKJ00vz" Organization: MarcusCom, Inc. Message-Id: <1086671609.18374.18.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 08 Jun 2004 01:13:29 -0400 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on creme-brulee.marcuscom.com cc: freebsd-amd64@freebsd.org cc: freebsd-current@freebsd.org cc: Sean McNeil cc: freebsd-gnome@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 05:13:38 -0000 --=-4faQEVN185PHyZKJ00vz Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2004-06-08 at 00:32, Daniel Eischen wrote: > On Mon, 7 Jun 2004, Sean McNeil wrote: >=20 > >=20 > > Up front, I'd like to make a few apologies: > >=20 > > 1) I am sorry for the length of this email. > > 2) Although some very valid opinions have been expressed, I respectfull= y > > have to disagree. This email will hopefully strengthen my position. >=20 > Please stop spamming multiple lists. >=20 > No, I don't want to litter all our thread libraries with strong reference= s. > As I've said before, build your shared libraries correctly so they don't > bring in the threads library. In order to do this, I'm a strong proponent of making -pthread the default PTHREAD_LIBS from 4.X and 5.X. This will do the right thing in all cases, and reduces diffs among branches. What is keeping this from happening from a threading standpoint? Joe --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-4faQEVN185PHyZKJ00vz Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAxUr5b2iPiv4Uz4cRAm8EAKCNndWyv3S5K6+bTsCc+F6MkQIyJgCgksgJ 4S+uSdmI4eKIGyXUUEbBDcs= =1kPV -----END PGP SIGNATURE----- --=-4faQEVN185PHyZKJ00vz-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 8 05:21:42 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A1A316A4CE; Tue, 8 Jun 2004 05:21:42 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id C833543D54; Tue, 8 Jun 2004 05:21:41 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from freebsd.org (junior-wifi.samsco.home [192.168.0.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i585NvTj001259; Mon, 7 Jun 2004 23:23:58 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <40C54CC4.8090602@freebsd.org> Date: Mon, 07 Jun 2004 23:21:08 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040304 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Marcus Clarke References: <1086671609.18374.18.camel@shumai.marcuscom.com> In-Reply-To: <1086671609.18374.18.camel@shumai.marcuscom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-amd64@freebsd.org cc: freebsd-gnome@freebsd.org cc: freebsd-threads@freebsd.org cc: freebsd-current@freebsd.org cc: Sean McNeil Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 05:21:42 -0000 Joe Marcus Clarke wrote: > On Tue, 2004-06-08 at 00:32, Daniel Eischen wrote: > >>On Mon, 7 Jun 2004, Sean McNeil wrote: >> >> >>>Up front, I'd like to make a few apologies: >>> >>>1) I am sorry for the length of this email. >>>2) Although some very valid opinions have been expressed, I respectfully >>>have to disagree. This email will hopefully strengthen my position. >> >>Please stop spamming multiple lists. >> >>No, I don't want to litter all our thread libraries with strong references. >>As I've said before, build your shared libraries correctly so they don't >>bring in the threads library. > > > In order to do this, I'm a strong proponent of making -pthread the > default PTHREAD_LIBS from 4.X and 5.X. This will do the right thing in > all cases, and reduces diffs among branches. What is keeping this from > happening from a threading standpoint? > > Joe > If you're going to change default behaviour like this then you need to do it before 5.3 and live with the change for the entire life of 5.x. I oppose changing it in 4.x. Scott From owner-freebsd-current@FreeBSD.ORG Tue Jun 8 05:24:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A5D816A4CE; Tue, 8 Jun 2004 05:24:56 +0000 (GMT) Received: from creme-brulee.marcuscom.com (rrcs-midsouth-24-172-16-118.biz.rr.com [24.172.16.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89D5343D45; Tue, 8 Jun 2004 05:24:55 +0000 (GMT) (envelope-from marcus@marcuscom.com) Received: from [192.168.1.4] (shumai.marcuscom.com [192.168.1.4]) i585Nvel096804; Tue, 8 Jun 2004 01:23:57 -0400 (EDT) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: Scott Long In-Reply-To: <40C54CC4.8090602@freebsd.org> References: <1086671609.18374.18.camel@shumai.marcuscom.com> <40C54CC4.8090602@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-BHBN6it8T3voSfmtqZO4" Organization: MarcusCom, Inc. Message-Id: <1086672287.18374.22.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 08 Jun 2004 01:24:47 -0400 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on creme-brulee.marcuscom.com cc: freebsd-amd64@freebsd.org cc: freebsd-gnome@freebsd.org cc: freebsd-threads@freebsd.org cc: freebsd-current@freebsd.org cc: Sean McNeil Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 05:24:56 -0000 --=-BHBN6it8T3voSfmtqZO4 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2004-06-08 at 01:21, Scott Long wrote: > Joe Marcus Clarke wrote: > > On Tue, 2004-06-08 at 00:32, Daniel Eischen wrote: > >=20 > >>On Mon, 7 Jun 2004, Sean McNeil wrote: > >> > >> > >>>Up front, I'd like to make a few apologies: > >>> > >>>1) I am sorry for the length of this email. > >>>2) Although some very valid opinions have been expressed, I respectful= ly > >>>have to disagree. This email will hopefully strengthen my position. > >> > >>Please stop spamming multiple lists. > >> > >>No, I don't want to litter all our thread libraries with strong referen= ces. > >>As I've said before, build your shared libraries correctly so they don'= t > >>bring in the threads library. > >=20 > >=20 > > In order to do this, I'm a strong proponent of making -pthread the > > default PTHREAD_LIBS from 4.X and 5.X. This will do the right thing in > > all cases, and reduces diffs among branches. What is keeping this from > > happening from a threading standpoint? > >=20 > > Joe > >=20 >=20 > If you're going to change default behaviour like this then you need to > do it before 5.3 and live with the change for the entire life of 5.x. > I oppose changing it in 4.x. Right, this would only be a change for 5.X, and would make it identical to 4.X. -pthread works for 5.X right now, and will link executables to libpthread. Shared objects will only use libpthread to resolve symbols at link-time. Joe >=20 > Scott --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-BHBN6it8T3voSfmtqZO4 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAxU2fb2iPiv4Uz4cRAqf5AJ9SfU4UTuiLp7I2I3Etf47S465qogCfRYdO O0S9uJCFTifzADBw6cK3euE= =IIbB -----END PGP SIGNATURE----- --=-BHBN6it8T3voSfmtqZO4-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 8 05:56:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF27F16A4CE for ; Tue, 8 Jun 2004 05:56:25 +0000 (GMT) Received: from afields.ca (afields.ca [216.194.67.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0B4643D45 for ; Tue, 8 Jun 2004 05:56:25 +0000 (GMT) (envelope-from afields@afields.ca) Received: from afields.ca (localhost.afields.ca [127.0.0.1]) by afields.ca (8.12.6/8.12.9) with ESMTP id i585uPSd001854; Tue, 8 Jun 2004 01:56:25 -0400 (EDT) (envelope-from afields@afields.ca) Received: (from afields@localhost) by afields.ca (8.12.6/8.12.9/Submit) id i585uOMH001853; Tue, 8 Jun 2004 01:56:24 -0400 (EDT) (envelope-from afields) Date: Tue, 8 Jun 2004 01:56:24 -0400 From: Allan Fields To: "Alastair G. Hogge" Message-ID: <20040608055624.GC59752@afields.ca> References: <200406061940.15400.agh@tpg.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406061940.15400.agh@tpg.com.au> User-Agent: Mutt/1.4i cc: current@freebsd.org Subject: Re: Custom kernels causing Promise ATA RAID to go down X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 05:56:25 -0000 On Sun, Jun 06, 2004 at 07:40:15PM +1000, Alastair G. Hogge wrote: > For a couple of weeks now I've been having problems with my custom kernel > crashing the system. I've re-cvsup'd and nuked /usr/obj and rebuild worlds > > The problem is that my kernel keeps causing ATA DMA READ/WRITE > errors and then eventually causing my RAID array to go down, thus > needing a deletation and re-definition thru the BIOS. Plus uncountable > fsck run thru. Yup, it sucks.. basically if your RAID goes bad, with most Promise controllers you need to reboot into BIOS and wait a long time for it to rebuild. I found the Promise BIOS a little lacking. I'm not a fan of oblique menu-based tools, especially when working w/ disks. Online rebuild is available on some ATA controllers but can also be slow. > I don't know how to capture and store the output. As the system just basicly > hangs and freezes the keyboard. Most of the time I've been X, which can only > be solved with a hard reboot. Also, just curious, but are you swapping off the RAID? If your RAID has read/write errors and you use it for swap, it is likely that it will cause the system to lock, possibly including the console. Do you have a second machine to use as a serial console? Another thing to try: try pinging the host and see if it responds. I use a null-modem cable and tip(1): When I was having problems w/ my Promise controller, I'd typically capture the output using script(1) or screen(1). > Running a GENERIC kernel is (with debuging things removed) is so slow. X/KDE > performs so poorly now. What's interesting is why this only happens w/ your custom kernels. I've also experienced instability with Promise RAID controllers in the past but didn't ever use a GENERIC kernel. I'm interested in this issue, but don't know if it's related. Also: Perhaps your Promise controller or drives are overheating? -- Allan Fields, AFRSL - http://afields.ca 2D4F 6806 D307 0889 6125 C31D F745 0D72 39B4 5541 From owner-freebsd-current@FreeBSD.ORG Tue Jun 8 06:33:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 800D616A4CE for ; Tue, 8 Jun 2004 06:33:17 +0000 (GMT) Received: from www.russia.cz (web.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DCF843D2D for ; Tue, 8 Jun 2004 06:33:16 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from portaone.com (localhost [127.0.0.1]) (authenticated bits=0) by www.russia.cz (8.12.8p2/8.12.8) with ESMTP id i586X9I6043224; Tue, 8 Jun 2004 08:33:13 +0200 (CEST) (envelope-from sobomax@portaone.com) Message-ID: <40C55D96.1000108@portaone.com> Date: Tue, 08 Jun 2004 09:32:54 +0300 From: Maxim Sobolev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, ru, uk MIME-Version: 1.0 To: Alexander Leidinger References: <40C3CC0A.2030300@portaone.com> <20040607135004.24050449@Magellan.Leidinger.net> In-Reply-To: <20040607135004.24050449@Magellan.Leidinger.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: Project Evil & ACX100-based cards (D-Link DWL-520+) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 06:33:17 -0000 Alexander Leidinger wrote: > On Mon, 07 Jun 2004 04:59:38 +0300 > Maxim Sobolev wrote: > > >>Hi Bill, >> >>I'm trying to make my D-Link DWL-520+ card working with if_ndis, but no >>luck yet. The card is correctly detected, driver attaches to it. If I >>configure it in the adhoc mode it is seen from the nearby machine and >>connected to, but traffic doesn't flow. :-( >> >>Any ideas? Please let me know if more information is necessary. > > > Have you tried the FreeBSD native KLD (wlan.kewl.org)? I've installed it > on my brother's system and on a system of a friend. Both don't complain, > so I assume it works for them (you may perhaps need to do a "ifconfig > acx0 down; sleep 5; ifconfig acx0 up" after booting, but then it should > negotiate with an AP). Thank you for the hint, but as long as I know native driver doesn't work in the adhoc mode, at least I was unable to make it working and this (mis)behaviour is acknoweleged by driver's author in the mailing list. :( Unfortunately I don't have any AP here. -Maxim From owner-freebsd-current@FreeBSD.ORG Tue Jun 8 06:37:27 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 56FF216A4CE; Tue, 8 Jun 2004 06:37:27 +0000 (GMT) Received: from www.russia.cz (mail.russia.cz [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id B00D143D31; Tue, 8 Jun 2004 06:37:26 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from portaone.com (localhost [127.0.0.1]) (authenticated bits=0) by www.russia.cz (8.12.8p2/8.12.8) with ESMTP id i586bII6043442; Tue, 8 Jun 2004 08:37:19 +0200 (CEST) (envelope-from sobomax@portaone.com) Message-ID: <40C55E8F.1070203@portaone.com> Date: Tue, 08 Jun 2004 09:37:03 +0300 From: Maxim Sobolev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, ru, uk MIME-Version: 1.0 To: Bill Paul References: <20040607162854.3CED016A4D0@hub.freebsd.org> In-Reply-To: <20040607162854.3CED016A4D0@hub.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Alexander Leidinger cc: freebsd-current@FreeBSD.ORG Subject: Re: Project Evil & ACX100-based cards (D-Link DWL-520+) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 06:37:27 -0000 Bill Paul wrote: >>On Mon, 07 Jun 2004 04:59:38 +0300 >>Maxim Sobolev wrote: >> >> >>>Hi Bill, >>> >>>I'm trying to make my D-Link DWL-520+ card working with if_ndis, but no >>>luck yet. The card is correctly detected, driver attaches to it. If I >>>configure it in the adhoc mode it is seen from the nearby machine and >>>connected to, but traffic doesn't flow. :-( >>> >>>Any ideas? Please let me know if more information is necessary. >> >>Have you tried the FreeBSD native KLD (wlan.kewl.org)? I've installed it >>on my brother's system and on a system of a friend. Both don't complain, >>so I assume it works for them (you may perhaps need to do a "ifconfig >>acx0 down; sleep 5; ifconfig acx0 up" after booting, but then it should >>negotiate with an AP). > > > I can probably get this card to work, but as I told Maxim directly, I > refuse to do debugging via e-mail. (I'm sorry, but it's just too goddamn > frustrating: what could take me an hour or two to fix on my own can take > weeks when I have to give a crash course in network debugging to someone > half a planet away.) Would it help if I'll provide you with root shell and serial console access to a well-connected machine with this card and another machine with wi(4) chip? -Maxim From owner-freebsd-current@FreeBSD.ORG Tue Jun 8 06:52:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 097E916A4CE; Tue, 8 Jun 2004 06:52:49 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49AD143D53; Tue, 8 Jun 2004 06:52:48 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i586wBwW030491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jun 2004 09:58:12 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i586qZHZ056855; Tue, 8 Jun 2004 09:52:35 +0300 (EEST) (envelope-from ru) Date: Tue, 8 Jun 2004 09:52:35 +0300 From: Ruslan Ermilov To: Gleb Smirnoff Message-ID: <20040608065235.GA56799@ip.net.ua> References: <20040607071701.GC17986@cell.sick.ru> <20040607074037.GB18232@cell.sick.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline In-Reply-To: <20040607074037.GB18232@cell.sick.ru> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: net@FreeBSD.org cc: Julian Elischer cc: FreeBSD current users Subject: Re: HEADSUP! netgraph Metadata changing. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 06:52:49 -0000 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 07, 2004 at 11:40:37AM +0400, Gleb Smirnoff wrote: > On Mon, Jun 07, 2004 at 12:35:56AM -0700, Julian Elischer wrote: > J> > On Sun, Jun 06, 2004 at 06:35:51PM -0700, Julian Elischer wrote: > J> > J> In addition the ng_ksocket node adds info into metadata and I sus= pect > J> > J> there are people using that. > J> >=20 > J> > Since ng_ksocket tags packets for itself only, we can safely change = it. > J>=20 > J> Since I did not add that code I am not very familiar with it or who us= es > J> it. (or why) > J>=20 > J> if this is true than yes we can do this.. >=20 > It is used only on UDP connection, to send replies back to where the orig= inal > packets came from. >=20 I wouldn't hardcode it this way. Rather, it just mimics the sendto()/recvfrom() semantics, to represent the "to"/"from" arguments, respectively. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAxWIzqRfpzJluFF4RAjOkAJ9JZGZNx59wAY8ZIqDgK2sQ7nq6/QCeLuI3 KVd2hlhxR9QUsnSrzv9K+BQ= =Ytac -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 8 06:58:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A62B816A4CE; Tue, 8 Jun 2004 06:58:51 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF35343D49; Tue, 8 Jun 2004 06:58:50 +0000 (GMT) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i586wWvw026932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jun 2004 10:58:32 +0400 (MSD) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i586wVCs026931; Tue, 8 Jun 2004 10:58:31 +0400 (MSD) Date: Tue, 8 Jun 2004 10:58:31 +0400 From: Gleb Smirnoff To: Ruslan Ermilov Message-ID: <20040608065831.GC26822@cell.sick.ru> References: <20040607071701.GC17986@cell.sick.ru> <20040607074037.GB18232@cell.sick.ru> <20040608065235.GA56799@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040608065235.GA56799@ip.net.ua> User-Agent: Mutt/1.5.6i cc: net@FreeBSD.org cc: Julian Elischer cc: FreeBSD current users Subject: Re: HEADSUP! netgraph Metadata changing. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 06:58:51 -0000 On Tue, Jun 08, 2004 at 09:52:35AM +0300, Ruslan Ermilov wrote: R> > J> > J> In addition the ng_ksocket node adds info into metadata and I suspect R> > J> > J> there are people using that. R> > J> > R> > J> > Since ng_ksocket tags packets for itself only, we can safely change it. R> > J> R> > J> Since I did not add that code I am not very familiar with it or who uses R> > J> it. (or why) R> > J> R> > J> if this is true than yes we can do this.. R> > R> > It is used only on UDP connection, to send replies back to where the original R> > packets came from. R> > R> I wouldn't hardcode it this way. Rather, it just mimics the R> sendto()/recvfrom() semantics, to represent the "to"/"from" R> arguments, respectively. Pardon, haven't understand what do you suggest. You mean, that it'll be better if node originating packets will insert this tag? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Tue Jun 8 07:02:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1E8116A4CE; Tue, 8 Jun 2004 07:02:55 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CB7243D49; Tue, 8 Jun 2004 07:02:55 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i5878Clc032285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jun 2004 10:08:13 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.12.11/8.12.11) id i5872afE057074; Tue, 8 Jun 2004 10:02:36 +0300 (EEST) (envelope-from ru) Date: Tue, 8 Jun 2004 10:02:36 +0300 From: Ruslan Ermilov To: Gleb Smirnoff Message-ID: <20040608070236.GA57053@ip.net.ua> References: <20040607071701.GC17986@cell.sick.ru> <20040607074037.GB18232@cell.sick.ru> <20040608065235.GA56799@ip.net.ua> <20040608065831.GC26822@cell.sick.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline In-Reply-To: <20040608065831.GC26822@cell.sick.ru> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: net@FreeBSD.org cc: Julian Elischer cc: FreeBSD current users Subject: Re: HEADSUP! netgraph Metadata changing. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 07:02:56 -0000 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 08, 2004 at 10:58:31AM +0400, Gleb Smirnoff wrote: > On Tue, Jun 08, 2004 at 09:52:35AM +0300, Ruslan Ermilov wrote: > R> > J> > J> In addition the ng_ksocket node adds info into metadata and = I suspect > R> > J> > J> there are people using that. > R> > J> >=20 > R> > J> > Since ng_ksocket tags packets for itself only, we can safely ch= ange it. > R> > J>=20 > R> > J> Since I did not add that code I am not very familiar with it or w= ho uses > R> > J> it. (or why) > R> > J>=20 > R> > J> if this is true than yes we can do this.. > R> >=20 > R> > It is used only on UDP connection, to send replies back to where the= original > R> > packets came from. > R> >=20 > R> I wouldn't hardcode it this way. Rather, it just mimics the > R> sendto()/recvfrom() semantics, to represent the "to"/"from" > R> arguments, respectively. >=20 > Pardon, haven't understand what do you suggest. You mean, that it'll be b= etter > if node originating packets will insert this tag? >=20 It's not just used "to send replies back". In our proprietary module, we expect the connected node to be of a type "inet/dgram/udp ksocket", and insert tags appropriately to send datagrams to a correct router. We also read tags to verify that the datagrams are coming from the correct router. And it just mimics the sendto()/recvfrom() behavior. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --zhXaljGHf11kAtnf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAxWSMqRfpzJluFF4RAkekAJ97yi0KbkzFeTJmD7l5mmvUXq7CNgCglEMW +096yFXJsnZxagmcpOv32qo= =85Md -----END PGP SIGNATURE----- --zhXaljGHf11kAtnf-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 8 07:27:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1889116A4CE; Tue, 8 Jun 2004 07:27:10 +0000 (GMT) Received: from ylpvm43.prodigy.net (ylpvm43-ext.prodigy.net [207.115.57.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4C2143D45; Tue, 8 Jun 2004 07:27:09 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (adsl-63-207-60-35.dsl.lsan03.pacbell.net [63.207.60.35])i587R7qE022779; Tue, 8 Jun 2004 03:27:07 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id D6D5651955; Tue, 8 Jun 2004 00:27:06 -0700 (PDT) Date: Tue, 8 Jun 2004 00:27:06 -0700 From: Kris Kennaway To: Dan Nelson Message-ID: <20040608072706.GA82243@xor.obsecurity.org> References: <1086663455.1258.79.camel@server.mcneil.com> <20040608044844.GA89198@dan.emsphone.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: <20040608044844.GA89198@dan.emsphone.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-amd64@freebsd.org cc: freebsd-gnome@freebsd.org cc: freebsd-threads@freebsd.org cc: freebsd-current@freebsd.org cc: Sean McNeil Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 07:27:10 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 07, 2004 at 11:48:45PM -0500, Dan Nelson wrote: > In the last episode (Jun 08), Daniel Eischen said: > > No, I don't want to litter all our thread libraries with strong > > references. As I've said before, build your shared libraries > > correctly so they don't bring in the threads library. >=20 > A good addition to bsd.port.mk, right next to the "possible network > server" etc checks, might be to run ldd on all installed shared > libraries and print a warning if any threads libraries show up. There > are a huge number of ports that install shlibs linked to libpthreads. Some of these are probably correct, in that the library started using libpthreads internally and there are a large number of clients that would otherwise need to be changed to link to that library. Kris --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAxWpKWry0BWjoQKURAn+6AJ46khXPmJulpz485nM4Xb2p43vargCdFEma OpAqGmYFBmYWVAdxb7FFKgk= =yXEK -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 8 07:36:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A56C816A4CE for ; Tue, 8 Jun 2004 07:36:19 +0000 (GMT) Received: from ylpvm01.prodigy.net (ylpvm01-ext.prodigy.net [207.115.57.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59CBA43D2D for ; Tue, 8 Jun 2004 07:36:19 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (adsl-63-207-60-35.dsl.lsan03.pacbell.net [63.207.60.35])i587aEnI012901; Tue, 8 Jun 2004 03:36:14 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id C299451955; Tue, 8 Jun 2004 00:36:13 -0700 (PDT) Date: Tue, 8 Jun 2004 00:36:13 -0700 From: Kris Kennaway To: Eirik Oeverby Message-ID: <20040608073613.GA82368@xor.obsecurity.org> References: <40BEC4D7.8070804@anduin.net> <20040606172659.T88480@ganymede.hub.org> <40C4B16B.5070509@anduin.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline In-Reply-To: <40C4B16B.5070509@anduin.net> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: unionfs issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 07:36:19 -0000 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 07, 2004 at 08:18:19PM +0200, Eirik Oeverby wrote: > Hi, >=20 > To start off, I don't have any DEBUG stuff enabled at all. This is a=20 > production server that I can't really do such things to, and I can't=20 > afford more than one amd64 machine at this point ;) Unfortunately you do need to do better at debugging this if you want further help. > However what I can tell you is what I am trying to do: Replace=20 > mount_null. There doesn't seem to be a mount_null (not mount_nullfs,=20 > which is different) in -CURRENT. No, mount_null was renamed to mount_nullfs, and apart from that cosmetic difference they are the same thing. Kris --/04w6evG8XlLl3ft Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAxWxtWry0BWjoQKURAkI0AKDvPg6ipTsW2zksWqtUaCWEkaqHBACfYmgE AEZ5xO0YssWiNnGK7sLsbE4= =Vrlf -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 8 07:55:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51FE216A4D0 for ; Tue, 8 Jun 2004 07:55:23 +0000 (GMT) Received: from mail023.syd.optusnet.com.au (mail023.syd.optusnet.com.au [211.29.132.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 936CB43D48 for ; Tue, 8 Jun 2004 07:55:21 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) i587ssj08867; Tue, 8 Jun 2004 17:54:58 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])i587smVd025011; Tue, 8 Jun 2004 17:54:53 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)i587smOM025010; Tue, 8 Jun 2004 17:54:48 +1000 (EST) (envelope-from pjeremy) Date: Tue, 8 Jun 2004 17:54:47 +1000 From: Peter Jeremy To: Mathew Kanner Message-ID: <20040608075447.GA1596@cirb503493.alcatel.com.au> References: <20040604155331.GO92188@cnd.mcgill.ca> <200406041645.i54GjcEk061517@sana.init-main.com> <20040604165742.GP92188@cnd.mcgill.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040604165742.GP92188@cnd.mcgill.ca> User-Agent: Mutt/1.4.2i cc: freebsd-current@freebsd.org Subject: Re: What happened to src/sys/dev/sound/midi ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 07:55:23 -0000 On Fri, 2004-Jun-04 12:57:42 -0400, Mathew Kanner wrote: > In regards to USB sound, I've lost the changes I did when I >cvsup'ed. Sad but true, I've done this a few times so I think I need >to improve the way I do work. Anyway, I plan to redo them since it >was mostly a couple hour of mechanical work. A couple of people have mentioned the P4 repository. Your other option is to CVSup (or CTM) the CVS repository rather than the relevant src branch. If you've got the 2GB or so of space available this means that you can easily move your src branch around in time (to debug which commit broke your system) or maintain local patches in your src branch (cvs will either merge updates automatically or whinge and obviously break your world). -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Tue Jun 8 08:08:42 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0EF6216A4CE for ; Tue, 8 Jun 2004 08:08:42 +0000 (GMT) Received: from mail004.syd.optusnet.com.au (mail004.syd.optusnet.com.au [211.29.132.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4DD943D41 for ; Tue, 8 Jun 2004 08:08:40 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) i5888GE26951; Tue, 8 Jun 2004 18:08:22 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])i5888FVd025083; Tue, 8 Jun 2004 18:08:15 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)i5888EVP025082; Tue, 8 Jun 2004 18:08:14 +1000 (EST) (envelope-from pjeremy) Date: Tue, 8 Jun 2004 18:08:14 +1000 From: Peter Jeremy To: "P.D. Seniura" Message-ID: <20040608080814.GB1596@cirb503493.alcatel.com.au> References: <20040604173514.D107C790037@ws1-14.us4.outblaze.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040604173514.D107C790037@ws1-14.us4.outblaze.com> User-Agent: Mutt/1.4.2i cc: freebsd-current@freebsd.org Subject: Re: What happened to src/sys/dev/sound/midi ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 08:08:42 -0000 On Fri, 2004-Jun-04 11:35:14 -0600, P.D. Seniura wrote: >>From my CTM log for June 2: > >./20040602/ctm_ports.log:234:> DM /ports/print/teTeX-base >./20040602/ctm_ports.log:235:> FM /ports/print/teTeX-base/Makefile >./20040602/ctm_ports.log:236:> FM /ports/print/teTeX-base/distinfo >./20040602/ctm_ports.log:237:> DM /ports/print/teTeX-base/files >./20040602/ctm_ports.log:238:> FM /ports/print/teTeX-base/files/listings.sty >./20040602/ctm_ports.log:239:> FM /ports/print/teTeX-base/files/pkg-install.in >./20040602/ctm_ports.log:240:> FM /ports/print/teTeX-base/pkg-descr >./20040602/ctm_ports.log:241:> FM /ports/print/teTeX-base/pkg-plist > > >I just can't find the cvs commit entry on cvs-ports@ >to see what's going on. And Nothing Much Relevent on >ports@. Whilst this is most likely a repo-copy, tagging operations also generate CVSup or CTM traffic (though FN rather than FM records) without any commit messages. (Hence the large and very slow to apply CTM delta files that appear leading up to releases). If you're really concerned about the change, you can always gunzip the delta and study it with more(1) or less(1). -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Tue Jun 8 11:22:30 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4739016A4CE for ; Tue, 8 Jun 2004 11:22:30 +0000 (GMT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 3CF6A43D1D for ; Tue, 8 Jun 2004 11:22:29 +0000 (GMT) (envelope-from ph.schulz@gmx.de) Received: (qmail 14094 invoked by uid 65534); 8 Jun 2004 11:22:27 -0000 Received: from p5090D1EE.dip0.t-ipconnect.de (EHLO gmx.de) (80.144.209.238) by mail.gmx.net (mp008) with SMTP; 08 Jun 2004 13:22:27 +0200 X-Authenticated: #1954550 Message-ID: <40C5A154.7010900@gmx.de> Date: Tue, 08 Jun 2004 13:21:56 +0200 From: Phil Schulz User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040520 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: Doug White References: <40C3960F.4080305@gmx.de> <20040606220342.W12662@carver.gumbysoft.com> In-Reply-To: <20040606220342.W12662@carver.gumbysoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: Execute BIOS function X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 11:22:30 -0000 Doug White wrote: >On Mon, 7 Jun 2004, Phil Schulz wrote: > > > >>Hello List! >> >> The radio transmitter of my new centrino laptop is turned on by a BIOS >>function which resides at a certain location in memory. I know how to >>find the adress of the function's start but I don't yet know how to tell >>the OS that I do want to execute that memory region and make it let me >>do so. When running the program I get "Bus error (core dumped)". So the >>question is: Can I actually execute the BIOS code from userland or do I >>have to do it from kernelspace? How do I tell the kernel that I want the >>memory region to be executed and make it let me do so? >> >> > >You'll have to do it from the kernel. The BIOS call will probably want to >poke memory and I/O ports you won't have access to. > >You'll also need to know if its 32-bit protected mode safe or not; if not >you'll have to set up VM86() to make the call. > >Have you checked for an ACPI method that implements the same thing? > > > How do I check that? I managed to get the code running in the kernel. I plan on posting the code at the ipw(4) homepage soon. I'm not sure if I did things 'right' but it works reliably. Phil. >>Any help is appreciated. >> >>Thanks, >>Phil. >> >>-- >> >> This is a part of the code (I hope it's not going to be wrapped). >>bios_code_addr holds the BIOS function's start address and dev_mem is a >>file-descriptor to /dev/mem. >> >>ptr = mmap( 0, BIOS_CODE_SIZE, PROT_EXEC, >> 0, dev_mem, bios_code_addr ); >> >>__asm__ __volatile__ ( >> "call *%3 \t\n" >> : "=a"(eax) >> : "a"(eax), "b"(ebx), "c"(ptr) >>); >> >> >>_______________________________________________ >>freebsd-current@freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-current >>To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> >> >> > > > From owner-freebsd-current@FreeBSD.ORG Tue Jun 8 11:54:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6337A16A4CE; Tue, 8 Jun 2004 11:54:11 +0000 (GMT) Received: from hetzner.co.za (lfw.hetzner.co.za [196.7.18.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id A055A43D5A; Tue, 8 Jun 2004 11:54:10 +0000 (GMT) (envelope-from ianf@hetzner.co.za) Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 3.36 #1) id 1BXfB6-0005ba-00; Tue, 08 Jun 2004 13:54:04 +0200 To: John Baldwin , freebsd-current@freebsd.org From: Ian FREISLICH In-Reply-To: Message from Ian FREISLICH of "Sat, 05 Jun 2004 23:44:09 +0200." Date: Tue, 08 Jun 2004 13:54:04 +0200 Sender: ianf@hetzner.co.za Message-Id: Subject: Re: It's happening again (panic early in boot) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 11:54:11 -0000 > John Baldwin wrote: > > Hmm, darn inlines. :) Can you compile the kernel with either > > INVARIANTS or MUTEX_NOINLINE so that mutex ops aren't inlined, > > reproduce the panic and then do the same lookup using the new faulting > > IP? > > (kgdb) l * 0xc04b9828 > 0xc04b9828 is in _mtx_lock_flags (../../../kern/kern_mutex.c:247). > 242 void > 243 _mtx_lock_flags(struct mtx *m, int opts, const char *file, int line) > 244 { > 245 > 246 MPASS(curthread != NULL); > 247 KASSERT(m->mtx_object.lo_class == &lock_class_mtx_sleep, > 248 ("mtx_lock() of spin mutex %s @ %s:%d", m->mtx_object.lo_ name, > 249 file, line)); > 250 WITNESS_CHECKORDER(&m->mtx_object, opts | LOP_NEWORDER | LOP_ EXCLUSIVE, > 251 file, line); > > > Interstingly with INVARIENTS, the panic is exactly the same except > for this (new) text at the end of the multiple panic: > > panic: page fault > at line 815 in file ../../../i386/i386/trap.ccpuid = 0; > Uptime: 1s > panic: _mtx_lock_sleep: recursed on non-recursive mutex system map @ ../../.. /vm/vm_map.c:2876 > > at line 437 in file ../../../kern/kern_mutex.ccpuid = 0; > Uptime: 1s > panic: _mtx_lock_sleep: recursed on non-rep Well, this problem went away after I disabled ACPI. I used to get these before the latest ACPI merge: acpi0: on motherboard ACPI-0265: *** Error: Hardware never changed modes ACPI-0168: *** Error: Could not transition to ACPI mode. acpi0: Could not enable ACPI: AE_NO_HARDWARE_RESPONSE device_probe_and_attach: acpi0 attach returned 6 Perhaps it now just blindly assumes that ACPI works and panics as a result. An off-line discussion with Nate revealed that this board's version of ACPI will never be supported (even though it worked with SMP in the early days - mid 2003 - and still works in UP). Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Tue Jun 8 11:57:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABE7716A4CE for ; Tue, 8 Jun 2004 11:57:23 +0000 (GMT) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id E891343D4C for ; Tue, 8 Jun 2004 11:57:22 +0000 (GMT) (envelope-from smckay@internode.on.net) Received: from dungeon.home (ppp191-218.lns1.bne1.internode.on.net [150.101.191.218])i58BvH4Y050468; Tue, 8 Jun 2004 21:27:17 +0930 (CST) Received: from dungeon.home (localhost [127.0.0.1]) by dungeon.home (8.12.8p2/8.11.6) with ESMTP id i58BvGJd012588; Tue, 8 Jun 2004 21:57:17 +1000 (EST) (envelope-from mckay) Message-Id: <200406081157.i58BvGJd012588@dungeon.home> To: freebsd-current@freebsd.org Date: Tue, 08 Jun 2004 21:57:16 +1000 From: Stephen McKay cc: Stephen McKay Subject: sshd should not use TCP_NODELAY X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 11:57:23 -0000 Hi! For some time now, ssh has been annoying me with little pauses. These pauses last about 1 second and until today I couldn't work out what could be causing them. It's particularly annoying when it happens in vi. The hardware involved is a FreeBSD 4.9 machine (the server) behind a PIX, over what I think is Frame Relay, thence to my ADSL, through a FreeBSD 4.8 PPPoE box, and finally to my FreeBSD 4.8 workstation. Today, I found a directory where "ls" would give me the pause 100% of the time. Small output always works, as does a large amount of output. Some magical middle ground would fail. The result of this particular "ls" is a blast of 34 small packets (nearly all with a 80 byte payload), taking a shade over 4 ms to generate in total. Of this flood of tinygrams, only 24 make it to the my workstation. I don't know why, but something fills up at 24 packets and the rest get eaten at about 70% probability per packet. The pause that I see is a retransmit timeout, which takes about 1.3 seconds. The reason that fast retransmit didn't trigger is that there are not many packets after the cutoff that get through, so the required number of duplicate acks do not arrive. An "ls" of a slightly larger directory works smoothly because of this mechanism. The data are sent in tinygrams because sshd sets TCP_NODELAY on the network socket and because the pty hands ssh little bits of data in each read. If you deliberately select protocol version 1 then extra code is activated which waits up to 10ms for a good amount of data from the pty. Packets are sent with approximately 300 byte payloads using protocol version 1 and this seems good enough to avoid my particular problem. But that's only for the version 1 protocol, and not for version 2! My quick and ready answer to my problem is to hack openssh/packet.c and take out the call to set_nodelay() from packet_set_interactive(). This means that TCP_NODELAY is no longer set on the socket. It also turns it off in the client but I may change my mind on that yet. But after this I had annoying 100ms pauses! :-) To save you all from the suspense, this pause is due to delayed acks at the client end. The server is waiting for an ack before sending another tinygram (though it's doing good by aggregating them into one good sized lump while waiting). To solve this, I set net.inet.tcp.delayed_ack=0, on the client, though I got reasonable results from using net.inet.tcp.delacktime=10 (the minimum) as an alternative. So, what should I blame for all this? The pty code? It hands ssh tiny bits of data at a time. I can't immediately think of any fix I could make at this level though. Ssh? It no longer coalesces little bits of pty output into 256 byte chunks. It also sets TCP_NODELAY, which guarantees that small writes equate to lots of tinygrams. More on this later... The TCP stack? Sending 34 packets in 4.4ms is silly for this application (ssh) but may be just the right thing for another. An old bug used to limit TCP connections to 4 outstanding packets and so this problem never used to appear. Any sort of slow ramp-up of packets as opposed to the usual ramping up of the window in bytes would also work, but that seems to be expressly prohibited when TCP_NODELAY is set. The NIC driver? If it didn't accept those packets in one burst, the TCP stack would have had a chance to coalesce some mbufs. :-) OK, I'm only kidding. Really! Stop looking at me like that! The mysterious packet eater between my server and workstation? Easy to blame, but impossible to fix. This is just how life is for me. Maybe it's like this all over the world. My client machine? The only thing it can change is delayed acks. That's handy if TCP_NODELAY is off, but not otherwise. All in all I think the best short term fix is to not use TCP_NODELAY in sshd. Long term, there should be a way to stop TCP spewing tinygrams even with TCP_NODELAY. A delay of just 1ms between tinygrams would be enough to stop this effect. A marginally useful alternative to all this is to add the pty output coalescing code to the version 2 protocol portion of ssh. I'm not sure this is as clearly a win as disabling TCP_NODELAY though. By the way, an extensive discussion of the sshd vs TCP_NODELAY issue can be found in the archives. This is a message part way through the discussion where Matt Dillon advocates removing TCP_NODELAY from ssh over two years ago: http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg30608.html As far as I can tell, there was no result from this discussion, though some people did note how badly ssh with TCP_NODELAY works over a modem, and by extension any high latency low bandwidth channel. I understand that ssh is 3rd party, but it's supplied as part of the FreeBSD base system. With this in mind, I am happy to edit it to remove the setting of TCP_NODELAY. Is anybody else of the same opinion? Similarly, does anyone have any idea of the long term effect of setting delacktime to 10ms? I doubt that it is any worse than using 100ms on modern machines, and is less disruptive. Has anyone done a study of this? Stephen. PS Why is libssh installed in /usr/lib? Why is a dynamic version created at all? Isn't it just part of ssh and sshd and with no other purpose? I can assure you it really got in the way of debugging this problem to have to make a new version of sshd that used a different library so that I didn't destroy my ability to use the real sshd to log in! From owner-freebsd-current@FreeBSD.ORG Mon Jun 7 20:05:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71CC416A4CE for ; Mon, 7 Jun 2004 20:05:09 +0000 (GMT) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id E05CD43D5F for ; Mon, 7 Jun 2004 20:05:07 +0000 (GMT) (envelope-from andreas-moeller@gmx.net) Received: (qmail 30197 invoked by uid 65534); 7 Jun 2004 20:05:03 -0000 Received: from pD9520248.dip.t-dialin.net (EHLO gmx.net) (217.82.2.72) by mail.gmx.net (mp006) with SMTP; 07 Jun 2004 22:05:03 +0200 X-Authenticated: #1940550 Message-ID: <40C4CA71.5010800@gmx.net> Date: Mon, 07 Jun 2004 22:05:05 +0200 From: Andreas Moeller User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-AT; rv:1.6) Gecko/20040603 X-Accept-Language: de-at, de, en-us, en MIME-Version: 1.0 To: John Baldwin References: <40BF38B4.6090208@gmx.net> <200406041521.34813.jhb@FreeBSD.org> <40C0FEFB.8050605@gmx.net> <200406070807.13562.jhb@FreeBSD.org> In-Reply-To: <200406070807.13562.jhb@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------020109050809000208000607" X-Mailman-Approved-At: Tue, 08 Jun 2004 12:16:11 +0000 cc: current@FreeBSD.org Subject: Re: fxp(4) device timeouts ACPI related? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 20:05:09 -0000 This is a multi-part message in MIME format. --------------020109050809000208000607 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit >>>>>>The ACPI updates predating last weekend seem to have broken my fxp(4) >>>>>>card (Intel PRO/100 S, Intel 82550 chip). Without disabling ACPI at the >>>>>>loader prompt (set hint.acpi.0.disabled=1) I get the consecutive >>>>>>message of the device timing out and network is unusable. >>>>>> >>>>>>Perhaps this is useful information for everybody desiring to workaround >>>>>>the problem or even some developer to have a closer look at it. If a >>>>>>more detailed description of my setup is needed, just let me know. >>>>> >>>>>Can you get before and after dmesg's and post a diff? >>>> >>>>Of course. diff is attached, the kernel is an unmodified GENERIC. >>> >>>Looks like !ACPI gives IRQ 11 to everyone and ACPI gives some devices IRQ >>>5 and some IRQ 11. Can you get a dmesg from the older kernel with ACPI >>>enabled and generate a diff of that dmesg against the current kernel with >>>ACPI? >> >>Attached. I had to get some older sources and build the kernel since I >>didn't keep an old enough kernel around. The sources used date to May >>28th, 2:50am (UTC) and network works with ACPI enabled. >> >>I'm by no means an expert but I don't see any new insight revealed by >>the diff between those two dmesgs. > > > How about a dmesg from a boot -v with the new kernel? > Find the dmesg aswell as the diff to the old kernel attached. Regards, -Andreas --------------020109050809000208000607 Content-Type: text/plain; name="dmesg.acpi" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.acpi" Copyright (c) 1992-2004 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.2-CURRENT #0: Sun Jun 6 22:58:12 CEST 2004 root@beta:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc0aca000. Preloaded elf module "/boot/kernel/snd_emu10k1.ko" at 0xc0aca210. Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc0aca2c0. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0aca36c. Calibrating clock(s) ... i8254 clock: 1193065 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1195217149 Hz CPU: AMD Athlon(tm) processor (1195.22-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x642 Stepping = 2 Features=0x183f9ff AMD Features=0xc0440000 Data TLB: 24 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 805240832 (767 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c29000 - 0x000000002f23ffff, 778137600 bytes (189975 pages) avail memory = 778256384 (742 MB) bios32: Found BIOS32 Service Directory header at 0xc00fb100 bios32: Entry = 0xfb560 (c00fb560) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xb590 pnpbios: Found PnP BIOS data at 0xc00fc060 pnpbios: Entry = f0000:c090 Rev = 1.0 Other BIOS signatures found: wlan: <802.11 Link Layer> random: mem: Pentium Pro MTRR support enabled null: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [GIANT-LOCKED] pci_open(1): mode 1 addr port (0x0cf8) is 0x80003c48 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=03051106) pcibios: BIOS version 2.10 Found $PIR table, 9 entries at 0xc00fd5d0 PCI-Only Interrupts: 10 11 Location Bus Device Pin Link IRQs slot 1 0 8 A 0x02 3 4 5 7 9 10 11 12 14 15 slot 1 0 8 B 0x03 3 4 5 7 9 10 11 12 14 15 slot 1 0 8 C 0x05 3 4 5 7 9 10 11 12 14 15 slot 1 0 8 D 0x01 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 A 0x03 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 B 0x05 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 C 0x01 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 D 0x02 3 4 5 7 9 10 11 12 14 15 slot 3 0 10 A 0x05 3 4 5 7 9 10 11 12 14 15 slot 3 0 10 B 0x01 3 4 5 7 9 10 11 12 14 15 slot 3 0 10 C 0x02 3 4 5 7 9 10 11 12 14 15 slot 3 0 10 D 0x03 3 4 5 7 9 10 11 12 14 15 slot 4 0 12 A 0x02 3 4 5 7 9 10 11 12 14 15 slot 4 0 12 B 0x03 3 4 5 7 9 10 11 12 14 15 slot 4 0 12 C 0x05 3 4 5 7 9 10 11 12 14 15 slot 4 0 12 D 0x01 3 4 5 7 9 10 11 12 14 15 slot 5 0 13 A 0x03 3 4 5 7 9 10 11 12 14 15 slot 5 0 13 B 0x05 3 4 5 7 9 10 11 12 14 15 slot 5 0 13 C 0x01 3 4 5 7 9 10 11 12 14 15 slot 5 0 13 D 0x02 3 4 5 7 9 10 11 12 14 15 slot 6 0 14 A 0x05 3 4 5 7 9 10 11 12 14 15 slot 6 0 14 B 0x01 3 4 5 7 9 10 11 12 14 15 slot 6 0 14 C 0x02 3 4 5 7 9 10 11 12 14 15 slot 6 0 14 D 0x03 3 4 5 7 9 10 11 12 14 15 slot 7 0 15 A 0x03 3 4 5 7 9 10 11 12 14 15 slot 7 0 15 B 0x05 3 4 5 7 9 10 11 12 14 15 slot 7 0 15 C 0x01 3 4 5 7 9 10 11 12 14 15 slot 7 0 15 D 0x02 3 4 5 7 9 10 11 12 14 15 embedded 0 1 A 0x01 3 4 5 7 9 10 11 12 14 15 embedded 0 1 B 0x02 3 4 5 7 9 10 11 12 14 15 embedded 0 1 C 0x03 3 4 5 7 9 10 11 12 14 15 embedded 0 1 D 0x05 3 4 5 7 9 10 11 12 14 15 embedded 0 7 C 0x03 3 4 5 7 9 10 11 12 14 15 embedded 0 7 D 0x05 3 4 5 7 9 10 11 12 14 15 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi0: Power Button (fixed) ACPI timer looks GOOD min = 1, max = 2, width = 1 ACPI timer looks GOOD min = 1, max = 2, width = 1 ACPI timer looks GOOD min = 1, max = 2, width = 1 ACPI timer looks GOOD min = 1, max = 2, width = 1 ACPI timer looks GOOD min = 1, max = 2, width = 1 ACPI timer looks GOOD min = 1, max = 2, width = 1 ACPI timer looks GOOD min = 1, max = 2, width = 1 ACPI timer looks GOOD min = 1, max = 2, width = 1 ACPI timer looks GOOD min = 1, max = 2, width = 1 ACPI timer looks GOOD min = 1, max = 2, width = 1 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 ACPI PCI link initial configuration: \\_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.8.0 \\_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.8.1 \\_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.8.2 \\_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.8.3 \\_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.9.0 \\_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.9.1 \\_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.9.2 \\_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.9.3 \\_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.10.0 \\_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.10.1 \\_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.10.2 \\_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.10.3 \\_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.12.0 \\_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.12.1 \\_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.12.2 \\_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.12.3 \\_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.13.0 \\_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.13.1 \\_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.13.2 \\_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.13.3 \\_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.14.0 \\_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.14.1 \\_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.14.2 \\_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.14.3 \\_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.15.0 \\_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.15.1 \\_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.15.2 \\_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.15.3 \\_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.7.0 \\_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.7.1 \\_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.7.2 \\_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.7.3 \\_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.1.0 \\_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.1.1 \\_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.1.2 \\_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.1.3 ACPI PCI link before setting link priority: \\_SB_.PCI0.LNKB: interrupts: 1 3 4 5 6 7 10 11 12 14 15 penalty: 103960 4960 4960 3960 4960 4960 3960 3960 4960 13960 13960 references: 9 priority: 0 \\_SB_.PCI0.LNKC: interrupts: 1 3 4 5 6 7 10 11 12 14 15 penalty: 103960 4960 4960 3960 4960 4960 3960 3960 4960 13960 13960 references: 9 priority: 0 \\_SB_.PCI0.LNKD: interrupts: 1 3 4 5 6 7 10 11 12 14 15 penalty: 103960 4960 4960 3960 4960 4960 3960 3960 4960 13960 13960 references: 9 priority: 0 \\_SB_.PCI0.LNKA: interrupts: 1 3 4 5 6 7 10 11 12 14 15 penalty: 103960 4960 4960 3960 4960 4960 3960 3960 4960 13960 13960 references: 9 priority: 0 ACPI PCI link before fixup for boot-disabled links: \\_SB_.PCI0.LNKB: interrupts: 1 3 4 5 6 7 10 11 12 14 15 penalty: 103960 4960 4960 3960 4960 4960 3960 3960 4960 13960 13960 references: 9 priority: 137912 \\_SB_.PCI0.LNKC: interrupts: 1 3 4 5 6 7 10 11 12 14 15 penalty: 103960 4960 4960 3960 4960 4960 3960 3960 4960 13960 13960 references: 9 priority: 137912 \\_SB_.PCI0.LNKD: interrupts: 1 3 4 5 6 7 10 11 12 14 15 penalty: 103960 4960 4960 3960 4960 4960 3960 3960 4960 13960 13960 references: 9 priority: 137912 \\_SB_.PCI0.LNKA: interrupts: 1 3 4 5 6 7 10 11 12 14 15 penalty: 103960 4960 4960 3960 4960 4960 3960 3960 4960 13960 13960 references: 9 priority: 137912 ACPI PCI link after fixup for boot-disabled links: ACPI PCI link arbitrated configuration: \\_SB_.PCI0.LNKB irq 11: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.8.0 \\_SB_.PCI0.LNKC irq 10: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.8.1 \\_SB_.PCI0.LNKD irq 5: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.8.2 \\_SB_.PCI0.LNKA irq 11: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.8.3 \\_SB_.PCI0.LNKC irq 10: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.9.0 \\_SB_.PCI0.LNKD irq 5: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.9.1 \\_SB_.PCI0.LNKA irq 11: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.9.2 \\_SB_.PCI0.LNKB irq 11: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.9.3 \\_SB_.PCI0.LNKD irq 5: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.10.0 \\_SB_.PCI0.LNKA irq 11: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.10.1 \\_SB_.PCI0.LNKB irq 11: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.10.2 \\_SB_.PCI0.LNKC irq 10: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.10.3 \\_SB_.PCI0.LNKB irq 11: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.12.0 \\_SB_.PCI0.LNKC irq 10: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.12.1 \\_SB_.PCI0.LNKD irq 5: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.12.2 \\_SB_.PCI0.LNKA irq 11: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.12.3 \\_SB_.PCI0.LNKC irq 10: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.13.0 \\_SB_.PCI0.LNKD irq 5: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.13.1 \\_SB_.PCI0.LNKA irq 11: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.13.2 \\_SB_.PCI0.LNKB irq 11: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.13.3 \\_SB_.PCI0.LNKD irq 5: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.14.0 \\_SB_.PCI0.LNKA irq 11: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.14.1 \\_SB_.PCI0.LNKB irq 11: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.14.2 \\_SB_.PCI0.LNKC irq 10: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.14.3 \\_SB_.PCI0.LNKC irq 10: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.15.0 \\_SB_.PCI0.LNKD irq 5: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.15.1 \\_SB_.PCI0.LNKA irq 11: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.15.2 \\_SB_.PCI0.LNKB irq 11: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.15.3 \\_SB_.PCI0.LNKB irq 11: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.7.0 \\_SB_.PCI0.LNKC irq 10: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.7.1 \\_SB_.PCI0.LNKD irq 5: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.7.2 \\_SB_.PCI0.LNKA irq 11: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.7.3 \\_SB_.PCI0.LNKA irq 11: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.1.0 \\_SB_.PCI0.LNKB irq 11: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.1.1 \\_SB_.PCI0.LNKC irq 10: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.1.2 \\_SB_.PCI0.LNKD irq 5: [ 1 3 4 5 6 7 10 11 12 14 15] low,level,sharable 0.1.3 pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base d0000000, size 27, enabled found-> vendor=0x1106, dev=0x0305, revid=0x03 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2210, cachelnsz=0 (dwords) lattimer=0x08 (240 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 found-> vendor=0x1106, dev=0x8305, revid=0x00 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x2230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x0686, revid=0x40 bus=0, slot=7, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0087, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000d000, size 4, enabled found-> vendor=0x1106, dev=0x0571, revid=0x06 bus=0, slot=7, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000d400, size 5, enabled pcib0: matched entry for 0.7.INTD (src \\_SB_.PCI0.LNKA) pcib0: slot 7 INTD is routed to irq 11 found-> vendor=0x1106, dev=0x3038, revid=0x1a bus=0, slot=7, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000d800, size 5, enabled pcib0: matched entry for 0.7.INTD (src \\_SB_.PCI0.LNKA) pcib0: slot 7 INTD is routed to irq 11 found-> vendor=0x1106, dev=0x3038, revid=0x1a bus=0, slot=7, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 powerspec 2 supports D0 D3 current D0 found-> vendor=0x1106, dev=0x3057, revid=0x40 bus=0, slot=7, func=4 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base e3020000, size 12, enabled map[14]: type 4, range 32, base 0000dc00, size 6, enabled map[18]: type 1, range 32, base e3000000, size 17, enabled pcib0: matched entry for 0.10.INTA (src \\_SB_.PCI0.LNKD) pcib0: slot 10 INTA is routed to irq 5 found-> vendor=0x8086, dev=0x1229, revid=0x0d bus=0, slot=10, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000e000, size 5, enabled pcib0: matched entry for 0.14.INTA (src \\_SB_.PCI0.LNKD) pcib0: slot 14 INTA is routed to irq 5 found-> vendor=0x1102, dev=0x0002, revid=0x04 bus=0, slot=14, func=0 class=04-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x14 (5000 ns) intpin=a, irq=5 powerspec 1 supports D0 D3 current D0 map[10]: type 4, range 32, base 0000e400, size 3, enabled found-> vendor=0x1102, dev=0x7002, revid=0x01 bus=0, slot=14, func=1 class=09-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 1 supports D0 D3 current D0 agp0: mem 0xd0000000-0xd7ffffff at device 0.0 on pci0 agp0: Reserved 0x8000000 bytes for rid 0x10 type 3 at 0xd0000000 agp0: allocating GATT for aperture of size 256M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xe0000000-0xe1ffffff pcib1: prefetched decode 0xd8000000-0xdfffffff pci1: on pcib1 pci1: physical bus=1 map[10]: type 1, range 32, base e0000000, size 24, enabled pcib1: device (null) requested decoded memory range 0xe0000000-0xe0ffffff map[14]: type 3, range 32, base d8000000, size 27, enabled pcib1: device (null) requested decoded memory range 0xd8000000-0xdfffffff pcib0: matched entry for 0.1.INTA (src \\_SB_.PCI0.LNKA) pcib0: slot 1 INTA is routed to irq 11 pcib1: slot 0 INTA is routed to irq 11 found-> vendor=0x10de, dev=0x0150, revid=0xa4 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x05 (1250 ns), maxlat=0x01 (250 ns) intpin=a, irq=11 powerspec 1 supports D0 D3 current D0 pci1: at device 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xd000-0xd00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xd000 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 mask=03 stat0=50 stat1=00 devices=0x1 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=50 ostat1=50 ata1-master: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata1-slave: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 mask=03 stat0=00 stat1=00 devices=0xc ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] uhci0: port 0xd400-0xd41f irq 11 at device 7.2 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd400 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhub0: port error, restarting port 1 uhub0: port error, giving up port 1 uhub0: port error, restarting port 2 uhub0: port error, giving up port 2 uhci1: port 0xd800-0xd81f irq 11 at device 7.3 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd800 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhub1: port error, restarting port 1 uhub1: port error, giving up port 1 uhub1: port error, restarting port 2 uhub1: port error, giving up port 2 fxp0: port 0xdc00-0xdc3f mem 0xe3000000-0xe301ffff,0xe3020000-0xe3020fff irq 5 at device 10.0 on pci0 fxp0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xe3020000 fxp0: using memory space register mapping fxp0: PCI IDs: 8086 1229 8086 0040 000d fxp0: Dynamic Standby mode is disabled miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: bpf attached fxp0: Ethernet address: 00:02:b3:4c:9c:32 fxp0: [GIANT-LOCKED] pcm0: port 0xe000-0xe01f irq 5 at device 14.0 on pci0 pcm0: Reserved 0x20 bytes for rid 0x10 type 4 at 0xe000 emu: setmap (2eddb000, 800), nseg=1, error=0 emu: setmap (2ed5a000, 1000), nseg=1, error=0 pcm0: pcm0: Codec features 6 bit master volume, no 3D Stereo Enhancement pcm0: [MPSAFE] emu: setmap (2edfd000, 1000), nseg=1, error=0 emu: setmap (2eae8000, 1000), nseg=1, error=0 emu: setmap (2ee86000, 1000), nseg=1, error=0 emu: setmap (2ee64000, 1000), nseg=1, error=0 pcm0: sndbuf_setmap 2ee42000, 1000; 0xc1f8e000 -> 2ee42000 pcm0: sndbuf_setmap 2ed60000, 1000; 0xc1f8c000 -> 2ed60000 fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: irq maps: 0x1 0x11 0x1 0x1 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1: irq maps: 0x1 0x9 0x1 0x1 sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A unknown: not probed (disabled) unknown: not probed (disabled) ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (NIBBLE-only) in NIBBLE mode ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 psmcpnp0 irq 12 on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: current command byte:0047 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4-00, 5 buttons psm0: config:00000000, flags:00000000, packet size:4 psm0: syncmask:08, syncbits:08 unknown: not probed (disabled) unknown: not probed (disabled) ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 ex_isa_identify() unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: