panic in getnewvnode
there is something fishy going on :-)
with latest current,
the tests are run on a diskless host, and just after booting,
this is what i do:
newfs /dev/ad0s2a
mount /dev/ad0s2a /mnt-root
cd /mnt-root
rsh dev -n dump 0f - /c/4| restore rf -
panic: vn_finished_write: neg cnt
zeroing vnmp in getnewvnode, i get:
panic: getnewvnode: free vnode isn't
Debugger("panic")
Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
db> t
Debugger(c04b615c,c056a400,c04bfa5a,cc8117e4,1) at Debugger+0x54
panic(c04bfa5a,0,c04bfa00,39a,c03e038b) at panic+0xab
getnewvnode(c04d19e9,c2761a00,c2301700,cc811884,c75810ae) at getnewvnode+0x3c6
ffs_vget(c2761a00,46cd,2,cc8118f4,8180) at ffs_vget+0x93
ffs_valloc(c23cc128,8180,c2744a00,cc8118f4,cc8118f8) at ffs_valloc+0x100
ufs_makeinode(8180,c23cc128,cc811bec,cc811c00,602) at ufs_makeinode+0x69
ufs_create(cc811a48,cc811a68,c0334a59,cc811a48,c04e78a0) at ufs_create+0x39
ufs_vnoperate(cc811a48,c04e78a0,c23cc128,cc811bec,cc811c00) at
ufs_vnoperate+0x18
VOP_CREATE(c23cc128,cc811bec,cc811c00,cc811aac,2) at VOP_CREATE+0x39
vn_open_cred(cc811bd8,cc811cd8,180,c2744a00,cc811cc4) at vn_open_cred+0x179
vn_open(cc811bd8,cc811cd8,180,28f,0) at vn_open+0x29
kern_open(c22a1270,80b32e1,0,602,1b6) at kern_open+0x183
open(c22a1270,cc811d10,c04de5a0,418,3) at open+0x30
syscall(2f,2f,2f,80b32e1,0) at syscall+0x2be
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (5, FreeBSD ELF32, open), eip = 0x8054953, esp = 0xbfbff3ec, ebp =
0xbfbff438 ---
BTW, I'm compiling on a 4.6 stable (cc version: gcc version 2.95.4)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Junior Kernel Hacker page updated...
On 2 Oct, Don Lewis wrote: > On 2 Oct, Stefan Farfeleder wrote: > >> /freebsd/current/src/sys/vm/uma_core.c:1307: could sleep with "filedesc structure" >locked from /freebsd/current/src/sys/kern/kern_event.c:959 >> >> at me and freezes badly at some point (no breaking into ddb possible). >> This is totally repeatable. Is anybody able to reproduce (and maybe >> fix) this? > > It looks like the problem is that knote_attach() calls hashinit() while > holding the lock, and that hashinit() calls MALLOC(..., M_WAITOK). > > Try the following patch: > [snip] I went ahead and committed the patch. It survived a "make -j10 buildworld" test with your patched version of make. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS hang on rmdir(2) with 5.0-current client, server
On Wed, 2 Oct 2002, Don Lewis wrote: > On 2 Oct, Robert Watson wrote: > > > > Running into an odd (and apparently recent) problem involving rmdir(2) and > > NFS. I have a diskless box started using pxeboot: NFS /, MFS /var, MFS > > /tmp, recent 5.0-CURRENT. Attempt to rmdir /usr/local (on NFS) results in > > NFS hanging. It appears to send out the RPC, but no response comes back > > from the (also recent) FreeBSD 5.0 NFS server. Here's the quicky on the > > client: > > > It looks like the client is basically hung waiting for an RPC response. > > I'd be glad to provide more debugging information if someone can point me > > in the right direction. > > I haven't seen this seen this problem with a 5.0-CURRENT client and a > 4.7-PRERELEASE server, so as near as I can tell the client side isn't > totally hosed. Interesting observation: rm on files, and rmdir on empty directories doesn't trigger it, but attempt to rmdir on a non-empty directory does. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCI brokenness
> > Here is my hints file (which has not changed in at least 6 months) > > Ok, so you only have ata0 and no ata1. So that means the ACPI ata > attachment almost worked. Humm, try doing a hack to change ATA_IOADDR_RID > in ata-all.h from 0 to 1 along with the previous patch to add an acpi > attachment for ata and see if that works. I still have no idea why > the ata hint device isn't working. It should be working fine. :( # I could be wrong, please correct me :) I think that Libretto 110CT doesn't have PCI-ISA bridge , so no isab, no isa, no isahint (requires isa) w/ acpi enabled. In legacy case, we have at least isa0 on motherboard even if there is no ISA bridge. OTOH, we never see isa0 if there is no ISA bridge in ACPI case. Also, most of isa device driver (more than 70!) don't have acpi attachment yet, including some important drivers such as sc0. Hmmm, it's not so simple... How about having acpi_isa bus code so that we have at least isa0 on the system w/o ISA bridge ? BTW, Libretto 110CT's DSDT at: http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/li110ct.dsdt?cvsroot=freebsd-jp please get it if you need. ata seems to be _SB_.PCI0.EIO_.HDD1. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS hang on rmdir(2) with 5.0-current client, server
On Wed, 2 Oct 2002, Don Lewis wrote: > On 2 Oct, Robert Watson wrote: > > > > Running into an odd (and apparently recent) problem involving rmdir(2) and > > NFS. I have a diskless box started using pxeboot: NFS /, MFS /var, MFS > > /tmp, recent 5.0-CURRENT. Attempt to rmdir /usr/local (on NFS) results in > > NFS hanging. It appears to send out the RPC, but no response comes back > > from the (also recent) FreeBSD 5.0 NFS server. Here's the quicky on the > > client: > > > It looks like the client is basically hung waiting for an RPC response. > > I'd be glad to provide more debugging information if someone can point me > > in the right direction. > > I haven't seen this seen this problem with a 5.0-CURRENT client and a > 4.7-PRERELEASE server, so as near as I can tell the client side isn't > totally hosed. I pointed my client at a Solaris server and it seems not to be a problem in that configuration, leading me to suspect the server. I'm going to twiddle kernels a bit and see if it's a local problem of some sort or not. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS hang on rmdir(2) with 5.0-current client, server
On 2 Oct, Robert Watson wrote: > > Running into an odd (and apparently recent) problem involving rmdir(2) and > NFS. I have a diskless box started using pxeboot: NFS /, MFS /var, MFS > /tmp, recent 5.0-CURRENT. Attempt to rmdir /usr/local (on NFS) results in > NFS hanging. It appears to send out the RPC, but no response comes back > from the (also recent) FreeBSD 5.0 NFS server. Here's the quicky on the > client: > It looks like the client is basically hung waiting for an RPC response. > I'd be glad to provide more debugging information if someone can point me > in the right direction. I haven't seen this seen this problem with a 5.0-CURRENT client and a 4.7-PRERELEASE server, so as near as I can tell the client side isn't totally hosed. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP! GEOM as default in 5 days...
In message <[EMAIL PROTECTED]>, Eric Hodel writes: >the bit that I cant figure out is that my CD-ROM won't mount the >CD I've got in it now, (an 80 minute CDR) but it has pre-geom. Yes, there is a problem with SCSI-CD devices. Can you please try this patch: http://phk.freebsd.dk/patch/scsi_cd.c.patch -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
GEOM
GEOM is working so far. I can mount a cd-rom without problems and permissions are fine. `dmesg' output follows. After that is my kernel configuration. There is one problem, not related to GEOM (it's been going on for at least a month), which follows: whenever I reboot the laptop from FreeBSD back into FreeBSD it never gets past "Mounting root ..." The only way I can get it to boot properly is by powering off the laptop. On the other hand I can boot into Windows Millennium fine after rebooting from FreeBSD and into FreeBSD from Windows Millennium. So it seems to just be rebooting from FreeBSD and booting FreeBSD. Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Wed Oct 2 22:02:06 EDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LAPTOP Preloaded elf kernel "/boot/kernel/kernel" at 0xc0438000. Preloaded elf module "/boot/kernel/if_dc.ko" at 0xc04380a8. Preloaded elf module "/boot/kernel/miibus.ko" at 0xc0438154. Preloaded elf module "/boot/kernel/if_wi.ko" at 0xc0438200. Preloaded elf module "/boot/kernel/snd_maestro3.ko" at 0xc04382ac. Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc0438360. Preloaded elf module "/boot/kernel/agp.ko" at 0xc043840c. Preloaded elf module "/boot/kernel/accf_data.ko" at 0xc04384b4. Preloaded elf module "/boot/kernel/accf_http.ko" at 0xc0438564. Preloaded elf module "/boot/kernel/random.ko" at 0xc0438614. Preloaded elf module "/boot/kernel/atspeaker.ko" at 0xc04386c0. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0438770. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 846325088 Hz CPU: Pentium III/Pentium III Xeon/Celeron (846.33-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x68a Stepping = 10 Features=0x387f9ff real memory = 268369920 (262080K bytes) avail memory = 255889408 (249892K bytes) Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard Using $PIR table, 7 entries at 0xc00fdf50 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-safe" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_cpu0: on acpi0 acpi_tz0: on acpi0 acpi_button0: on acpi0 acpi_lid0: on acpi0 acpi_button1: on acpi0 acpi_cmbat0: on acpi0 acpi_acad0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xec00-0xefff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 1.0 (no driver attached) cbb0: at device 4.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib0: slot 4 INTA is routed to irq 11 cbb1: at device 4.1 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 pcib0: slot 4 INTA is routed to irq 11 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1050-0x105f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at device 7.2 (no driver attached) pci0: at device 7.3 (no driver attached) pcm0: port 0x1400-0x14ff irq 5 at device 8.0 on pci0 pci0: at device 8.1 (no driver attached) dc0: port 0x1c00-0x1cff mem 0xe800-0xe80003ff irq 11 at device 16.0 on pci0 dc0: Ethernet address: 00:d0:59:5c:40:f4 miibus0: on dc0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto atspeaker0 port 0x61 on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 acpi_ec0: port 0x66,0x62 on acpi0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x158-0x15f,0x2f8-0x2ff irq 3 drq 0 on acpi0 sio1: type 16550A fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 orm0: at iomem 0xdc000-0xd,0xc-0xcbfff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec Initializing GEOMetry subsystem acpi_cpu: CPU throttling enabled, 8 steps from 100% to 12.5% wi0: at port 0x100-0x13f irq 11 function 0 config 1 on pccard1 wi0: 802.11 address: 00:30:ab:15:ea:81 wi0: using RF:PRISM2 MAC:HFA3841 CARD:HWB3163 rev.A wi0: Intersil Firmware: Primary 0.03.00, Station 0.08.03 ad0: 19077MB [38760/16/63] at ata0-master UDMA33 acd0: DVD-ROM at ata1-master PIO4 Mounting root from ufs:/dev/ad0s2a machine i386 cpu I686_CPU ident LAPTOP maxusers0 makeoptions DEBUG=-g options INET options INET6 options FFS options SOFTUPDATES options UFS_DIRHASH options COMPAT_43 options COMPAT_FREEBSD4 options KTRACE options SYSVSHM options SYSVMSG options SYSVSEM options P1003_1B options _KPOSIX_PRIORI
Re: aic7890/91 controller
> Me neither but my 2642 additionally only boots from channel B. Meaning it hangs if you attempt to boot from channel B? I really have no feel for what the actual failure mode is yet. Do we get timeouts? No devices are seen? What does a verbose boot print out about the controller and its termination? -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Reason: releng4 comp. hack, machdep.c 1.539 (was: cvsupd death (signal 6))
On Wed, Oct 02, 2002 at 20:51:40 -0700, Julian Elischer wrote: > > > > Please back it out or do it properly! > > this IS the backout.. it's now how it was before, including in 4.x I mean - back out this backout - it damage 5.0 FP binaries. I don't care about 4.x -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Reason: releng4 comp. hack, machdep.c 1.539 (was: cvsupd death (signal 6))
On Wed, Oct 02, 2002 at 20:50:52 -0700, Julian Elischer wrote: > > Please back it out or do it properly! > > did you recompile the apps and the libraries? 1st try: I got signal 6 with old, but 5.0 binaries dynamically linked with m3 libraries. 2nd try: I recompile whole cvsup, getting very -current 5.0 binaries, statically linked with m3 libraries. Signal 6 too. m3 seriously use FP, so SIGABRT comes when some internal check fails. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Reason: releng4 comp. hack, machdep.c 1.539 (was: cvsupd death(signal 6))
On Thu, 3 Oct 2002, Andrey A. Chernov wrote: > The bug completely gone after I revert machdep.c to 1.538. This commit > cause bug: > > > revision 1.539 > date: 2002/09/30 07:02:22; author: obrien; state: Exp; lines: +10 -0 > Save the FP state in the PCB as that is compatable with releng4 binaries. > > This is a band-aid until the KSE pthread committers get back on the ground > and have their machines setup. > > Submitted by: eischen > > > Please back it out or do it properly! this IS the backout.. it's now how it was before, including in 4.x > > Additional details: it cause not only cvsupd death, but rarely cvsup > signal 6 death too with this diagnostic: > > *** > *** runtime error: > ***Value out of range > ***file > "/tmp/a/ports/lang/ezm3/work/ezm3-1.0/libs/libm3/src/uid/Common/Time > Stamp.m3", line 63 > *** > > On Tue, Oct 01, 2002 at 19:25:43 +0400, Andrey A. Chernov wrote: > > Now I constantly got cvsupd death on very recent -current. Either TCPIP or > > thread changes involved, all works two days ago. Does anybody else saw > > this too? > > > > cvsup & cvsupd on the same machine talking to each other: > > > > messages says: > > kernel: pid 15533 (cvsupd), uid 2068: exited on signal 6 (core dumped) > > > > cvsup.log says: > > TreeList failed: Network write failure: Connection closed > > -- > Andrey A. Chernov > http://ache.pp.ru/ > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Reason: releng4 comp. hack, machdep.c 1.539 (was: cvsupd death(signal 6))
On Thu, 3 Oct 2002, Andrey A. Chernov wrote: > The bug completely gone after I revert machdep.c to 1.538. This commit > cause bug: > > > revision 1.539 > date: 2002/09/30 07:02:22; author: obrien; state: Exp; lines: +10 -0 > Save the FP state in the PCB as that is compatable with releng4 binaries. > > This is a band-aid until the KSE pthread committers get back on the ground > and have their machines setup. > > Submitted by: eischen > > > Please back it out or do it properly! did you recompile the apps and the libraries? > > Additional details: it cause not only cvsupd death, but rarely cvsup > signal 6 death too with this diagnostic: > > *** > *** runtime error: > ***Value out of range > ***file > "/tmp/a/ports/lang/ezm3/work/ezm3-1.0/libs/libm3/src/uid/Common/Time > Stamp.m3", line 63 > *** > > On Tue, Oct 01, 2002 at 19:25:43 +0400, Andrey A. Chernov wrote: > > Now I constantly got cvsupd death on very recent -current. Either TCPIP or > > thread changes involved, all works two days ago. Does anybody else saw > > this too? > > > > cvsup & cvsupd on the same machine talking to each other: > > > > messages says: > > kernel: pid 15533 (cvsupd), uid 2068: exited on signal 6 (core dumped) > > > > cvsup.log says: > > TreeList failed: Network write failure: Connection closed > > -- > Andrey A. Chernov > http://ache.pp.ru/ > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: laptop panicked [with trace]
* De: Mikhail Teterin <[EMAIL PROTECTED]> [ Data: 2002-10-02 ] [ Subjecte: laptop panicked [with trace] ] > With today's -current. No X11, two ttyv0 in use -- cvs updating, the > other -- playing hack(6): This is known; A temporary fix is to modify the part dereferencing p->p_limit to check for NULL first. jhb@ is working on a proper fix, I believe. > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0xbc > [... retyped, not copy-pasted, seemingly random numbers marked ``skipped'' ...] > kernel: type 12 trap, code=0 > Stopped atmi_switch+0x186:movl0xbc(%ecx),%edx > db> trace > mi_switch(c159b270,0,c0340d60,183,4) at mi_switch+0x186 > ithread_schedule(c4086200,1,c03ae560,c4074270,296) at ithread_schedule+0x135 > sched_ithd(e) at Xintr14+0x6a > Xintr14() at Xintr14+0x6a > --- interrupt, eip = 0xc02f101f, esp = 0xd7b88c44, ebp = 0xd7b88c50 > cpu_unpend( [skipped] ) at cpu_unpend+0x2f > cpu_critical_exit( [skipped] ,1) at cpu_critical_exit+0x15 > critical_exit( [skipped], [skipped], 1b2, [skipped] ) at critical_exit+0x24 > _mtx_unlock_spin_flags( [skipped],0,[skipped],1b3,[skipped] ) at >_mtx_unlock_spin_flags+0xbd > exit1([skipped],0,[skipped],6f,[skipped]) at exit1+0xb15 > sys_exit( [skipped] ,418,1) at sys_exit+0x41 > syscall(2f,2f,2f,bfbffd98,3) at syscall+0x2be > Xint0x80_syscall() at Xint0x80_syscall+0x1d > --- syscall(1, FreeBSD ELF32, sys_exit), eip = 0x807af27, esp = bfbffc3c, ebp = >0xbfbffd50 > db> > > I'm going to leave it in this sorry state overnight -- if you'd like me > to check something else before rebooting -- please, respond. Thanks, > > -mi > -mi > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- Juli Mallett <[EMAIL PROTECTED]> | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
NFS hang on rmdir(2) with 5.0-current client, server
Running into an odd (and apparently recent) problem involving rmdir(2) and
NFS. I have a diskless box started using pxeboot: NFS /, MFS /var, MFS
/tmp, recent 5.0-CURRENT. Attempt to rmdir /usr/local (on NFS) results in
NFS hanging. It appears to send out the RPC, but no response comes back
from the (also recent) FreeBSD 5.0 NFS server. Here's the quicky on the
client:
crash1# which rmdir
/bin/rmdir
crash1# rmdir /usr/local
load: 0.04 cmd: rmdir 466 [sbwait] 0.00u 0.00s 0% 76k
~^B
Stopped at siointr1+0xf4: movl$0,brk_state1.0
db> trace 466
mi_switch(c0baa8d8,1f4,c02eb8f0,c0baa840,3d4) at mi_switch+0x238
msleep(c1996eec,0,58,c04bdba0,1f4) at msleep+0x474
sbwait(c1996ed4,c0518e80,c0bac630,c0bac630,f4240) at sbwait+0x51
soreceive(c1996e88,0,c86a1aec,c86a1b38,0) at soreceive+0x306
nfs_receive(c1bcb800,c86a1b3c,c86a1b38,c199d000,c0e34844) at
nfs_receive+0x4c0
nfs_reply(c1bcb800,c18d7850,c0bb3400,c1bcb800,44) at nfs_reply+0x5e
nfs_request(c19d94a0,c0bb3d00,d,c0baa840,c1cdb280) at nfs_request+0x2dc
nfs_rmdir(c86a1c04,c04e8600,c19d94a0,c1bc8de0,c86a1c98) at nfs_rmdir+0x11a
VOP_RMDIR(c19d94a0,c1bc8de0,c86a1c98,c86a1c98,0) at VOP_RMDIR+0x33
kern_rmdir(c0baa840,bfbffd3e,0,c86a1d40,c044ff4e) at kern_rmdir+0x1be
rmdir(c0baa840,c86a1d10,c04dedc9,418,1) at rmdir+0x22
syscall(2f,2f,2f,0,0) at syscall+0x2be
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (137, FreeBSD ELF32, rmdir), eip = 0x804886f, esp =
0xbfbffbfc, ebp = 0xbfbffc20 ---
db>
I can't do much debugging on the server just yet as it's actually the
development box and I don't have remote serial console access / debugger
access / etc on it. It strikes me that either the client is sending an
invalid request that the server blocks, or the server is getting unhappy
about the request. The server NFS processes seem to be idle, so at the
very least the server doesn't care:
0 354 1 85 106 0 1104 776 select Is??0:00.12 nfsd:
master
0 356 354 0 4 0 1012 628 nfsd I ??1:16.66 nfsd:
server
0 357 354 0 4 0 1012 628 nfsd I ??0:00.18 nfsd:
server
0 358 354 0 4 0 1012 628 nfsd I ??0:00.03 nfsd:
server
0 359 354 0 4 0 1012 628 nfsd I ??0:00.02 nfsd:
server
I've attached the tcpdump output from the server interface below, if
anyone is interested. Has anyone else experienced this problem?
I believe / is mounted using NFSv3, and quite possibly "soft":
file:/home on /home (nfs)
file:/projects on /projects (nfs)
It looks like the client is basically hung waiting for an RPC response.
I'd be glad to provide more debugging information if someone can point me
in the right direction.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
23:46:09.588003 192.168.50.10.1260868882 > 192.168.50.1.2049: 152 lookup
[|nfs]
4500 00b4 12b2 4011 822b c0a8 320a
c0a8 3201 03ff 0801 00a0 22d0 4b27 5512
0002 0001 86a3 0002
0004 0001 0044
000c
23:46:09.588168 192.168.50.1.2049 > 192.168.50.10.1260868882: reply ok 128
lookup [|nfs]
4500 009c 7e3b 4011 16ba c0a8 3201
c0a8 320a 0801 03ff 0088 15d3 4b27 5512
0001
4f29 ba3b db0f a103
0c00 3356 0a00 6e81 461d
23:46:09.588675 192.168.50.10.1260868883 > 192.168.50.1.2049: 152 rmdir
[|nfs]
4500 00b4 12b3 4011 822a c0a8 320a
c0a8 3201 03ff 0801 00a0 22c4 4b27 5513
0002 0001 86a3 0002
000f 0001 0044
000c
23:46:10.592213 192.168.50.10.1260868883 > 192.168.50.1.2049: 152 rmdir
[|nfs]
4500 00b4 12b4 4011 8229 c0a8 320a
c0a8 3201 03ff 0801 00a0 22c4 4b27 5513
0002 0001 86a3 0002
000f 0001 0044
000c
23:46:12.602134 192.168.50.10.1260868883 > 192.168.50.1.2049: 152 rmdir
[|nfs]
4500 00b4 12b5 4011 8228 c0a8 320a
c0a8 3201 03ff 0801 00a0 22c4 4b27 5513
0002 0001 86a3 0002
000f 0001 0044
000c
laptop panicked [with trace]
With today's -current. No X11, two ttyv0 in use -- cvs updating, the other -- playing hack(6): Fatal trap 12: page fault while in kernel mode fault virtual address = 0xbc [... retyped, not copy-pasted, seemingly random numbers marked ``skipped'' ...] kernel: type 12 trap, code=0 Stopped at mi_switch+0x186:movl0xbc(%ecx),%edx db> trace mi_switch(c159b270,0,c0340d60,183,4) at mi_switch+0x186 ithread_schedule(c4086200,1,c03ae560,c4074270,296) at ithread_schedule+0x135 sched_ithd(e) at Xintr14+0x6a Xintr14() at Xintr14+0x6a --- interrupt, eip = 0xc02f101f, esp = 0xd7b88c44, ebp = 0xd7b88c50 cpu_unpend( [skipped] ) at cpu_unpend+0x2f cpu_critical_exit( [skipped] ,1) at cpu_critical_exit+0x15 critical_exit( [skipped], [skipped], 1b2, [skipped] ) at critical_exit+0x24 _mtx_unlock_spin_flags( [skipped],0,[skipped],1b3,[skipped] ) at _mtx_unlock_spin_flags+0xbd exit1([skipped],0,[skipped],6f,[skipped]) at exit1+0xb15 sys_exit( [skipped] ,418,1) at sys_exit+0x41 syscall(2f,2f,2f,bfbffd98,3) at syscall+0x2be Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall(1, FreeBSD ELF32, sys_exit), eip = 0x807af27, esp = bfbffc3c, ebp = 0xbfbffd50 db> I'm going to leave it in this sorry state overnight -- if you'd like me to check something else before rebooting -- please, respond. Thanks, -mi -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rpcbind failure mode non-ideal if run more than once
On Wed, Oct 02, 2002 at 08:38:51PM -0700, Kris Kennaway wrote:
> On Wed, Oct 02, 2002 at 08:34:34PM -0700, Kris Kennaway wrote:
>
> > + (hosts[nhostsbak] = NULL) ? hosts[nhostsbak] : "*",
>
> Silly last-minute typo==
Dammit.
Index: rpcbind.c
===
RCS file: /usr/home/ncvs/src/usr.sbin/rpcbind/rpcbind.c,v
retrieving revision 1.4
diff -u -r1.4 rpcbind.c
--- rpcbind.c 22 Jul 2002 15:22:53 - 1.4
+++ rpcbind.c 3 Oct 2002 03:39:40 -
@@ -359,17 +359,18 @@
servname, &hints, &res)) != 0) {
syslog(LOG_ERR, "cannot get local address for %s: %s",
nconf->nc_netid, gai_strerror(aicode));
- continue;
+ goto error;
}
addrlen = res->ai_addrlen;
sa = (struct sockaddr *)res->ai_addr;
oldmask = umask(S_IXUSR|S_IXGRP|S_IXOTH);
if (bind(fd, sa, addrlen) != 0) {
syslog(LOG_ERR, "cannot bind %s on %s: %m",
- hosts[nhostsbak], nconf->nc_netid);
+ (hosts[nhostsbak] == NULL) ? "*" :
+hosts[nhostsbak],
+ nconf->nc_netid);
if (res != NULL)
freeaddrinfo(res);
- continue;
+ goto error;
} else
checkbind++;
(void) umask(oldmask);
@@ -382,7 +383,7 @@
nconf->nc_netid);
if (res != NULL)
freeaddrinfo(res);
- return 1;
+ goto error;
}
memcpy(taddr.addr.buf, sa, addrlen);
#ifdef ND_DEBUG
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: rpcbind failure mode non-ideal if run more than once
On Wed, Oct 02, 2002 at 08:34:34PM -0700, Kris Kennaway wrote: > + (hosts[nhostsbak] = NULL) ? hosts[nhostsbak] : "*", Silly last-minute typo== Kris msg43792/pgp0.pgp Description: PGP signature
Re: rpcbind failure mode non-ideal if run more than once
On Wed, Oct 02, 2002 at 12:49:43PM -0400, Robert Watson wrote:
>
> crash1# rpcbind
> Oct 2 12:47:15 crash1 rpcbind: cannot bind (null) on udp6: Address
> already in use
> Segmentation fault
> Oct 2 12:47:15 crash1 kernel: pid 1595 (rpcbind), uid 0: exited on signal
> 11
> crash1#
>
> I'm having trouble extracting a core so won't be able to follow-up just
> yet, but it looks like it might not be too hard to track down.
The error-handling code in rpcbind was bogus..there were failure paths
that would continue to execute with a null pointer that eventually
causes the crash.
Kris
Index: rpcbind.c
===
RCS file: /usr/home/ncvs/src/usr.sbin/rpcbind/rpcbind.c,v
retrieving revision 1.4
diff -u -r1.4 rpcbind.c
--- rpcbind.c 22 Jul 2002 15:22:53 - 1.4
+++ rpcbind.c 3 Oct 2002 03:32:39 -
@@ -359,17 +359,18 @@
servname, &hints, &res)) != 0) {
syslog(LOG_ERR, "cannot get local address for %s: %s",
nconf->nc_netid, gai_strerror(aicode));
- continue;
+ goto error;
}
addrlen = res->ai_addrlen;
sa = (struct sockaddr *)res->ai_addr;
oldmask = umask(S_IXUSR|S_IXGRP|S_IXOTH);
if (bind(fd, sa, addrlen) != 0) {
syslog(LOG_ERR, "cannot bind %s on %s: %m",
- hosts[nhostsbak], nconf->nc_netid);
+ (hosts[nhostsbak] = NULL) ? hosts[nhostsbak] : "*",
+ nconf->nc_netid);
if (res != NULL)
freeaddrinfo(res);
- continue;
+ goto error;
} else
checkbind++;
(void) umask(oldmask);
@@ -382,7 +383,7 @@
nconf->nc_netid);
if (res != NULL)
freeaddrinfo(res);
- return 1;
+ goto error;
}
memcpy(taddr.addr.buf, sa, addrlen);
#ifdef ND_DEBUG
msg43791/pgp0.pgp
Description: PGP signature
Re: Junior Kernel Hacker page updated...
On 2 Oct, Stefan Farfeleder wrote:
> /freebsd/current/src/sys/vm/uma_core.c:1307: could sleep with "filedesc structure"
>locked from /freebsd/current/src/sys/kern/kern_event.c:959
>
> at me and freezes badly at some point (no breaking into ddb possible).
> This is totally repeatable. Is anybody able to reproduce (and maybe
> fix) this?
It looks like the problem is that knote_attach() calls hashinit() while
holding the lock, and that hashinit() calls MALLOC(..., M_WAITOK).
Try the following patch:
Index: sys/kern/kern_event.c
===
RCS file: /home/ncvs/src/sys/kern/kern_event.c,v
retrieving revision 1.45
diff -u -r1.45 kern_event.c
--- sys/kern/kern_event.c 17 Aug 2002 02:36:16 - 1.45
+++ sys/kern/kern_event.c 3 Oct 2002 03:10:09 -
@@ -953,15 +953,27 @@
static void
knote_attach(struct knote *kn, struct filedesc *fdp)
{
- struct klist *list, *oldlist;
+ struct klist *list, *oldlist, *tmp_knhash;
+ u_long tmp_knhashmask;
int size, newsize;
FILEDESC_LOCK(fdp);
if (! kn->kn_fop->f_isfd) {
- if (fdp->fd_knhashmask == 0)
- fdp->fd_knhash = hashinit(KN_HASHSIZE, M_KQUEUE,
- &fdp->fd_knhashmask);
+ if (fdp->fd_knhashmask == 0) {
+ FILEDESC_UNLOCK(fdp);
+ tmp_knhash = hashinit(KN_HASHSIZE, M_KQUEUE,
+ &tmp_knhashmask);
+ FILEDESC_LOCK(fdp);
+ if (fdp->fd_knhashmask == 0) {
+ fdp->fd_knhash = tmp_knhash;
+ fdp->fd_knhashmask = tmp_knhashmask;
+ } else {
+ FILEDESC_UNLOCK(fdp);
+ free(tmp_knhash, M_KQUEUE);
+ FILEDESC_LOCK(fdp);
+ }
+ }
list = &fdp->fd_knhash[KN_HASH(kn->kn_id, fdp->fd_knhashmask)];
goto done;
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: aic7890/91 controller
On Wed, Oct 02, 2002 at 07:53:27PM -0700, Long, Scott wrote: > > > > The aic 7890/91 is a dual 160 MB controller. > > No, the 7890/91 is 80MB/s max. The Tyan S2462UNG has an aic-7899w. > > > Adaptec's > > documentation expliciely states that the bus speed is the > > rate of the _slowest_ device on the channel. > > No it does not. Well, the whole bus will switch to SE-speed if a SE-device is connected, guess that's what he meant. > > > Did you try > > placing the cd on the B channel or vice-versa? Tyan, in > > their 2642 SMP manual, recommends that the faster (and > > boot) drives be placed on the B bus. > > I can't imagine why it would say this. Can you provide a > reference? > Me neither but my 2642 additionally only boots from channel B. The manual is available at: ftp://ftp.tyan.com/manuals/thunder/m_s2462_100.pdf He was refering to: "You can connect Ultra160 and Ultra2 SCSI devices to the 68-pin Low Voltage Differential/Single-Ended (LVD/SE) connectors on both SCSI channels. Or you can operate the newer Ultra160 and Ultra2 devices at their maximum speed on Channel B while at the same time using legacy SCSI devices on Channel A." (page 47) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: aic7890/91 controller
> > The aic 7890/91 is a dual 160 MB controller. No, the 7890/91 is 80MB/s max. > Adaptec's > documentation expliciely states that the bus speed is the > rate of the _slowest_ device on the channel. No it does not. > Did you try > placing the cd on the B channel or vice-versa? Tyan, in > their 2642 SMP manual, recommends that the faster (and > boot) drives be placed on the B bus. I can't imagine why it would say this. Can you provide a reference? > This worked fine for me through builds of 31 Dec; I > discovered with the 20 Feb slice that you could no > longer use both channels with CURRENT. the da drives > would boot from A or B, but when on B, the kernel would > not recognize the DVDRAM on A. The SCSI firmware > utility always reported all drives correctly on both > channels. This is the first I've heard of this problem. Can you provide more details? Did you file a PR back then? Did you post any mail to the freebsd-scsi list? > I tried every combination of hints; and finally went to > a separate controller (Tekram DC395U) for the slow > peripherals. Hints worked on assigning cd0 and cd1 until > 27 Sep build and now only block them moving the devices > to cd2 and cd3 in the order found. Hints were fixed on RELENG_4 on September 22. Can you provide more information? > > I'm going to add GEOM in a few minutes --if it stays > stable for a while, I'll go through the cable swapping > and hints routine again to try and control all devices > with the dual controller. I don't have any non-SCSI > devices. > > Sent: Wed, 2 Oct 2002 17:08:45 -0700 by Eric Hodel > > + ahc0: port > 0xb000-0xb0ff mem 0xdd00-0xdd000fff irq 7 at device 6.0 on pci0 > + aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs > + ... > + Initializing GEOMetry subsystem > + IPsec: Initialized Security Association Processing. > + ad0: 1033MB [2100/16/63] at ata0-master WDMA2 > + ad2: 2014MB [4092/16/63] at > ata1-master WDMA2 > + Waiting 2 seconds for SCSI devices to settle > + cd0 at ahc0 bus 0 target 6 lun 0 > + cd0: Removable CD-ROM SCSI-2 device > + cd0: 20.000MB/s transfers (20.000MHz, offset 16) > + cd0: cd present [355664 x 2048 byte records] > + da0 at ahc0 bus 0 target 0 lun 0 > + da0: Fixed Direct Access > SCSI-2 device > + da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), > Tagged Queueing Enabled > + da0: 4350MB (8910423 512 byte sectors: 255H 63S/T 554C) > + da1 at ahc0 bus 0 target 1 lun 0 > + da1: Fixed Direct Access SCSI-2 device > + da1: 10.000MB/s transfers (10.000MHz, offset 15), Tagged > Queueing Enabled > + da1: 2075MB (4250695 512 byte sectors: 255H 63S/T 264C) > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: aic7890/91 controller
attila! ([EMAIL PROTECTED]) wrote: > Eric: > > The aic 7890/91 is a dual 160 MB controller. Adaptec's > documentation expliciely states that the bus speed is the > rate of the _slowest_ device on the channel. Did you try > placing the cd on the B channel or vice-versa? Tyan, in > their 2642 SMP manual, recommends that the faster (and > boot) drives be placed on the B bus. Mine aic is far too old to be a dual 160 controller, its part of an ASUS P2B-LS board. As far as I recall, I've never had a B channel (there's no connector for it on the motherboard). I have a 50 pin connector, a 68 pin Wide-SCSI connector, and a 68 pin U2LVD connector (to which my LVD is attached). da1 and cd0 are attached to the 50 pin connector. The motherboard manual says an AIC-3860 transciever is used to bridge the non-LVD devices. > This worked fine for me through builds of 31 Dec; I > discovered with the 20 Feb slice that you could no > longer use both channels with CURRENT. the da drives > would boot from A or B, but when on B, the kernel would > not recognize the DVDRAM on A. The SCSI firmware > utility always reported all drives correctly on both > channels. > -- Eric Hodel - [EMAIL PROTECTED] - http://segment7.net All messages signed with fingerprint: FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04 msg43966/pgp0.pgp Description: PGP signature
Reason: releng4 comp. hack, machdep.c 1.539 (was: cvsupd death (signal 6))
The bug completely gone after I revert machdep.c to 1.538. This commit cause bug: revision 1.539 date: 2002/09/30 07:02:22; author: obrien; state: Exp; lines: +10 -0 Save the FP state in the PCB as that is compatable with releng4 binaries. This is a band-aid until the KSE pthread committers get back on the ground and have their machines setup. Submitted by: eischen Please back it out or do it properly! Additional details: it cause not only cvsupd death, but rarely cvsup signal 6 death too with this diagnostic: *** *** runtime error: ***Value out of range ***file "/tmp/a/ports/lang/ezm3/work/ezm3-1.0/libs/libm3/src/uid/Common/Time Stamp.m3", line 63 *** On Tue, Oct 01, 2002 at 19:25:43 +0400, Andrey A. Chernov wrote: > Now I constantly got cvsupd death on very recent -current. Either TCPIP or > thread changes involved, all works two days ago. Does anybody else saw > this too? > > cvsup & cvsupd on the same machine talking to each other: > > messages says: > kernel: pid 15533 (cvsupd), uid 2068: exited on signal 6 (core dumped) > > cvsup.log says: > TreeList failed: Network write failure: Connection closed -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: optimization/6627: -fno-align-functions regression from 2.95
Synopsis: -fno-align-functions regression from 2.95 State-Changed-From-To: analyzed->closed State-Changed-By: sayle State-Changed-When: Wed Oct 2 19:45:09 2002 State-Changed-Why: This has just been fixed on mainline CVS by the following patch: 2002-10-02 Roger Sayle <[EMAIL PROTECTED]> PR optimization/6627 * toplev.c (force_align_functions_log): New global variable. * flags.h (force_align_functions_log): Add extern prototype. * varasm.c (assemble_start_function): Use it to force minimum function alignment. * config/i386/i386.h (FUNCTION_BOUNDARY): Set the correct minimum function alignment to one byte. (TARGET_PTRMEMFUNC_VBIT_LOCATION): Store the virtual bit in the least significant bit of vtable member function pointers. * tree.h (enum ptrmemfunc_vbit_where_t): Move definition to here from cp/cp-tree.h. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6627 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
GEOM and -CURRENT
Hi Poul et al, I have been unable to test GEOM on my Sparc64 box on the latest -CURRENT due to the rstat.h breakage for the last two days. Please hold off your GEOM-being-standard commit until that's been fixed. BTW, why the heck are people not fixing code that breaks world in <24 hours, let alone COMPILE TESTING IT BEFORE THEY COMMIT?! ===> libexec/rpc.rstatd cc -O -pipe-Wformat=2 -Wno-format-extra-args -Werror -c /usr/src/libexec/rpc.rstatd/rstatd.c cc -O -pipe-Wformat=2 -Wno-format-extra-args -Werror -c /usr/src/libexec/rpc.rstatd/rstat_proc.c /usr/src/libexec/rpc.rstatd/rstat_proc.c:87: conflicting types for `havedisk' /usr/obj/usr/src/sparc64/usr/include/rpcsvc/rstat.h:88: previous declaration of `havedisk' *** Error code 1 Stop in /usr/src/libexec/rpc.rstatd. *** Error code 1 regards, -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel boot messages absent
Also sprach Bernd Walter ([EMAIL PROTECTED]): > You can verify with conscontrol. > It should list consolectl for vga console and Muting off. from dmesg: sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x0> but then: # conscontrol Configured: Available: Muting: off Hmm. Does look odd. My other machines do have at least one console listed in Available :) Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ?deleted include file sys/sys/bus_private.h
On Thu, Oct 03, 2002 at 12:22:42AM +, attila! wrote: > 5.0-CURRENT slice as of 2002.10.02.12.0.0 > > cvs log: > > Delete src/sys/sys/bus_private.h > > kernel compile log: > > /usr/src/sys/dev/trm/trm.c:71:29: \ > sys/bus_private.h: No such file or directory > > updating at 1800 does not show the file restored. > > 3762 Sep 5 2001 bus_private.h > > Is there any external consequences adding bus_private.h > to the sys/dev/trm directory for the DC395 controller? > > I placed a copy of bus_private.h in the trm directory > and it compiles and the driver works... > > all's well that ends well? > > hopefully the Tekram DC395U/W will be officially > committed Hi, Could you please try this one: http://www.ci0.org/trm/trm.tar.gz ? It should fix your problem. Cheers, Olivier Houchard To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP! GEOM as default in 5 days...
Poul-Henning Kamp wrote: > Provided nothing terminal pops up in the next 5 days, GEOM will > become default in -current on Saturday 5th of october. > > Please test it now on _your_ configuration and tell me if it > fails to work. A few of my slices got shuffled about, but that was an easy fix, the bit that I cant figure out is that my CD-ROM won't mount the CD I've got in it now, (an 80 minute CDR) but it has pre-geom. # ls /dev/cd* /dev/cd0 I had a cd0 and a cd0c device earlier # cat /etc/fstab | grep cd0 /dev/cd0/disks/cd0 cd9660 ro,noauto 0 0 # mount /disks/cd0 sits with I as its process state. # mount_cd9660 /dev/cd0 /disks/cd0 sits with D as its process state, drive door is locked: root14438 0.0 0.1 204 104 p1 D+4:33PM 0:00.12 mount_cd9660 /de I'll reboot verbosely and see if its the same with other CDs, but until then here are some dmesg snippits: atapci0: port 0xb800-0xb80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ... ahc0: port 0xb000-0xb0ff mem 0xdd00-0xdd000fff irq 7 at device 6.0 on pci0 aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs ... Initializing GEOMetry subsystem IPsec: Initialized Security Association Processing. ad0: 1033MB [2100/16/63] at ata0-master WDMA2 ad2: 2014MB [4092/16/63] at ata1-master WDMA2 Waiting 2 seconds for SCSI devices to settle cd0 at ahc0 bus 0 target 6 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 20.000MB/s transfers (20.000MHz, offset 16) cd0: cd present [355664 x 2048 byte records] da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled da0: 4350MB (8910423 512 byte sectors: 255H 63S/T 554C) da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da1: 2075MB (4250695 512 byte sectors: 255H 63S/T 264C) Mounting root from ufs:/dev/ad0s1a g_pc98_taste: error 0 guessing 17 sectors g_pc98_taste: error 0 guessing 8 heads -- Eric Hodel - [EMAIL PROTECTED] - http://segment7.net All messages signed with fingerprint: FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04 msg43784/pgp0.pgp Description: PGP signature
Re: PCI brokenness
After a cvsup and buildworld/kernel, everything seems to be working again.
Thanks!
On Wed, Oct 02, 2002 at 08:41:10AM +0900, Mitsuru IWASAKI wrote:
> Hi,
>
> > On 01-Oct-2002 Michael McGoldrick wrote:
> > > On Tue, Oct 01, 2002 at 12:48:47PM -0400, John Baldwin wrote:
> > >>
> > >> On 01-Oct-2002 Michael McGoldrick wrote:
> > >> > 'Me too'
> > >> > Dmesg from working kernel attached, not sure how to get a dmesg from the
> > >> > broken one. :(
> > >> > Send me a mail if any further info would help.
> > >> > (I have built two kernels recently, both have had this problem)
> > >>
> > >> What exact problem do you have. No PCI devices?
> > >>
> > >> --
> > >>
> > >> John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
> > >> "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
> > >>
> > >> To Unsubscribe: send mail to [EMAIL PROTECTED]
> > >> with "unsubscribe freebsd-current" in the body of the message
> > >
> > > Yes, the kernel seems to attempt to mount root right after this line:
> > > device_probe_and_attach: acpi0 attach returned 6
> >
> > Can you try with the stuff I committed yesterday? It fixed the case (for
> > my tests at least) of legacy0 failing to attach or probe when acpi failed
> > to attach.
>
> If still failed, please try this.
> I've noticed that no chance to call pci_cfgregopen() before probing
> PCI children in case Host PCI bridge _CRS is not method or _INI method
> don't access to PCI config space or something.
>
> Thanks
>
> Index: acpi_pcib_acpi.c
> ===
> RCS file: /home/ncvs/src/sys/dev/acpica/acpi_pcib_acpi.c,v
> retrieving revision 1.23
> diff -u -r1.23 acpi_pcib_acpi.c
> --- acpi_pcib_acpi.c 26 Aug 2002 18:30:27 - 1.23
> +++ acpi_pcib_acpi.c 1 Oct 2002 23:17:51 -
> @@ -114,6 +115,9 @@
> !acpi_disabled("pci") &&
> acpi_MatchHid(dev, "PNP0A03")) {
>
> + if (!pci_cfgregopen())
> + return(ENXIO);
> +
> /*
>* Set device description
>*/
> Index: acpi_pcib_pci.c
> ===
> RCS file: /home/ncvs/src/sys/dev/acpica/acpi_pcib_pci.c,v
> retrieving revision 1.1
> diff -u -r1.1 acpi_pcib_pci.c
> --- acpi_pcib_pci.c 26 Aug 2002 18:30:27 - 1.1
> +++ acpi_pcib_pci.c 1 Oct 2002 23:18:38 -
> @@ -114,6 +115,9 @@
> return (ENXIO);
> if (acpi_get_handle(dev) == NULL)
> return (ENXIO);
> +if (!pci_cfgregopen())
> + return (ENXIO);
> +
> device_set_desc(dev, "ACPI PCI-PCI bridge");
> return (-1000);
> }
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
--
Michael McGoldrick: [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: expat2 in the base system?
At 2:28 PM +0200 10/2/02, Sheldon Hearn wrote: >We're at a lucky moment in time, where there's only one version of >expat in the ports tree. But think about what happens when there >are two mainstream versions at large again. > >Please let's learn from past mistakes and give this library a >completely separate name, perhaps with stripped down functionality. >Then ports can still choose to use it instead of the expat2 port >if it does the job for them, and we have our cake and eat it. I think it would be very prudent that any base-system expat have it's own name, even if it's just "expat2fb". I have no opinion on whether that should be the full expat2 or a stripped down functionality, but I think we should make it clear that "this is the expat which the base system needs -- if you do not like this version, then use the appropriate port and don't complain to us about which version we install in the base system". -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fatal warnings breaks ipfw on LP64
It's been one month, have you made any progress on this? Mike Barcroft <[EMAIL PROTECTED]> writes: > > cc1: warnings being treated as errors > /usr/src/sys/netinet/ip_fw2.c: In function `ipfw_ctl': > /usr/src/sys/netinet/ip_fw2.c:2508: warning: cast from pointer to integer of >different size > /usr/src/sys/netinet/ip_fw2.c:2521: warning: cast from pointer to integer of >different size > > Some of the code in question looks questionable: > /* > * abuse 'next_rule' to store the set_disable word > */ > (u_int32_t)(((struct ip_fw *)bp)->next_rule) = > set_disable; > > The rvalue is being cast in an assignment to make a pointer store an > integer? Surely this can be written better. > > Best regards, > Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: hack(6) does not run in xterm!
On Wed, 2 Oct 2002 18:27:29 -0400 Mikhail Teterin <[EMAIL PROTECTED]> wrote: > Just noticed on my > > FreeBSD 5.0-CURRENT #0: Thu Sep 26 11:07:24 EDT 2002 > > % hack > Terminal must backspace. > > Here is the end of the ktrace: > > [...] > 41386 hack RET break 0 > 41386 hack CALL break(0x8089000) > 41386 hack RET break 0 > 41386 hack CALL ioctl(0x1,TIOCGETA,0xbfbff6a0) > 41386 hack RET ioctl 0 > 41386 hack CALL ioctl(0x1,TIOCGETA,0xbfbff660) > 41386 hack RET ioctl 0 > 41386 hack CALL ioctl(0x1,TIOCGWINSZ,0xbfbff6c0) > 41386 hack RET ioctl 0 > 41386 hack CALL ioctl(0,TIOCSETP,0x807eeac) > 41386 hack RET ioctl 0 > 41386 hack CALL ioctl(0,TIOCSLTC,0x807e534) > 41386 hack RET ioctl 0 > 41386 hack CALL write(0x1,0x807e5a0,0x19) > 41386 hack GIO fd 1 wrote 25 bytes > "Terminal must backspace. > " > 41386 hack RET write 25/0x19 > 41386 hack CALL exit(0x1) > > On my system at home: > > FreeBSD 5.0-CURRENT #0: Mon Aug 19 00:18:21 EDT 2002 > > it still works... If I setenv TERM to cons25 in xterm, it will come > up too... > > -mi > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > Slash'EM (0.0.6E4F8) and Nethack (3.4.0) die with the same error. It's something broken in Termcap, as copying Termcap and Termcap.db over from a -STABLE (4.6-stable of August 19th 2002) box makes them work again. Any info I can supply to help fix this, let me know. -Adam To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP! GEOM as default in 5 days...
Poul-Henning Kamp wrote: > Provided nothing terminal pops up in the next 5 days, GEOM will > become default in -current on Saturday 5th of october. > > Please test it now on _your_ configuration and tell me if it > fails to work. When I enable geom, vinum won't start claiming it can't find its drives. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
alpha tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Wed Oct 2 15:19:29 PDT 2002 -- >>> Kernel build for GENERIC completed on Wed Oct 2 15:50:28 PDT 2002 -- >>> Kernel build for LINT started on Wed Oct 2 15:50:28 PDT 2002 -- ===> vinum cc1: warnings being treated as errors /h/des/src/sys/dev/advansys/adv_pci.c: In function `adv_pci_attach': /h/des/src/sys/dev/advansys/adv_pci.c:197: warning: overflow in implicit constant conversion *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
hack(6) does not run in xterm!
Just noticed on my FreeBSD 5.0-CURRENT #0: Thu Sep 26 11:07:24 EDT 2002 % hack Terminal must backspace. Here is the end of the ktrace: [...] 41386 hack RET break 0 41386 hack CALL break(0x8089000) 41386 hack RET break 0 41386 hack CALL ioctl(0x1,TIOCGETA,0xbfbff6a0) 41386 hack RET ioctl 0 41386 hack CALL ioctl(0x1,TIOCGETA,0xbfbff660) 41386 hack RET ioctl 0 41386 hack CALL ioctl(0x1,TIOCGWINSZ,0xbfbff6c0) 41386 hack RET ioctl 0 41386 hack CALL ioctl(0,TIOCSETP,0x807eeac) 41386 hack RET ioctl 0 41386 hack CALL ioctl(0,TIOCSLTC,0x807e534) 41386 hack RET ioctl 0 41386 hack CALL write(0x1,0x807e5a0,0x19) 41386 hack GIO fd 1 wrote 25 bytes "Terminal must backspace. " 41386 hack RET write 25/0x19 41386 hack CALL exit(0x1) On my system at home: FreeBSD 5.0-CURRENT #0: Mon Aug 19 00:18:21 EDT 2002 it still works... If I setenv TERM to cons25 in xterm, it will come up too... -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Junior Kernel Hacker page updated...
On Sat, Sep 14, 2002 at 12:17:53PM +0200, Poul-Henning Kamp wrote:
>
> This is just to note that I have updated the JKH page with a lot of new
> stuff, so if your coding-pencil itches:
>
> http://people.freebsd.org/~phk/TODO/
|Make -j improvement
|
|make(1) with -j option uses a select loop to wait for events, and every
|100msec it drops out to look for processes exited etc. A pure "make
|buildworld" on a single-CPU machine is up to 25% faster that the best
|"make -j N buildworld" time on the same hardware. Changing to timeout
|to be 10msec improves things about 10%.
|I think that make(1) should use kqueue(2) instead, since that would
|eliminate the need for timeouts.
Ok, here's what I came up with. However, with the patch applied, each
'make buildworld' on a SMP machine throws tons of
/freebsd/current/src/sys/vm/uma_core.c:1307: could sleep with "filedesc structure"
locked from /freebsd/current/src/sys/kern/kern_event.c:959
at me and freezes badly at some point (no breaking into ddb possible).
This is totally repeatable. Is anybody able to reproduce (and maybe
fix) this?
Regards,
Stefan Farfeleder
Index: job.c
===
RCS file: /home/ncvs/src/usr.bin/make/job.c,v
retrieving revision 1.43
diff -u -r1.43 job.c
--- job.c 29 Sep 2002 00:20:28 - 1.43
+++ job.c 2 Oct 2002 21:34:51 -
@@ -64,9 +64,8 @@
* Job_CatchOutput Print any output our children have produced.
* Should also be called fairly frequently to
* keep the user informed of what's going on.
- * If no output is waiting, it will block for
- * a time given by the SEL_* constants, below,
- * or until output is ready.
+ * If no output is waiting, it will block until
+ * a child terminates or until output is ready.
*
* Job_InitCalled to intialize this module. in addition,
* any commands attached to the .BEGIN target
@@ -107,6 +106,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -237,8 +238,7 @@
* (2) a job can only be run locally, but
* nLocal equals maxLocal */
#ifndef RMT_WILL_WATCH
-static fd_set outputs;/* Set of descriptors of pipes connected to
-* the output channels of children */
+static int kqfd; /* File descriptor obtained by kqueue() */
#endif
STATIC GNode *lastNode; /* The node for which output was most recently
@@ -692,8 +692,6 @@
if (usePipes) {
#ifdef RMT_WILL_WATCH
Rmt_Ignore(job->inPipe);
-#else
- FD_CLR(job->inPipe, &outputs);
#endif
if (job->outPipe != job->inPipe) {
(void) close(job->outPipe);
@@ -1265,14 +1263,25 @@
/*
* The first time a job is run for a node, we set the current
* position in the buffer to the beginning and mark another
-* stream to watch in the outputs mask
+* stream to watch in the outputs mask. The termination of this
+* job and the availability of new data in the pipe are
+* registered in the kqueue.
*/
+ struct kevent kev[2];
+
job->curPos = 0;
#ifdef RMT_WILL_WATCH
Rmt_Watch(job->inPipe, JobLocalInput, job);
#else
- FD_SET(job->inPipe, &outputs);
+ EV_SET(&kev[0], job->inPipe, EVFILT_READ, EV_ADD, 0, 0, job);
+ EV_SET(&kev[1], job->pid, EVFILT_PROC, EV_ADD | EV_ONESHOT,
+ NOTE_EXIT, 0, NULL);
+ if (kevent(kqfd, kev, 2, NULL, 0, NULL) != 0) {
+ /* kevent() will fail if the job is already finished */
+ if (errno != EBADF && errno != ESRCH)
+ Punt("kevent: %s", strerror(errno));
+ }
#endif /* RMT_WILL_WATCH */
}
@@ -2229,12 +2238,12 @@
Job_CatchOutput()
{
int nfds;
-struct timeval timeout;
-fd_set readfds;
-LstNode ln;
-Job *job;
#ifdef RMT_WILL_WATCH
int pnJobs; /* Previous nJobs */
+#else
+struct keventkev[4]; /* 4 is somewhat arbitrary */
+size_t kevsize = sizeof(kev) / sizeof(kev[0]);
+int i;
#endif
(void) fflush(stdout);
@@ -2262,25 +2271,20 @@
}
#else
if (usePipes) {
- readfds = outputs;
- timeout.tv_sec = SEL_SEC;
- timeout.tv_usec = SEL_USEC;
-
- if ((nfds = select(FD_SETSIZE, &readfds, (fd_set *) 0,
- (fd_set *) 0, &timeout)) <= 0)
- return;
- else {
- if (Lst_
panic (Fatal trap 12: page fault while in kernel mode) today
Saw Alfred's commit to un-break -CURRENT, did likewise locally,
built today's -CURRENT, and an attempted multi-user boot panics:
...
Starting nfsd.
Updating motd.
Starting ntpd.
Configuring syscons: blanktime.
Starting sshd.
Expensive timeout(9) function: 0xc02bea10(0xc406a000) 0.006791320
g_dev_clone(tty)
Expensive timeout(9) function: 0xc02bea10(0xc406a000) 0.006783223
Initial i386 initialization:.
Additional ABI support:.
Local package initialization:g_post_event(1, 0, 0, 0xc439a300, 0)
Eg_do_event(0xc43730c0) 1 m:0 g:0 p:0xc439a300 c:0 -
EV_NEWx_PROVIDER(md10)
aes_taste(AES,md10)
pensive timeout(9) function: 0xc02125a0(0) 0.008110381
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id =
fault virtual address = 0x110
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0153d95
stack pointer = 0x10:0xd6963ba8
frame pointer = 0x10:0xd6963bc0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 2 (g_event)
kernel: type 12 trap, code=0
Stopped at mdopen+0x45:movl0x110(%ecx),%eax
db> tr
mdopen(c4393000,3,0,0,0) at mdopen+0x45
g_disk_access(c439a300,1,0,0,0) at g_disk_access+0xf8
g_access_rel(c4367b80,1,0,0,a) at g_access_rel+0x2af
g_aes_taste(c03b1260,c439a300,0,98,0) at g_aes_taste+0xc8
g_do_event(c43730c0,0,c036eba0,f3,6667) at g_do_event+0x229
one_event(d6963d08,c01a9425,c03b198c,0,4c) at one_event+0x1e6
g_run_events(c03b198c,0,4c,c036f04f,a) at g_run_events+0x15
g_event_procbody(0,d6963d48,c0371bd1,34d,0) at g_event_procbody+0x25
fork_exit(c01a9400,0,d6963d48) at fork_exit+0xa7
fork_trampoline() at fork_trampoline+0x1a
--- trap 0x1, eip = 0, esp = 0xd6963d7c, ebp = 0 ---
db> show pcpu 0
cpuid= 0
curthread= 0xc15838f0: pid 2 "g_event"
curpcb = 0xd6963da0
fpcurthread = none
idlethread = 0xc1582a90: pid 12 "idle: cpu0"
currentldt = 0x28
spin locks held:
db> show pcpu 1
cpuid= 1
curthread= 0xc15829c0: pid 11 "idle: cpu1"
curpcb = 0xd692dda0
fpcurthread = none
idlethread = 0xc15829c0: pid 11 "idle: cpu1"
currentldt = 0x28
spin locks held:
db> show lockedvnods
Locked vnodes
db> show locks
exclusive sleep mutex Giant r = 0 (0xc03b7520) locked @ /usr/src/sys/vm/vm_fault.c:206
exclusive sx GEOM topology r = 0 (0xc03b17e0) locked @
/usr/src/sys/geom/geom_event.c:224
db>
Single-user seems to boot OK, but trying to get a dump is less useful:
db> panic
panic: from debugger
cpuid = 0; lapic.id =
Debugger("panic")
Fatal trap 3: breakpoint instruction fault while in kernel mode
cpuid = 0; lapic.id =
instruction pointer = 0x8:0xc032ad85
stack pointer = 0x10:0xd696391c
frame pointer = 0x10:0xd6963928
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= IOPL = 0
current process = 2 (g_event)
Stopped at mdopen+0x45:movl0x110(%ecx),%eax
db>
This is on my SMP (2x866 PIII) build machine; I added GEOM yesterday
(and built and ran -CURRENT OK then).
I just reset the machine, booted to single-user (same kernel, built with
sources updated via CVSup at 0347 PDT (7 hrs. west of GMT) from
cvsup13), and am doing a "fsck -p" (which just finished as I was typing).
Some of the programs being run in the mutli-user startup were compiled
under -STABLE: I run both -CURRENT and -STABLE (on diffeent slices) on
the machine, but /usr/local is shared between them, and build all the
ports under -STABLE (except that ebery once in a while, I go ahead and
upgrade X11 under -CURRENT).
Anyway, this appears fairly repeatable, so if someone would like
me to try some thing, I'm willing.
Oh, and booting the previous kernel seems OK:
freebeast(5.0-C)[1] uname -a
FreeBSD freebeast.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #9: Tue Oct 1
15:40:23 PDT 2002
[EMAIL PROTECTED]:/common/S4/obj/usr/src/sys/FREEBEAST i386
freebeast(5.0-C)[2] tail /var/log/cvsup-history.log
Oct 1 00:00:00 freebeast newsyslog[1077]: logfile turned over
CVSup begin from cvsup14.freebsd.org at Tue Oct 1 03:47:02 PDT 2002
CVSup begin from cvsup13.freebsd.org at Tue Oct 1 03:47:05 PDT 2002
CVSup ended from cvsup13.freebsd.org at Tue Oct 1 03:54:41 PDT 2002
CVSup begin from cvsup14.freebsd.org at Wed Oct 2 03:47:03 PDT 2002
CVSup begin from cvsup13.freebsd.org at Wed Oct 2 03:47:06 PDT 2002
CVSup ended from cvsup13.freebsd.org at Wed Oct 2 04:31:07 PDT 2002
freebeast(5.0-C)[3]
Cheers,
david
--
David H. Wolfskill [EMAIL PROTECTED]
To paraphrase David Hilbert, there can be no conflicts between the
discipline of systems administration and Microsoft, since they have
nothing in common.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body
Re: PCI brokenness
On 02-Oct-2002 Mark Murray wrote: >> > Ok, so you only have ata0 and no ata1. So that means the ACPI ata >> > attachment almost worked. Humm, try doing a hack to change ATA_IOADDR_RID >> > in ata-all.h from 0 to 1 along with the previous patch to add an acpi >> > attachment for ata and see if that works. I still have no idea why >> > the ata hint device isn't working. It should be working fine. :( >> >> OK. I'll get back to you shortly. > > Doesn't work. > > "duplicate case value". Ok, just hack the ata_isa attachment to use a rid of 1 for it's ioport. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
uipc_sem.c
So, erm, are there any users of the new semaphore code? I kind of doubt it since it has verbose printf's in just about every function. I'm also curious why we don't just use a single semaphore implementation that is shared via wrappers between the SYSV semaphores and the POSIX semaphores. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCI brokenness
> > Ok, so you only have ata0 and no ata1. So that means the ACPI ata > > attachment almost worked. Humm, try doing a hack to change ATA_IOADDR_RID > > in ata-all.h from 0 to 1 along with the previous patch to add an acpi > > attachment for ata and see if that works. I still have no idea why > > the ata hint device isn't working. It should be working fine. :( > > OK. I'll get back to you shortly. Doesn't work. "duplicate case value". M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: expat2 in the base system?
* De: "Andrew P. Lentvorski" <[EMAIL PROTECTED]> [ Data: 2002-10-02 ] [ Subjecte: Re: expat2 in the base system? ] > On Wed, 2 Oct 2002, Marc Recht wrote: > > > IMO 1. would be better with a complete expat. So the ports could use the > > system version and probably/maybe the drift between the official- and > > system-version will not be that big. And compared to Perl expat it > > rather small. So the bloat couldn't be that big.. > > This strikes me as a step in the wrong direction. Isn't FreeBSD moving to > making more things optional packages rather than direct parts of base? > > If Perl and the userland things which depend upon it can be made into > install time packages, what's stopping the same thing from being done for > GEOM (ie. libexpat and the userland things which depend upon it)? GEOM is a kernel option, and one that is about to become the default, and a method for a uniform system for passign data around would be great. I seem to remember a discussion with Robert Watson and myself about a year ago where we discussed some sort of classy parser in libc for the MAC config files, etc., and we discussed XML at some point... Having libexpat around makes it a lot easier for people who need to do config files, or pass around data structures. -- Juli Mallett <[EMAIL PROTECTED]> | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: expat2 in the base system?
On Wed, 2 Oct 2002, Marc Recht wrote: > IMO 1. would be better with a complete expat. So the ports could use the > system version and probably/maybe the drift between the official- and > system-version will not be that big. And compared to Perl expat it > rather small. So the bloat couldn't be that big.. This strikes me as a step in the wrong direction. Isn't FreeBSD moving to making more things optional packages rather than direct parts of base? If Perl and the userland things which depend upon it can be made into install time packages, what's stopping the same thing from being done for GEOM (ie. libexpat and the userland things which depend upon it)? -a To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Announce: informal quirk maintainer
On Wed, 2 Oct 2002, Giorgos Keramidas wrote: > On 2002-10-01 13:08, Nate Lawson <[EMAIL PROTECTED]> wrote: > > I will be taking ownership of quirk maintenance to help clarify and > > expedite things. The goal is to interoperate with as much hardware > > as possible while keeping the table attributed and in > > well-maintained order. > > > > Here are a few guidelines: ... > > 3. Please follow the quirk submission guidelines to help things proceed > > quickly: > > http://www.root.org/~nate/freebsd/quirks.html > > 4. Please do not commit quirks directly. > > 5. GNATS maintainers should assign quirk-related PRs to njl@ > > I am unfamiliar with the notion of "quirks", but as long as you or > anyone else takes precautions to avoid creating a bottleneck, in case > you have to go away for extended periods of time, that's a fine thing. > This is all, IMHO, of course. Quirks are entries in CAM or the SCSI periph driver for devices which cannot handle certain (legal) commands. It the hardware returns an error, we can recover without a quirk. If the hardware hangs, a quirk is needed. The link above has more details on this if you're interested. In this case, before they were sitting untouched in PRs or developers would commit their own entries at will. Now if they're untouched you have someone to yell at and if developers commit away, someone will yell at them. ;-) -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
rpcbind failure mode non-ideal if run more than once
crash1# rpcbind Oct 2 12:47:15 crash1 rpcbind: cannot bind (null) on udp6: Address already in use Segmentation fault Oct 2 12:47:15 crash1 kernel: pid 1595 (rpcbind), uid 0: exited on signal 11 crash1# I'm having trouble extracting a core so won't be able to follow-up just yet, but it looks like it might not be too hard to track down. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCI brokenness
> >> So it doesn't boot at all, that's different from "hard-hang during reboot". > >> :) After ppc your device probe is over. You could be getting an > >> interrupt storm. Can you break into ddb when this happens? > > > > Roger the diference. :-) > > > > No. I cannot break into DDB. The keyboard may as well not be there. > > Humm. :( This is definitely a regression that needs to be fixed. > (For the non-ACPI case). Did you have this problem on older kernels > as well? Does 4.x work ok w/o hanging? I'll check. The current problems are on my laptop, and I cannot afford the trauma that reverting it to RELENG_4 will cause. I have a crash box at home that I'll try. > >> > In practical terms, this is a regression, in that previous function > >> > has been removed before an adequate replacement was ready. > >> > >> Ok, I have a question now. How did ata get probed before? If you > >> add hints for it does it get probed? It doesn't appear to be a PCI > >> device. It may be that we need to make it work as an ATA attachment > >> somehow. Also, did ata1 show up before? > > > > Yes - I have hints. > > > > Here is my hints file (which has not changed in at least 6 months) > > Ok, so you only have ata0 and no ata1. So that means the ACPI ata > attachment almost worked. Humm, try doing a hack to change ATA_IOADDR_RID > in ata-all.h from 0 to 1 along with the previous patch to add an acpi > attachment for ata and see if that works. I still have no idea why > the ata hint device isn't working. It should be working fine. :( OK. I'll get back to you shortly. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCI brokenness
On 02-Oct-2002 Mark Murray wrote: >> > "Hard hang" means that the probe messages stop around the parallel >> > device, and nothing else happens. The PCCARD ethernet remains dead. >> > the disk is silent and no amount of keyboard activity does anything >> > at all. Serial console dead. Reset needed to reboot. >> >> So it doesn't boot at all, that's different from "hard-hang during reboot". >> :) After ppc your device probe is over. You could be getting an >> interrupt storm. Can you break into ddb when this happens? > > Roger the diference. :-) > > No. I cannot break into DDB. The keyboard may as well not be there. Humm. :( This is definitely a regression that needs to be fixed. (For the non-ACPI case). Did you have this problem on older kernels as well? Does 4.x work ok w/o hanging? >> > In practical terms, this is a regression, in that previous function >> > has been removed before an adequate replacement was ready. >> >> Ok, I have a question now. How did ata get probed before? If you >> add hints for it does it get probed? It doesn't appear to be a PCI >> device. It may be that we need to make it work as an ATA attachment >> somehow. Also, did ata1 show up before? > > Yes - I have hints. > > Here is my hints file (which has not changed in at least 6 months) Ok, so you only have ata0 and no ata1. So that means the ACPI ata attachment almost worked. Humm, try doing a hack to change ATA_IOADDR_RID in ata-all.h from 0 to 1 along with the previous patch to add an acpi attachment for ata and see if that works. I still have no idea why the ata hint device isn't working. It should be working fine. :( -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Is Your Credit Report Stopping You? Find Out!
We're Not Clowning Around with These Offers: 1) Is Your Credit Report Stopping You? Let Junum's Expertise & Technology Help you! You Only Pay If We Help http://www.qksrv.net/click-1030333-1510752 2) We're Not Clowning Around Get Your Free Auto, Health, Home, or Life Insurance Quote http://www.qksrv.net/click-1030333-1513745 3) Get a Free* Nokia 3390 and Free Long Distance. Check Out this Great Deal Soon...Offer Ends Sept. 30th. http://wireless.freeze.com/family/fyruss/ 4) Claim Your Copy of "The Lord of the Rings" + 3 Other DVD's All for just $9.95 + Shipping and Handling http://www.partner2profit.com/redir.cfm?ccode=C7EC5E29&pcode=90FA2E13 Offer Manager Daily-Deals UNSUBSCRIBE INSTRUCTIONS: If you no longer wish to receive this newsletter, you can unsubscribe by going here: http://tilw.net/unsub.php?client=freeyankee&msgid=2100200012 and entering your email address. TRCK:freeyankee;Fxuuhqw*Iuhhevg!Ruj;1;
i386 tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- ===> libexec/rpc.rstatd /local0/scratch/des/src/libexec/rpc.rstatd/rstat_proc.c:87: conflicting types for `havedisk' /home/des/tinderbox/i386/obj/local0/scratch/des/src/i386/usr/include/rpcsvc/rstat.h:88: previous declaration of `havedisk' *** Error code 1 Stop in /local0/scratch/des/src/libexec/rpc.rstatd. *** Error code 1 Stop in /local0/scratch/des/src/libexec. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel boot messages absent
On Wed, Oct 02, 2002 at 01:48:20PM +0200, Alexander Langer wrote: > Thus spake John Baldwin ([EMAIL PROTECTED]): > > > > Can anyone explain me why with a recent kernel (last kernel was from > > > 1 year ago) the kernel boot messages disappear from the monitor > > > once the "propellor" of the kernel boot has done like 5 rounds > > > (last message is the last line of the > > > "Booting kernel in X seconds" line, followed by a single "-" on > > > the line, which used to be the propellor) > > You need to setup a /boot/device.hints file if you haven't already so > > that the kernel can configure it's console device. > > Nah, that machine already had a device.hints installed. And also > with an upgraded device.hints (GENERIC.hints copied from /sys/i386/conf) > the same problem occurs. > > And I don't think I'd have to edit device.hints on common hardware, > using a GENERIC kernel, do I? It used to work before :-( You can verify with conscontrol. It should list consolectl for vga console and Muting off. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCI brokenness
> > "Hard hang" means that the probe messages stop around the parallel > > device, and nothing else happens. The PCCARD ethernet remains dead. > > the disk is silent and no amount of keyboard activity does anything > > at all. Serial console dead. Reset needed to reboot. > > So it doesn't boot at all, that's different from "hard-hang during reboot". > :) After ppc your device probe is over. You could be getting an > interrupt storm. Can you break into ddb when this happens? Roger the diference. :-) No. I cannot break into DDB. The keyboard may as well not be there. > > In practical terms, this is a regression, in that previous function > > has been removed before an adequate replacement was ready. > > Ok, I have a question now. How did ata get probed before? If you > add hints for it does it get probed? It doesn't appear to be a PCI > device. It may be that we need to make it work as an ATA attachment > somehow. Also, did ata1 show up before? Yes - I have hints. Here is my hints file (which has not changed in at least 6 months) # $FreeBSD$ #hint.acpi.0.disabled="1" #hint.apm.0.at="nexus" #hint.apm.0.flags="0x20" hint.ata.0.at="isa" hint.ata.0.irq="14" hint.ata.0.port="0x1F0" hint.atkbd.0.at="atkbdc" hint.atkbd.0.flags="0x1" hint.atkbd.0.irq="1" hint.atkbdc.0.at="isa" hint.atkbdc.0.port="0x060" hint.fdc.0.at="isa" hint.fdc.0.port="0x3F0" hint.fdc.0.irq="6" hint.fdc.0.drq="2" hint.fd.0.at="fdc0" hint.fd.0.drive="0" hint.npx.0.at="nexus" hint.npx.0.irq="13" hint.npx.0.port="0x0F0" hint.pcic.0.at="isa" #hint.pcic.0.irq="3" hint.pcic.0.maddr="0xd" hint.pcic.0.port="0x3e0" hint.pmtimer.0.at="isa" hint.ppc.0.at="isa" hint.ppc.0.irq="7" hint.psm.0.at="atkbdc" hint.psm.0.irq="12" hint.sc.0.at="isa" hint.sc.0.flags="0x100" hint.vga.0.at="isa" hint.pcm.0.at="isa" hint.pcm.0.irq="5" hint.pcm.0.drq="1" hint.pcm.0.flags="0x0" #hint.midi.0.at="isa" #hint.midi.0.irq="5" #hint.midi.0.flags="0x0" #hint.midi.0.at="isa" #hint.midi.0.port="0x2F8" #hint.midi.0.irq="3" hint.sbc.0.at="isa" hint.sbc.0.port="0x220" hint.sbc.0.irq="5" hint.sbc.0.drq="1" hint.sbc.0.flags="0x10" > >> Iwasaki-San's patch adds back in the only part of the extra "bogus" > >> stuff that legacy took out that could have an effect on your system > >> with respect to PCI. > > > > Ok. But it doesn't work. :-( > > Well, it does fix some things since we now find your PCI devices. > Assuming that works that is all that legacy changed. Adding > legacy didn't change anything wrt ata(4). Did you used to have > hints for ata and now don't perchance? No. I have 2 kernels - /boot/kernel (today's sources) /boot/kernel.old (sept 22nd sources) same device.hints. kernel.old works, kernel has no hard disk. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCI brokenness
On 02-Oct-2002 Mark Murray wrote: >> > Iwasaki-San's patch made no difference that I could see. Disabling ACPI >> > causes my system to hard-hang during reboot. I might be able to fix that >> > by futzing with device.hints, but that took me a whole weekend and a >> > reinstall last time I tried. Device.hints is a dangerous thing to play with. >> >> All device.hints should give you is your console back if you are >> missing it. Do you mean hard hangs on reboot such as after you do a >> shutdown -r now the system shuts down, tries to reboot, and then just >> stays black and never boots? > > "Hard hang" means that the probe messages stop around the parallel > device, and nothing else happens. The PCCARD ethernet remains dead. > the disk is silent and no amount of keyboard activity does anything > at all. Serial console dead. Reset needed to reboot. So it doesn't boot at all, that's different from "hard-hang during reboot". :) After ppc your device probe is over. You could be getting an interrupt storm. Can you break into ddb when this happens? >> > 22nd September ACPI works. Suspend/resume, power shutdown, etc. >> >> That's like saying that PAM works if all the programs that use PAM >> automatically fall back to reading /etc/master.passwd manually and >> complaining that people broke things when they removed the ability >> to read /etc/master.passwd manually thus revealing the inherent >> breakage in PAM. > > Point taken. > >> (Just in hypothetical terms.) > > In practical terms, this is a regression, in that previous function > has been removed before an adequate replacement was ready. Ok, I have a question now. How did ata get probed before? If you add hints for it does it get probed? It doesn't appear to be a PCI device. It may be that we need to make it work as an ATA attachment somehow. Also, did ata1 show up before? >> Iwasaki-San's patch adds back in the only part of the extra "bogus" >> stuff that legacy took out that could have an effect on your system >> with respect to PCI. > > Ok. But it doesn't work. :-( Well, it does fix some things since we now find your PCI devices. Assuming that works that is all that legacy changed. Adding legacy didn't change anything wrt ata(4). Did you used to have hints for ata and now don't perchance? -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Tool make ordering, or something
On Wed, Oct 02, 2002 at 04:46:48PM +1000, Tim Robbins wrote: > The best we can do to src/bin/sh is to do something like this: > > #ifndef BOOTSTRAPPING > fmtstr(s, 64, "[%td] ", jp - jobtab + 1); We know when this hit the tree, so please use: #if defined(BOOTSTRAPPING) && (__FreeBSD_version > 5000xy) fmtstr(s, 64, "[%lld] ", (long long)(jp - jobtab + 1)); #else fmtstr(s, 64, "[%td] ", jp - jobtab + 1); #endif It makes it clear which is the special case and which is the normal one; it does not penaltize uptodate -CURRENT systems; and lastely lets us know that when RELENG_5 is branched, we can totally remove it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Announce: informal quirk maintainer
On 2002-10-01 13:08, Nate Lawson <[EMAIL PROTECTED]> wrote: > I will be taking ownership of quirk maintenance to help clarify and > expedite things. The goal is to interoperate with as much hardware > as possible while keeping the table attributed and in > well-maintained order. > > Here are a few guidelines: > > 1. All quirks submissions must go through GNATS PR db. This is to > facilitate tracking and archival of discussion. Sounds a nice idea. > 2. A quirk is only needed if the device hangs or refuses to operate > without it. > 3. Please follow the quirk submission guidelines to help things proceed > quickly: > http://www.root.org/~nate/freebsd/quirks.html > 4. Please do not commit quirks directly. > 5. GNATS maintainers should assign quirk-related PRs to njl@ I am unfamiliar with the notion of "quirks", but as long as you or anyone else takes precautions to avoid creating a bottleneck, in case you have to go away for extended periods of time, that's a fine thing. This is all, IMHO, of course. Giorgos. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCI brokenness
> > Iwasaki-San's patch made no difference that I could see. Disabling ACPI > > causes my system to hard-hang during reboot. I might be able to fix that > > by futzing with device.hints, but that took me a whole weekend and a > > reinstall last time I tried. Device.hints is a dangerous thing to play with. > > All device.hints should give you is your console back if you are > missing it. Do you mean hard hangs on reboot such as after you do a > shutdown -r now the system shuts down, tries to reboot, and then just > stays black and never boots? "Hard hang" means that the probe messages stop around the parallel device, and nothing else happens. The PCCARD ethernet remains dead. the disk is silent and no amount of keyboard activity does anything at all. Serial console dead. Reset needed to reboot. > > 22nd September ACPI works. Suspend/resume, power shutdown, etc. > > That's like saying that PAM works if all the programs that use PAM > automatically fall back to reading /etc/master.passwd manually and > complaining that people broke things when they removed the ability > to read /etc/master.passwd manually thus revealing the inherent > breakage in PAM. Point taken. > (Just in hypothetical terms.) In practical terms, this is a regression, in that previous function has been removed before an adequate replacement was ready. > Iwasaki-San's patch adds back in the only part of the extra "bogus" > stuff that legacy took out that could have an effect on your system > with respect to PCI. Ok. But it doesn't work. :-( M Latest dmesg (with Iwasaki-San's patch): Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #1: Wed Oct 2 15:49:33 BST 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/LIBRETTO Preloaded elf kernel "/boot/kernel/kernel" at 0xc04ce000. Preloaded elf module "/boot/kernel/linux.ko" at 0xc04ce0a8. Preloaded elf module "/boot/kernel/sysvshm.ko" at 0xc04ce154. Preloaded elf module "/boot/kernel/sysvsem.ko" at 0xc04ce200. Preloaded elf module "/boot/kernel/sysvmsg.ko" at 0xc04ce2ac. Preloaded elf module "/boot/kernel/if_dc.ko" at 0xc04ce358. Preloaded elf module "/boot/kernel/miibus.ko" at 0xc04ce404. Preloaded elf module "/boot/kernel/if_wi.ko" at 0xc04ce4b0. Preloaded elf module "/boot/kernel/snd_mss.ko" at 0xc04ce55c. Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc04ce608. Preloaded elf module "/boot/kernel/random.ko" at 0xc04ce6b4. Preloaded elf module "/boot/kernel/atspeaker.ko" at 0xc04ce760. Preloaded elf module "/boot/kernel/if_ep.ko" at 0xc04ce810. Preloaded elf module "/boot/kernel/nfsserver.ko" at 0xc04ce8bc. Preloaded elf module "/boot/kernel/nfsclient.ko" at 0xc04ce96c. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04cea1c. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 233289621 Hz CPU: Pentium/P55C (quarter-micron) (233.29-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x581 Stepping = 1 Features=0x8001bf real memory = 67174400 (65600K bytes) avail memory = 60010496 (58604K bytes) Intel Pentium detected, installing workaround for F00F bug npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <32-bit timer at 3.579545MHz> port 0x18a8-0x18ab on acpi0 acpi_cpu0: on acpi0 acpi_tz0: on acpi0 acpi_lid0: on acpi0 acpi_acad0: on acpi0 acpi_cmbat0: on acpi0 Using $PIR table, 5 entries at 0xc00f8e80 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 4.0 (no driver attached) pci0: at device 17.0 (no driver attached) cbb0: at device 19.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib0: possible interrupts: 3 4 5 6 7 9 10 11 12 14 15 pcib0: slot 19 INTA routed to irq 3 via \\_SB_.PCI0.EIO_.LNKA cbb1: at device 19.1 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 pcib0: possible interrupts: 3 4 5 6 7 9 10 11 12 14 15 pcib0: slot 19 INTB routed to irq 3 via \\_SB_.PCI0.EIO_.LNKB atspeaker0 port 0x61 on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A ppc0: parallel port not found. ppc0: parallel port not found. Timecounters tick every 10.000 msec Initializing GEOMetry subsystem acpi_cpu: CPU throttling enabled, 16 steps from 100% to 6.2% ep0: <3Com 3c589 10Mbps Ethernet> at port 0x100-0x10f irq 3 function 0 config 1 on pccard0 ep0: Ethernet address 00:10:5a:2d:39:c6 Mounting root from ufs:/dev/ad0s2a setrootbyname failed ffs_mountroot: can't find rootvp Root mount failed: 6 Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List va
Re: PCI brokenness
On 02-Oct-2002 Mark Murray wrote: >> > I tried this patch, and it made some progress (dmesg included). The >> > ATA system still seems badly broken, there is a spurious mention of >> > some kerneldump. I also have no console. >> >> Hmm, ata0 may be getting the wrong resources. Hmm. Try iwasaki-san's >> patch to acpi_pcib_* instead and see if it that helps. Either that or >> turn off ACPI for the time being. > > Iwasaki-San's patch made no difference that I could see. Disabling ACPI > causes my system to hard-hang during reboot. I might be able to fix that > by futzing with device.hints, but that took me a whole weekend and a > reinstall last time I tried. Device.hints is a dangerous thing to play with. All device.hints should give you is your console back if you are missing it. Do you mean hard hangs on reboot such as after you do a shutdown -r now the system shuts down, tries to reboot, and then just stays black and never boots? >> > Perhaps the legacy stuff needs to be backed out or disabled pending fixing? >> >> Well, the problem here is that ACPI isn't working, not that legacy is broken. >> What legacy does is make it so that if we try to use ACPI, we actually rely >> on it to work. If we can't get ACPI to work like it is supposed to we need >> to either fix it or disable it for now. > > 22nd September ACPI works. Suspend/resume, power shutdown, etc. That's like saying that PAM works if all the programs that use PAM automatically fall back to reading /etc/master.passwd manually and complaining that people broke things when they removed the ability to read /etc/master.passwd manually thus revealing the inherent breakage in PAM. (Just in hypothetical terms.) Iwasaki-San's patch adds back in the only part of the extra "bogus" stuff that legacy took out that could have an effect on your system with respect to PCI. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCI brokenness
> > Hmm, ata0 may be getting the wrong resources. Hmm. Try iwasaki-san's > > patch to acpi_pcib_* instead and see if it that helps. Either that or > > turn off ACPI for the time being. > > Iwasaki-San's patch made no difference that I could see. Disabling ACPI > causes my system to hard-hang during reboot. I might be able to fix that > by futzing with device.hints, but that took me a whole weekend and a > reinstall last time I tried. Device.hints is a dangerous thing to play with. Hmmm, did you rebuild and reinstall acpi.ko ? At least cbb should be appeared under pci0 Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCI brokenness
> > I tried this patch, and it made some progress (dmesg included). The > > ATA system still seems badly broken, there is a spurious mention of > > some kerneldump. I also have no console. > > Hmm, ata0 may be getting the wrong resources. Hmm. Try iwasaki-san's > patch to acpi_pcib_* instead and see if it that helps. Either that or > turn off ACPI for the time being. Iwasaki-San's patch made no difference that I could see. Disabling ACPI causes my system to hard-hang during reboot. I might be able to fix that by futzing with device.hints, but that took me a whole weekend and a reinstall last time I tried. Device.hints is a dangerous thing to play with. > > Perhaps the legacy stuff needs to be backed out or disabled pending fixing? > > Well, the problem here is that ACPI isn't working, not that legacy is broken. > What legacy does is make it so that if we try to use ACPI, we actually rely > on it to work. If we can't get ACPI to work like it is supposed to we need > to either fix it or disable it for now. 22nd September ACPI works. Suspend/resume, power shutdown, etc. > > Copyright (c) 1992-2002 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > The Regents of the University of California. All rights reserved. > > FreeBSD 5.0-CURRENT #0: Wed Oct 2 12:15:40 BST 2002 > > [EMAIL PROTECTED]:/usr/src/sys/i386/compile/LIBRETTO > > Preloaded elf kernel "/boot/kernel/kernel" at 0xc04ce000. > > Preloaded elf module "/boot/kernel/linux.ko" at 0xc04ce0a8. > > Preloaded elf module "/boot/kernel/sysvshm.ko" at 0xc04ce154. > > Preloaded elf module "/boot/kernel/sysvsem.ko" at 0xc04ce200. > > Preloaded elf module "/boot/kernel/sysvmsg.ko" at 0xc04ce2ac. > > Preloaded elf module "/boot/kernel/if_dc.ko" at 0xc04ce358. > > Preloaded elf module "/boot/kernel/miibus.ko" at 0xc04ce404. > > Preloaded elf module "/boot/kernel/if_wi.ko" at 0xc04ce4b0. > > Preloaded elf module "/boot/kernel/snd_mss.ko" at 0xc04ce55c. > > Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc04ce608. > > Preloaded elf module "/boot/kernel/random.ko" at 0xc04ce6b4. > > Preloaded elf module "/boot/kernel/atspeaker.ko" at 0xc04ce760. > > Preloaded elf module "/boot/kernel/if_ep.ko" at 0xc04ce810. > > Preloaded elf module "/boot/kernel/nfsserver.ko" at 0xc04ce8bc. > > Preloaded elf module "/boot/kernel/nfsclient.ko" at 0xc04ce96c. > > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04cea1c. > > Timecounter "i8254" frequency 1193182 Hz > > Timecounter "TSC" frequency 233289544 Hz > > CPU: Pentium/P55C (quarter-micron) (233.29-MHz 586-class CPU) > > Origin = "GenuineIntel" Id = 0x581 Stepping = 1 > > Features=0x8001bf > > real memory = 67174400 (65600K bytes) > > avail memory = 60010496 (58604K bytes) > > Intel Pentium detected, installing workaround for F00F bug > > npx0: on motherboard > > npx0: INT 16 interface > > acpi0: on motherboard > > acpi0: power button is handled as a fixed feature programming model. > > Timecounter "ACPI-fast" frequency 3579545 Hz > > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x18a8-0x18ab on acpi0 > > acpi_cpu0: on acpi0 > > acpi_tz0: on acpi0 > > acpi_lid0: on acpi0 > > acpi_acad0: on acpi0 > > acpi_cmbat0: on acpi0 > > pcib0: port 0xcf8-0xcff on acpi0 > > pci0: on pcib0 > > atspeaker0 port 0x61 on acpi0 > > atkbdc0: port 0x64,0x60 irq 1 on acpi0 > > atkbd0: flags 0x1 irq 1 on atkbdc0 > > kbd0 at atkbd0 > > psm0: irq 12 on atkbdc0 > > psm0: model IntelliMouse, device ID 3 > > ata0 port 0x3f6,0x1f0-0x1f7 irq 14 on acpi0 > > sio0 port 0x3f8-0x3ff irq 4 on acpi0 > > sio0: type 16550A > > ppc0: parallel port not found. > > ppc0: parallel port not found. > > Timecounters tick every 10.000 msec > > Initializing GEOMetry subsystem > > acpi_cpu: CPU throttling enabled, 16 steps from 100% to 6.2% > > ad0: 19077MB [38760/16/63] at ata0-master BIOSPIO > > Mounting root from ufs:/dev/ad0s2a > > stray irq 7 > > stray irq 7 > > Kerneldump off=2239236096 len=134217728 > > Kerneldump off=2239236096 len=134217728 > > Waiting (max 60 seconds) for system process `vnlru' to stop...stopped > > Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped > > Waiting (max 60 seconds) for system process `syncer' to stop...stopped > > > > syncing disks... 2 2 2 1 1 > > done > > Uptime: 22s > > Terminate ACPI > > Rebooting... > > > >> On 01-Oct-2002 Mark Murray wrote: > >> > Hi > >> > > >> > I'm running a kernel with your very latest nexus.c 1.49. > >> > > >> > The problem of the disappearing HD has not been fixed by this. > >> > > >> > Enclosed are verbose mesg's, one from a three-hour-ago > >> > (1st Oct 2002, 11:00 am, BST) kernel (broken), and another > >> > from a working Sept 22nd kernel. > >> > >> This is quite weird. You have a PCI bus and ACPI still finds > >> it fine, it just doesn't probe/attach any child devices. Hmm, > >> and your ATA controller isn't on the PCI bus. Ok, weird. Do > >> you have hints for your ata
Re: HEADSUP! GEOM as default in 5 days...
In message <[EMAIL PROTECTED]>, Andrew Gallatin w rites: > >Poul-Henning Kamp writes: > > > > Provided nothing terminal pops up in the next 5 days, GEOM will > > become default in -current on Saturday 5th of october. > > > > Please test it now on _your_ configuration and tell me if it > > fails to work. > > > >What, exactly, would you like tested? > >options GEOM on a random alpha I have laying around seems to cause no >harm. I can still boot, and disklabel seems to work (only tried >reading labels). That is already a big help for me to know, thanks a lot! >Anything else you'd like tested? Well, anything you can think of which I might have forgotten :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP! GEOM as default in 5 days...
Poul-Henning Kamp writes: > > Provided nothing terminal pops up in the next 5 days, GEOM will > become default in -current on Saturday 5th of october. > > Please test it now on _your_ configuration and tell me if it > fails to work. > What, exactly, would you like tested? options GEOM on a random alpha I have laying around seems to cause no harm. I can still boot, and disklabel seems to work (only tried reading labels). Anything else you'd like tested? Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NIS broken by pw_scan.c commits?
On Wed, 2 Oct 2002, Maxim Konovalov wrote: > Yes, it is my bug, fixed in rev. 1.23, sorry for inconvenience. No problem -- sorry for getting a bit snippy. I was just a bit surprised and couldn't imagine at first what I had broken in my password file :-). > By the way, there is still an issue: pw_scan() allows an empty GID in > non-NIS entries too. Any objections to a patch below? It looks to me like this is a reasonable approach, but if for some reason it doesn't work out, I'll be sure to whine when it hits my office machines. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] Workaround for bogus INT 12H BIOS serviceimplementation
Hi, > > > The patch makes no difference for booting directly from boot2 ... except > > > memsize() in boot2 also fails to check for errors, so it returns garbage > > > values. > > > > Yes I know that :-) > > But booting kernel directly from boot2 is not working at all for > > several years, so my understanding is that /boot/loader is necessary > > to boot kernel. > > It mostly works. I submitted patches in a PR many years ago and still use > them. Great! I tried to find the PR, but couldn't find... Why isn't it committed yet? :-) > > Hmmm, actually no. I know that some machines get panic with fatal trap > > 12 if we do 0x12 call. The worst case is getting panic, not losing > > 640K memory. > > Where does the panic occur? I checked that there is no problem here if > the result of INT 0x12 is ignored and basemem is set to 0. panic messages attached. It seems to be within BIOS routine after reti jumped from vm86_bioscall. Strangely, this panic can be recovered by continue command in DDB, FreeBSD continues its boot process after this. So, this panic problem is not serious for me :) OTOH, the same problem in boot program is very critical, completely stops with register dump... > > And it seems that today's Linux don't have 0x12 calling any more, > > so I didn't see any problem on the machines. > > > > Now I have some ideas on this issue; > > - 0x15/0xe820 call in getmemsize() to determine base mem size. (But how?) > > - 0x15/0xe820 call in locore.s before calling init386(). > > - specify the size by loader tunable (e.g. hw.basememsize). > > I would first fix all the broken code that doesn't check for errors > and see if the problem goes away. Then recover any low memory not > reported by int 0x12 in the int 0x15/0xe820 code in i386/machdep.c, > like libi386/biosmem.c does it (I think machdep.c intentionally skips > the low memory, while biosmem.c tries to find it). Cool. Thanks! Stopped at 0xf842: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xf842 fault code = supervisor read, page not present instruction pointer = 0x8:0xc03b5108 stack pointer = 0x10:0xc0a68e90 frame pointer = 0x10:0xc0a68e94 code segment= base 0x0,limit 0xf, type 0x1b = DPL 0, press 1, def32 1, gran 1 processor eflags= resume,IOPL = 0 current process = 0 () kernel:type 12 trap,code=0 db> t Fatal trap 12: page fault while in kernel mode To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCI brokenness
On 02-Oct-2002 Mark Murray wrote: > Hi > > I tried this patch, and it made some progress (dmesg included). The > ATA system still seems badly broken, there is a spurious mention of > some kerneldump. I also have no console. Hmm, ata0 may be getting the wrong resources. Hmm. Try iwasaki-san's patch to acpi_pcib_* instead and see if it that helps. Either that or turn off ACPI for the time being. > Perhaps the legacy stuff needs to be backed out or disabled pending fixing? Well, the problem here is that ACPI isn't working, not that legacy is broken. What legacy does is make it so that if we try to use ACPI, we actually rely on it to work. If we can't get ACPI to work like it is supposed to we need to either fix it or disable it for now. > M > > Copyright (c) 1992-2002 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 5.0-CURRENT #0: Wed Oct 2 12:15:40 BST 2002 > [EMAIL PROTECTED]:/usr/src/sys/i386/compile/LIBRETTO > Preloaded elf kernel "/boot/kernel/kernel" at 0xc04ce000. > Preloaded elf module "/boot/kernel/linux.ko" at 0xc04ce0a8. > Preloaded elf module "/boot/kernel/sysvshm.ko" at 0xc04ce154. > Preloaded elf module "/boot/kernel/sysvsem.ko" at 0xc04ce200. > Preloaded elf module "/boot/kernel/sysvmsg.ko" at 0xc04ce2ac. > Preloaded elf module "/boot/kernel/if_dc.ko" at 0xc04ce358. > Preloaded elf module "/boot/kernel/miibus.ko" at 0xc04ce404. > Preloaded elf module "/boot/kernel/if_wi.ko" at 0xc04ce4b0. > Preloaded elf module "/boot/kernel/snd_mss.ko" at 0xc04ce55c. > Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc04ce608. > Preloaded elf module "/boot/kernel/random.ko" at 0xc04ce6b4. > Preloaded elf module "/boot/kernel/atspeaker.ko" at 0xc04ce760. > Preloaded elf module "/boot/kernel/if_ep.ko" at 0xc04ce810. > Preloaded elf module "/boot/kernel/nfsserver.ko" at 0xc04ce8bc. > Preloaded elf module "/boot/kernel/nfsclient.ko" at 0xc04ce96c. > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04cea1c. > Timecounter "i8254" frequency 1193182 Hz > Timecounter "TSC" frequency 233289544 Hz > CPU: Pentium/P55C (quarter-micron) (233.29-MHz 586-class CPU) > Origin = "GenuineIntel" Id = 0x581 Stepping = 1 > Features=0x8001bf > real memory = 67174400 (65600K bytes) > avail memory = 60010496 (58604K bytes) > Intel Pentium detected, installing workaround for F00F bug > npx0: on motherboard > npx0: INT 16 interface > acpi0: on motherboard > acpi0: power button is handled as a fixed feature programming model. > Timecounter "ACPI-fast" frequency 3579545 Hz > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x18a8-0x18ab on acpi0 > acpi_cpu0: on acpi0 > acpi_tz0: on acpi0 > acpi_lid0: on acpi0 > acpi_acad0: on acpi0 > acpi_cmbat0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > atspeaker0 port 0x61 on acpi0 > atkbdc0: port 0x64,0x60 irq 1 on acpi0 > atkbd0: flags 0x1 irq 1 on atkbdc0 > kbd0 at atkbd0 > psm0: irq 12 on atkbdc0 > psm0: model IntelliMouse, device ID 3 > ata0 port 0x3f6,0x1f0-0x1f7 irq 14 on acpi0 > sio0 port 0x3f8-0x3ff irq 4 on acpi0 > sio0: type 16550A > ppc0: parallel port not found. > ppc0: parallel port not found. > Timecounters tick every 10.000 msec > Initializing GEOMetry subsystem > acpi_cpu: CPU throttling enabled, 16 steps from 100% to 6.2% > ad0: 19077MB [38760/16/63] at ata0-master BIOSPIO > Mounting root from ufs:/dev/ad0s2a > stray irq 7 > stray irq 7 > Kerneldump off=2239236096 len=134217728 > Kerneldump off=2239236096 len=134217728 > Waiting (max 60 seconds) for system process `vnlru' to stop...stopped > Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped > Waiting (max 60 seconds) for system process `syncer' to stop...stopped > > syncing disks... 2 2 2 1 1 > done > Uptime: 22s > Terminate ACPI > Rebooting... > >> On 01-Oct-2002 Mark Murray wrote: >> > Hi >> > >> > I'm running a kernel with your very latest nexus.c 1.49. >> > >> > The problem of the disappearing HD has not been fixed by this. >> > >> > Enclosed are verbose mesg's, one from a three-hour-ago >> > (1st Oct 2002, 11:00 am, BST) kernel (broken), and another >> > from a working Sept 22nd kernel. >> >> This is quite weird. You have a PCI bus and ACPI still finds >> it fine, it just doesn't probe/attach any child devices. Hmm, >> and your ATA controller isn't on the PCI bus. Ok, weird. Do >> you have hints for your ata device? It looks like you had >> hints for it in your good kernel boot since it was found on >> isa0. Hmm, can you try this patch: >> >> Index: ata-isa.c >> === >> RCS file: /usr/cvs/src/sys/dev/ata/ata-isa.c,v >> retrieving revision 1.9 >> diff -u -r1.9 ata-isa.c >> --- ata-isa.c 20 Sep 2002 18:08:57 - 1.9 >> +++ ata-isa.c 1 Oct 2002 14:26:39 - >> @@ -98,6 +98,7 @@ >> }; >> >> DRIVER_MODULE(ata, isa, ata_isa_drive
Re: Longer term fix for sigreturn ABI breaking
On Wed, 2 Oct 2002, Bruce Evans wrote: > On Mon, 30 Sep 2002, Daniel Eischen wrote: > > > - ret = set_fpcontext(td, &ucp->uc_mcontext); > > - if (ret != 0) > > - return (ret); > > + /* > > +* Intentionally ignore the error to keep binary > > +* compatibility with applications that fiddle with > > +* the FPU save area in the context. The kernel > > +* now saves the FPU state in the context, but it > > +* gets corrupted by those applications that try > > +* to work around the kernel NOT saving it. > > +*/ > > + (void)set_fpcontext(td, &ucp->uc_mcontext); > > bcopy(&ucp->uc_mcontext.mc_fs, regs, sizeof(*regs)); > > } > > > > ... > > I think this is a bit too simple. If set_fpcontext() fails then the > interrupted code may resume with a garbage FP context (most likely > whatever is in the PCB). Snipped parts of the patch back out the > temporary hack of forcing of the state to the PCB in sendsig(), so > the resumed FP context is quite like likely to be garbage. We could keep a copy of the original state (saved in sendsig) in the PCB and load it from the PCB if the state in the ucontext was deemed invalid. Either that or just mark the PCB as uninitialized so it would get a clean state. > I think not using the parts of the state that is corrupted by > applications would work better (basically the same as the temporary > hack, except it would waste time instead of space). The space > wastage would be approximately 28 * 4 bytes. This would be wasted > forever or until the struct is versioned better. I'm not sure this works because the 4.x version of libc_r copies the ucontext to save the state of an interrupted thread (signals are delivered on an alternate signal stack forcing the library to save the context so the signal stack can be reused). So a sigreturn() will give you a partially valid context. I think we need to either force a clean state or keep a copy of the state saved in the ucontext in the PCB as a backup. Or make a new sigaction and sigreturn. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCI brokenness
Hi I tried this patch, and it made some progress (dmesg included). The ATA system still seems badly broken, there is a spurious mention of some kerneldump. I also have no console. Perhaps the legacy stuff needs to be backed out or disabled pending fixing? M Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Wed Oct 2 12:15:40 BST 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/LIBRETTO Preloaded elf kernel "/boot/kernel/kernel" at 0xc04ce000. Preloaded elf module "/boot/kernel/linux.ko" at 0xc04ce0a8. Preloaded elf module "/boot/kernel/sysvshm.ko" at 0xc04ce154. Preloaded elf module "/boot/kernel/sysvsem.ko" at 0xc04ce200. Preloaded elf module "/boot/kernel/sysvmsg.ko" at 0xc04ce2ac. Preloaded elf module "/boot/kernel/if_dc.ko" at 0xc04ce358. Preloaded elf module "/boot/kernel/miibus.ko" at 0xc04ce404. Preloaded elf module "/boot/kernel/if_wi.ko" at 0xc04ce4b0. Preloaded elf module "/boot/kernel/snd_mss.ko" at 0xc04ce55c. Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc04ce608. Preloaded elf module "/boot/kernel/random.ko" at 0xc04ce6b4. Preloaded elf module "/boot/kernel/atspeaker.ko" at 0xc04ce760. Preloaded elf module "/boot/kernel/if_ep.ko" at 0xc04ce810. Preloaded elf module "/boot/kernel/nfsserver.ko" at 0xc04ce8bc. Preloaded elf module "/boot/kernel/nfsclient.ko" at 0xc04ce96c. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04cea1c. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 233289544 Hz CPU: Pentium/P55C (quarter-micron) (233.29-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x581 Stepping = 1 Features=0x8001bf real memory = 67174400 (65600K bytes) avail memory = 60010496 (58604K bytes) Intel Pentium detected, installing workaround for F00F bug npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <32-bit timer at 3.579545MHz> port 0x18a8-0x18ab on acpi0 acpi_cpu0: on acpi0 acpi_tz0: on acpi0 acpi_lid0: on acpi0 acpi_acad0: on acpi0 acpi_cmbat0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 atspeaker0 port 0x61 on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 ata0 port 0x3f6,0x1f0-0x1f7 irq 14 on acpi0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A ppc0: parallel port not found. ppc0: parallel port not found. Timecounters tick every 10.000 msec Initializing GEOMetry subsystem acpi_cpu: CPU throttling enabled, 16 steps from 100% to 6.2% ad0: 19077MB [38760/16/63] at ata0-master BIOSPIO Mounting root from ufs:/dev/ad0s2a stray irq 7 stray irq 7 Kerneldump off=2239236096 len=134217728 Kerneldump off=2239236096 len=134217728 Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks... 2 2 2 1 1 done Uptime: 22s Terminate ACPI Rebooting... > On 01-Oct-2002 Mark Murray wrote: > > Hi > > > > I'm running a kernel with your very latest nexus.c 1.49. > > > > The problem of the disappearing HD has not been fixed by this. > > > > Enclosed are verbose mesg's, one from a three-hour-ago > > (1st Oct 2002, 11:00 am, BST) kernel (broken), and another > > from a working Sept 22nd kernel. > > This is quite weird. You have a PCI bus and ACPI still finds > it fine, it just doesn't probe/attach any child devices. Hmm, > and your ATA controller isn't on the PCI bus. Ok, weird. Do > you have hints for your ata device? It looks like you had > hints for it in your good kernel boot since it was found on > isa0. Hmm, can you try this patch: > > Index: ata-isa.c > === > RCS file: /usr/cvs/src/sys/dev/ata/ata-isa.c,v > retrieving revision 1.9 > diff -u -r1.9 ata-isa.c > --- ata-isa.c 20 Sep 2002 18:08:57 - 1.9 > +++ ata-isa.c 1 Oct 2002 14:26:39 - > @@ -98,6 +98,7 @@ > }; > > DRIVER_MODULE(ata, isa, ata_isa_driver, ata_devclass, 0, 0); > +DRIVER_MODULE(ata, acpi, ata_isa_driver, ata_devclass, 0, 0); > > /* > * the following is a bandaid to get ISA only setups to link, > > -- > > John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Longer term fix for sigreturn ABI breaking
On Mon, 30 Sep 2002, Daniel Eischen wrote: > At the end is a potentially longer term fix for the ABI > breakage that was introduced when the i386 mcontext_t > was changed/enlarged. > > Someone other than I (Bruce?) should vet this. It should > solve the libc_r binary compatibility problem, but it may > not fix everything. Applications that copy ucontext_t's > around (without changing corrupting the mc_fpformat field) > will still break, but there may not be many (if any) of > those. > ... > Index: i386/i386/machdep.c > === > RCS file: /opt/d/CVS/src/sys/i386/i386/machdep.c,v > retrieving revision 1.539 > diff -u -r1.539 machdep.c > --- i386/i386/machdep.c 30 Sep 2002 07:02:22 - 1.539 > +++ i386/i386/machdep.c 30 Sep 2002 20:42:30 - > ... > @@ -754,9 +754,15 @@ > return (EINVAL); > } > > - ret = set_fpcontext(td, &ucp->uc_mcontext); > - if (ret != 0) > - return (ret); > + /* > + * Intentionally ignore the error to keep binary > + * compatibility with applications that fiddle with > + * the FPU save area in the context. The kernel > + * now saves the FPU state in the context, but it > + * gets corrupted by those applications that try > + * to work around the kernel NOT saving it. > + */ > + (void)set_fpcontext(td, &ucp->uc_mcontext); > bcopy(&ucp->uc_mcontext.mc_fs, regs, sizeof(*regs)); > } > > ... I think this is a bit too simple. If set_fpcontext() fails then the interrupted code may resume with a garbage FP context (most likely whatever is in the PCB). Snipped parts of the patch back out the temporary hack of forcing of the state to the PCB in sendsig(), so the resumed FP context is quite like likely to be garbage. I think not using the parts of the state that is corrupted by applications would work better (basically the same as the temporary hack, except it would waste time instead of space). The space wastage would be approximately 28 * 4 bytes. This would be wasted forever or until the struct is versioned better. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: expat2 in the base system?
On (2002/10/02 13:57), Marc Recht wrote: > IMO 1. would be better with a complete expat. So the ports could use > the system version and probably/maybe the drift between the official- > and system-version will not be that big. And compared to Perl expat it > rather small. So the bloat couldn't be that big.. What? Have you had much experience with the expat ports? I'm guessing that you're arguing a theoretical point. For a while, we had two versions in the ports tree, and some applications had conflicting version requirements that caused them to blow up horribly (e.g. mod_perl, PageKit). We're at a lucky moment in time, where there's only one version of expat in the ports tree. But think about what happens when there are two mainstream versions at large again. Please let's learn from past mistakes and give this library a completely separate name, perhaps with stripped down functionality. Then ports can still choose to use it instead of the expat2 port if it does the job for them, and we have our cake and eat it. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: expat2 in the base system?
> > 2. Under assumed name, "libxmlread" or something. This means that > > nothing which doesn't explicitly ask for it will get in touch with > > this version of libexpat, and that will only be the programs in > > the tree. We don't need to track the official libexpat (sort of > > like the DB(3) situation, except with better isolation I guess). > > This seems to be a nice idea. Can you trim down "our" version of expat > to only the libxmlread part or so? This way we don't get too much > bloat, the perl fiasco won't happen, and once we've got a working > version we can update only for bug fixes. IMO 1. would be better with a complete expat. So the ports could use the system version and probably/maybe the drift between the official- and system-version will not be that big. And compared to Perl expat it rather small. So the bloat couldn't be that big.. Marc msg43745/pgp0.pgp Description: PGP signature
Re: [PATCH] Workaround for bogus INT 12H BIOS service implementation
On Mon, 30 Sep 2002, Mitsuru IWASAKI wrote:
> > > Index: sys/i386/i386/machdep.c
> > > ===
> > > RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v
> > > retrieving revision 1.532
> > > diff -u -r1.532 machdep.c
> > > --- sys/i386/i386/machdep.c 7 Sep 2002 19:12:42 - 1.532
> > > +++ sys/i386/i386/machdep.c 29 Sep 2002 21:15:26 -
> > > @@ -1269,8 +1269,12 @@
> > > /*
> > >* Perform "base memory" related probes & setup
> > >*/
> > > - vm86_intcall(0x12, &vmf);
> > > - basemem = vmf.vmf_ax;
> > > + if (bootinfo.bi_basemem != 0) {
> > > + basemem = bootinfo.bi_basemem;
> > > + } else {
> > > + vm86_intcall(0x12, &vmf);
> > > + basemem = vmf.vmf_ax;
> > > + }
> > > if (basemem > 640) {
> > > printf("Preposterous BIOS basemem of %uK, truncating to 640K\n",
> > > basemem);
> >
> > The kernel hasn't used bootinfo.bi_basemem for a long time and shouldn't
> > start using it again now. It already uses the 0x15/0xe820 call for
> > everything except basemem (except when the this call fails, it falls
> > back to 0x15/0xe801). Maybe the bug has something to do with the
> > kernel using the 0x12 call without checking whether the call succeeded.
I checked that a kernel boots fine when int 0x12 returns 0. But there
would probably be problems if it returned a garbage value.
> > When both the 0x15/0xe820 and the 0x15/0xe801 calls fail, the kernel
> > falls back to an 0x15/0x88 call for determining extmem ... except this
> > is ifdefed out and replaced by looking at the rtc values. Maybe the
> > unreliability of the 0x15/0x88 call has something to do with not
> > checking if the call succeeded.
>
> Yes, I think the best way to determine base mem size in getmemsize()
> is to try 0x15/0xe820 call first, then fall back to 0x12 call. But
> I'm not sure whether it's OK to call vm86_datacall(0x15) before
> determining base mem size...
>
> > The patch makes no difference for booting directly from boot2 ... except
> > memsize() in boot2 also fails to check for errors, so it returns garbage
> > values.
>
> Yes I know that :-)
> But booting kernel directly from boot2 is not working at all for
> several years, so my understanding is that /boot/loader is necessary
> to boot kernel.
It mostly works. I submitted patches in a PR many years ago and still use
them.
> > I think the basemem == 0 case should just work, so the systems with a
> > broken INT 0x12 should at worst lose 640K of memory, no matter whether
> > basemem is set to 0 because INT 0x12 fails or because it actually
> > returns 0.
>
> Hmmm, actually no. I know that some machines get panic with fatal trap
> 12 if we do 0x12 call. The worst case is getting panic, not losing
> 640K memory.
Where does the panic occur? I checked that there is no problem here if
the result of INT 0x12 is ignored and basemem is set to 0.
> And it seems that today's Linux don't have 0x12 calling any more,
> so I didn't see any problem on the machines.
>
> Now I have some ideas on this issue;
> - 0x15/0xe820 call in getmemsize() to determine base mem size. (But how?)
> - 0x15/0xe820 call in locore.s before calling init386().
> - specify the size by loader tunable (e.g. hw.basememsize).
I would first fix all the broken code that doesn't check for errors
and see if the problem goes away. Then recover any low memory not
reported by int 0x12 in the int 0x15/0xe820 code in i386/machdep.c,
like libi386/biosmem.c does it (I think machdep.c intentionally skips
the low memory, while biosmem.c tries to find it).
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Profiling kld-modules
Hi, Is it possible to profile kld-modules using kgmon and gprof or any other combination of profiling tools? I've tried, and failed. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCI brokenness
On Tue, Oct 01, 2002 at 05:23:34PM -0400, John Baldwin wrote: > > On 01-Oct-2002 Michael McGoldrick wrote: > > On Tue, Oct 01, 2002 at 12:48:47PM -0400, John Baldwin wrote: > >> > >> On 01-Oct-2002 Michael McGoldrick wrote: > >> > 'Me too' > >> > Dmesg from working kernel attached, not sure how to get a dmesg from the > >> > broken one. :( > >> > Send me a mail if any further info would help. > >> > (I have built two kernels recently, both have had this problem) > >> > >> What exact problem do you have. No PCI devices? > >> > >> -- > >> > >> John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ > >> "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > >> > >> To Unsubscribe: send mail to [EMAIL PROTECTED] > >> with "unsubscribe freebsd-current" in the body of the message > > > > Yes, the kernel seems to attempt to mount root right after this line: > > device_probe_and_attach: acpi0 attach returned 6 > > Can you try with the stuff I committed yesterday? It fixed the case (for > my tests at least) of legacy0 failing to attach or probe when acpi failed > to attach. > > -- > > John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ I'm cvsupping now, will let you know in a few hours (barring random reboots) This does sound like it should cure my problem though. If it fails, I will give Mitsuru Iwasaki's acpi patch a try, however, this machine is not particularly quick and I won't be around for a few hours, so I will probably report this evening some time. -- Michael McGoldrick: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: expat2 in the base system?
Thus spake Poul-Henning Kamp ([EMAIL PROTECTED]): > 2. Under assumed name, "libxmlread" or something. This means that > nothing which doesn't explicitly ask for it will get in touch with > this version of libexpat, and that will only be the programs in > the tree. We don't need to track the official libexpat (sort of > like the DB(3) situation, except with better isolation I guess). This seems to be a nice idea. Can you trim down "our" version of expat to only the libxmlread part or so? This way we don't get too much bloat, the perl fiasco won't happen, and once we've got a working version we can update only for bug fixes. Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel boot messages absent
Thus spake John Baldwin ([EMAIL PROTECTED]): > > Can anyone explain me why with a recent kernel (last kernel was from > > 1 year ago) the kernel boot messages disappear from the monitor > > once the "propellor" of the kernel boot has done like 5 rounds > > (last message is the last line of the > > "Booting kernel in X seconds" line, followed by a single "-" on > > the line, which used to be the propellor) > You need to setup a /boot/device.hints file if you haven't already so > that the kernel can configure it's console device. Nah, that machine already had a device.hints installed. And also with an upgraded device.hints (GENERIC.hints copied from /sys/i386/conf) the same problem occurs. And I don't think I'd have to edit device.hints on common hardware, using a GENERIC kernel, do I? It used to work before :-( Any more tips? Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
alpha tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- ===> libexec/rpc.rstatd /h/des/src/libexec/rpc.rstatd/rstat_proc.c:87: conflicting types for `havedisk' /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include/rpcsvc/rstat.h:88: previous declaration of `havedisk' *** Error code 1 Stop in /h/des/src/libexec/rpc.rstatd. *** Error code 1 Stop in /h/des/src/libexec. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: expat2 in the base system?
> Rather than write another monster filled with weird structs and enums > I decided that ASCII is very extensible, and putting XML structure > on top of it meant that readily available libraries and tools could > work on it. Yes, it's IMHO the best way to do it. > And in fact, I have every reason to believe that it takes less code > in the kernel to construct XML with sbuf's than it takes to pack > everything in and out in a way which is properly versioned and all > that hair. > > So, I need an XML parser in the userland side of things. No, that it's there maybe other tools could (slowly) start using it. > (NB: XML flows from the kernel to userland, not the other way!) Maybe sometime.. :-) [...] > I've sent many emails to try to get peoples attention to this subject, > but nobody has really expressed much of an interest, but maybe now > that it is a more tangible issue that will change. I didn't see any message. After your commit, I made a quick glance through my archives current@, hackers@ and arch@ ... > I have not connected libexpat and xmlwf to the build yet, so nobody > will be screwed in any way until we do so. > > There are two ways this can be done, and I don't really have a > preference: > > 1. Under the name libexpat, in full flying colours. This means that > we are obligated to track the official libexpat rather closely > and ports will use the in-tree version instead of the ports version. I would go/vote for that. If it's expat then call it expat. Everything else is confusing.. [..] > Remembering the perl fiasco[*], I have tried for quite some time > to see if anybody had any good input on this, and nothing very > conclusional has emerged from any corner. In any ml? > I don't plan to commit the next stuff which depends on the existance > of this library this for another couple of weeks, so this is your > chance to test it out: Here is the patch which connects libexpat > in the tree in fashion 1 above. Hmm, with 5.0R in about six weeks wouldn't it be good to build and install the library asap ? > Let me know how much it breaks. We'll see. I've some stuff which depends on expat2 (python, apache2, ..) But: No risk - no fun. -:) Marc msg43738/pgp0.pgp Description: PGP signature
Re: HEADSUP! GEOM as default in 5 days...
In message <[EMAIL PROTECTED]>, Bruce Evans writes: >This could have been done without devfs by mapping names of special files >to numeric indexes in the kernel. Putting the index in the inode is mainly >an efficiency hack. Numeric indexes work quite well in the kernel (better >than pointers in the current implementation, since most drivers prefer to >work with numbers and call the inefficient replacements of the major() and >minor macros a lot). This is actually not true any more. An increasing number of drivers derive their softc pointer directly from the dev_t without the detour over compile-time-fixed-sized arrays of possible unit numbers. >> In the meantime, DEVFS is the best I could come up with which makes >> life simpler for users, developers and administrators, and still >> retains as many of the flaws as we want to keep. > >For me, it has saved about 10 minutes of admin time and cost a few >working weeks of development time so far. I don't think you are anywhere near the mean, or the median for that matter, of FreeBSD users. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: expat2 in the base system?
In message <[EMAIL PROTECTED]>, Marc Recht
writes:
>
>Hi!
>
>I just saw the import of expat 1.95.5 into the base system. And
>because expat2 is such a moving target I'm a little bit wondering
>why this did happen. Isn't it better to keep such a beast in the
>ports-tree?
>Or is there a major config-file to xml rewrite (or something
>similar) going on nobody told us users about? :-)
GEOM needs to be able to export a configuration to userland tools.
Since GEOM doesn't know what kind of configuration information
each GEOM method may have or want to share with userland, the
format used has to be generally extensible.
Rather than write another monster filled with weird structs and enums
I decided that ASCII is very extensible, and putting XML structure
on top of it meant that readily available libraries and tools could
work on it.
And in fact, I have every reason to believe that it takes less code
in the kernel to construct XML with sbuf's than it takes to pack
everything in and out in a way which is properly versioned and all
that hair.
So, I need an XML parser in the userland side of things.
(NB: XML flows from the kernel to userland, not the other way!)
I've sent many emails to try to get peoples attention to this subject,
but nobody has really expressed much of an interest, but maybe now
that it is a more tangible issue that will change.
I have not connected libexpat and xmlwf to the build yet, so nobody
will be screwed in any way until we do so.
There are two ways this can be done, and I don't really have a
preference:
1. Under the name libexpat, in full flying colours. This means that
we are obligated to track the official libexpat rather closely
and ports will use the in-tree version instead of the ports version.
2. Under assumed name, "libxmlread" or something. This means that
nothing which doesn't explicitly ask for it will get in touch with
this version of libexpat, and that will only be the programs in
the tree. We don't need to track the official libexpat (sort of
like the DB(3) situation, except with better isolation I guess).
(similar for the include file of course)
Remembering the perl fiasco[*], I have tried for quite some time
to see if anybody had any good input on this, and nothing very
conclusional has emerged from any corner.
I don't plan to commit the next stuff which depends on the existance
of this library this for another couple of weeks, so this is your
chance to test it out: Here is the patch which connects libexpat
in the tree in fashion 1 above.
Let me know how much it breaks.
Poul-Henning
Index: lib/Makefile
===
RCS file: /home/ncvs/src/lib/Makefile,v
retrieving revision 1.144
diff -u -r1.144 Makefile
--- lib/Makefile19 Sep 2002 08:06:23 - 1.144
+++ lib/Makefile2 Oct 2002 08:30:46 -
@@ -25,7 +25,7 @@
libncurses libradius librpcsvc libsbuf libtacplus libutil libypclnt \
${_compat} libalias libatm ${_libbind} libbz2 libc ${_libc_r} \
libcalendar libcam libcompat libdevinfo libdevstat libdisk \
- libedit libfetch libform libftpio ${_libio} libipsec \
+ libedit libexpat libfetch libform libftpio ${_libio} libipsec \
libipx libisc libmenu ${_libmilter} ${_libmp} ${_libncp} \
libnetgraph libopie libpam libpanel libpcap \
${_libsm} ${_libsmb} ${_libsmdb} ${_libsmutil} \
Index: usr.bin/Makefile
===
RCS file: /home/ncvs/src/usr.bin/Makefile,v
retrieving revision 1.221
diff -u -r1.221 Makefile
--- usr.bin/Makefile17 Sep 2002 01:48:59 - 1.221
+++ usr.bin/Makefile2 Oct 2002 08:31:01 -
@@ -196,6 +196,7 @@
write \
xargs \
xinstall \
+ xmlwf \
xstr \
yacc \
yes \
[*] Don't ask "which one ?", it should be obvious from context :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
vnode lock assertion failure in nfs_doio()
Version 1.114 of nfs_bio.c added a call to ASSERT_VOP_LOCKED() to nfs_doio(). I've been running a kernel with the DEBUG_VFS_LOCKS option and I can consistently get this assertion to fail by running mozilla with an nfs mounted home directory. The DDB stack trace indicates this assertion fails when nfs_doio() is called from nfssvc_iod(), which is used by the nfsiod. I tried wrapping the bracketing calls to nfs_doio() in nfssvc_iod() with calls to vn_lock() and VOP_UNLOCK(), but I then get what appears to be an interruptable deadlock ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP! GEOM as default in 5 days...
On Wed, 2 Oct 2002, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Bruce Evans writes:
> >I don't really like MAKEDEV. It is creating work and bugs by moving
> >problems around that I object to.
>
> So you don't like DEVFS and you don't like MAKEDEV.
>
> Say, how _do_ you access your devices Bruce ? :-)
Mostly using read() and write() :-).
To create them I normally use tar or cp -pR to copy them from another
machine (nfs mounted for cp). Yes, major/minor numbers have their
weakest points near tar and nfs, but this causes few problems in
practice. To create the original versions I must have used mknod(8)
or MAKEDEV some time, but I only use these about once a month. Preserving
timestamps has given some amazingly old files (much older than the
disk they are on :-):
$ ls -ltr /dev
total 44
crw--- 1 root wheel 7, 0 Sep 14 1991 klog
crw-rw 2 root operator 14, 2 May 5 1993 esa0.0
...
crw-rw-rw- 1 root wheel 6, 10 Jun 11 1994 ptypa
...
crw-rw-rw- 1 root wheel 5, 10 Jun 11 1994 ttypa
klog is so old that it must have have a corrupt time stamp or have been
copied from a 386BSD distribution -- 386BSD wasn't released until early
1992 IIRC and I didn't get it until a few months later. Apparently,
Julian's scsi drivers were committed by May 5 1993. ttypa may be the
worlds oldest pty. I think it actually hasn't been touched since then.
Some of the other devices (not shown) are old because modtime timestamps
don't work right on them.
Ob devfs complaint: timestamps don't work right on devfs either. After
booting, ls -lt /dev and some periodic scripts report timestamps in
the future because devfs doesn't understand changing the time as
specified by /etc/wall_cmos_clock. This bug is more apparent to users
in timezones ahead of GMT.
> As various people have heard me whine about at conferences for some years
> now, devices were the first thing that broke the "UNIX filesystem model".
>
> Manually hacking a numeric index from a kernel table into filesystem
> nodes is just plain wrong, it is however better than what they did before
> where they hardwired inode numbers to devices.
This could have been done without devfs by mapping names of special files
to numeric indexes in the kernel. Putting the index in the inode is mainly
an efficiency hack. Numeric indexes work quite well in the kernel (better
than pointers in the current implementation, since most drivers prefer to
work with numbers and call the inefficient replacements of the major() and
minor macros a lot).
> The next big mistake was networking. The "unix filesystem model"
> would have me open("/net/tcp/www.freebsd.org/80", "r"), not
> socket(...), bind(...), connect(...).
I could agree with that.
> I'll just silently (well, not quite) pass on the sysV IPC fiasco.
The next+N mistake was sysctl, which started with numeric indexes and
which you improved to support strings. The indexes are worse than for
device nodes because they are layered. Supporting and using both of
these gave a fine unfinished mess, with complications for both and
efficiency for neither.
> In the meantime, DEVFS is the best I could come up with which makes
> life simpler for users, developers and administrators, and still
> retains as many of the flaws as we want to keep.
For me, it has saved about 10 minutes of admin time and cost a few
working weeks of development time so far.
> Like it or not, unless you have a better alternative you'll be stuck
> with it.
If it were the only alternative, then I would move somewhere that
doesn't have it :-).
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
expat2 in the base system?
Hi! I just saw the import of expat 1.95.5 into the base system. And because expat2 is such a moving target I'm a little bit wondering why this did happen. Isn't it better to keep such a beast in the ports-tree? Or is there a major config-file to xml rewrite (or something similar) going on nobody told us users about? :-) I'm a little bit confused and excited at the moment.. :-) Marc msg43733/pgp0.pgp Description: PGP signature
Re: could sleep with messages
Rasmus Skaarup (mfbsd) writes: > > > I've been getting the following messages for quite some time, during > boot and when using the pcm device: > > ... > /usr/src/sys/vm/uma_core.c:1307: could sleep with "pcm0:play:0" locked [...] > ... > > Is anyone interesting in getting more details? > This is a well known problem. It is basically a diagnostic message telling you that there's a deficiency in the pcm driver. If you want to fix it permanently I suggest that you go and have a look at dev/sound/pcm/sound.c:134 and look for a way of invoking UMA without holding the lock. A possible workaround, is to try and disable INVARIANTS and WITNESS in the your kernel conf. and hope it won't turn into a real problem (fx. panic.) -- Best Regards, Michael Landin Hostbaek FreeBSDCluster.org - an International Community */ PGP-key available upon request /* To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: zombies from linux binaries
On 01-Oct-2002 Lars Eggert wrote: > Duncan Barclay wrote: >> On 01-Oct-2002 Lars Eggert wrote: >>> >>>I've been running the guidescope web ad blocker >>>(http://www.guidescope.com/home/) as a Linux binary under FreeBSD for a >>>long time. The thing seems to fork a child for each web request it proxies. >>> >>>Under -current, it seems that the child processes become zombies, and >>>the proxy stops working once 1024 or so accumulate. The zombies don't go >>>away when parent process finishes, they stick around until reboot. >> >> Is this http://www.freebsd.org/cgi/query-pr.cgi?pr=42457 related? It >> is for stable but I belive that the same behaviour is present in -current >> and it may manifest itself differently. > > Don't know - I know the symptom, but haven't looked into finding the > cause; guidescope is closed source. So is matlab that I tracked it down with. I used ktrace and linux_kdump from ports to watch the thread creation and destruction. It took an evening. > Lars > -- > Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute -- Duncan Barclay | God smiles upon the little children, [EMAIL PROTECTED] | the alcoholics, and the permanently stoned. [EMAIL PROTECTED]| Steven King To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PCI brokenness
> On Tue, 1 Oct 2002, Mark Murray wrote: > > I'm running a kernel with your very latest nexus.c 1.49. > > > > The problem of the disappearing HD has not been fixed by this. > > > > Enclosed are verbose mesg's, one from a three-hour-ago > > (1st Oct 2002, 11:00 am, BST) kernel (broken), and another > > from a working Sept 22nd kernel. > > I noticed both of yours and the other "me too" reply indicated ACPI was in > use. Is the behavior different when acpi is disabled? Yeah. Booting fails completely. Hard hang after probing the parallel port. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
