Re: ioctl(CAMGETPASSTHRU) hung X11/cda process
On Wed, 11 Dec 2002, Kenneth D. Merry wrote:
On Wed, Dec 11, 2002 at 11:37:42 -0800, Nate Lawson wrote:
On Tue, 10 Dec 2002, Lamont Granquist wrote:
# ps xauww | egrep cda
root 36761 0.0 0.3 1884 1452 p4 D 7:25PM 0:00.01
/usr/X11R6/lib/X11/xmcd/bin-FreeBSD_5-i386/cda -batch -dev /dev/cd0 on
# strace -p 36761
ioctl(0, CAMGETPASSTHRU
(...hangs forever and won't die with kill -9...)
ps axl output for that proc, please.
It's probably hanging waiting for a CCB, although ps axl output should tell
us whether or not that's the case.
If that is the case, it raises the why question, especially since nothing
has changed in that area recently that I know of.
i panic'd the system and got this for a bt on the process:
(kgdb) bt
#0 mi_switch () at /usr/src/sys/kern/kern_synch.c:522
#1 0xc02f2027 in msleep (ident=0xc41fc0b8, mtx=0x0, priority=76,
wmesg=0x0,
timo=0) at /usr/src/sys/kern/kern_synch.c:262
#2 0xc0140ffc in cam_periph_getccb (periph=0xc41fc080, priority=1)
at /usr/src/sys/cam/cam_periph.c:748
#3 0xc01410a5 in cam_periph_ioctl (periph=0x0, cmd=-1033890813, addr=0x0,
error_routine=0xc01574f0 passerror) at
/usr/src/sys/cam/cam_periph.c:784
#4 0xc01573b8 in passioctl (dev=0x0, cmd=0, addr=0xc41f2800 , flag=3,
td=0xc42fdc40) at /usr/src/sys/cam/scsi/scsi_pass.c:533
#5 0xc02b45ee in spec_ioctl (ap=0xc41f2800)
at /usr/src/sys/fs/specfs/spec_vnops.c:352
#6 0xc02b3d18 in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:126
#7 0xc034ae91 in vn_ioctl (fp=0xc4340f3c, com=3261076483,
data=0xc41f2800,
active_cred=0xc5eb9100, td=0xc42fdc40) at vnode_if.h:488
#8 0xc0310686 in ioctl (td=0xc42fdc40, uap=0xdacb0d10) at file.h:227
#9 0xc046cc7e in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077942432, tf_esi =
134979584, tf_ebp = -1077942408, tf_isp = -624226956, tf_ebx = 672215480,
tf_edx = 0, tf_ecx = 0, tf_eax = 54, tf_trapno = 12, tf_err = 2, tf_eip =
672506643, tf_cs = 31, tf_eflags = 582, tf_esp = -1077943092, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1033
#10 0xc045cd2d in Xint0x80_syscall () at {standard input}:140
Cannot access memory at address 0xbfbfe778
(kgdb)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Upgrade of port audio/id3lib - stdc++ wchar support missing
David O'Brien wrote: On Thu, Dec 12, 2002 at 12:33:18AM +0100, Jens Rehsack wrote: This would pull files off the vendor branch; and before doing that I'd like to know why the GCC developers have commented out those bits. ... But 4.7-STABLE has already support for wchar_t and it works fine So? I want to know why the GCC developers commented out those bits in GCC 3.2.1. I don't care about GCC 2.95 in RELNEG_4. I know that the id3v2 need wchar_t support. That's why I asked for a patch for FreeBSD 5.0-CURRENT which is sent by Tim Robbins. I do not know what exactly is included in 4.7 or in 5.0 but I know that id3v2 and id3lib build fine in 4.7 but didn't in 5.0. I thought it was more or less important because of Greg Lehey PR 9 (ports) which has serverity critical. Maybe you can ask Tim who created the patch why he did it that way. - BEGIN console extract - portupgrade -f id3lib id3v2 [...] Stop in /usr/ports/audio/id3v2. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade542.2 make ** Fix the problem and try again. ** The following packages were not installed or upgraded (*:skipped / !:failed) ! audio/id3lib38 (id3lib-3.8.1) (linker error) ! audio/id3v2 (id3v2-0.1.7) (linker error) - END console extract - Bye Jens -- L i W W W i Jens Rehsack LW W W L i W W W W i nnnLiWing IT-Services L iW W W Wi n n g g i W W i n n g gFriesenstraße 2 06112 Halle g g g Tel.: +49 - 3 45 - 5 17 05 91ggg e-Mail: [EMAIL PROTECTED] Fax: +49 - 3 45 - 5 17 05 92http://www.liwing.de/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
another crash in series
Hi
I see it's been discussed in the -current list.. This is with kernel
and sources from Dec 9 09:09 GMT. Happens _only_ after leaving KDE
and shutting down X. Considering the fact that I'm starting and
shutting down X/KDE once a day (startx), it's quite easy to
reproduce. Kernel and vmcore available on request.
Script started on Thu Dec 12 10:24:27 2002
bash-2.05b# gdb -k /sys/i386/compile/Myhakas-5.0-SMP/kernel.debug vmcore.5
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: bwrite: buffer is not busy???
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id = 0100
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0242508
stack pointer = 0x10:0xd68b6c20
frame pointer = 0x10:0xd68b6c58
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 = 13 (swi6: tty:sio clock)
trap number = 12
panic: page fault
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
syncing disks, buffers remaining... panic: bwrite: buffer is not busy???
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
Uptime: 2d5h21m2s
Dumping 511 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496
---
#0 doadump () at ../../../kern/kern_shutdown.c:232
232 dumping++;
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:232
#1 0xc023f4fa in boot (howto=260) at ../../../kern/kern_shutdown.c:364
#2 0xc023f7b7 in panic () at ../../../kern/kern_shutdown.c:517
#3 0xc0289582 in bwrite (bp=0xce5d3278) at ../../../kern/vfs_bio.c:796
#4 0xc028ac76 in vfs_bio_awrite (bp=0xce5d3278)
at ../../../kern/vfs_bio.c:1643
#5 0xc035073a in ffs_fsync (ap=0xd68b6a20) at ../../../ufs/ffs/ffs_vnops.c:258
#6 0xc034f919 in ffs_sync (mp=0xc41b1a00, waitfor=2, cred=0xc1514e80,
td=0xc0440100) at vnode_if.h:612
#7 0xc029e83b in sync (td=0xc0440100, uap=0x0)
at ../../../kern/vfs_syscalls.c:138
#8 0xc023f0db in boot (howto=256) at ../../../kern/kern_shutdown.c:273
#9 0xc023f7b7 in panic () at ../../../kern/kern_shutdown.c:517
#10 0xc03bef92 in trap_fatal (frame=0xd68b6be0, eva=0)
at ../../../i386/i386/trap.c:844
#11 0xc03bec42 in trap_pfault (frame=0xd68b6be0, usermode=0, eva=0)
at ../../../i386/i386/trap.c:758
#12 0xc03be732 in trap (frame=
{tf_fs = -1071579112, tf_es = -1001914352, tf_ds = -695533552, tf_edi =
-64200, tf_esi = 1, tf_ebp = -695505832, tf_isp = -695505908, tf_ebx = 0, tf_edx =
0, tf_ecx = 8192, tf_eax = 8192, tf_trapno = 12, tf_err = 0, tf_eip = -1071373048,
tf_cs = 8, tf_eflags = 66054, tf_esp = -63956, tf_ss = 134217742})
at ../../../i386/i386/trap.c:445
#13 0xc03a7378 in calltrap () at {standard input}:99
#14 0xc024df9c in realitexpire (arg=0xc465c1d8)
at ../../../kern/kern_time.c:544
#15 0xc024e5f5 in softclock (dummy=0x0) at ../../../kern/kern_timeout.c:195
#16 0xc022ca94 in ithread_loop (arg=0xc1516600)
at ../../../kern/kern_intr.c:535
#17 0xc022b954 in fork_exit (callout=0xc022c8c0 ithread_loop, arg=0x0,
frame=0x0) at ../../../kern/kern_fork.c:866
(kgdb) quit
bash-2.05b# exit
exit
Script done on Thu Dec 12 10:24:41 2002
--
Vallo Kallaste
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
UMA panic under load
I got this on an alpha tonight. It was under heavy load at the time (18 simultaneous package builds had just been spawned on the machine). Any ideas? Slab at 0xfc00042d3fb8, freei 2 = 0. panic: Duplicate free of item 0xfc00042d22e0 from zone 0xfc0007d31800(VMSPACE) db_print_backtrace() at db_print_backtrace+0x18 panic() at panic+0x104 uma_dbg_free() at uma_dbg_free+0x170 uma_zfree_arg() at uma_zfree_arg+0x150 vmspace_free() at vmspace_free+0xe4 swapout_procs() at swapout_procs+0x428 vm_daemon() at vm_daemon+0x74 fork_exit() at fork_exit+0xe0 exception_return() at exception_return --- root of call graph --- panic Stopped at Debugger+0x34: zapnot v0,#0xf,v0 v0=0x0 db Kris msg48592/pgp0.pgp Description: PGP signature
Re: RC NG, ntp and routed
Mike Makonnen wrote: I still don't see how having the routing daemon start before the network interfaces come up helps you. The correct order seems to me: local filesystem, network, routing, remote filesystem. Am I missing something here? That what it looks like from where I'm sitting too. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] The great nations have always acted like gangsters and the small nations like prostitutes. -- Stanley Kubrick To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RC NG, ntp and routed
Mike Makonnen wrote: On Wed, Dec 11, 2002 at 03:28:12PM -0200, Daniel C. Sobral wrote: [root@piratinga root]# ls -l /usr/local/sbin/ospfd -r-xr-xr-x 1 root wheel 471392 Dec 1 00:58 /usr/local/sbin/ospfd* [root@piratinga root]# ls -l /usr/local/sbin/bgpd -r-xr-xr-x 1 root wheel 691952 Dec 1 00:58 /usr/local/sbin/bgpd* Who said anything about moving ports into /? I meant the routing daemons in /usr/sbin. But as Gordon pointed out that's still quite a bit of disk space. I mean that routed is _one_ routing daemon, one that supports the old, would someone please shot it in the head to give it peace, RIP. If you happen to run a modern routing protocol... hell, if you happen to run a middle-aged routing protocol, you'll be using something else. And, since you do not seem to be aware of it, Zebra, for one, is run as... router_enable=YES router=/usr/local/sbin/zebractl router_flags=start ie, it is run by /etc/rc.d/routed. A very good thing, in fact, since one _needs_ it to be run early. So, please, let's not assume one is using routed(8), just like we do not assume one is using sendmail(8). And all this because... people don't want to break fs mounting in local and remote? I saw break it, and have routing run after local. If your /usr is remote, then either you'll copy routed (or whatever you use) to a local disk, or you won't be using it. People, let's face it. There *ARE* things you want to be run *after* local fs mount and *before* remote fs mount. And we are hurting ourselves in a few places just because we haven't admitted to it. I don't understand what you are saying. Why would we have routing run after local filesystems are mounted but before the network is up? Not before network is up. Before one mounts remote filesystems. Network is _not_ up until routing is in place. For most configurations, that is done in network2 (see defaultrouter). For a few, it needs routed. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] HOW YOU CAN TELL THAT IT'S GOING TO BE A ROTTEN DAY: #32: You call your answering service and they've never heard of you. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RC NG, ntp and routed
Doug Barton wrote: On Wed, 11 Dec 2002, Mike Makonnen wrote: I don't understand what you are saying. Why would we have routing run after local filesystems are mounted but before the network is up? What if /usr/local is an nfs-mounted partition (like it is on my systems, both at home and work)? As for that, I already answered. If you have /usr/local nfs-mounted, one of the following two things are happening: 1) You do not use a dynamic router in that host. 2) You use a dynamic router that is not resident in /usr/local, either by design (you use /usr/sbin/routed), or because you moved it from /usr/local to a locally-mounted fs. Let's try to put that in another perspective. Let's consider two possibilities: 1) You use routed_enable=NO. In that case, nothing will change for you, except locally mounted fs becoming available a bit earlier. 2) You use routed_enable=YES. This we subdivide in: 2.1) You need a router to mount remote fs. For this case, it follows that your router, whatever it is, is _not_ located in the remote fs. 2.2) You do not need a router to mount remote fs. Either because all remote fs are directly connected (ie, on one of the networks you belong to), or because you have a static route to each of them. This case might or might not present you with a problem. If you use a router which is located on a remote fs, then, indeed, the proposed ordering will cause you trouble. I argue, though, that this configuration is intrinsically wrong, because it depends on a particularity if your topology (the fact that the remote filesystems do not need the dynamic router, but normal operation does). Now... to me things seem simple. You can mount local fs very early, so there shouldn't be any trouble having them before network. And if you have them before network, there shouldn't be any problem having routed about network2, where it should logically belong. Am I missing something here? -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Nature makes boys and girls lovely to look upon so they can be tolerated until they acquire some sense. -- William Phelps To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RC NG, ntp and routed
At 5:41 PM -0800 2002/12/11, Tim Kientzle wrote: The point of the barrier scripts is to provide simple dependencies to other scripts. In particular, NETWORKING should represent a fully-functional network, including any routing or multicast routing that is normally used on this network. It does not, in itself, depend on any filesystems. (It runs no programs itself, so why would it?) Sure it does. In order to do anything, you have to run programs -- right? And where do those programs come from -- a filesystem, right? And what if that filesystem is not local, but mounted via NFS? So, you need a way to bootstrap the early parts of networking before mounting the later filesystems. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: sysctl -a loops forever...
From: Sean Chittenden [mailto:[EMAIL PROTECTED]] Anyone seen sysctl -a loop forever? I haven't been able to track down the MIB that it's gettinng hung up on, but it looks like there's a flaw in the algo that is walking through the MIBs. Given that this halts the machine while trying to collect entropy (sysctl -a is used to help feed /dev/random) at system start up, I think it's something worth addressing or pointing out. -sc I've observed this when e.g. I had too many nmbclusters configured, ie when vm.kvm_free was too low (0 in my case :) --don ([EMAIL PROTECTED] www.sandvine.com) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ACPI and PS/2 mouse trouble
I have some problem whith PS/2 mouse under -CURRENT (last cvsup was at 7 Dec 2002) When i enable ACPI in bios my mouse not works properly, cursor moves not adequate for mouse moving. When i disable ACPI - all works fine. In both cases i use moused -t ps/2 -p /dev/psm0 One more, when mouse works (without ACPI), vmstat -i shows psm0 irq12953 0 But without ACPI this line in vmstat -i is not present - looks like some problem with interrupt for mouse. What i can do with that? -- Vitaly Markitantov mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sysinstall and serial consoles
I meant sysinstall generating cons25 output. But there were recently a lot of terminfo changes that may have caused this. Oh. sysinstall asked if I wanted ANSI, vt100, cons25, something else related to FreeBSD console, or xterm. Most of those options were wrong, which is the bug that I think I'm trying to report. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: if_fxp and pause packets (or, I didn't need the network any
On 12-Dec-2002 Nate Lawson wrote: On Wed, 11 Dec 2002, Robert Watson wrote: I'm having a recurring problem on a number of machines wherein the fxp interfaces on those machines will spew out pause packets in vast quantities while the system is in ddb, or following a shutdown. I've noticed this too with fxp. It only happens while in ddb and I thought it was my fault (I was debugging some networking problems). I had this happen over a year ago on a machine at WRS. It completely wiped out an entire lan singlehandedly when it panic'd. :-/ -- 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: UMA panic under load
On 12-Dec-2002 Kris Kennaway wrote: I got this on an alpha tonight. It was under heavy load at the time (18 simultaneous package builds had just been spawned on the machine). Any ideas? Slab at 0xfc00042d3fb8, freei 2 = 0. panic: Duplicate free of item 0xfc00042d22e0 from zone 0xfc0007d31800(VMSPACE) db_print_backtrace() at db_print_backtrace+0x18 panic() at panic+0x104 uma_dbg_free() at uma_dbg_free+0x170 uma_zfree_arg() at uma_zfree_arg+0x150 vmspace_free() at vmspace_free+0xe4 swapout_procs() at swapout_procs+0x428 vm_daemon() at vm_daemon+0x74 fork_exit() at fork_exit+0xe0 exception_return() at exception_return --- root of call graph --- panic Stopped at Debugger+0x34: zapnot v0,#0xf,v0 v0=0x0 db I have seen this on a couple of different arch's I think. A vmspace shouldn't be free'd here, it's refcount should not be that low. I wonder if something is free'ing the vmspace w/o dropping the refcount? -- 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: if_fxp and pause packets (or, I didn't need the network anyway)
On Wed, 11 Dec 2002 23:09:46 -0800 (PST), Nate Lawson [EMAIL PROTECTED] said: I've noticed this too with fxp. It only happens while in ddb and I thought it was my fault (I was debugging some networking problems). It happens when the NIC's receive queue fills up. When you're in DDB, the kernel is not answering network interrupts. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Cardbus/dc(4) still broken
Hi My Netgear FA510 card is still not working. If I boot with the card in a cardbus slot, I get the below: Product version: 5.0 Product name: NETGEAR | FA510 | Fast Ethernet CardBus Card | 1.00 | Manufacturer ID: 13958100 Functions: Network Adaptor, Multi-Functioned Function Extension: 0102 Function Extension: 0280969800 Function Extension: 0200e1f505 Function Extension: 0301 CIS reading done cardbus1: Resource not specified in CIS: id=14, size=400 dc0: Intel 21143 10/100BaseTX port 0x1000-0x107f mem 0x88002400-0x880027ff irq 5 at device 0.0 on cardbus1 dc0: Ethernet address: 00:10:7a:15:ec:60 miibus0: MII bus on dc0 dcphy0: Intel 21143 NWAY media interface on miibus0 dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto The card/interface is pingable if I manually give it an IP, but it never seet the wire (no carrier). There _are_ lights on on the dongle, but nothing changes if I pull out the cable (except the lights go out). If I insert the card after boot, I get an identical (non-)result, with the exception that the MAC address is ff:ff:ff:ff:ff:ff, and if I remove/insert more than about three times, the machine will hard-hang (only way out is reset). M -- Mark Murray Beware! I'm umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RC NG, ntp and routed
Brad Knowles wrote: At 5:41 PM -0800 2002/12/11, Tim Kientzle wrote: The point of the barrier scripts is to provide simple dependencies to other scripts. In particular, NETWORKING should represent a fully-functional network, including any routing or multicast routing that is normally used on this network. It does not, in itself, depend on any filesystems. (It runs no programs itself, so why would it?) Sure it does. In order to do anything, you have to run programs -- right? And where do those programs come from -- a filesystem, right? And what if that filesystem is not local, but mounted via NFS? So, you need a way to bootstrap the early parts of networking before mounting the later filesystems. This I disagree with. Networking should bring the network up. If something is necessary to bring the network up, it should be available locally. Remote filesystems should come _after_ the network is up. If a program needed to bring networking up is on a remote fs, then there is a problem with the system project. If it so happens to work without a fully functional network, good for it, but it's designer must shoulder the burden of supporting it. The standard way of doing things should be get the network up, and _then_ mounting the remote fs. Daemons which _depend_ on network are not part of networking, of course. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] A day without orange juice is like a day without orange juice. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
DP2: ar / sysinstall fdisk trouble / GEOM?
Hi, In order to debug a minor problem with the ar-driver, I installed DP2 on an Abit KR7A-RAID with HighPoint ATA-RAID controller. The machine contains two identical 40GB IBM drives as masters on each of the two HighPoint IDE channels. The issue I ran into was that the partition editor in sysinstall does not work correctly. While it correctly displays the existing disk partitioning scheme, it insists on reporting an incorrect drive geometry of 0/255/63. Trying to delete slices does not work and causes sysinstall to go unresponsive. Manually overriding geometry to the correct value of 7476/255/63 (as determined by FreeBSD 4.6) did not help. I could not find a way to make the partition editor work right. In the end I worked around the problem by using a 4.6 disk to do the partitioning. Labeling and the rest of the installation process were done with DP2 and worked like a charm. (GEOM and RCng kick ass!) Once installed and booted into DP2, I checked /stand/sysinstall again, with the exact same results. Executing /sbin/fdisk however does report the correct geometry which leads me to believe that the problem is sysinstall-specific. Attached are dmesg, fdisk output. The machine is available for remote root login over SSH. Any suggestions? -J - [sysinstall partition editor] - Disk name: ar0FDISK Partition Editor DISK Geometry: 0 cyls/255 heads/63 sectors = 0 sectors (0MB) Offset Size(ST)End Name PType Desc Subtype Flags 0 63 62- 12 unused0 63 120101877 120101939ar0s1 8freebsd 165 120101940 1259 120103198- 12 unused0 The following commands are supported (in upper or lower case): A = Use Entire Disk G = set Drive Geometry C = Create Slice F = `DD' mode D = Delete Slice Z = Toggle Size UnitsS = Set Bootable | = Wizard m. T = Change Type U = Undo All Changes W = Write Changes Use F1 or ? to get more help, arrow keys to select. - [ fdisk output ] - # fdisk *** Working on device /dev/ar0 *** parameters extracted from in-core disklabel are: cylinders=7476 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=7476 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 120101877 (58643 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 2 is: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED # - [ dmesg (verbose) ] - Dec 12 12:39:49 syslogd: kernel boot file is /boot/kernel/kernel Dec 12 12:39:49 kernel: Copyright (c) 1992-2002 The FreeBSD Project. Dec 12 12:39:49 kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Dec 12 12:39:49 kernel: The Regents of the University of California. All rights reserved. Dec 12 12:39:49 kernel: FreeBSD 5.0-DP2 #1: Sat Nov 16 13:38:33 GMT 2002 Dec 12 12:39:49 kernel: [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Dec 12 12:39:49 kernel: Preloaded elf kernel /boot/kernel/kernel at 0xc0679000. Dec 12 12:39:49 kernel: Preloaded elf module /boot/kernel/acpi.ko at 0xc06790b4. Dec 12 12:39:49 kernel: Calibrating clock(s) ... TSC clock: 1534133428 Hz, i8254 clock: 1193301 Hz Dec 12 12:39:49 kernel: CLK_USE_I8254_CALIBRATION not specified - using default frequency Dec 12 12:39:49 kernel: Timecounter i8254 frequency 1193182 Hz Dec 12 12:39:49 kernel: CLK_USE_TSC_CALIBRATION not specified - using old calibration method Dec 12 12:39:49 kernel: Timecounter TSC frequency 1533986470 Hz Dec 12 12:39:49 kernel: CPU: AMD Athlon(tm) XP 1800+ (1533.99-MHz 686-class CPU) Dec 12 12:39:49 kernel: Origin = AuthenticAMD Id = 0x662 Stepping = 2 Dec 12 12:39:49 kernel: Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE, MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE Dec 12 12:39:49 kernel: AMD Features=0xc048MP,AMIE,DSP,3DNow! Dec 12 12:39:49 kernel: Data TLB: 32 entries, fully associative Dec 12 12:39:49 kernel: Instruction TLB: 16 entries, fully associative Dec 12 12:39:49 kernel: L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative Dec 12 12:39:49 kernel: L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative Dec 12 12:39:49 kernel: L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative Dec 12 12:39:49 kernel: real memory = 536805376 (511 MB) Dec 12 12:39:49 kernel: Physical memory chunk(s): Dec 12
Re: Cardbus/dc(4) still broken
Yup. Known problem with some cards. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: if_fxp and pause packets (or, I didn't need the network anyway)
On Thu, Dec 12, 2002 at 12:04:13PM -0500, Garrett Wollman wrote: On Wed, 11 Dec 2002 23:09:46 -0800 (PST), Nate Lawson [EMAIL PROTECTED] said: I've noticed this too with fxp. It only happens while in ddb and I thought it was my fault (I was debugging some networking problems). It happens when the NIC's receive queue fills up. When you're in DDB, the kernel is not answering network interrupts. One of my machines has an fxp that likes to do this while the machine is still up -- perhaps it's just a manifestation of 5.0's higher interrupt latency. Kris msg48608/pgp0.pgp Description: PGP signature
Another UMA panic under load
I think this is the same one I reported a few days ago (another alpha under heavy load). panic: mutex Giant not owned at /local0/src-client/sys/vm/vm_kern.c:312 db_print_backtrace() at db_print_backtrace+0x18 panic() at panic+0x104 _mtx_assert() at _mtx_assert+0xb4 kmem_malloc() at kmem_malloc+0x50 page_alloc() at page_alloc+0x3c uma_large_malloc() at uma_large_malloc+0x58 malloc() at malloc+0x10c fdalloc() at fdalloc+0x1b0 do_dup() at do_dup+0x1a4 dup2() at dup2+0x24 syscall() at syscall+0x338 XentSys() at XentSys+0x64 --- syscall (90) --- --- user mode --- panic Kris msg48609/pgp0.pgp Description: PGP signature
Re: RC NG, ntp and routed
On Thu, Dec 12, 2002 at 08:09:24AM -0200, Daniel C. Sobral wrote: I mean that routed is _one_ routing daemon, one that supports the old, would someone please shot it in the head to give it peace, RIP. If you happen to run a modern routing protocol... hell, if you happen to run a middle-aged routing protocol, you'll be using something else. And, since you do not seem to be aware of it, Zebra, for one, is run as... router_enable=YES router=/usr/local/sbin/zebractl router_flags=start If you are using a daemon essential to network connectivity in /usr/local and at the same time have it (/usr/local) mounted remotely, then you haven't thought things through properly. Listen, I think we're talking past each other here. I _am_ in favour of adding routing to NETWORKING (look at an earlier email in the thread). My only argument is that if an admin chooses to use a daemon from ports then he should be bright enough to include it in a local filesystem. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg48610/pgp0.pgp Description: PGP signature
Re: Another UMA panic under load
Ugh. Since it may call kmem_malloc(), UMA must hold Giant. This is the same problem the mbuf system has, and its what's keeping network device drivers under Giant in 5.0. Both subsytems should probably have GIANT_REQUIRED at all entry points so as to catch locking problems like this earlier. Drew Kris Kennaway writes: I think this is the same one I reported a few days ago (another alpha under heavy load). panic: mutex Giant not owned at /local0/src-client/sys/vm/vm_kern.c:312 db_print_backtrace() at db_print_backtrace+0x18 panic() at panic+0x104 _mtx_assert() at _mtx_assert+0xb4 kmem_malloc() at kmem_malloc+0x50 page_alloc() at page_alloc+0x3c uma_large_malloc() at uma_large_malloc+0x58 malloc() at malloc+0x10c fdalloc() at fdalloc+0x1b0 do_dup() at do_dup+0x1a4 dup2() at dup2+0x24 syscall() at syscall+0x338 XentSys() at XentSys+0x64 --- syscall (90) --- --- user mode --- panic Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RC NG, ntp and routed
Mike Makonnen wrote: If you are using a daemon essential to network connectivity in /usr/local and at the same time have it (/usr/local) mounted remotely, then you haven't thought things through properly. Listen, I think we're talking past each other here. I _am_ in favour of adding routing to NETWORKING (look at an earlier email in the thread). My only argument is that if an admin chooses to use a daemon from ports then he should be bright enough to include it in a local filesystem. Good. That's what I'm saying too. :-) Well, that, and that local filesystems should be mounted before networking, and remote fs afterwards (which, as I see, is the present case). -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] A University without students is like an ointment without a fly. -- Ed Nather, professor of astronomy at UT Austin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Posix Semaphores in -CURRENT
I have been looking at the implementation of POSIX semaphores in -CURRENT. I noticed that there are several missing pieces, specifically the man pages and the removal of uthread_sem.c from libc_r. I suppose the man pages are not critical, but it seems silly to keep uthread_sem.c in libc_r if there is a completely new kernel-based implementation of the sem_* routines in -CURRENT. There are some other things about uipc_sem.c that seem unnecessarily restrictive. For one thing, it *requires* named semaphores to begin with a '/' but not contain embedded '/'. This seems like a severe portabliity issue as TRU64 (at least) allows arbitrary pathnames as sempahores, probably storing some sort of marker in the directories (I get this only from examining the TRU64 online manual pages at http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/HTML/APS33DTE_html/DOCU_010.HTM There seems to be some broad interpretation of the POSIX semantice in TRU64 to allow for negative semaphore values, one of their questionable choices, although their example code is instructive). Since the semaphore names are merely stored in kernel structures, what difference does it make if they contain embedded '/' characters or not? And why not allow names without leading '/'? I don't think that there is any wording in POSIX preventing this. I would like to take advantage of the posix semaphore implementation when 5.0 comes out. I think the libc_r issue at least needs looking at. Or maybe I misunderstand the reading of src/lib/libc_r/uthread/Makefile HEAD branch. /Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ioctl(CAMGETPASSTHRU) hung X11/cda process
On Thu, 12 Dec 2002, Lamont Granquist wrote:
On Wed, 11 Dec 2002, Kenneth D. Merry wrote:
On Wed, Dec 11, 2002 at 11:37:42 -0800, Nate Lawson wrote:
On Tue, 10 Dec 2002, Lamont Granquist wrote:
# ps xauww | egrep cda
root 36761 0.0 0.3 1884 1452 p4 D 7:25PM 0:00.01
/usr/X11R6/lib/X11/xmcd/bin-FreeBSD_5-i386/cda -batch -dev /dev/cd0 on
# strace -p 36761
ioctl(0, CAMGETPASSTHRU
(...hangs forever and won't die with kill -9...)
ps axl output for that proc, please.
It's probably hanging waiting for a CCB, although ps axl output should tell
us whether or not that's the case.
If that is the case, it raises the why question, especially since nothing
has changed in that area recently that I know of.
i panic'd the system and got this for a bt on the process:
(kgdb) bt
#0 mi_switch () at /usr/src/sys/kern/kern_synch.c:522
#1 0xc02f2027 in msleep (ident=0xc41fc0b8, mtx=0x0, priority=76,
wmesg=0x0,
timo=0) at /usr/src/sys/kern/kern_synch.c:262
#2 0xc0140ffc in cam_periph_getccb (periph=0xc41fc080, priority=1)
at /usr/src/sys/cam/cam_periph.c:748
#3 0xc01410a5 in cam_periph_ioctl (periph=0x0, cmd=-1033890813, addr=0x0,
error_routine=0xc01574f0 passerror) at
/usr/src/sys/cam/cam_periph.c:784
#4 0xc01573b8 in passioctl (dev=0x0, cmd=0, addr=0xc41f2800 , flag=3,
td=0xc42fdc40) at /usr/src/sys/cam/scsi/scsi_pass.c:533
#5 0xc02b45ee in spec_ioctl (ap=0xc41f2800)
at /usr/src/sys/fs/specfs/spec_vnops.c:352
#6 0xc02b3d18 in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:126
#7 0xc034ae91 in vn_ioctl (fp=0xc4340f3c, com=3261076483,
data=0xc41f2800,
active_cred=0xc5eb9100, td=0xc42fdc40) at vnode_if.h:488
#8 0xc0310686 in ioctl (td=0xc42fdc40, uap=0xdacb0d10) at file.h:227
#9 0xc046cc7e in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077942432, tf_esi =
134979584, tf_ebp = -1077942408, tf_isp = -624226956, tf_ebx = 672215480,
tf_edx = 0, tf_ecx = 0, tf_eax = 54, tf_trapno = 12, tf_err = 2, tf_eip =
672506643, tf_cs = 31, tf_eflags = 582, tf_esp = -1077943092, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1033
#10 0xc045cd2d in Xint0x80_syscall () at {standard input}:140
This indicates the system is waiting for a CCB (blocked on tsleep in
cam_periph_getccb). The call to xpt_schedule should make a CCB available
and if it doesn't, it goes to sleep. A later schedule should hit the
start entry for a driver that relinquishes its ccb and calls wakeup.
Ken, I don't see any change that would cause this problem either. When
did this problem start occurring? Also, it might be good to add a PCATCH
to the tsleep since it's ok to interrupt here (I think).
It would be great if you could do frame 2 and then print *periph
-Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Cardbus/dc(4) still broken
Yup. Known problem with some cards. How do I fix? M -- Mark Murray Beware! I'm umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Cardbus/dc(4) still broken
In message: [EMAIL PROTECTED] Mark Murray [EMAIL PROTECTED] writes: : Yup. Known problem with some cards. : : How do I fix? Fix the dc driver to not suck so much in this reguard. :-) I think that some flags aren't being properly set in the probe routine, but haven't had a chance to look at it in detail. I'm sorry I don't have a more complete answer... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: More missing perl dependencies
On Wed, 11 Dec 2002 17:06:07 -0800 Kris Kennaway [EMAIL PROTECTED] wrote: http://bento.freebsd.org/errorlogs/i386-5-latest/modlogan-0.8.1.log In the case of modlogan it may be a bug in the configure script (I haven't looked at it). I'm not aware of a runtime dependency, so a quick fix would be to add a build dependency until I get a definitive answer from the author. Bye, Alexander. -- Failure is not an option. It comes bundled with your Microsoft product. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Cardbus/dc(4) still broken
Fix the dc driver to not suck so much in this reguard. :-) I think that some flags aren't being properly set in the probe routine, but haven't had a chance to look at it in detail. I'm sorry I don't have a more complete answer... What is my prognosis for the future? Is my best chance to bin this card and buy something that is actually supported? If so, what cardbus 100Mb ethernet card has the best chance of sustained support? M -- Mark Murray Beware! I'm umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Renumber IPPROTO_DIVERT
Hi, I'm running into an issue with divert sockets under perl after the renumbering. I use the following snippet to open one: $fh = IO::Socket::INET-new(LocalPort = $port, Proto = divert, Type = SOCK_RAW); IO::Socket::INET then does a getprotobyname() on divert, which according to /etc/protocols is 254, which results in Dec 12 13:21:29 nik kernel: Old IPDIVERT program needs to be recompiled, or new IP proto 254 user needs sysctl net.inet.raw.olddiverterror=0 Was /etc/protocols maybe simply forgotten in the 10/29/02 change? Thanks, Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Renumber IPPROTO_DIVERT
Was /etc/protocols maybe simply forgotten in the 10/29/02 change? Yes. Does changing it to 258 work? Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sysctl -a loops forever...
Anyone seen sysctl -a loop forever? I haven't been able to track down the MIB that it's gettinng hung up on, but it looks like there's a flaw in the algo that is walking through the MIBs. Given that this halts the machine while trying to collect entropy (sysctl -a is used to help feed /dev/random) at system start up, I think it's something worth addressing or pointing out. -sc I've observed this when e.g. I had too many nmbclusters configured, ie when vm.kvm_free was too low (0 in my case :) Ah, hrm, I think you're onto something here. I haven't played with vm.kvm_free, but I do run with 65536 mbuf clusters. Hrm... this is outside of my expertise. I have 4.X boxes running with 130K mbuf clusters (and I actually need to find a way to increase this further!) so this is definately something I'll run into and likely others will when they update their production boxen. Is this a sysctl data presentation issue? -sc -- Sean Chittenden To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: More missing perl dependencies
On Thu, Dec 12, 2002 at 10:18:06PM +0100, Alexander Leidinger wrote: On Wed, 11 Dec 2002 17:06:07 -0800 Kris Kennaway [EMAIL PROTECTED] wrote: http://bento.freebsd.org/errorlogs/i386-5-latest/modlogan-0.8.1.log In the case of modlogan it may be a bug in the configure script (I haven't looked at it). I'm not aware of a runtime dependency, so a quick fix would be to add a build dependency until I get a definitive answer from the author. Thanks for looking into it. Here is another one: http://bento.freebsd.org/errorlogs/i386-5-latest/screem-0.5.6.log Kris msg48622/pgp0.pgp Description: PGP signature
Re: Renumber IPPROTO_DIVERT
Bill Fenner wrote: Was /etc/protocols maybe simply forgotten in the 10/29/02 change? Yes. Does changing it to 258 work? it makes the syslog message go away and the socket opens. I haven't tested yet if diverting works, need to port some other pieces first. I'll let you know later (today, hopefully.) Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Renumber IPPROTO_DIVERT
Lars Eggert wrote: Bill Fenner wrote: Was /etc/protocols maybe simply forgotten in the 10/29/02 change? Yes. Does changing it to 258 work? it makes the syslog message go away and the socket opens. I haven't tested yet if diverting works, need to port some other pieces first. I'll let you know later (today, hopefully.) Yes, changing 254 - 258 in /etc/protocols works. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: RC NG, ntp and routed
Brad Knowles wrote: At 5:41 PM -0800 2002/12/11, Tim Kientzle wrote: NETWORKING ... does not, in itself, depend on any filesystems. Sure it does. In order to do anything, you have to run programs -- right? The NETWORKING script does nothing. It runs no programs, therefore it needs no filesystems. It's purely a placeholder to simplify dependency specifications: all networking initialization is gauranteed to happen before NETWORKING. Therefore, scripts that require networking (such as lpd, sshd, ftpd, etc.) can safely depend on NETWORKING without having to know the details of the network initialization. For example, someone who needs a special routing daemon can add a script that REQUIREs network2 and comes BEFORE NETWORKING, and then their routing daemon will be started at the appropriate time: before any network-capable daemons (or remote filesystems), but after the initial interface configuration. Tim Kientzle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
fincore.c strikes again (panic bremfree: bp not locked)
I don't have any more info since for some reason the kernel wasn't saved
when my system dumped core, but yet again fincore.c causes evidence that
-CURRENT has regressed again. I can't find the old thread I'm thinking of,
but from a slightly different thread, bde knew what was going on. For
further reference:
#include stdio.h
#include unistd.h
#include stdlib.h
#include sys/types.h
#include sys/mman.h
#include fcntl.h
#include sys/stat.h
#include machine/param.h
#include errno.h
/*
** print pages of file in core
*/
void usage(char *name)
{
printf(Usage: %s [-ns] files...\n,name);
printf(\t-n\t\tDo not print filename\n);
printf(\t-o\t\tOnly print files with at least one page in core\n);
printf(\t-s\t\tDo not print file size in pages\n);
}
main(int ac,char **av)
{
int c;
int print_name = 1;
int print_sizepages = 1;
int only_nonzero = 0;
int status = 0;
while((c = getopt(ac,av,nos)) != -1) {
switch(c) {
case 'n':
print_name = 0;
break;
case 'o':
only_nonzero = 1;
break;
case 's':
print_sizepages = 0;
break;
default:
usage(av[0]);
exit(1);
}
}
for(; optind ac ; optind++) {
int fd;
int pind,pcount;
caddr_t addr;
struct stat statbuf;
size_t len;
size_t numpages;
char *pvec;
if (stat(av[optind],statbuf)) {
perror(stat);
status = 1;
continue;
}
if (!S_ISREG(statbuf.st_mode)) {
close(fd);
continue;
}
if ((fd = open(av[optind],O_RDONLY)) 0) {
perror(av[optind]);
status = 1;
continue;
}
if (fstat(fd,statbuf)) {
perror(fstat);
close(fd);
status = 1;
continue;
}
if (!S_ISREG(statbuf.st_mode)) {
close(fd);
continue;
}
len = statbuf.st_size;
numpages = len/PAGE_SIZE + ((len % PAGE_SIZE) != 0);
if (! (statbuf.st_mode (S_IFREG|S_IFCHR))) {
pcount = 0;
} else if (len) {
if ((addr = mmap(0,len,PROT_READ,MAP_SHARED,fd,0)) ==
MAP_FAILED) {
fprintf(stderr, mmap (%s): %s\n, av[optind],
strerror(errno));
close(fd);
status = 1;
continue;
}
pvec = malloc(numpages);
if (mincore(addr,len,pvec))
{
perror(mincore);
exit(1);
}
for(pcount = 0,pind = 0 ; pind numpages ; pind++) {
if (pvec[pind]) pcount++;
}
free(pvec);
if (munmap(addr,len)) {
perror(munmap);
exit(1);
}
} else {
pcount = 0;
}
if (pcount || !only_nonzero) {
if (print_name) printf(%s: ,av[optind]);
printf(%d,pcount);
if (print_sizepages) printf(/%d,numpages);
printf(\n);
}
close(fd);
}
exit(status);
}
--
Brian Fundakowski Feldman \'[ FreeBSD ]''\
[EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \
Opinions expressed are my own. \,,\
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
cvs(1) assertion failure
Has anyone else seen something like this with CVS?
%%%
(jmallett@luna:~/Work/Mono)59% mcvs rlog mono mono-cvs-log; mcvs rlog mcs
mcs-cvs-log
cvs rlog: Logging mono
cvs [rlog aborted]: received abort signal
cvs: lock.c:177: lock_name: Assertion `(__extension__ (__builtin_constant_p (strlen
(current_parsed_root-directory)) ((__builtin_constant_p (repository) strlen
(repository) ((size_t) (strlen (current_parsed_root-directory ||
(__builtin_constant_p (current_parsed_root-directory) strlen
(current_parsed_root-directory) ((size_t) (strlen
(current_parsed_root-directory) ? __extension__ ({ size_t __s1_len, __s2_len;
(__builtin_constant_p (repository) __builtin_constant_p
(current_parsed_root-directory) (__s1_len = strlen (repository), __s2_len = strlen
(current_parsed_root-directory), (!((size_t)(const void *)((repository) + 1) -
(size_t)(const void *)(repository) == 1) || __s1_len = 4) (!((size_t)(const void
*)((current_parsed_root-directory) + 1) - (size_t)(const void
*)(current_parsed_root-directory) == 1) || __s2_len = 4)) ? memcmp ((__const char *)
(repository), (__const char *) (current_parsed_root-directory), (__s1_len __s2_len
? __s1_len : __s2_len) + 1) : (__builtin_constant_p (repository) ((size_t)(const
void *)((repository) + 1) - (size_t)(const void *)(repository) == 1) (__s1_len =
strlen (repository), __s1_len 4) ? (__builtin_constant_p
(current_parsed_root-directory) ((size_t)(const void
*)((current_parsed_root-directory) + 1) - (size_t)(const void
*)(current_parsed_root-directory) == 1) ? (__extension__ ({ register int __result =
(((__const unsigned char *) (__const char *) (repository))[0] - ((__const unsigned
char *) (__const char *)(current_parsed_root-directory))[0]); if (__s1_len 0
__result == 0) { __result = (((__const unsigned char *) (__const char *)
(repository))[1] - ((__const unsigned char *) (__const char *)
(current_parsed_root-directory))[1]); if (__s1_len 1 __result == 0) { __result =
(((__const unsigned char *) (__const char *) (repository))[2] - ((__const unsigned
char *) (__const char *) (current_parsed_root-directory))[2]); if (__s1_len 2
__result == 0) __result = (((__const unsigned char *) (__const char *)
(repository))[3] - ((__const unsigned char *) (__const char *)
(current_parsed_root-directory))[3]); } } __result; })) : (__extension__ ({ __const
unsigned char *__s2 = (__const unsigned char *) (__const char *)
(current_parsed_root-directory); register int __result = (((__const unsigned char *)
(__const char *) (repository))[0] - __s2[0]); if (__s1_len 0 __result == 0) {
__result = (((__const unsigned char *) (__const char *) (repository))[1] - __s2[1]);
if (__s1_len 1 __result == 0) { __result = (((__const unsigned char *) (__const
char *) (repository))[2] - __s2[2]); if (__s1_len 2 __result == 0) __result =
(((__const unsigned char *) (__const char *) (repository))[3] - __s2[3]); } }
__result; }))) : (__builtin_constant_p (current_parsed_root-directory)
((size_t)(const void *)((current_parsed_root-directory) + 1) - (size_t)(const void
*)(current_parsed_root-directory) == 1) (__s2_len = strlen
(current_parsed_root-directory), __s2_len 4) ? (__builtin_constant_p (repository)
((size_t)(const void *)((repository) + 1) - (size_t)(const void *)(repository) ==
1) ? (__extension__ ({ register int __result = (((__const unsigned char *) (__const
char *) (repository))[0] - ((__const unsigned char *) (__const char
*)(current_parsed_root-directory))[0]); if (__s2_len 0 __result == 0) { __result
= (((__const unsigned char *) (__const char *) (repository))[1] - ((__const unsigned
char *) (__const char *) (current_parsed_root-directory))[1]); if (__s2_len 1
__result == 0) { __result = (((__const unsigned char *) (__const char *)
(repository))[2] - ((__const unsigned char *) (__const char *)
(current_parsed_root-directory))[2]); if (__s2_len 2 __result == 0) __result =
(((__const unsigned char *) (__const char *) (repository))[3] - ((__const unsigned
char *) (__const char *) (current_parsed_root-directory))[3]); } } __result; })) :
(__extension__ ({ __const unsigned char *__s1 = (__const unsigned char *) (__const
char *) (repository); register int __result = __s1[0] - ((__const unsigned char *)
(__const char *) (current_parsed_root-directory))[0]; if (__s2_len 0 __result ==
0) { __result = (__s1[1] - ((__const unsigned char *) (__const char *)
(current_parsed_root-directory))[1]); if (__s2_len 1 __result == 0) { __result =
(__s1[2] - ((__const unsigned char *) (__const char *)
(current_parsed_root-directory))[2]); if (__s2_len 2 __result == 0) __result =
(__s1[3] - ((__const unsigned char *) (__const char *)
(current_parsed_root-directory))[3]); } } __result; }))) : strcmp (repository,
current_parsed_root-directory; }) : strncmp (repository,
current_parsed_root-directory, strlen (current_parsed_root-directory == 0'
failed.
cvs [rlog aborted]: received abort signal
Re: HELP: vinum and newfs on 5.0-RC1
On Wednesday, 11 December 2002 at 12:45:05 -0700, Aaron D. Gifford wrote: I wrote in my previous message: # newfs -O 2 -U /dev/vinum/raid5vol newfs: /dev/vinum/raid5vol: 'e' partition is unavailable ... Here's my vinum setup: ... volume raid5vol Let me correct this to state that the full volume name was raid5volume and I just shortened it to save typing. This turns out to be important. Looking at newfs.c, it looks like the last letter of the special device is used to choose the partition. Thus e was selected during my attempts to do newfs. (Note to self: Do NOT to abbreviate when reporting trouble.) Today I renamed my vinum volume as sp1a, and newfs worked just fine: #newfs -U -O 2 /dev/vinum/sp1a A few attempts to use disklabel on /dev/vinum/sp1a still had some problems (i.e. any changes made during 'disklabel -e /dev/vinum/sp1a' were still ignored as subsequent disklabel sessions would revert to the version I saw before my changes - 'disklabel -e -r /dev/vinum/sp1a' did save my changes to the on-disk--or on vinum volume in this case--label but the in-memory label remaind unchanged), but apparently I didn't really need to use disklabel with this newly named volume. So... Is there some place in the vinum manual that I missed that discusses volume naming requirements that had I read I could have avoided this trouble? No, it's all part of using -CURRENT. Over the last couple of days, I've found a number of bugs which have slipped in during the conversion to GEOM and devfs. This particular one is still there, pending approval from the Release Engineers to commit a fix. I'll forward you the message when it happens; I'd like you to then confirm that it fixes your problem. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: fincore.c strikes again (panic bremfree: bp not locked)
On Thu, Dec 12, 2002 at 07:20:15PM -0500, Brian Fundakowski Feldman wrote:
I don't have any more info since for some reason the kernel wasn't saved
when my system dumped core, but yet again fincore.c causes evidence that
-CURRENT has regressed again. I can't find the old thread I'm thinking of,
but from a slightly different thread, bde knew what was going on.
[...]
I can reproduce the panic here. This is the message backtrace, for anyone
who wants to help track it down:
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: from debugger
panic messages:
---
panic: mutex vm page queue mutex not owned at /usr/src/sys/i386/i386/pmap.c:3141
panic: from debugger
Uptime: 2h37m31s
Dumping 64 MB
ata0: resetting devices ..
done
16 32 48
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232
232 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232
#1 0xc0197bfc in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:364
#2 0xc0197e43 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#3 0xc01318d2 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4 0xc0131852 in db_command (last_cmdp=0xc02d73c0, cmd_table=0x0,
aux_cmd_tablep=0xc02d20e4, aux_cmd_tablep_end=0xc02d20e8)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc0131966 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6 0xc013465a in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:72
#7 0xc0287862 in kdb_trap (type=3, code=0, regs=0xc6279ba8)
at /usr/src/sys/i386/i386/db_interface.c:166
#8 0xc0298eef in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1058181856, tf_esi = 256, tf_ebp
= -970482700, tf_isp = -970482732, tf_ebx = 0, tf_edx = 0, tf_ecx = 32, tf_eax = 18,
tf_trapno = 3, tf_err = 0, tf_eip = -107102, tf_cs = 8, tf_eflags = 646, tf_esp =
-1070805470, tf_ss = -1070875346})
at /usr/src/sys/i386/i386/trap.c:603
#9 0xc0289048 in calltrap () at {standard input}:98
#10 0xc0197e2b in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:503
#11 0xc018eb3c in _mtx_assert (m=0xc02ef400, what=0,
file=0xc02ce210 /usr/src/sys/i386/i386/pmap.c, line=3141)
at /usr/src/sys/kern/kern_mutex.c:838
#12 0xc0296b24 in pmap_ts_referenced (m=0xc45)
at /usr/src/sys/i386/i386/pmap.c:3141
---Type return to continue, or q return to quit---
#13 0xc0296ec3 in pmap_mincore (pmap=0x0, addr=0)
at /usr/src/sys/i386/i386/pmap.c:3340
#14 0xc025d51c in mincore (td=0x3ab0405, uap=0x0)
at /usr/src/sys/vm/vm_mmap.c:874
#15 0xc02997f7 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077937044, tf_esi = -1077937032,
tf_ebp = -1077937084, tf_isp = -970482316, tf_ebx = 2, tf_edx = 134524928, tf_ecx = 8,
tf_eax = 78, tf_trapno = 12, tf_err = 2, tf_eip = 671813747, tf_cs = 31, tf_eflags =
658, tf_esp = -1077937300, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1033
#16 0xc028909d in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---
(kgdb) frame 12
#12 0xc0296b24 in pmap_ts_referenced (m=0xc45)
at /usr/src/sys/i386/i386/pmap.c:3141
3141mtx_assert(vm_page_queue_mtx, MA_OWNED);
(kgdb) print vm_page_queue_mtx
$1 = {mtx_object = {lo_class = 0xc02df5c0,
lo_name = 0xc02ca52a vm page queue mutex,
lo_type = 0xc02ca52a vm page queue mutex, lo_flags = 196608, lo_list = {
tqe_next = 0xc02ef3a0, tqe_prev = 0xc030d10c}, lo_witness = 0xc0310148},
mtx_lock = 4, mtx_recurse = 0, mtx_blocked = {tqh_first = 0x0,
tqh_last = 0xc02ef424}, mtx_contested = {le_next = 0x0, le_prev = 0x0},
mtx_acqtime = 0, mtx_filename = 0x0, mtx_lineno = 0}
This stuff probably is not useful:
(kgdb) frame 14
#14 0xc025d51c in mincore (td=0x3ab0405, uap=0x0)
at /usr/src/sys/vm/vm_mmap.c:874
874 mincoreinfo = pmap_mincore(pmap, addr);
(kgdb) print pmap
$2 = (struct pmap *) 0xc0609bdc
(kgdb) print addr
$3 = 672395264
(kgdb) print *pmap
$4 = {pm_pdir = 0xc62b7000, pm_pteobj = 0xc1048410, pm_pvlist = {
tqh_first = 0xc05c5188, tqh_last = 0xc05a8be0}, pm_active = 1, pm_stats = {
resident_count = 173, wired_count = 0}, pm_ptphint = 0xc0484368,
pm_list = {le_next = 0xc060962c, le_prev = 0xc02f56fc}}
(kgdb) frame 13
#13 0xc0296ec3 in pmap_mincore (pmap=0x0, addr=0)
at /usr/src/sys/i386/i386/pmap.c:3340
(kgdb) print m
$5 = (struct vm_page *) 0xc0543138
(kgdb) print *m
$6 = {pageq = {tqe_next = 0xc054a6c8, tqe_prev = 0xc04967a0}, listq = {
tqe_next = 0xc04fd580, tqe_prev = 0xc04806f8}, left = 0xc053df60,
right = 0xc04afc10, object = 0xc0435958, pindex = 6, phys_addr = 61538304,
md =
Eat pizza and lose weight?
Hello !
If you're like me, you've tried EVERYTHING to lose
weight. I know how you feel - the special diets,
miracle pills, and fancy exercise equipment never helped
me lose a pound either. It seemed like the harder I tried,
the bigger I got, until I heard about a product called
Power Diet Plus.
You're probably thinking to yourself, Oh geez, not another
miracle diet pill! Like you, I was skeptical at first, but
my sister swore it helped her lose 23 pounds in just two weeks,
so I told her I'd give it a shot. I mean, there was nothing
to lose except a lot of weight! Let me tell you, it was
the best decision I've ever made. Period. Six months later,
as I'm writing this message to you, I've gone from 355 pounds
to 210 pounds, and I haven't changed my exercise routine or diet
at all. Yes, I still eat pizza, and lots of it!
I was so happy with the results that I contacted the manufacturer
and got permission to resell it - at a BIG discount. I want
to help other people lose weight like I did, because it
does so much for your self-esteem, not to mention your health.
I give you my personal pledge that Power Diet Plus
absolutely WILL WORK FOR YOU. If it doesn't, you can return it
any time for a full refund.
If you are frustrated with trying other products, not having
any success, and just not getting the results you were promised,
then I recommend the only product that worked for me - POWER DIET
PLUS.
You're probably asking yourself, Ok, so how does this stuff
actually work?
Power Diet Plus contains Lipotropic fat burners which are
scientifically proven to increase metabolism and cause rapid
weight loss. No hocus pocus in these pills - just RESULTS, RESULTS,
RESULTS!!
Here is the bottom line ...
I can help you lose 10-15 pounds per week naturally, without
exercising and without having to eat rice cakes all day.
Just try it for one month - there's nothing to lose, and everything
to gain. You will lose weight fast - GUARANTEED. That is my
pledge to you.
To order Power Diet Plus on our secure server, just click
on the link below:
http://coprohgh.diy.163.com/images/powerorder.htm
To see what some of our customers have said about this product,
visit http://coprohgh.diy.163.com/images/testimonials.htm
To see a list of ingredients and for more information
on test studies and how it will help you lose weight, visit
http://coprohgh.diy.163.com/images/howitworks.htm
{%rand%}
9885NEXx1-546XKQz3371psdx7-504KSLB5360LTQK0-650yl45
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: fincore.c strikes again (panic bremfree: bp not locked)
Here's a proposed patch for this problem:
Index: src/sys/i386/i386/pmap.c
===
RCS file: /x/freebsd/src/sys/i386/i386/pmap.c,v
retrieving revision 1.376
diff -u -r1.376 pmap.c
--- src/sys/i386/i386/pmap.c3 Dec 2002 04:00:42 - 1.376
+++ src/sys/i386/i386/pmap.c13 Dec 2002 02:54:44 -
@@ -3300,7 +3300,7 @@
{
pt_entry_t *ptep, pte;
vm_page_t m;
- int val = 0;
+ int refd, val = 0;
ptep = pmap_pte(pmap, addr);
if (ptep == 0) {
@@ -3337,9 +3337,17 @@
/*
* Referenced by someone
*/
- else if ((m-flags PG_REFERENCED) || pmap_ts_referenced(m)) {
+ else if (m-flags PG_REFERENCED) {
val |= MINCORE_REFERENCED_OTHER;
vm_page_flag_set(m, PG_REFERENCED);
+ } else {
+ vm_page_lock_queues();
+ refd = pmap_ts_referenced(m);
+ vm_page_unlock_queues();
+ if (refd) {
+ val |= MINCORE_REFERENCED_OTHER;
+ vm_page_flag_set(m, PG_REFERENCED);
+ }
}
}
return val;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Major disk problem
I cvsup'ed today (dec 12, about 5pm est) from DP2, and it went all fine and dandy until I went to boot into it, when it said that /usr had a bad superblock. I then went on to fsck -y it, and it says that _every_ file is an unknown type and goes on to ruin the fs. It was a UFS2 volume. I'm not sure what else to say, just that I wish this didn't happen! I guess it's back to 4.7 for me! -Craig To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
recent openssh problem
Hi, My simple openssh port-forwarding script doesn't work after updating my -current notebook to today's one. (13 Dec +0900) Key part of my script is as follows: % ssh -2 -N -f -L 9595:remote-host:25 remote-host bind: Can't assign requested address I usually use it to forward SMTP to remote host. Is there any change to system or openssh upgrade? Before upgrading, my -current box was built on 25 Nov. It worked silently before. -- +++ Any opinions in this posting are my own and not those of my employers +++ CHOI Junho [sleeping now]http://www.kr.FreeBSD.org/~cjh [while sleeping] cjh @ kr.FreeBSD.ORG cjh @ FreeBSD.ORG cjh @ wdb.co.kr Korea FreeBSD Users Group www.kr.FreeBSD.org Web Data Bankwww.wdb.co.kr To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: recent openssh problem
On Fri, 2002-12-13 at 15:53, CHOI Junho wrote: % ssh -2 -N -f -L 9595:remote-host:25 remote-host bind: Can't assign requested address I usually use it to forward SMTP to remote host. Is there any change to system or openssh upgrade? Before upgrading, my -current box was built on 25 Nov. It worked silently before. Does lo0 have 127.0.0.1 as it's address? -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Cardbus/dc(4) still broken
In message: [EMAIL PROTECTED] Mark Murray [EMAIL PROTECTED] writes: : Fix the dc driver to not suck so much in this reguard. :-) : : I think that some flags aren't being properly set in the probe : routine, but haven't had a chance to look at it in detail. I'm sorry : I don't have a more complete answer... : : What is my prognosis for the future? : : Is my best chance to bin this card and buy something that is actually : supported? : : If so, what cardbus 100Mb ethernet card has the best chance of sustained : support? The prognosis is good, but I've been busy with work/devd so I've not been able to focus on these cards. When I return my focus to these cards, chances are good that they will be supported relatively quickly. I have a few different samples of failing cards that I'd like to get working. Maybe by new-years? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ioctl(CAMGETPASSTHRU) hung X11/cda process
(kgdb) frame 2
#2 0xc0140ffc in cam_periph_getccb (periph=0xc41fc080, priority=1)
at /usr/src/sys/cam/cam_periph.c:748
748 /usr/src/sys/cam/cam_periph.c: No such file or directory.
in /usr/src/sys/cam/cam_periph.c
(kgdb) print *periph
$11 = {pinfo = {priority = 1, generation = 6, index = 1},
periph_start = 0xc0157220 passstart,
periph_oninval = 0xc0156d70 passoninvalidate,
periph_dtor = 0xc0156e00 passcleanup, periph_name = 0xc049b503 pass,
path = 0xc406dcc0, softc = 0xc41e6000, unit_number = 1,
type = CAM_PERIPH_BIO, flags = 0, immediate_priority = 1, refcount = 1,
ccb_list = {slh_first = 0x0}, periph_links = {sle_next = 0x0},
unit_links = {
tqe_next = 0x0, tqe_prev = 0xc41cdb40}, deferred_callback = 0,
deferred_ac = 0}
(kgdb)
On Thu, 12 Dec 2002, Nate Lawson wrote:
On Thu, 12 Dec 2002, Lamont Granquist wrote:
On Wed, 11 Dec 2002, Kenneth D. Merry wrote:
On Wed, Dec 11, 2002 at 11:37:42 -0800, Nate Lawson wrote:
On Tue, 10 Dec 2002, Lamont Granquist wrote:
# ps xauww | egrep cda
root 36761 0.0 0.3 1884 1452 p4 D 7:25PM 0:00.01
/usr/X11R6/lib/X11/xmcd/bin-FreeBSD_5-i386/cda -batch -dev /dev/cd0 on
# strace -p 36761
ioctl(0, CAMGETPASSTHRU
(...hangs forever and won't die with kill -9...)
ps axl output for that proc, please.
It's probably hanging waiting for a CCB, although ps axl output should tell
us whether or not that's the case.
If that is the case, it raises the why question, especially since nothing
has changed in that area recently that I know of.
i panic'd the system and got this for a bt on the process:
(kgdb) bt
#0 mi_switch () at /usr/src/sys/kern/kern_synch.c:522
#1 0xc02f2027 in msleep (ident=0xc41fc0b8, mtx=0x0, priority=76,
wmesg=0x0,
timo=0) at /usr/src/sys/kern/kern_synch.c:262
#2 0xc0140ffc in cam_periph_getccb (periph=0xc41fc080, priority=1)
at /usr/src/sys/cam/cam_periph.c:748
#3 0xc01410a5 in cam_periph_ioctl (periph=0x0, cmd=-1033890813, addr=0x0,
error_routine=0xc01574f0 passerror) at
/usr/src/sys/cam/cam_periph.c:784
#4 0xc01573b8 in passioctl (dev=0x0, cmd=0, addr=0xc41f2800 , flag=3,
td=0xc42fdc40) at /usr/src/sys/cam/scsi/scsi_pass.c:533
#5 0xc02b45ee in spec_ioctl (ap=0xc41f2800)
at /usr/src/sys/fs/specfs/spec_vnops.c:352
#6 0xc02b3d18 in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:126
#7 0xc034ae91 in vn_ioctl (fp=0xc4340f3c, com=3261076483,
data=0xc41f2800,
active_cred=0xc5eb9100, td=0xc42fdc40) at vnode_if.h:488
#8 0xc0310686 in ioctl (td=0xc42fdc40, uap=0xdacb0d10) at file.h:227
#9 0xc046cc7e in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077942432, tf_esi =
134979584, tf_ebp = -1077942408, tf_isp = -624226956, tf_ebx = 672215480,
tf_edx = 0, tf_ecx = 0, tf_eax = 54, tf_trapno = 12, tf_err = 2, tf_eip =
672506643, tf_cs = 31, tf_eflags = 582, tf_esp = -1077943092, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1033
#10 0xc045cd2d in Xint0x80_syscall () at {standard input}:140
This indicates the system is waiting for a CCB (blocked on tsleep in
cam_periph_getccb). The call to xpt_schedule should make a CCB available
and if it doesn't, it goes to sleep. A later schedule should hit the
start entry for a driver that relinquishes its ccb and calls wakeup.
Ken, I don't see any change that would cause this problem either. When
did this problem start occurring? Also, it might be good to add a PCATCH
to the tsleep since it's ok to interrupt here (I think).
It would be great if you could do frame 2 and then print *periph
-Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
