From owner-freebsd-bugs@FreeBSD.ORG Sun May 18 12:01:28 2003 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2590A37B401 for ; Sun, 18 May 2003 12:01:28 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DE7B43F75 for ; Sun, 18 May 2003 12:01:27 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9/8.12.9) with ESMTP id h4IJ13On052127; Sun, 18 May 2003 15:01:03 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)h4IJ1318052124; Sun, 18 May 2003 15:01:03 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 18 May 2003 15:01:03 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Gabriel Tataranu In-Reply-To: <200305161758.08030.tgabi@belent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-bugs@freebsd.org Subject: Re: fxp driver lockups on 4.8r X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2003 19:01:28 -0000 On Fri, 16 May 2003, Gabriel Tataranu wrote: > I'd like to report strange behavior of fxp driver on 4.8r. The hardware > configuration is: > - Intel D845GERG2L motherboard (lan on board) > - Pentium 4 processor and PC2700 memory > - Adaptec 29160N with Seagate 15k3 drives > - 3Com 905C nic > - IDE CDROM > > Once the system has load on intel nic (on the motherboard) and discs > (like rsync a large directory from a server) the system locks-up > (console becomes not responsive), the nic is broadcasting IP storms at > full capacity (so hard that the network switch lock-up) and the disk LED > is solid bright red (during regular disk access the LED can be solid red > but not so bright). Are you sure it's an IP storm? Could you send a tcpdump with a few sample packets from another machine? I suspect strongly the symptom you're seeing is that the OS (for whatever reason) has ceased to process fxp interrupts, and as a result the fxp card has started to spew our link layer flow control packets. I run into the same problem when my system drops into DDB, and ceases to respond. I recently committed a tunable to -current to disable flow control for the card. Note: this is not the same as solving the source of the problem, which is presumably a bug somewhere, but this would prevent your switch from hanging when this happens. To force your fxp card not to enable flow control (which may be a reasonable default), find the following lines in src/sys/dev/fxp/if_fxp.c: cbp->multi_ia = 0; /* (don't) accept multiple IAs */ cbp->mc_all = sc->flags & FXP_FLAG_ALL_MCAST ? 1 : 0; if (sc->revision == FXP_REV_82557) { /* * The 82557 has no hardware flow control, the values * below are the defaults for the chip. */ Replace the if statement with: if (1) { This will always disable flow control. Then comes the second question, which is why this happened in the first place, but this may be a lot easier to diagnose without your fxp card going nuts. I suggest compiling your kernel with "options DDB" and seeing if you can break into the debugger when it appears hung. > The same operation on 3Com card is OK. Same operation on 4.6.2r > and 4.7r is again OK. The system has no IRQ conflicts. > > I cannot provide a system log since the only way I can restore > the system to sanity is cold reboot. There are no indication of kernel > panics (the console just "freeze"). > > I can provide other details / run some scripts upon request. > > Regards, > > Gabriel > _______________________________________________ > freebsd-bugs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-bugs > To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org" > From owner-freebsd-bugs@FreeBSD.ORG Sun May 18 12:20:16 2003 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC65B37B40B for ; Sun, 18 May 2003 12:20:16 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6EA0243FB1 for ; Sun, 18 May 2003 12:20:13 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h4IJKDUp008556 for ; Sun, 18 May 2003 12:20:13 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h4IJKDWP008555; Sun, 18 May 2003 12:20:13 -0700 (PDT) Resent-Date: Sun, 18 May 2003 12:20:13 -0700 (PDT) Resent-Message-Id: <200305181920.h4IJKDWP008555@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Lukas Ertl Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF0F537B401 for ; Sun, 18 May 2003 12:12:40 -0700 (PDT) Received: from mailbox.univie.ac.at (mailbox.univie.ac.at [131.130.1.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BCA043F85 for ; Sun, 18 May 2003 12:12:39 -0700 (PDT) (envelope-from le@univie.ac.at) Received: from korben.in.tern (adslle.cc.univie.ac.at [131.130.102.11]) by mailbox.univie.ac.at (8.12.2/8.12.2) with ESMTP id h4IJCM9D217014 for ; Sun, 18 May 2003 21:12:26 +0200 Received: from korben.in.tern (korben.in.tern [127.0.0.1]) by korben.in.tern (8.12.9/8.12.9) with ESMTP id h4IJCJfF000903 for ; Sun, 18 May 2003 21:12:19 +0200 (CEST) (envelope-from le@korben.in.tern) Received: (from root@localhost) by korben.in.tern (8.12.9/8.12.9/Submit) id h4IJCJAr000902; Sun, 18 May 2003 21:12:19 +0200 (CEST) (envelope-from le) Message-Id: <200305181912.h4IJCJAr000902@korben.in.tern> Date: Sun, 18 May 2003 21:12:19 +0200 (CEST) From: Lukas Ertl To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: kern/52404: kernel panic on laptop resume (related to device csa) X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Lukas Ertl List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2003 19:20:17 -0000 >Number: 52404 >Category: kern >Synopsis: kernel panic on laptop resume (related to device csa) >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun May 18 12:20:12 PDT 2003 >Closed-Date: >Last-Modified: >Originator: Lukas Ertl >Release: FreeBSD 5.1-BETA i386 >Organization: Vienna University Computer Center >Environment: System: FreeBSD korben 5.1-BETA FreeBSD 5.1-BETA #0: Sun May 18 19:30:12 CEST 2003 le@korben:/usr/src/sys/i386/compile/KORBEN i386 Hardware: IBM ThinkPad T20 >Description: On resume from apm suspend, the laptop panics. >How-To-Repeat: Suspend/resume on Thinkpad T20. >Fix: Not really known, but rev. 1.23 of sys/dev/sound/pci/csa.c works, while rev. 1.24 does not. Note: the diff between 1.23 and 1.24 was also MFC'ed, but was backed out again due to panics on suspend/resume (rev. 1.8.2.11 and 1.8.2.12). --- backtrace begins here --- Script started on Sun May 18 21:00:04 2003 [root@korben crash]# gdb -k kernel.debug vmcore.1 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: page fault panic messages: --- panic: resource_list_alloc: resource entry is busy syncing disks, buffers remaining... 2087 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8:0xc02432b6 stack pointer = 0x10:0xcd25cc9c frame pointer = 0x10:0xcd25cc9c 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 = 21 (irq11: cbb0 cbb1+++) trap number = 12 panic: page fault Uptime: 7m43s Dumping 255 MB ata0: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 --- Reading symbols from /usr/src/sys/i386/compile/KORBEN/modules/usr/src/sys/modules/apm/apm.ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/KORBEN/modules/usr/src/sys/modules/apm/apm.ko.debug Reading symbols from /usr/src/sys/i386/compile/KORBEN/modules/usr/src/sys/modules/linux/linux.ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/KORBEN/modules/usr/src/sys/modules/linux/linux.ko.debug #0 doadump () at ../../../kern/kern_shutdown.c:238 238 dumping++; (kgdb) bt full #0 doadump () at ../../../kern/kern_shutdown.c:238 No locals. #1 0xc0222dc3 in boot (howto=260) at ../../../kern/kern_shutdown.c:370 No locals. #2 0xc022310b in panic () at ../../../kern/kern_shutdown.c:543 td = (struct thread *) 0xc0ec9130 bootopt = 260 newpanic = 0 buf = "page fault\0st_alloc: resource entry is busy", '\0' #3 0xc036e502 in trap_fatal (frame=0xcd25cc5c, eva=0) at ../../../i386/i386/trap.c:834 code = 16 type = 12 ss = 16 esp = 0 softseg = {ssd_base = 0, ssd_limit = 1048575, ssd_type = 27, ssd_dpl = 0, ssd_p = 1, ssd_xx = 1, ssd_xx1 = 0, ssd_def32 = 1, ssd_gran = 1} #4 0xc036e1e2 in trap_pfault (frame=0xcd25cc5c, usermode=0, eva=36) at ../../../i386/i386/trap.c:748 va = 0 vm = (struct vmspace *) 0x0 map = (struct vm_map *) 0xc0425b40 rv = 1 ftype = 1 '\001' td = (struct thread *) 0xc0ec9130 p = (struct proc *) 0xc0ecf780 #5 0xc036ddad in trap (frame= {tf_fs = 67108888, tf_es = 16, tf_ds = -853213168, tf_edi = 0, tf_esi = -1034067708, tf_ebp = -853160804, tf_isp = -853160824, tf_ebx = -1058277184, tf_edx = -1058238160, tf_ecx = 1, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1071369546, tf_cs = 8, tf_eflags = 66195, tf_esp = -853160768, tf_ss = -1072045048}) at ../../../i386/i386/trap.c:433 td = (struct thread *) 0xc0ec9130 p = (struct proc *) 0xc0ecf780 sticks = 3225091543 ---Type to continue, or q to quit--- i = 0 ucode = 0 type = 12 code = 0 eva = 36 #6 0xc035e658 in calltrap () at {standard input}:96 No locals. #7 0xc019e408 in csa_readio (resp=0xc25d6104, offset=0) at bus_at386.h:237 ul = 536 #8 0xc019dbf5 in csa_intr (arg=0xc25d6100) at ../../../dev/sound/pci/csa.c:512 scp = (struct csa_softc *) 0xc25d6104 resp = (struct csa_res *) 0x0 hisr = 3236690112 #9 0xc020fb52 in ithread_loop (arg=0xc0ec6600) at ../../../kern/kern_intr.c:537 ithd = (struct ithd *) 0xc25d6104 ih = (struct intrhand *) 0xc0ebf8c0 td = (struct thread *) 0x0 p = (struct proc *) 0xc0ecf780 #10 0xc020eb40 in fork_exit (callout=0xc0ebf8c0, arg=0x0, frame=0x0) at ../../../kern/kern_fork.c:768 td = (struct thread *) 0x0 p = (struct proc *) 0xc25d6104 (kgdb) quit [root@korben crash]# dmesg Copyright (c) 1992-2003 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.1-BETA #0: Sun May 18 19:30:12 CEST 2003 le@korben:/usr/src/sys/i386/compile/KORBEN Preloaded elf kernel "/boot/kernel/kernel" at 0xc0519000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc05191f4. Preloaded elf module "/boot/kernel/apm.ko" at 0xc0519244. Timecounter "i8254" frequency 1193182 Hz CPU: Intel Pentium III (696.97-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x383f9ff real memory = 268369920 (255 MB) avail memory = 255107072 (243 MB) Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 Using $PIR table, 11 entries at 0xc00fdee0 apm0: on motherboard apm0: found APM BIOS v1.2, connected at v1.2 pcib0: at pcibus 0 on motherboard pci0: on pcib0 agp0: mem 0xf8000000-0xfbffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) cbb0: mem 0x50000000-0x50000fff irq 11 at device 2.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: mem 0x50100000-0x50100fff irq 11 at device 2.1 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 fxp0: port 0x1800-0x183f mem 0xe8100000-0xe811ffff,0xe8120000-0xe8120fff irq 11 at device 3.0 on pci0 fxp0: Ethernet address 00:02:b3:04:8d:3b miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci0: at device 3.1 (no driver attached) csa0: mem 0xe8000000-0xe80fffff,0xe8122000-0xe8122fff irq 11 at device 5.0 on pci0 csa: card is Thinkpad 600X/A20/T20 pcm0: on csa0 pcm0: isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1850-0x185f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0x1860-0x187f irq 11 at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at device 7.3 (no driver attached) orm0:
Here is anothe= r way to create the pidfile (or any file, for that matter):
&n= bsp;
int create(char *path)
{
 = ;    int fd;
    
     if((fd=3Dopen(path, CREATE|EXCL|WRONLY, READ|= WRITE)) =3D=3D -1)
     {
 = ;         return(0);
&= nbsp;    }
     close(= fd);
     return(1);
}
 
Note that create() returns a 1 on success and a 0 on= failure.
 
Lucas

------=_NextPart_001_0000_01C32030.8F63FE80-- From owner-freebsd-bugs@FreeBSD.ORG Thu May 22 05:19:29 2003 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0417A37B401; Thu, 22 May 2003 05:19:29 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24DDF43F75; Thu, 22 May 2003 05:19:27 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id WAA25740; Thu, 22 May 2003 22:19:22 +1000 Date: Thu, 22 May 2003 22:19:20 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Yar Tikhiy In-Reply-To: <20030519182357.GA99588@comp.chem.msu.su> Message-ID: <20030522220631.P43165@gamplex.bde.org> References: <200305161646.h4GGkdDS000677@stylish.chem.msu.su> <20030517091047.GA82314@comp.chem.msu.su> <20030519182357.GA99588@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-bugs@freebsd.org cc: FreeBSD-gnats-submit@freebsd.org cc: joerg@freebsd.org Subject: Re: kern/52338: fd(4) floppy disk driver & non-blocking I/O X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 12:19:29 -0000 On Mon, 19 May 2003, Yar Tikhiy wrote: > On Sun, May 18, 2003 at 12:39:03AM +1000, Bruce Evans wrote: > > > > It should set bp->bio_resid (to bp->bio_bcount) (bio_resid and bio_bcount > > are the same as b_resid and b_bcount here; strategy routines only have > > access to a struct bio so they must use the former). > > What do you think about the following straightforward patch to fd.c? > It catches all spots where BIO_ERROR is set, but bio_resid isn't. > In fd.c, bio_resid is never set in advance, so the simplest approach > should work. > > OTOH, I wonder if bio_resid could be set equal to bio_bcount at the > beginning of fdstrategy() and changed only if needed. Does this have > any obscure implications? I think that is the right place to set it. The residual count really is the full count initially. Any obfuscations come later. The driver might prefer to only set bio_resid to its final value at the end of normal i/o instead of as every block is finished. Then the initial setting would only used for abnormal i/o. This is essentially what the fd driver does (except it just forgets to set bio_resid for abnormal i/o). > And my other thought is: What if physio() sets bio_resid equal to > bio_bcount before calling DEV_STRATEGY()? Currently, physio() > leaves bio_resid unset. An obvious drawback of this approach is > that it would encourage poor coding in drivers, though. Rev.1.37 of kern/subr_disk.c sets bio_resid to bio_bcount in the generic strategy routine. This is a better place than physio(). The fd driver didn't benefit from this because it never used the disk mini-layer. Now geom is used instead of the disk mini-layer. geom now uses essentially the same method as the fd driver for normal i/o -- it keeps track of the amount of i/o completed and subtracts this from bio_bcount to get bio_resid when i/o completes, and it doesn't set bio_resid initially. The fd driver doesn't benefit from this because it doesn't use geom either. > --- fd.c.dist Fri Apr 11 15:39:24 2003 > +++ fd.c Mon May 19 21:48:11 2003 > @@ -1668,8 +1668,9 @@ fdstrategy(struct bio *bp) > (u_long)major(bp->bio_dev), (u_long)minor(bp->bio_dev)); > fdc = fd->fdc; > if (fd->type == FDT_NONE || fd->ft == 0) { > - bp->bio_error = ENXIO; > + bp->bio_error = fd->type == FDT_NONE ? ENXIO : EAGAIN; > bp->bio_flags |= BIO_ERROR; > + bp->bio_resid = bp->bio_bcount; > goto bad; > } > fdblk = 128 << (fd->ft->secsize); I think this should check FD_NONBLOCK like the next clause does, and only return EAGAIN when FD_NONBLOCK is set. This is clearer even if it is equivalent (can we get here with a type but no ft?). Bruce From owner-freebsd-bugs@FreeBSD.ORG Thu May 22 05:20:10 2003 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1513A37B401 for ; Thu, 22 May 2003 05:20:10 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DD7743F3F for ; Thu, 22 May 2003 05:20:09 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h4MCK9Up046314 for ; Thu, 22 May 2003 05:20:09 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h4MCK9Fw046313; Thu, 22 May 2003 05:20:09 -0700 (PDT) Date: Thu, 22 May 2003 05:20:09 -0700 (PDT) Message-Id: <200305221220.h4MCK9Fw046313@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Bruce Evans Subject: Re: kern/52338: fd(4) floppy disk driver & non-blocking I/O X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Bruce Evans List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 12:20:10 -0000 The following reply was made to PR kern/52338; it has been noted by GNATS. From: Bruce Evans To: Yar Tikhiy Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-bugs@freebsd.org, joerg@freebsd.org Subject: Re: kern/52338: fd(4) floppy disk driver & non-blocking I/O Date: Thu, 22 May 2003 22:19:20 +1000 (EST) On Mon, 19 May 2003, Yar Tikhiy wrote: > On Sun, May 18, 2003 at 12:39:03AM +1000, Bruce Evans wrote: > > > > It should set bp->bio_resid (to bp->bio_bcount) (bio_resid and bio_bcount > > are the same as b_resid and b_bcount here; strategy routines only have > > access to a struct bio so they must use the former). > > What do you think about the following straightforward patch to fd.c? > It catches all spots where BIO_ERROR is set, but bio_resid isn't. > In fd.c, bio_resid is never set in advance, so the simplest approach > should work. > > OTOH, I wonder if bio_resid could be set equal to bio_bcount at the > beginning of fdstrategy() and changed only if needed. Does this have > any obscure implications? I think that is the right place to set it. The residual count really is the full count initially. Any obfuscations come later. The driver might prefer to only set bio_resid to its final value at the end of normal i/o instead of as every block is finished. Then the initial setting would only used for abnormal i/o. This is essentially what the fd driver does (except it just forgets to set bio_resid for abnormal i/o). > And my other thought is: What if physio() sets bio_resid equal to > bio_bcount before calling DEV_STRATEGY()? Currently, physio() > leaves bio_resid unset. An obvious drawback of this approach is > that it would encourage poor coding in drivers, though. Rev.1.37 of kern/subr_disk.c sets bio_resid to bio_bcount in the generic strategy routine. This is a better place than physio(). The fd driver didn't benefit from this because it never used the disk mini-layer. Now geom is used instead of the disk mini-layer. geom now uses essentially the same method as the fd driver for normal i/o -- it keeps track of the amount of i/o completed and subtracts this from bio_bcount to get bio_resid when i/o completes, and it doesn't set bio_resid initially. The fd driver doesn't benefit from this because it doesn't use geom either. > --- fd.c.dist Fri Apr 11 15:39:24 2003 > +++ fd.c Mon May 19 21:48:11 2003 > @@ -1668,8 +1668,9 @@ fdstrategy(struct bio *bp) > (u_long)major(bp->bio_dev), (u_long)minor(bp->bio_dev)); > fdc = fd->fdc; > if (fd->type == FDT_NONE || fd->ft == 0) { > - bp->bio_error = ENXIO; > + bp->bio_error = fd->type == FDT_NONE ? ENXIO : EAGAIN; > bp->bio_flags |= BIO_ERROR; > + bp->bio_resid = bp->bio_bcount; > goto bad; > } > fdblk = 128 << (fd->ft->secsize); I think this should check FD_NONBLOCK like the next clause does, and only return EAGAIN when FD_NONBLOCK is set. This is clearer even if it is equivalent (can we get here with a type but no ft?). Bruce From owner-freebsd-bugs@FreeBSD.ORG Thu May 22 09:40:29 2003 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB91637B401 for ; Thu, 22 May 2003 09:40:29 -0700 (PDT) Received: from vexpert.dbai.tuwien.ac.at (vexpert.dbai.tuwien.ac.at [128.131.111.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C88743F75 for ; Thu, 22 May 2003 09:40:29 -0700 (PDT) (envelope-from gerald@FreeBSD.org) Received: from [128.131.111.52] (naos [128.131.111.52]) by vexpert.dbai.tuwien.ac.at (Postfix) with ESMTP id 9835B13789; Thu, 22 May 2003 18:40:25 +0200 (CEST) Date: Thu, 22 May 2003 18:40:22 +0200 (CEST) From: Gerald Pfeifer To: Keith Bostic In-Reply-To: <200305211400.h4LE06nx008396@abyssinian.sleepycat.com> Message-ID: References: <200305211400.h4LE06nx008396@abyssinian.sleepycat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-bugs@FreeBSD.org Subject: Re: gnu/13525: gcc fails load against library with both C++ and C modules X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 16:40:30 -0000 On Wed, 21 May 2003, Keith Bostic wrote: > Your analysis misses the point I tried to make -- if you write > a C program, which only uses C library modules, why should a C++ > compiler be needed? You don't actually need the C++ _compiler_, but C++ code generated by GCC needs to link in some support library. This can be accomplished by explicitly specifying this library or by using the g++ driver instead of the gcc to perform the final linkage. > Neither the C code you wrote, nor the C library modules you loaded, > should have "used any C++ library routines (directly or indirectly)" -- > why does the act of loading against a library that contains both C and > C++ modules, suddenly require use of a C++ compiler? You don't need a C++ compiler, but the C++ modules require you to link with libstdc++ or (as of GCC 3.0) libsupc++. In fact, GCC 3 switch to a minimal library like libsupc++ also to help users like you who don't really need a full C++ library. > There shouldn't be any "additional libraries" required -- it's > a program written entirely in C, it never loaded a C++ anything, > why would there be any need for additional C++ libraries!? The (nice) example program added to the PR by someone else used iostream, so in that case one explictly needs full C++ libraries, but even if we remove that use of iostream, current GCCs will complain about __gxx_personality_v0 missing. That is, the problem you were seeing gut improved, indeed, and if you just add -lsupc++ to your linker command, everything is fine (and you can indeed link using gcc). > I mean, it's probably that there's something that's getting magically > loaded out of the library, just because it exists in the library, but my > point is there's no reason for that to happen that I can think of. Intuitively I agree with you, but would you mind raising this issue on the gcc@gcc.gnu.org list where you can reach those GCC developers who have more in depth knowledge of that? (This issue is not FreeBSD-specific, as has also been observed by other committers, that's why I have closed the PR now.) Gerald From owner-freebsd-bugs@FreeBSD.ORG Thu May 22 09:49:42 2003 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5735737B404; Thu, 22 May 2003 09:49:42 -0700 (PDT) Received: from abyssinian.sleepycat.com (abyssinian.sleepycat.com [199.103.242.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66A6D43FA3; Thu, 22 May 2003 09:49:41 -0700 (PDT) (envelope-from bostic@abyssinian.sleepycat.com) Received: from abyssinian.sleepycat.com (bostic@localhost [127.0.0.1]) h4MGlPDh098429; Thu, 22 May 2003 12:47:25 -0400 (EDT) (envelope-from bostic@abyssinian.sleepycat.com) Received: (from bostic@localhost) by abyssinian.sleepycat.com (8.12.6/8.12.6/Submit) id h4MGlPL2098428; Thu, 22 May 2003 12:47:25 -0400 (EDT) (envelope-from bostic) Date: Thu, 22 May 2003 12:47:25 -0400 (EDT) From: Keith Bostic Message-Id: <200305221647.h4MGlPL2098428@abyssinian.sleepycat.com> To: gerald@FreeBSD.org cc: freebsd-bugs@FreeBSD.org Subject: Re: gnu/13525: gcc fails load against library with both C++ and C modules X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 16:49:42 -0000 >> I mean, it's probably that there's something that's getting magically >> loaded out of the library, just because it exists in the library, but my >> point is there's no reason for that to happen that I can think of. > > Intuitively I agree with you, but would you mind raising this issue on > the gcc@gcc.gnu.org list where you can reach those GCC developers who > have more in depth knowledge of that? I agree, this isn't a FreeBSD specific issue. Regards, --keith =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Keith Bostic bostic@sleepycat.com Sleepycat Software Inc. keithbosticim (ymsgid) 118 Tower Rd. +1-781-259-3139 Lincoln, MA 01773 http://www.sleepycat.com From owner-freebsd-bugs@FreeBSD.ORG Thu May 22 10:22:27 2003 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66F5B37B401; Thu, 22 May 2003 10:22:27 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A246143FA3; Thu, 22 May 2003 10:22:26 -0700 (PDT) (envelope-from anholt@FreeBSD.org) Received: from freefall.freebsd.org (anholt@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h4MHMQUp071933; Thu, 22 May 2003 10:22:26 -0700 (PDT) (envelope-from anholt@freefall.freebsd.org) Received: (from anholt@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h4MHMQ8R071929; Thu, 22 May 2003 10:22:26 -0700 (PDT) Date: Thu, 22 May 2003 10:22:26 -0700 (PDT) From: Eric Anholt Message-Id: <200305221722.h4MHMQ8R071929@freefall.freebsd.org> To: ura@euro-bill.net, anholt@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: i386/51210: gcc compiler bug with floating point X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 17:22:27 -0000 Synopsis: gcc compiler bug with floating point State-Changed-From-To: open->closed State-Changed-By: anholt State-Changed-When: Thu May 22 10:20:38 PDT 2003 State-Changed-Why: Duplicate of bin/43299 and a patch has been committed to bsd.cpu.mk to prevent -march=pentium4 from being added with p4 CPUTYPE. http://www.freebsd.org/cgi/query-pr.cgi?pr=51210 From owner-freebsd-bugs@FreeBSD.ORG Thu May 22 10:30:08 2003 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8339D37B401 for ; Thu, 22 May 2003 10:30:08 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F31F43FAF for ; Thu, 22 May 2003 10:30:07 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h4MHU6Up073046 for ; Thu, 22 May 2003 10:30:06 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h4MHU6xR073045; Thu, 22 May 2003 10:30:06 -0700 (PDT) Resent-Date: Thu, 22 May 2003 10:30:06 -0700 (PDT) Resent-Message-Id: <200305221730.h4MHU6xR073045@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, "Kostik I. Belousov" Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A0B0D37B401 for ; Thu, 22 May 2003 10:27:01 -0700 (PDT) Received: from smtp3.lucky.net (smtp3.lucky.net [62.244.55.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id D75C743F75 for ; Thu, 22 May 2003 10:26:58 -0700 (PDT) (envelope-from kostik@kib.kiev.ua) Received: from smtp.lucky.net (smtp1.lucky.net [193.193.193.117]) by smtp3.lucky.net (postfix-1.1.5) with ESMTP id 24BD08990A for ; Thu, 22 May 2003 20:26:56 +0300 (EEST) Received: from kozlik.carrier.kiev.ua (smmsp@kozlik.carrier.kiev.ua [193.193.193.111]) by smtp.lucky.net with ESMTP id h5MHQp2D069430 for ; Thu, 22 May 2003 20:26:54 +0300 (EEST) (envelope-from kostik@kib.kiev.ua) Received: (from uucp@localhost) by kozlik.carrier.kiev.ua with UUCP id h5MHQi04034555 for FreeBSD-gnats-submit@freebsd.org; Thu, 22 May 2003 20:26:44 +0300 (EEST) (envelope-from kostik@kib.kiev.ua) Received: from kib.UUCP (uucp@localhost)UUCP; Thu, 22 May 2003 17:26:44 +0000 GMT Received: from little.home (kostik@localhost [127.0.0.1]) by little.home (8.12.8p1/8.12.8) with ESMTP id h4MHNPTR000432 for ; Thu, 22 May 2003 20:23:25 +0300 (EEST) (envelope-from kostik@little.home) Received: (from kostik@localhost) by little.home (8.12.8p1/8.12.8/Submit) id h4MHNPiP000431; Thu, 22 May 2003 20:23:25 +0300 (EEST) (envelope-from kostik) Message-Id: <200305221723.h4MHNPiP000431@little.home> Date: Thu, 22 May 2003 20:23:25 +0300 (EEST) From: "Kostik I. Belousov" To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: kern/52585: Kernel panic with ipfw2 and syncookies X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Kostik I. Belousov" List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 17:30:09 -0000 >Number: 52585 >Category: kern >Synopsis: Kernel panic with ipfw2 and syncookies >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu May 22 10:30:03 PDT 2003 >Closed-Date: >Last-Modified: >Originator: Kostik I. Belousov >Release: FreeBSD 4.8-RELEASE i386 >Organization: none >Environment: System: FreeBSD little.home 4.8-RELEASE FreeBSD 4.8-RELEASE #1: Fri May 2 18:08:25 EEST 2003 root@little.home:/usr/obj/usr/src/sys/LITTLE i386 sysctl hw.machine: i386 hw.model: Pentium II/Pentium II Xeon/Celeron hw.ncpu: 2 hw.byteorder: 1234 hw.physmem: 533917696 hw.usermem: 491724800 hw.pagesize: 4096 hw.floatingpoint: 1 hw.machine_arch: i386 hw.ata.ata_dma: 1 hw.ata.wc: 1 hw.ata.tags: 0 hw.ata.atapi_dma: 0 hw.instruction_sse: 0 hw.availpages: 130185 net.inet.tcp.syncookies: 1 net.inet.tcp.syncache.bucketlimit: 30 net.inet.tcp.syncache.cachelimit: 15359 net.inet.tcp.syncache.count: 0 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.rexmtlimit: 3 Kernel compiled with ipfw2. >Description: By adding/removing aliases and manipulating ipfw rules (I caused the panic using ipfw fwd, see below), the kernel could be paniced. The trace: (kgdb) bt #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487 #1 0xc0158847 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:316 #2 0xc0158cb9 in panic (fmt=0xc0291b19 "%s") at /usr/src/sys/kern/kern_shutdown.c:595 #3 0xc024b459 in trap_fatal (frame=0xd3933cc0, eva=8) at /usr/src/sys/i386/i386/trap.c:974 #4 0xc024b0c5 in trap_pfault (frame=0xd3933cc0, usermode=0, eva=8) at /usr/src/sys/i386/i386/trap.c:867 #5 0xc024ac1f in trap (frame={tf_fs = 1644167192, tf_es = -1072234480, tf_ds = -745340912, tf_edi = 1644167168, tf_esi = -1054094552, tf_ebp = -745325300, tf_isp = -745325332, tf_ebx = -761024704, tf_edx = -1070824920, tf_ecx = 0, tf_eax = -1, tf_trapno = 12, tf_err = 0, tf_eip = -1071929334, tf_cs = 8, tf_eflags = 66198, tf_esp = -761024704, tf_ss = -1050054796}) at /usr/src/sys/i386/i386/trap.c:466 #6 0xc01ba80a in syncache_insert (sc=0xd2a3af40, sch=0xc12bcb28) at /usr/src/sys/netinet/tcp_syncache.c:302 #7 0xc01bb67c in syncache_add (inc=0xd3933db4, to=0xd3933e20, th=0xc1051950, sop=0xd3933db0, m=0xc1051900) at /usr/src/sys/netinet/tcp_syncache.c:1021 #8 0xc01b5809 in tcp_input (m=0xc1051900, off0=20, proto=6) at /usr/src/sys/netinet/tcp_input.c:826 #9 0xc01b026c in ip_input (m=0xc1051900) at /usr/src/sys/netinet/ip_input.c:927 #10 0xc01b02cb in ipintr () at /usr/src/sys/netinet/ip_input.c:948 #11 0xc023c051 in swi_net_next () #12 0xc017a835 in connect (p=0xd3876be0, uap=0xd3933f80) at /usr/src/sys/kern/uipc_syscalls.c:394 #13 0xc024b795 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135174508, tf_esi = -1077953148, tf_ebp = -1077953136, tf_isp = -745324588, tf_ebx = 0, tf_edx = 134570369, tf_ecx = 135112576, tf_eax = 98, tf_trapno = 22, tf_err = 2, tf_eip = 673579312, tf_cs = 31, tf_eflags = 659, tf_esp = -1077953564, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1175 #14 0xc0237f5b in Xint0x80_syscall () #15 0x805b4b5 in ?? () #16 0x8059c0e in ?? () #17 0x805985f in ?? () #18 0x806e639 in ?? () #19 0x804c03a in ?? () (kgdb) frame 6 #6 0xc01ba80a in syncache_insert (sc=0xd2a3af40, sch=0xc12bcb28) at /usr/src/sys/netinet/tcp_syncache.c:302 302 if (sc2 != NULL) (kgdb) list 297 * first non-empty timer queue with the largest 298 * timeout value. 299 */ 300 for (i = SYNCACHE_MAXREXMTS; i >= 0; i--) { 301 sc2 = TAILQ_FIRST(&tcp_syncache.timerq[i]); 302 if (sc2 != NULL) 303 break; 304 } 305 sc2->sc_tp->ts_recent = ticks; 306 syncache_drop(sc2, NULL); >How-To-Repeat: ifconfig lo0 192.168.2.1 alias ipfw 50 add fwd 192.168.2.1,23 tcp from any to 192.168.2.1 some time ... ipfw del 50 ifconfig lo0 192.168.2.1 remove some more time ... attempt to make tcp connection to the machine panics the kernel >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-bugs@FreeBSD.ORG Thu May 22 10:37:16 2003 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA64937B409 for ; Thu, 22 May 2003 10:37:16 -0700 (PDT) Received: from ns1.digital-network.net (ns1.digital-network.net [81.91.65.187]) by mx1.FreeBSD.org (Postfix) with SMTP id E852743FBF for ; Thu, 22 May 2003 10:37:10 -0700 (PDT) (envelope-from aferrari@nerim.net) Received: (qmail 1614 invoked from network); 22 May 2003 17:29:08 -0000 Received: from alyon-209-1-16-170.w81-49.abo.wanadoo.fr (HELO laptop1.bsd.digital-network.org) (81.49.78.170) by ns1.digital-network.net with SMTP; 22 May 2003 17:29:08 -0000 Date: Thu, 22 May 2003 19:37:09 +0200 From: Ange Ferrari To: freebsd-bugs@freebsd.org Message-Id: <20030522193709.5c3b5e5b.aferrari@nerim.net> Organization: Nerim X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386-portbld-freebsd4.7) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: bug in /usr/ports/x11-fonts/Xft X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 17:37:17 -0000 bug in /usr/ports/x11-fonts/Xft/ system: FreeBSD 4.7-RELEASE ===> Building for Xft-2.1.2 gmake all-am gmake[1]: Entering directory `/usr/ports/x11-fonts/Xft/work/xft-2.1.2' source='xftfreetype.c' object='xftfreetype.lo' libtool=yes \ depfile='.deps/xftfreetype.Plo' tmpdepfile='.deps/xftfreetype.TPlo' \ depmode=gcc /bin/sh ./depcomp \ /bin/sh ./libtool --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/X11R6/include -I/usr/X11R6/include -I/usr/local/include/freetype2 -I/usr/local/include -I/usr/X11R6/include -O -pipe -c -o xftfreetype.lo `test -f 'xftfreetype.c' || echo './'`xftfreetype.c cc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/X11R6/include -I/usr/X11R6/include -I/usr/local/include/freetype2 -I/usr/local/include -I/usr/X11R6/include -O -pipe -c xftfreetype.c -Wp,-MD,.deps/xftfreetype.TPlo -fPIC -o .libs/xftfreetype.o xftfreetype.c: In function `XftFontOpenInfo': xftfreetype.c:705: `PictStandardARGB32' undeclared (first use in this function) xftfreetype.c:705: (Each undeclared identifier is reported only once xftfreetype.c:705: for each function it appears in.) xftfreetype.c:705: warning: assignment makes pointer from integer without a cast xftfreetype.c:708: `PictStandardA8' undeclared (first use in this function) xftfreetype.c:708: warning: assignment makes pointer from integer without a cast xftfreetype.c:714: `PictStandardA1' undeclared (first use in this function) xftfreetype.c:714: warning: assignment makes pointer from integer without a cast gmake[1]: *** [xftfreetype.lo] Error 1 gmake[1]: Leaving directory `/usr/ports/x11-fonts/Xft/work/xft-2.1.2' gmake: *** [all] Error 2 *** Error code 2 Stop in /usr/ports/x11-fonts/Xft. *** Error code 1 Stop in /usr/ports/www/mozilla. *** Error code 1 Stop in /usr/ports/www/mozilla-headers. *** Error code 1 Stop in /usr/ports/www/galeon. [19:52:46] root@hp:(/usr/ports/www/galeon): -- You can get a good standard workstation install by using the instant-workstation port/package. If you have ports installed, you can install it by doing # cd /usr/ports/misc/instant-workstation # make install && make clean as root. This will install a collection of packages that is convenient to have on a workstation. From owner-freebsd-bugs@FreeBSD.ORG Thu May 22 10:41:08 2003 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1539E37B401 for ; Thu, 22 May 2003 10:41:08 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7357A43F93 for ; Thu, 22 May 2003 10:41:07 -0700 (PDT) (envelope-from eta@lclark.edu) Received: from [192.168.0.101] (12-224-152-126.client.attbi.com[12.224.152.126]) by attbi.com (sccrmhc02) with SMTP id <20030522174106002002m6l9e>; Thu, 22 May 2003 17:41:06 +0000 From: Eric Anholt To: Ange Ferrari In-Reply-To: <20030521195544.388688c3.aferrari@nerim.net> References: <20030521195544.388688c3.aferrari@nerim.net> Content-Type: text/plain Organization: Message-Id: <1053625713.664.83.camel@leguin> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 May 2003 10:48:33 -0700 Content-Transfer-Encoding: 7bit cc: bugs@freebsd.org Subject: Re: bug in /usr/ports/x11-fonts/Xft/work/xft-2.1.2 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 17:41:08 -0000 On Wed, 2003-05-21 at 10:55, Ange Ferrari wrote: > there is a bug in a port > /usr/ports/x11-fonts/Xft/work/xft-2.1.2 > my system is FreeBSD 4.7-RELEASE > > ===> Building for Xft-2.1.2 > gmake all-am > gmake[1]: Entering directory `/usr/ports/x11-fonts/Xft/work/xft-2.1.2' > source='xftfreetype.c' object='xftfreetype.lo' libtool=yes \ > depfile='.deps/xftfreetype.Plo' tmpdepfile='.deps/xftfreetype.TPlo' \ > depmode=gcc /bin/sh ./depcomp \ > /bin/sh ./libtool --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I. > -I/usr/X11R6/include -I/usr/X11R6/include -I/usr/local/include/freetype2 > -I/usr/local/include -I/usr/X11R6/include -O -pipe -c -o xftfreetype.lo > `test -f 'xftfreetype.c' || echo './'`xftfreetype.c > cc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/X11R6/include -I/usr/X11R6/include > -I/usr/local/include/freetype2 -I/usr/local/include -I/usr/X11R6/include > -O -pipe -c xftfreetype.c -Wp,-MD,.deps/xftfreetype.TPlo -fPIC -o > .libs/xftfreetype.o > xftfreetype.c: In function `XftFontOpenInfo': > xftfreetype.c:705: `PictStandardARGB32' undeclared (first use in this > function) > xftfreetype.c:705: (Each undeclared identifier is reported only once > xftfreetype.c:705: for each function it appears in.) > xftfreetype.c:705: warning: assignment makes pointer from integer without > a cast > xftfreetype.c:708: `PictStandardA8' undeclared (first use in this > function) > xftfreetype.c:708: warning: assignment makes pointer from integer without > a cast > xftfreetype.c:714: `PictStandardA1' undeclared (first use in this > function) > xftfreetype.c:714: warning: assignment makes pointer from integer without > a cast > gmake[1]: *** [xftfreetype.lo] Error 1 > gmake[1]: Leaving directory `/usr/ports/x11-fonts/Xft/work/xft-2.1.2' > gmake: *** [all] Error 2 > *** Error code 2 You need to update your XFree86-4-libraries to 4.3.0 or later to use Xft 2.1.2. BTW, something like this should go to ports@freebsd.org. -- Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org From owner-freebsd-bugs@FreeBSD.ORG Thu May 22 12:10:10 2003 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1DBB37B404 for ; Thu, 22 May 2003 12:10:10 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A009943F75 for ; Thu, 22 May 2003 12:10:08 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h4MJA7Up097285 for ; Thu, 22 May 2003 12:10:07 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h4MJA7Uu097284; Thu, 22 May 2003 12:10:07 -0700 (PDT) Resent-Date: Thu, 22 May 2003 12:10:07 -0700 (PDT) Resent-Message-Id: <200305221910.h4MJA7Uu097284@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, "Bruce R. Montague" Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3BE937B401; Thu, 22 May 2003 12:07:07 -0700 (PDT) Received: from mail.cruzio.com (mail.cruzio.com [63.249.95.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 343ED43F3F; Thu, 22 May 2003 12:07:07 -0700 (PDT) (envelope-from brucem@cruzio.com) Received: from cruzio.com (dsl3-63-249-85-132.cruzio.com [63.249.85.132]) by mail.cruzio.com with ESMTP id h4MJDWaX023632; Thu, 22 May 2003 12:13:32 -0700 (PDT) Received: (from brucem@localhost) by cruzio.com (8.12.6/8.12.6/Submit) id h4MK5Wlx094455; Thu, 22 May 2003 13:05:32 -0700 (PDT) Message-Id: <200305222005.h4MK5Wlx094455@cruzio.com> Date: Thu, 22 May 2003 13:05:32 -0700 (PDT) From: "Bruce R. Montague" To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 cc: ticso@bwct.de cc: rizzo@icir.org cc: joe@tao.org.uk cc: n_hibma@FreeBSD.org Subject: kern/52589: [patch] Add isochronous usb OHCI support to ohci.c X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Bruce R. Montague" List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 19:10:11 -0000 >Number: 52589 >Category: kern >Synopsis: [patch] Add isochronous usb OHCI support to ohci.c >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: update >Submitter-Id: current-users >Arrival-Date: Thu May 22 12:10:07 PDT 2003 >Closed-Date: >Last-Modified: >Originator: Bruce R. Montague >Release: FreeBSD 5.1-BETA i386 >Organization: >Environment: System: FreeBSD geode 5.1-BETA FreeBSD 5.1-BETA #9: Thu May 22 03:14:15 GMT 2003 brucem@geode:/usr/obj/usr/src/sys/GENERIC i386 FreeBSD 5.1 -Current with a Geode GX1 CPU and CS5530 southbridge containing an OHCI compatible usb controller. The "ohci.c" and "ohcivar.h" file do not appear to have been modified in over 2 months. >Description: Isochronous OHCI usb transfers do not currently work with "ohci.c". The initial transfers created on open will operate once, after which the driver will stall. There is at least one critical bug (each iteration of the isochronous transfer, resources just allocated are erroneously immediately deallocated). >How-To-Repeat: Attempt to use a web-camera with an OHCI controller. >Fix: The following patch to: /usr/src/sys/dev/usb/ohci.c /usr/src/sys/dev/usb/ohcivar.h implements support for usb isochronous input transfers on the OHCI usb controller. The patch is with respect to the latest -current HEAD files: ohci.c - rev 1.118 ohcivar.h - rev 1.33 This patch has been tested with a DLINK DSB-C100 web camera. This code has acquired images (at a rate of roughly one per second) for over a week at a time under varying loads on a very small machine; no panics, errors, or obvious memory leaks have been observed. I have not tested it on anything else. This patch has one significant bug-fix with respect to the previous patch I posted to freebsd-hardware. The current ohci isochronous code has no possibility of working for any request that does more than a few isochronous transfers, so this patch is of interest to anyone wanting to work with web cameras using the OHCI usb controller. I will try to MFC this into -stable. A copy of this patch, and the patched, working "ohci.c" and "ohcivar.h" source files, can currently be found at: http://63.249.85.132/ohci_patches.htm --- send-pr.diff.txt begins here --- diff -u old/ohci.c new/ohci.c --- old/ohci.c Thu May 22 08:35:50 2003 +++ new/ohci.c Thu May 22 08:32:39 2003 @@ -255,6 +255,7 @@ struct ohci_pipe { struct usbd_pipe pipe; ohci_soft_ed_t *sed; + u_int32_t aborting; union { ohci_soft_td_t *td; ohci_soft_itd_t *itd; @@ -635,6 +636,7 @@ OHCI_ITD_ALIGN, &dma); if (err) return (NULL); + s = splusb(); for(i = 0; i < OHCI_SITD_CHUNK; i++) { offs = i * OHCI_SITD_SIZE; sitd = KERNADDR(&dma, offs); @@ -642,6 +644,7 @@ sitd->nextitd = sc->sc_freeitds; sc->sc_freeitds = sitd; } + splx(s); } s = splusb(); @@ -974,6 +977,18 @@ ohci_freex(struct usbd_bus *bus, usbd_xfer_handle xfer) { struct ohci_softc *sc = (struct ohci_softc *)bus; + struct ohci_xfer *oxfer = (struct ohci_xfer *)xfer; + ohci_soft_itd_t *sitd; + + if (oxfer->ohci_xfer_flags & OHCI_ISOC_DIRTY) { + sitd = xfer->hcpriv; + if (sitd) { + for (; sitd->xfer == xfer; sitd = sitd->nextitd) { + if ( sitd == NULL ) break; + ohci_free_sitd(sc, sitd); + } + } + } #ifdef DIAGNOSTIC if (xfer->busy_free != XFER_BUSY) { @@ -1380,7 +1395,9 @@ xfer->actlen += len; if (std->flags & OHCI_CALL_DONE) { xfer->status = USBD_NORMAL_COMPLETION; + s = splusb(); usb_transfer_complete(xfer); + splx(s); } ohci_free_std(sc, std); } else { @@ -1420,7 +1437,10 @@ xfer->status = USBD_STALLED; else xfer->status = USBD_IOERROR; + + s = splusb(); usb_transfer_complete(xfer); + splx(s); } } @@ -1434,6 +1454,7 @@ for (sitd = sidone; sitd != NULL; sitd = sitdnext) { xfer = sitd->xfer; sitdnext = sitd->dnext; + sitd->flags |= OHCI_ITD_INTFIN; DPRINTFN(1, ("ohci_process_done: sitd=%p xfer=%p hcpriv=%p\n", sitd, xfer, xfer ? xfer->hcpriv : 0)); if (xfer == NULL) @@ -1445,27 +1466,37 @@ /* Handled by abort routine. */ continue; } + if (xfer->pipe) { + if (xfer->pipe->aborting) continue; /*Ignore.*/ + } #ifdef DIAGNOSTIC if (sitd->isdone) printf("ohci_softintr: sitd=%p is done\n", sitd); sitd->isdone = 1; #endif + struct ohci_pipe *opipe = + (struct ohci_pipe *)xfer->pipe; + if (opipe->aborting ) + continue; + cc = OHCI_ITD_GET_CC(le32toh(sitd->itd.itd_flags)); if (cc == OHCI_CC_NO_ERROR) { /* XXX compute length for input */ - struct ohci_pipe *opipe = - (struct ohci_pipe *)xfer->pipe; if (sitd->flags & OHCI_CALL_DONE) { opipe->u.iso.inuse -= xfer->nframes; /* XXX update frlengths with actual length */ /* XXX xfer->actlen = actlen; */ xfer->status = USBD_NORMAL_COMPLETION; + s = splusb(); usb_transfer_complete(xfer); + splx(s); } } else { /* XXX Do more */ xfer->status = USBD_IOERROR; + s = splusb(); usb_transfer_complete(xfer); + splx(s); } } @@ -2079,6 +2110,7 @@ if (sitd == NULL) goto bad1; opipe->tail.itd = sitd; + opipe->aborting = 0; tdphys = sitd->physaddr; fmt = OHCI_ED_FORMAT_ISO; if (UE_GET_DIR(ed->bEndpointAddress) == UE_DIR_IN) @@ -3223,8 +3255,9 @@ ohci_softc_t *sc = (ohci_softc_t *)dev->bus; ohci_soft_ed_t *sed = opipe->sed; struct iso *iso = &opipe->u.iso; + struct ohci_xfer *oxfer = (struct ohci_xfer *)xfer; ohci_soft_itd_t *sitd, *nsitd; - ohci_physaddr_t buf, offs, noffs, bp0; + ohci_physaddr_t buf, offs, noffs, bp0, tdphys; int i, ncur, nframes; int s; @@ -3242,6 +3275,24 @@ iso->next)); } + if (xfer->hcpriv) { + sitd = xfer->hcpriv; + for (; sitd->xfer == xfer; sitd = sitd->nextitd) { + if (sitd == NULL) break; + ohci_free_sitd(sc, sitd); /* Free ITDs in prev xfer*/ + } + if (sitd == NULL) { + sitd = ohci_alloc_sitd(sc); + if (sitd == NULL) panic( "cant alloc isoc" ); + opipe->tail.itd = sitd; + tdphys = sitd->physaddr; + sed->ed.ed_flags |= htole32(OHCI_ED_SKIP); /* Stop*/ + sed->ed.ed_headp = + sed->ed.ed_tailp = htole32(tdphys); + sed->ed.ed_flags &= htole32(~OHCI_ED_SKIP); /* Start.*/ + } + } + sitd = opipe->tail.itd; buf = DMAADDR(&xfer->dmabuf, 0); bp0 = OHCI_PAGE(buf); @@ -3273,7 +3324,7 @@ sitd->itd.itd_nextitd = htole32(nsitd->physaddr); sitd->itd.itd_be = htole32(bp0 + offs - 1); sitd->xfer = xfer; - sitd->flags = 0; + sitd->flags = OHCI_ITD_ACTIVE; sitd = nsitd; iso->next = iso->next + ncur; @@ -3301,7 +3352,7 @@ sitd->itd.itd_nextitd = htole32(nsitd->physaddr); sitd->itd.itd_be = htole32(bp0 + offs - 1); sitd->xfer = xfer; - sitd->flags = OHCI_CALL_DONE; + sitd->flags = OHCI_CALL_DONE | OHCI_ITD_ACTIVE; iso->next = iso->next + ncur; iso->inuse += nframes; @@ -3310,6 +3361,8 @@ xfer->status = USBD_IN_PROGRESS; + oxfer->ohci_xfer_flags |= OHCI_ISOC_DIRTY; + #ifdef USB_DEBUG if (ohcidebug > 5) { DPRINTF(("ohci_device_isoc_enter: frame=%d\n", @@ -3340,6 +3393,8 @@ { struct ohci_pipe *opipe = (struct ohci_pipe *)xfer->pipe; ohci_softc_t *sc = (ohci_softc_t *)opipe->pipe.device->bus; + ohci_soft_ed_t *sed; + int s; DPRINTFN(5,("ohci_device_isoc_start: xfer=%p\n", xfer)); @@ -3353,6 +3408,11 @@ /* XXX anything to do? */ + s = splusb(); + sed = opipe->sed; /* Turn off ED skip-bit to start processing */ + sed->ed.ed_flags &= htole32(~OHCI_ED_SKIP); /* ED's ITD list.*/ + splx(s); + return (USBD_IN_PROGRESS); } @@ -3362,10 +3422,11 @@ struct ohci_pipe *opipe = (struct ohci_pipe *)xfer->pipe; ohci_softc_t *sc = (ohci_softc_t *)opipe->pipe.device->bus; ohci_soft_ed_t *sed; - ohci_soft_itd_t *sitd; - int s; + ohci_soft_itd_t *sitd,*tmp_sitd; + int s,undone,num_sitds; s = splusb(); + opipe->aborting = 1; DPRINTFN(1,("ohci_device_isoc_abort: xfer=%p\n", xfer)); @@ -3383,6 +3444,7 @@ sed = opipe->sed; sed->ed.ed_flags |= htole32(OHCI_ED_SKIP); /* force hardware skip */ + num_sitds = 0; sitd = xfer->hcpriv; #ifdef DIAGNOSTIC if (sitd == NULL) { @@ -3391,23 +3453,54 @@ return; } #endif - for (; sitd->xfer == xfer; sitd = sitd->nextitd) { + if ( sitd ) { /* Find head sitd in next xfer, only if xfer has ITDs. */ + for (; sitd->xfer == xfer; sitd = sitd->nextitd) { + if ( sitd == NULL ) break; + num_sitds++; #ifdef DIAGNOSTIC DPRINTFN(1,("abort sets done sitd=%p\n", sitd)); sitd->isdone = 1; #endif + } } splx(s); - usb_delay_ms(&sc->sc_bus, OHCI_ITD_NOFFSET); + /* Each sitd has up to OHCI_ITD_NOFFSET transfers, each can + take a usb 1ms cycle. Conservatively wait for it to drain. + Even with DMA done, it can take awhile for the "batch" + delivery of completion interrupts to occur thru the controller. + */ + + do { + usb_delay_ms(&sc->sc_bus, 2*(num_sitds*OHCI_ITD_NOFFSET)); + + undone = 0; + tmp_sitd = xfer->hcpriv; + if ( tmp_sitd ) { + for (; tmp_sitd->xfer == xfer; tmp_sitd = tmp_sitd->nextitd) { + if (tmp_sitd != NULL) { + if (OHCI_CC_NO_ERROR == OHCI_ITD_GET_CC(le32toh(tmp_sitd->itd.itd_flags)) ) { + if (tmp_sitd->flags & OHCI_ITD_ACTIVE) { + if ( (tmp_sitd->flags & OHCI_ITD_INTFIN) == 0 ) undone++; + } + } + } + } + } + } while( undone != 0 ); + s = splusb(); /* Run callback. */ usb_transfer_complete(xfer); - sed->ed.ed_headp = htole32(sitd->physaddr); /* unlink TDs */ + if ( sitd ) { /* Only if there is a `next' sitd in next xfer... */ + sed->ed.ed_headp = htole32(sitd->physaddr); /* unlink this xfer's sitds.*/ + } else + sed->ed.ed_headp = 0; + sed->ed.ed_flags &= htole32(~OHCI_ED_SKIP); /* remove hardware skip */ splx(s); @@ -3416,21 +3509,23 @@ void ohci_device_isoc_done(usbd_xfer_handle xfer) { - struct ohci_pipe *opipe = (struct ohci_pipe *)xfer->pipe; - ohci_softc_t *sc = (ohci_softc_t *)opipe->pipe.device->bus; - ohci_soft_itd_t *sitd, *nsitd; - - DPRINTFN(1,("ohci_device_isoc_done: xfer=%p\n", xfer)); +/* This null routine corresponds to non-isoc "done()" routines + * that free the stds associated with an xfer after a completed + * xfer interrupt. However, in the case of isoc transfers, the + * sitds associated with the transfer have already been processed + * and reallocated for the next iteration by "ohci_device_isoc_transfer()". + * + * Routine "usb_transfer_complete()" is called at the end of every + * relevant usb interrupt. "usb_transfer_complete()" indirectly + * calls 1) "ohci_device_isoc_transfer()" (which keeps pumping the + * pipeline by setting up the next transfer iteration) and 2) then + * calls "ohci_device_isoc_done()". Isoc transfers have not been + * working for the ohci usb because this routine was trashing the + * xfer set up for the next iteration (thus, only the first + * UGEN_NISOREQS xfers outstanding on an open would work). Perhaps + * this could all be re-factored, but that's another pass... + */ - for (sitd = xfer->hcpriv; - !(sitd->flags & OHCI_CALL_DONE); - sitd = nsitd) { - nsitd = sitd->nextitd; - DPRINTFN(1,("ohci_device_isoc_done: free sitd=%p\n", sitd)); - ohci_free_sitd(sc, sitd); - } - ohci_free_sitd(sc, sitd); - xfer->hcpriv = NULL; } usbd_status @@ -3456,11 +3551,20 @@ { struct ohci_pipe *opipe = (struct ohci_pipe *)pipe; ohci_softc_t *sc = (ohci_softc_t *)pipe->device->bus; + ohci_soft_ed_t *sed; DPRINTF(("ohci_device_isoc_close: pipe=%p\n", pipe)); - ohci_close_pipe(pipe, sc->sc_isoc_head); + + sed = opipe->sed; + sed->ed.ed_flags |= htole32(OHCI_ED_SKIP); /* Stop device. */ + + ohci_close_pipe(pipe, sc->sc_isoc_head); /* Stop isoc list, free ED.*/ + + /* up to NISOREQs xfers still outstanding. */ + + #ifdef DIAGNOSTIC opipe->tail.itd->isdone = 1; #endif - ohci_free_sitd(sc, opipe->tail.itd); + ohci_free_sitd(sc, opipe->tail.itd); /* Next `avail free' sitd.*/ } diff -u old/ohcivar.h new/ohcivar.h --- old/ohcivar.h Thu May 22 08:35:50 2003 +++ new/ohcivar.h Thu May 22 08:32:39 2003 @@ -70,6 +70,8 @@ LIST_ENTRY(ohci_soft_itd) hnext; usbd_xfer_handle xfer; u_int16_t flags; +#define OHCI_ITD_ACTIVE 0x0010 /* Hardware op in progress */ +#define OHCI_ITD_INTFIN 0x0020 /* Hw completion interrupt seen.*/ #ifdef DIAGNOSTIC char isdone; #endif @@ -149,7 +151,9 @@ struct ohci_xfer { struct usbd_xfer xfer; struct usb_task abort_task; + u_int32_t ohci_xfer_flags; }; +#define OHCI_ISOC_DIRTY 0x01 #define OXFER(xfer) ((struct ehci_xfer *)(xfer)) --- send-pr.diff.txt ends here --- >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-bugs@FreeBSD.ORG Thu May 22 15:10:14 2003 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A23E137B401 for ; Thu, 22 May 2003 15:10:14 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 055DC43F85 for ; Thu, 22 May 2003 15:10:14 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h4MMADUp014919 for ; Thu, 22 May 2003 15:10:13 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h4MMADtw014918; Thu, 22 May 2003 15:10:13 -0700 (PDT) Date: Thu, 22 May 2003 15:10:13 -0700 (PDT) Message-Id: <200305222210.h4MMADtw014918@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Rob Wise Subject: Re: kern/46619: Installation hangs on IBM Thinkpad T23 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Rob Wise List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2003 22:10:15 -0000 The following reply was made to PR kern/46619; it has been noted by GNATS. From: Rob Wise To: freebsd-gnats-submit@FreeBSD.org, arun@sharma-home.net Cc: Subject: Re: kern/46619: Installation hangs on IBM Thinkpad T23 Date: Fri, 23 May 2003 08:05:28 +1000 (EST) This bug is still present on the install floppy set for 5.1-BETA and 5.1-BETA2. Rob From owner-freebsd-bugs@FreeBSD.ORG Thu May 22 21:40:12 2003 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CBE7D37B404 for ; Thu, 22 May 2003 21:40:12 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84E4043FAF for ; Thu, 22 May 2003 21:40:11 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h4N4eBUp051417 for ; Thu, 22 May 2003 21:40:11 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h4N4eBIc051416; Thu, 22 May 2003 21:40:11 -0700 (PDT) Resent-Date: Thu, 22 May 2003 21:40:11 -0700 (PDT) Resent-Message-Id: <200305230440.h4N4eBIc051416@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Dan Nelson Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5CB5637B401 for ; Thu, 22 May 2003 21:33:10 -0700 (PDT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0F9843F3F for ; Thu, 22 May 2003 21:33:09 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.9/8.12.9) id h4N4X99D064233; Thu, 22 May 2003 23:33:09 -0500 (CDT) (envelope-from dan) Message-Id: <200305230433.h4N4X99D064233@dan.emsphone.com> Date: Thu, 22 May 2003 23:33:09 -0500 (CDT) From: Dan Nelson To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: bin/52601: [PATCH] rpc.yppasswdd fails if master.passwd is not in /etc/ X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2003 04:40:13 -0000 >Number: 52601 >Category: bin >Synopsis: [PATCH] rpc.yppasswdd fails if master.passwd is not in /etc/ >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu May 22 21:40:11 PDT 2003 >Closed-Date: >Last-Modified: >Originator: Dan Nelson >Release: FreeBSD 5.1-BETA i386 >Organization: The Allant Group >Environment: System: FreeBSD dan.emsphone.com 5.1-BETA FreeBSD 5.1-BETA #270: Thu May 22 09:18:13 CDT 2003 dan@dan.emsphone.com:/usr/src/sys/i386/compile/DANSMP i386 >Description: rpc.yppasswd always calls yp_mkdb on master.passwd, which really should only be done if you are exporting /etc/master.passwd. >How-To-Repeat: Set up an NIS server, and run passwd on a client. If it succeeds, you'll see that passwd.db and spwd.db get created in /yar/yp. It also ends up zeroing out the passwd field in the passwd map, which is not a good idea if you're serving non-FreeBSD clients. >Fix: Only call pw_mkdb if passfile == _PATH_MASTERPASSWD. Otherwise, rename master.passwd to a temp filename, rename the new passwd to master.passwd, and let yppwupdate update passwd as it sees fit. This also fixes PR bin/7968. Index: yppasswdd_server.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/rpc.yppasswdd/yppasswdd_server.c,v retrieving revision 1.27 diff -u -p -r1.27 yppasswdd_server.c --- yppasswdd_server.c 3 May 2003 21:06:39 -0000 1.27 +++ yppasswdd_server.c 23 May 2003 04:06:29 -0000 @@ -448,6 +448,7 @@ yppasswdproc_update_1_svc(yppasswd *argp char *oldgecos = NULL; char *passfile_hold; char passfile_buf[MAXPATHLEN + 2]; + char passfile_hold_buf[MAXPATHLEN + 2]; char *domain = yppasswd_domain; static struct sockaddr_in clntaddr; static struct timeval t_saved, t_test; @@ -572,6 +573,11 @@ yppasswdproc_update_1_svc(yppasswd *argp passfile = (char *)&passfile_buf; } + /* Create a filename to hold the original master.passwd so if our call + to yppwupdate fails we can roll back */ + snprintf(passfile_hold_buf, sizeof(passfile_hold_buf), "%s.hold", passfile); + passfile_hold = (char *)&passfile_hold_buf; + /* Step 5: make a new password file with the updated info. */ if (pw_init(dirname(passfile), passfile)) { @@ -593,11 +599,32 @@ yppasswdproc_update_1_svc(yppasswd *argp yp_error("pw_copy() failed"); return &result; } - if (pw_mkdb(yp_password.pw_name) == -1) { + if (rename(passfile, passfile_hold) == -1) { pw_fini(); - yp_error("pw_mkdb() failed"); + yp_error("rename of %s to %s failed", passfile, passfile_hold); return &result; } + if (strcmp(passfile, _PATH_MASTERPASSWD) == 0) { + /* NIS server is exporting the system's master.passwd. */ + /* Call pw_mkdb to rebuild passwd and the .db files */ + if (pw_mkdb(yp_password.pw_name) == -1) { + pw_fini(); + yp_error("pw_mkdb() failed"); + rename(passfile_hold, passfile); + return &result; + } + } else + { + /* NIS server is exporting a private master.passwd. */ + /* Rename tempfile into final location */ + if (rename(pw_tempname(), passfile) == -1) { + pw_fini(); + yp_error("rename of %s to %s failed", pw_tempname(), passfile); + rename(passfile_hold, passfile); + return &result; + } + } + pw_fini(); if (inplace) { @@ -633,9 +660,10 @@ yppasswdproc_update_1_svc(yppasswd *argp } if (verbose) { - yp_error("update completed for user %s (uid %d):", + yp_error("update completed for user %s (uid %d) in %s:", argp->newpw.pw_name, - argp->newpw.pw_uid); + argp->newpw.pw_uid, + passfile); if (passwd_changed) yp_error("password changed"); @@ -677,7 +705,7 @@ yppasswdproc_update_master_1_svc(master_ transp = rqstp->rq_xprt; /* - * NO AF_INET CONNETCIONS ALLOWED! + * NO AF_INET CONNECTIONS ALLOWED! */ rqhost = svc_getcaller(transp); if (rqhost->sin_family != AF_UNIX) { @@ -780,10 +808,12 @@ allow additions to be made to the passwo yp_error("pw_copy() failed"); return &result; } - if (pw_mkdb(argp->newpw.pw_name) == -1) { - pw_fini(); - yp_error("pw_mkdb() failed"); - return &result; + if (strcmp(passfile, _PATH_MASTERPASSWD) == 0) { + if (pw_mkdb(argp->newpw.pw_name) == -1) { + pw_fini(); + yp_error("pw_mkdb() failed"); + return &result; + } } pw_fini(); >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-bugs@FreeBSD.ORG Thu May 22 22:51:49 2003 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F09D537B401; Thu, 22 May 2003 22:51:49 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D7C443FA3; Thu, 22 May 2003 22:51:49 -0700 (PDT) (envelope-from silby@FreeBSD.org) Received: from freefall.freebsd.org (silby@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h4N5pnUp057712; Thu, 22 May 2003 22:51:49 -0700 (PDT) (envelope-from silby@freefall.freebsd.org) Received: (from silby@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h4N5pnx7057708; Thu, 22 May 2003 22:51:49 -0700 (PDT) Date: Thu, 22 May 2003 22:51:49 -0700 (PDT) From: Mike Silbersack Message-Id: <200305230551.h4N5pnx7057708@freefall.freebsd.org> To: silby@FreeBSD.org, freebsd-bugs@FreeBSD.org, silby@FreeBSD.org Subject: Re: kern/50839: icmp time-exceeded causes tcp connect to return success bogusly X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2003 05:51:50 -0000 Synopsis: icmp time-exceeded causes tcp connect to return success bogusly Responsible-Changed-From-To: freebsd-bugs->silby Responsible-Changed-By: silby Responsible-Changed-When: Thu May 22 22:51:29 PDT 2003 Responsible-Changed-Why: Barney reminded me to take this http://www.freebsd.org/cgi/query-pr.cgi?pr=50839 From owner-freebsd-bugs@FreeBSD.ORG Thu May 22 23:25:04 2003 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 550FB37B401; Thu, 22 May 2003 23:25:04 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E67A143F75; Thu, 22 May 2003 23:25:03 -0700 (PDT) (envelope-from silby@FreeBSD.org) Received: from freefall.freebsd.org (silby@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h4N6P3Up062183; Thu, 22 May 2003 23:25:03 -0700 (PDT) (envelope-from silby@freefall.freebsd.org) Received: (from silby@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h4N6P2tE062179; Thu, 22 May 2003 23:25:02 -0700 (PDT) Date: Thu, 22 May 2003 23:25:02 -0700 (PDT) From: Mike Silbersack Message-Id: <200305230625.h4N6P2tE062179@freefall.freebsd.org> To: lars.koeller@uni-bielefeld.de, silby@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: bin/51586: rsh/rshd connect problem (select: protocol failure in circuit setup) X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2003 06:25:04 -0000 Synopsis: rsh/rshd connect problem (select: protocol failure in circuit setup) State-Changed-From-To: open->closed State-Changed-By: silby State-Changed-When: Thu May 22 23:24:18 PDT 2003 State-Changed-Why: This bug turns out to be related to the em driver somehow, not rsh / rshd. So, I'm closing it. Lars, you're welcome to open a new PR with updated info on the problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=51586 From owner-freebsd-bugs@FreeBSD.ORG Thu May 22 23:49:36 2003 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB53037B405; Thu, 22 May 2003 23:49:36 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C8F543FB1; Thu, 22 May 2003 23:49:36 -0700 (PDT) (envelope-from mbr@FreeBSD.org) Received: from freefall.freebsd.org (mbr@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h4N6nZUp062911; Thu, 22 May 2003 23:49:36 -0700 (PDT) (envelope-from mbr@freefall.freebsd.org) Received: (from mbr@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h4N6nZRd062907; Thu, 22 May 2003 23:49:35 -0700 (PDT) Date: Thu, 22 May 2003 23:49:35 -0700 (PDT) From: Martin Blapp Message-Id: <200305230649.h4N6nZRd062907@freefall.freebsd.org> To: mbr@FreeBSD.org, freebsd-bugs@FreeBSD.org, mbr@FreeBSD.org Subject: Re: kern/51823: ADMtek 9511 Ethernet isn't probed X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2003 06:49:37 -0000 Synopsis: ADMtek 9511 Ethernet isn't probed Responsible-Changed-From-To: freebsd-bugs->mbr Responsible-Changed-By: mbr Responsible-Changed-When: Thu May 22 23:49:02 PDT 2003 Responsible-Changed-Why: Take care about this. http://www.freebsd.org/cgi/query-pr.cgi?pr=51823 From owner-freebsd-bugs@FreeBSD.ORG Fri May 23 04:20:13 2003 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE04237B401 for ; Fri, 23 May 2003 04:20:13 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7833043F93 for ; Fri, 23 May 2003 04:20:13 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h4NBKDUp093878 for ; Fri, 23 May 2003 04:20:13 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h4NBKDs1093877; Fri, 23 May 2003 04:20:13 -0700 (PDT) Date: Fri, 23 May 2003 04:20:13 -0700 (PDT) Message-Id: <200305231120.h4NBKDs1093877@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Masachika ISHIZUKA Subject: Re: kern/52425: kern.maxvnodes cannot limit the number of vnodes in use X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Masachika ISHIZUKA List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2003 11:20:14 -0000 The following reply was made to PR kern/52425; it has been noted by GNATS. From: Masachika ISHIZUKA To: das@FreeBSD.ORG Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: kern/52425: kern.maxvnodes cannot limit the number of vnodes in use Date: Fri, 23 May 2003 20:16:47 +0900 (JST) >> I think kern.maxvnodes should limit the debug.numvnodes. > > Tor Egge addressed this issue in rev 1.249.2.30 of > src/sys/kern/vfs_subr.c. Can you please verify that > the symptoms you are experiencing are gone in -STABLE? Hi, David-san. Thank you for mail. I'm too sorry that I missed it had already updated in stable branch. I'll report next Monday whether vfs_subr.c of rev 1.249.2.30 fixes this problem or not. -- ishizuka@ish.org From owner-freebsd-bugs@FreeBSD.ORG Fri May 23 11:20:05 2003 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE89A37B401 for ; Fri, 23 May 2003 11:20:05 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3C5443FCB for ; Fri, 23 May 2003 11:20:04 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h4NIK4Up021992 for ; Fri, 23 May 2003 11:20:04 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h4NIK4uD021991; Fri, 23 May 2003 11:20:04 -0700 (PDT) Resent-Date: Fri, 23 May 2003 11:20:04 -0700 (PDT) Resent-Message-Id: <200305231820.h4NIK4uD021991@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Anatoly Zaharov Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6F2837B401 for ; Fri, 23 May 2003 11:19:33 -0700 (PDT) Received: from kiev.relc.com (scelto.ts.kiev.ua [194.183.162.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F78543FDF for ; Fri, 23 May 2003 11:19:26 -0700 (PDT) (envelope-from zah@relc.com) Received: from relc.com (localhost [127.0.0.1]) by kiev.relc.com (8.12.9/8.12.9) with ESMTP id h4NIJHdZ069334 for ; Fri, 23 May 2003 21:19:19 +0300 (EEST) Received: (from zah@localhost) by relc.com (8.12.9/8.12.9/Submit) id h4NIJGjv069333; Fri, 23 May 2003 21:19:16 +0300 (EEST) Message-Id: <200305231819.h4NIJGjv069333@relc.com> Date: Fri, 23 May 2003 21:19:16 +0300 (EEST) From: Anatoly Zaharov To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: kern/52623: Error in driver for the Intel EtherExpress Pro/10 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Anatoly Zaharov List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2003 18:20:06 -0000 >Number: 52623 >Category: kern >Synopsis: Error in driver for the Intel EtherExpress Pro/10 >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri May 23 11:20:03 PDT 2003 >Closed-Date: >Last-Modified: >Originator: Anatoly Zaharov >Release: FreeBSD 4.8-RELEASE i386 >Organization: Relcom-Ukraine ltd. >Environment: System: FreeBSD scelto.relc.com 4.8-RELEASE FreeBSD 4.8-RELEASE #3: Fri May 23 10:06:57 EEST 2003 zah@variag.relc.com:/usr/src/sys/compile/NIK i386 >Description: Intel EtherExpress Pro/10 configured to use IRQ 3,5 or 9 not working. >How-To-Repeat: >Fix: fix maping irq number to internal table. Patch : --- if_ex.c.4.8 Fri May 23 14:36:23 2003 +++ sys/dev/ex/if_ex.c Fri May 23 16:20:43 2003 @@ -81,9 +81,9 @@ #endif char irq2eemap[] = - { -1, -1, 0, 1, -1, 2, -1, -1, -1, 0, 3, 4, -1, -1, -1, -1 }; + { -1, -1, 2, 0, -1, 1, -1, -1, -1, 2, 3, 4, -1, -1, -1, -1 }; u_char ee2irqmap[] = - { 9, 3, 5, 10, 11, 0, 0, 0 }; + { 3, 5, 9, 10, 11, 0, 0, 0 }; char plus_irq2eemap[] = { -1, -1, -1, 0, 1, 2, -1, 3, -1, 4, 5, 6, 7, -1, -1, -1 }; >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-bugs@FreeBSD.ORG Fri May 23 22:50:15 2003 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 228CB37B401 for ; Fri, 23 May 2003 22:50:15 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A907443FB1 for ; Fri, 23 May 2003 22:50:14 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h4O5oEUp084331 for ; Fri, 23 May 2003 22:50:14 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h4O5oEWw084330; Fri, 23 May 2003 22:50:14 -0700 (PDT) Date: Fri, 23 May 2003 22:50:14 -0700 (PDT) Message-Id: <200305240550.h4O5oEWw084330@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: oremanj@adsl-64-161-78-226.dsl.lsan03.pacbell.net Subject: Re: kern/52454: [PATCH] let init change securelevel to -1 for single-user mode X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: oremanj@adsl-64-161-78-226.dsl.lsan03.pacbell.net List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2003 05:50:15 -0000 The following reply was made to PR kern/52454; it has been noted by GNATS. From: oremanj@adsl-64-161-78-226.dsl.lsan03.pacbell.net To: freebsd-gnats-submit@freebsd.org Cc: Subject: Re: kern/52454: [PATCH] let init change securelevel to -1 for single-user mode Date: 24 May 2003 05:46:07 -0000 > This was intentionally removed from FreeBSD. See rev. 1.36 of init.c. Yes, but if you look deeper into the patch, it contains a kernel patch too. Is there a reason even this wouldn't work? Is it against policy or something? -- Josh From owner-freebsd-bugs@FreeBSD.ORG Sat May 24 09:50:14 2003 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 17A9837B401 for ; Sat, 24 May 2003 09:50:14 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BE2343FA3 for ; Sat, 24 May 2003 09:50:12 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h4OGoCUp049373 for ; Sat, 24 May 2003 09:50:12 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h4OGoCWZ049372; Sat, 24 May 2003 09:50:12 -0700 (PDT) Resent-Date: Sat, 24 May 2003 09:50:12 -0700 (PDT) Resent-Message-Id: <200305241650.h4OGoCWZ049372@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, sad@mailaps.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D87037B401 for ; Sat, 24 May 2003 09:45:10 -0700 (PDT) Received: from prserv.net (out4.prserv.net [32.97.166.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD14443FDD for ; Sat, 24 May 2003 09:45:08 -0700 (PDT) (envelope-from sad@attglobal.net) Received: from brahms.asylum.net (slip32-106-24-219.ehn.de.prserv.net[32.106.24.219]) by prserv.net (out4) with SMTP id <2003052416450120405raca3e>; Sat, 24 May 2003 16:45:04 +0000 Received: by localhost (IBM OS/2 SENDMAIL VERSION 2.0/2.0) id WAA030.50; Wed, 21 May 2003 22:56:19 -0400 Message-Id: <20030521225317.A3004@attglobal.net> Date: Wed, 21 May 2003 22:53:17 +0000 From: "Stefan A. Deutscher" To: FreeBSD-gnats-submit@FreeBSD.org cc: sad@mailaps.org Subject: kern/52648: bonnie gives kernel panic in SMP but not in UNI on FBSD 5.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: sad@mailaps.org List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2003 16:50:14 -0000 >Number: 52648 >Category: kern >Synopsis: bonnie gives kernel panic in SMP but not in UNI on FBSD 5.0 >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat May 24 09:50:12 PDT 2003 >Closed-Date: >Last-Modified: >Originator: Charlie & >Release: FreeBSD 5.0-RELEASE i386 >Organization: >Environment: System: FreeBSD twintower.asylum.net 5.0-RELEASE FreeBSD 5.0-RELEASE #0: Sun Mar 2 16:12:08 CET 2003 root@twintower.asylum.net:/usr/src/sys/i386/compile/TD4-SMP-DEBUG-i586 i386 Intergraph TD-4 SMP box (PCI/EISA), 2 Pentium 100 MHz CPUs, 192 MB FPM RAM, NCR SCSI 53c810 based, all SCSI disks, Matrox Millenium Graphics card, FreeBSD 5.0-Release (same problem on 4.7 and 4.8 Release) >Description: running bonnie with SMP kernel leads within seconds to kernel dump; (building kernel with SMP kernel does as well, running gnome2 sooner or later too, but I don't have output of gdb at hand for these cases. On these same tasks and in general, the machine is stable running with the GENERIC non-SMP kernel config. The RAM is stable, too: removing modules or switching them around (down to only 32 MB) does not change anything, it passes memtest (from ports) and standalone from www.memtest86.com w/o a hickup. The same thing happens on 4.7 Release and 4.8 Release and 5.0 Release. Output of mptable, pciconf, gdb -k and dmesg, kernel config below >How-To-Repeat: boot into SMP kernel and start bonnie >Fix: No idea, other than running GENERIC non-SMP kernel Cheers, Stefan # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.369.2.2 2002/12/31 05:35:45 scottl Exp $ machine i386 #cpu I486_CPU cpu I586_CPU #cpu I686_CPU ident TD4-SMP-DEBUG-i586 maxusers 0 #To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" #Default places to look for devices. makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols options INET #InterNETworking #options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options MD_ROOT #MD is a potential root device options NFSCLIENT #Network Filesystem Client options NFSSERVER #Network Filesystem Server options NFS_ROOT #NFS usable as root device, requires NFSCLIENT options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 #Compatible with FreeBSD4 options SCSI_DELAY=15000 #Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. # Debugging for use in -current options DDB #Enable the kernel debugger options DDB_UNATTENDED #Start panic and dump automtically #options INVARIANTS #Enable calls of extra sanity checking options INVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS #options WITNESS #Enable checks to detect deadlocks and cycles #options WITNESS_SKIPSPIN #Don't run witness on spinlocks for speed # To make an SMP kernel, the next two are needed options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O device isa device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices #device ata #device atadisk # ATA disk drives #device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives #options ATA_STATIC_ID #Static device numbering # SCSI Controllers #device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices #device ahd # AHA39320/29320 and onboard AIC79xx devices #device amd # AMD 53C974 (Tekram DC-390(T)) #device isp # Qlogic family #device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') device adv # Advansys SCSI adapters device adw # Advansys wide SCSI adapters #device aha # Adaptec 154x SCSI adapters #device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. #device bt # Buslogic/Mylex MultiMaster SCSI adapters #device ncv # NCR 53C500 #device nsp # Workbit Ninja SCSI-3 #device stg # TMC 18C30/18C50 # RAID controllers interfaced to the SCSI subsystem #device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID #device ciss # Compaq Smart RAID 5* #device dpt # DPT Smartcache III, IV - See NOTES for options! #device iir # Intel Integrated RAID #device mly # Mylex AcceleRAID/eXtremeRAID # SCSI peripherals device scbus # SCSI bus (required) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers #device aac # Adaptec FSA RAID #device aacp # SCSI passthrough for aac (requires CAM) #device amr # AMI MegaRAID #device ida # Compaq Smart RAID #device mlx # Mylex DAC960 family #device pst # Promise Supertrak SX6000 #device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc # Enable this for the pcvt (VT220 compatible) console driver #device vt #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor #device agp # support several AGP chipsets # Floating point support - do not disable. device npx # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # Pcmcia and cardbus bridge support device cbb # cardbus (yenta) bridge #device pcic # ExCA ISA and PCI bridges device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 adapter Gigabit Ethernet Card device txp # 3Com 3cR990 (``Typhoon'') device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B (82557, 82558) device pcn # AMD Am79C97x PCI 10/100 (precedence over 'lnc') device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (``Starfire'') device sis # Silicon Integrated Systems SiS 900/SiS 7016 device ste # Sundance ST201 (D-Link DFE-550TX) device tl # Texas Instruments ThunderLAN device tx # SMC EtherPower II (83c170 ``EPIC'') device vr # VIA Rhine, Rhine II device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') device bge # Broadcom BCM570xx Gigabit Ethernet # ISA Ethernet NICs. pccard nics included. device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards device ex # Intel EtherExpress Pro/10 and Pro/10+ device ep # Etherlink III based cards device fe # Fujitsu MB8696x based cards device lnc # NE2100, NE32-VL Lance Ethernet cards device sn # SMC's 9000 series of ethernet chips device xe # Xircom pccard ethernet # ISA devices that use the old ISA shims #device le # Wireless NIC cards device an # Aironet 4500/4800 802.11 wireless NICs. device awi # BayStack 660 and others device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices - the number indicates how many units to allocate. device random # Entropy device device loop # Network loopback device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf # Berkeley packet filter # USB support #device uhci # UHCI PCI->USB interface #device ohci # OHCI PCI->USB interface #device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices #device ugen # Generic #device uhid # "Human Interface Devices" #device ukbd # Keyboard #device ulpt # Printer #device umass # Disks/Mass storage - Requires scbus and da #device ums # Mouse #device urio # Diamond Rio 500 MP3 player #device uscanner # Scanners # USB Ethernet, requires mii #device aue # ADMtek USB ethernet #device cue # CATC USB ethernet #device kue # Kawasaki LSI USB ethernet # mptable -verbose -dmesg > dmesg.txt =============================================================================== MPTable, version 2.0.15 looking for EBDA pointer @ 0x040e, found, searching EBDA @ 0x0009fc00 searching CMOS 'top of mem' @ 0x0009e800 (634K) searching default 'top of mem' @ 0x0009fc00 (639K) searching BIOS @ 0x000f0000 MP FPS found in BIOS @ physical addr: 0x000fbab0 ------------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000fbab0 signature: '_MP_' length: 16 bytes version: 1.1 checksum: 0x9d mode: Virtual Wire ------------------------------------------------------------------------------- MP default config type: 6 bus: EISA+PCI, APIC: Integrated ------------------------------------------------------------------------------- dmesg output: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-RELEASE #0: Sun Mar 2 16:12:08 CET 2003 root@twintower.asylum.net:/usr/src/sys/i386/compile/TD4-SMP-DEBUG-i586 Preloaded elf kernel "/boot/kernel/kernel" at 0xc04f0000. Timecounter "i8254" frequency 1193182 Hz CPU: Pentium/P54C (97.58-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x524 Stepping = 4 Features=0x7bf real memory = 201326592 (192 MB) avail memory = 190210048 (181 MB) Changing APIC ID for IO APIC #0 from 0 to 2 on chip Programming 16 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00030010, at 0xfee00000 cpu1 (AP): apic id: 1, version: 0x00030010, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x000f0011, at 0xfec00000 Intel Pentium detected, installing workaround for F00F bug Initializing GEOMetry subsystem npx0: on motherboard npx0: INT 16 interface pcib0: at pcibus 0 on motherboard pci0: on pcib0 eisab0: at device 2.0 on pci0 eisa0: on eisab0 mainboard0: on eisa0 slot 0 isa0: on eisab0 lnc0: port 0xff80-0xff9f irq 9 at device 6.0 on pci0 lnc0: Attaching PCNet/PCI Ethernet adapter lnc0: PCnet-PCI address 08:00:36:30:75:02 sym0: <810> port 0xfc00-0xfcff mem 0xffbebf00-0xffbebfff irq 10 at device 7.0 on pci0 sym0: No NVRAM, ID 7, Fast-10, SE, parity checking pci0: at device 8.0 (no driver attached) orm0: