Re: ATA errors on recent -current
On 16 Apr, Matthias Schuendehuette wrote:
Then I tried various combinations of UDMA100/66/33 and wc=0/1 - it
nearly doesn't change anything. If WC was enabled, I saw errors
concerning tags 0 *and* 1, whereas without write caching only tag=0 was
mentioned. I should say that my simple test was a 'tar cvf /dev/null
/usr/ports' with /usr/ports on an ATA-partition. Why *Write*Caching has
any influence here...???
If it wasn't read only: access time update.
CPU: AMD Duron(tm) processor (801.82-MHz 686-class CPU)
real memory = 268369920 (262080K bytes)
Same here.
pcib1: VIA 8363 (Apollo KT133) PCI-PCI (AGP) bridge \
at device 1.0 on pci0
I've an KT133A.
...and 'atacontrol cap 0 0' says:
ATA channel 0, Master, device ad0:
ATA/ATAPI revision5
device model IC35L060AVER07-0
firmware revision ER6OA44A
cylinders 16383
heads 16
sectors/track 63
lba supported 120103200 sectors
lba48 not supported
dma supported
overlap not supported
Feature Support EnableValue Vendor
write cacheyes yes
read ahead yes yes
dma queued yes yes 31/1F
SMART yes yes
microcode download no no
security yes yes
power management yes yes
advanced power management yes no 0/00
automatic acoustic management yes no 254/FE 128/80
And some general questions not related to the problem:
- What's the security feature?
- What does {,advanced} power management do?
- Is there a way to modify the acoustic management setting?
- We don't have SMART support, right?
Bye,
Alexander.
--
Loose bits sink chips.
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: ATA errors on recent -current
Alexander Leidinger wrote: device model IC35L060AVER07-0 ** ** These match the test in ad_tagsupported(); I have to wonder about: device model IC35L060AVER07-0 ** firmware revision ER6OA44A I also have to wonder about the firmware revision feature set; it's probably not an issue. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
On 17 Apr, Terry Lambert wrote: device model IC35L060AVER07-0 ** ** These match the test in ad_tagsupported(); I have to wonder about: device model IC35L060AVER07-0 ** Can you be more specific? firmware revision ER6OA44A I also have to wonder about the firmware revision feature set; it's probably not an issue. I don't knwo what you are trying to tell me. Bye, Alexander. -- One world, one web, one program -- Microsoft promotional ad Ein Volk, ein Reich, ein Fuehrer -- Adolf Hitler 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
i386 ATA is very broken after sparc64 ATA mega-commit (April 5)
This mega-commit: date: 2002/04/05 13:13:XX; author: sos; Make the ATA driver compile work on the sparc64 platform. breaks i386 ATA at least for following card: atapci0: Intel ICH2 ATA100 controller port 0xb800-0xb80f at device 31.1 on pci0 Last working kernel is from date=2002.04.05.13.09.00, all kernels after this mega-commit including very recent -current are broken. Symptoms are very strange, no error diagnostics at all but rtld's map_object() can't map any shared library with invalid file format error. Programs can't start from /etc/rc too. Please, fix. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
problem building libh
Hi,
When trying to build libh (from CVS) on a 5.0-DP1 system I get the
following error:
=== disk
c++ -pipe -g -I/usr/local/include/tcl8.3 -fpic -DPIC
-I/pub/devel/libh/lib/disk/../../include -Wall -c
/pub/devel/libh/lib/disk/Disk.cc -o Disk.o
In file included from /pub/devel/libh/lib/disk/Disk.cc:39:
/usr/include/sys/disklabel.h:191: `lp' was not declared in this scope
/usr/include/sys/disklabel.h:192: syntax error before `*'
/usr/include/sys/disklabel.h:189: warning: `u_int16_t dkcksum(disklabel
*)' declared `static' but never defined
*** Error code 1
However, looking at the code one can apply the following (trivial)
patch:
flynn@saioa# diff -ruN disklabel.h.old disklabel.h
--- disklabel.h.old Wed Apr 17 19:03:59 2002
+++ disklabel.h Wed Apr 17 19:04:39 2002
@@ -188,8 +188,7 @@
static __inline u_int16_t dkcksum __P((struct disklabel *lp));
static __inline u_int16_t
-dkcksum(lp)
- struct disklabel *lp;
+dkcksum(struct disklabel * lp)
{
u_int16_t *start, *end;
u_int16_t sum = 0;
-
Has this been fixed in recent -CURRENT includes?
Cheers,
--
Miguel Mendez - [EMAIL PROTECTED]
GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt
EnergyHQ :: http://www.energyhq.tk
FreeBSD - The power to serve!
msg37329/pgp0.pgp
Description: PGP signature
weird date/time
Hello, all my X-proggys tell me its about 15:48 (and it's true) my Windows on the same machine told me the same after a reboot. But a date in console will tell: Tue Apr 16 17:49:20 MEST 2002 what the hell is this? And every fs timestamps are also 2 hours in the future. Clock normally set to localtime and German timezone selected. MEST looks quite good: Middle European Sommer Time.. and it is. So MEST is GMT +0200. Maybe someone is adding this time to my localtime Jan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sometimes make install does nothing
On Tue, Apr 16, 2002 at 03:31:06PM +, Jan Stocker wrote:
twoflower# make install clean
Check you
a) don't already have an .install_done cookie in the ${WRKDIR}.
b) have an up-to-date bsd.port.mk
Kris
msg37331/pgp0.pgp
Description: PGP signature
Re: alpha tinderbox failure
On Wed, 17 Apr 2002, Dag-Erling Smorgrav wrote: In file included from /.amd_mnt/freefall/host/d/home/des/tinderbox/src/lib/libatm/atm_addr.c:50: /tmp/des/obj/alpha/.amd_mnt/freefall/host/d/home/des/tinderbox/src/alpha/usr/include/netatm/atm_if.h:68: syntax error before `VENDOR_IDT' /tmp/des/obj/alpha/.amd_mnt/freefall/host/d/home/des/tinderbox/src/alpha/usr/include/netatm/atm_if.h:80: syntax error before `VENDAPI_IDT_1' /tmp/des/obj/alpha/.amd_mnt/freefall/host/d/home/des/tinderbox/src/alpha/usr/include/netatm/atm_if.h:95: syntax error before `DEV_IDT_155' /tmp/des/obj/alpha/.amd_mnt/freefall/host/d/home/des/tinderbox/src/alpha/usr/include/netatm/atm_if.h:122: syntax error before `BUS_EISA' This has been fixed. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 ATA is very broken after sparc64 ATA mega-commit (April 5)
It seems Andrey A. Chernov wrote: This mega-commit: date: 2002/04/05 13:13:XX; author: sos; Make the ATA driver compile work on the sparc64 platform. breaks i386 ATA at least for following card: atapci0: Intel ICH2 ATA100 controller port 0xb800-0xb80f at device 31.1 on pci0 Last working kernel is from date=2002.04.05.13.09.00, all kernels after this mega-commit including very recent -current are broken. Symptoms are very strange, no error diagnostics at all but rtld's map_object() can't map any shared library with invalid file format error. Programs can't start from /etc/rc too. Hmm, I dont think so Have you recompiled both kernel and potential kld's ? I just had wierd behavior here using old kld's... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 ATA is very broken after sparc64 ATA mega-commit (April 5)
On 17 Apr, Andrey A. Chernov wrote: Symptoms are very strange, no error diagnostics at all but rtld's map_object() can't map any shared library with invalid file format error. Programs can't start from /etc/rc too. Please, fix. If you are running with tagged queing: turn it off. I got the same behavior. This (tags, not this particular representation) is a known bug, but unfortunately Søren isn't able to reproduce it in his lab. Bye, Alexander. -- Yes, I've heard of decaf. What's your point? 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: sometimes make install does nothing
On Wed, 2002-04-17 at 18:15, Alfred Perlstein wrote: * Jan Stocker [EMAIL PROTECTED] [020417 06:33] wrote: Hi, sometime a 'make install' does completely nothing. This leads that dependencies weren't installed or i've to call the make again. Mostly this happens while defining install and clean on the commandline together. Have a look at the following output. The port wasnt installed before (and no work directory exists!) twoflower# make install clean === Cleaning for autoconf213-2.13.000227_1 === Cleaning for m4-1.4_1 === Cleaning for ruby-1.6.7.2002.03.27 === Cleaning for ruby-fnmatch-1.1b_1 twoflower# make install clean === Extracting for ruby-fnmatch-1.1b_1 Checksum OK for ruby/ruby-fnmatch-1.1b.tar.gz. === ruby-fnmatch-1.1b_1 depends on file: /usr/local/bin/ruby - found === Patching for ruby-fnmatch-1.1b_1 === Configuring for ruby-fnmatch-1.1b_1 === Running extconf.rb to configure ... It happens here and there and not all the time, i cant find a common part when or where it happens... Check for a .install_done file in the work dir. I think that's what can cause this. I think the answer is to use reinstall instead of install or to make clean first. As i wrote the port is clean NO WORK DIR, SO NO .install_done ! This happens also with a clean port (no work-dir) with $ make install nothing happens $ make install the make starts... so here cant the maybe (but really not) existing .install_done file disappear. But with clean and install both in one make the problem appears more times. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
Hello, Am Mittwoch, 17. April 2002 03:14 schrieben Sie: Matthias Schuendehuette wrote: I used 'atacontrol' to read the number of tags allowed: it is 31 (0x1F). Perhaps Soren could tell me how to force it to, say, 0x10? You have to modify the source code in ~line 180 of /sys/dev/ata/ata-disk.c. Well, thanks for the hint. I just have to wait until I get a new 'current'-world... yesterday it didn't compile and because of an, say, 'indisposition' of vinum (I changed another slice on a vinum-disk, so it dislikes the whole plex :-^ ) I lost my current /usr/obj... Then I tried various combinations of UDMA100/66/33 and wc=0/1 - it nearly doesn't change anything. BTW: I switched UDMA speed using 'atacontrol'... After the first switch to PIO4, I umounted the filesystem and switched back to UDMA33 for instance - I couldn't even *mount* the filesystem again! [...] My hunch, which is why I suggested decreasing the number of tags seen by the driver, is that the tagged queues are over used, and this locks the disk up. [...] Yes, I understand this (I for myself had already your 'off-by-one'-suspicion - it's obvious if one sees the error message) and I'll test it ASAP. What I was wondering yesterday before I fell asleep is that the disk is obviously not able to recover from this error - even if the error condition is no longer valid due to the switch to PIO-mode. *Any* DMA-mode is no longer useable. I don't know if it's an attribute of these disks or an issue solvable by a/the driver. I would expect to be able to do a software reset of the drive like with SCSI, but I'm a bit biased against ATA (vs. SCSI) because of the opinion/argues of a very knowledgeable guy here in the german newsgroup (former core team member ;-), so I wouldn't be surprised if that's not possible or not specified. -- Ciao/BSD - Matthias Matthias Schuendehuette [EMAIL PROTECTED], Berlin (Germany) Powered by FreeBSD 4.5-STABLE To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: weird date/time
Problem solved itself... cant say why... after some reboots everything looks fine. On Tue, 2002-04-16 at 19:25, Jan Stocker wrote: Hello, all my X-proggys tell me its about 15:48 (and it's true) my Windows on the same machine told me the same after a reboot. But a date in console will tell: Tue Apr 16 17:49:20 MEST 2002 what the hell is this? And every fs timestamps are also 2 hours in the future. Clock normally set to localtime and German timezone selected. MEST looks quite good: Middle European Sommer Time.. and it is. So MEST is GMT +0200. Maybe someone is adding this time to my localtime Jan 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
LIBCOMPATDIR semantics mismatch
Don't know what prevented this from being caught, but:
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/compat/Makefile.inc?only_with_tag=MAIN#rev1.5
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/compat/compat1x/Makefile?only_with_tag=MAIN#rev1.8
These two doesn't seem to mix together (note the last argument):
- snip - snip - snip -
sh /usr/src/tools/install.sh -c -o root -g wheel -m 444 libc.so.1.1 libcurses.so.1.1
libf2c.so.1.1 libg++.so.1.1 libgcc.so.1.1 libgnumalloc.so.1.1 libgnuregex.so.1.1
libln.so.1.1 libm.so.1.1 libmalloc.so.1.1 libreadline.so.1.1 libresolv.so.1.1
librpcsvc.so.1.1 libskey.so.1.1 libtelnet.so.1.1 libtermcap.so.1.1 libutil.so.1.1
liby.so.1.1 /usr/obj/usr/src/i386/usr/lib/compat/aout/aout
usage: install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
[-o owner] file1 file2
install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
[-o owner] file1 ... fileN directory
install -d [-v] [-g group] [-m mode] [-o owner] directory ...
*** Error code 64
- snip - snip - snip -
Attached is a patch that fixes this by unifying the semantics of
LIBCOMPATDIR.
Thanks,
Eugene
--- src/lib/compat/Makefile.inc Sat Nov 10 02:08:09 2001
+++ src/lib/compat/Makefile.inc.new Wed Apr 17 14:27:40 2002
-1,6 +1,6
# $FreeBSD: src/lib/compat/Makefile.inc,v 1.8 2001/09/22 08:11:24 ru Exp $
-LIBCOMPATDIR?= ${LIBDIR}/compat/aout
+LIBCOMPATDIR?= ${LIBDIR}/compat
.if defined(LIBS) !empty(LIBS)
beforeinstall: __remove-stale-libs
--- src/lib/compat/compat3x.i386/Makefile Sat Nov 10 02:08:09 2001
+++ src/lib/compat/compat3x.i386/Makefile.new Wed Apr 17 14:28:05 2002
-2,8 +2,6
DISTRIBUTION= compat3x
-LIBCOMPATDIR= ${LIBDIR}/compat
-
LIBS= libalias.so.3 libc.so.3 libc_r.so.3 libc_r.so.4 libcurses.so.2 \
libdialog.so.3 libedit.so.2 libf2c.so.2 libfetch.so.1 libftpio.so.4 \
libg++.so.4 libhistory.so.3 libmytinfo.so.2 libncurses.so.3 \
--- src/lib/compat/compat4x.alpha/Makefile Wed Apr 17 01:16:56 2002
+++ src/lib/compat/compat4x.alpha/Makefile.new Wed Apr 17 14:28:12 2002
-2,8 +2,6
DISTRIBUTION= compat4x
-LIBCOMPATDIR= ${LIBDIR}/compat
-
LIBS= \
libc.so.4 \
libc_r.so.4 \
--- src/lib/compat/compat4x.i386/Makefile Wed Apr 17 01:16:57 2002
+++ src/lib/compat/compat4x.i386/Makefile.new Wed Apr 17 14:28:21 2002
-2,8 +2,6
DISTRIBUTION= compat4x
-LIBCOMPATDIR= ${LIBDIR}/compat
-
LIBS= \
libc.so.4 \
libc_r.so.4 \
Re: sometimes make install does nothing
On Wed, 2002-04-17 at 21:14, Kris Kennaway wrote:
On Tue, Apr 16, 2002 at 03:31:06PM +, Jan Stocker wrote:
twoflower# make install clean
Check you
a) don't already have an .install_done cookie in the ${WRKDIR}.
As i wrote: no work dir exists, so no .install_done.
b) have an up-to-date bsd.port.mk
Freshly cvsuped the last time... but it happens always in the last days.
Jan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
What does FPU bounds check fault mean?
I got this fault on a production machine.. The given fault PC was 0xc01499f0 which is the first byte of fxpintr() (??) even though coredumps were enabled, for some reason none was made. wss0c left this message in /var/log/messages: Apr 17 08:36:55 wss0c /kernel: Fatal trap 21: FPU bounds check fault while in kernel mode Apr 17 08:36:55 wss0c /kernel: instruction pointer = 0x8:0xc01499f0 Apr 17 08:36:55 wss0c /kernel: stack pointer= 0x10:0xd9f83f9c Apr 17 08:36:55 wss0c /kernel: frame pointer= 0x10:0xbfbffc8c Apr 17 08:36:55 wss0c /kernel: code segment = base 0x0, limit 0xf, type 0x1b Apr 17 08:36:55 wss0c /kernel: = DPL 0, pres 1, def32 1, gran 1 Apr 17 08:36:55 wss0c /kernel: processor eflags = interrupt enabled, IOPL = 0 Apr 17 08:36:55 wss0c /kernel: current process = 78317 (gzip) Apr 17 08:36:55 wss0c /kernel: interrupt mask = net Apr 17 08:36:55 wss0c /kernel: trap number = 21 Apr 17 08:36:55 wss0c /kernel: panic: FPU bounds check fault Apr 17 08:36:55 wss0c /kernel: To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 ATA is very broken after sparc64 ATA mega-commit (April 5)
On Wed, Apr 17, 2002 at 20:29:02 +0200, Søren Schmidt wrote:
Have you recompiled both kernel and potential kld's ?
I just had wierd behavior here using old kld's...
I completely remove compile/{KERNEL} contents each time, so kld's is up to
date too. BTW, the bug is not on load stage but at /etc/rc stage, even
simple non-kld related commands 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: i386 ATA is very broken after sparc64 ATA mega-commit (April 5)
On Wed, Apr 17, 2002 at 21:42:19 +0200, Alexander Leidinger wrote: If you are running with tagged queing: turn it off. I got the same Thanks, turning tags off helps! It means that sparc64 ATA commit breaks tags. They work nice before it. -- 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: ATA errors on recent -current
Matthias Schuendehuette wrote: My hunch, which is why I suggested decreasing the number of tags seen by the driver, is that the tagged queues are over used, and this locks the disk up. [...] Yes, I understand this (I for myself had already your 'off-by-one'-suspicion - it's obvious if one sees the error message) and I'll test it ASAP. What I was wondering yesterday before I fell asleep is that the disk is obviously not able to recover from this error - even if the error condition is no longer valid due to the switch to PIO-mode. *Any* DMA-mode is no longer useable. My other hunch is that there will need to be a channel reserved for reset commands to be queued to the disk, so that you can queue more commands to it later (e.g. can't connect to send the reset because of the already disconnected commands in progress). This is what I was implying when I said that it involved error handling with the decoupled operations, which John Baldwin took exception to the idea (It is still my hunch...). I think that control channel commands, which aren't data commands, need to be explicitly serialized (maybe) on a reserved channel, to avoid the problem. This takes 1/N tags out of service, but guarantees that you can reset the disk drive or whatever. I don't know if it's an attribute of these disks or an issue solvable by a/the driver. I would expect to be able to do a software reset of the drive like with SCSI, but I'm a bit biased against ATA (vs. SCSI) because of the opinion/argues of a very knowledgeable guy here in the german newsgroup (former core team member ;-), so I wouldn't be surprised if that's not possible or not specified. I'm personally very biased against ATA for most production use; assuming you know your application, though, and there's not a huge concurrent access requirement, then ATA is OK (I guess), if you can live with the electrical limitations. Manually hacking the drive probe/attach to halve the number of tag queues that get used based on the reported values seems like a very quick way to validate whether it's command queue overflow, or an intrinsic problem with the drive, that's hanging you up. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
DRM in the sys/ tree: looking for testers
The DRM kernel modules (kernel support for 3d hardware acceleration through the DRI) may be integrated into our sys tree soon. I may be getting a commit bit soon to work on this. I think getting the modules in the sys tree will help keep the DRI supported on FreeBSD even if I become less active, and will help users by keeping the modules up to date with their kernels. It may also act as an incentive to keep me working on the DRI when my patches may go in sooner. So, I have been working over the last few days on integrating the modules from drm-kmod-0.9.5 into the sys tree again, and have it almost done. The files are up at the website http://gladstone.uoregon.edu/~eanholt/dri/. This also includes my current set of code for mesa4 (XFree86 CVS, DRI CVS) and TCL (DRI CVS tcl-0-0-1-branch) compatible DRM modules if anyone is interested in experimenting, though they are much less tested. For now instructions on using it are on the news page of that website. Could people test this in-kernel DRM and tell me how it works for them? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
5-current buildworld breakage?
Using 5-current code as of Apr/17/2002 15:00:00 GMT: # pwd /usr/src/gnu/usr.bin/groff/src/preproc/eqn # ident Makefile Makefile: $FreeBSD: src/gnu/usr.bin/groff/src/preproc/eqn/Makefile,v 1.3 2002/04/11 11:06:03 ru Exp $ # make -n neqn make: don't know how to make neqn. Stop # Anybody have seen this? or it's my local problem? -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: lockmgr: draining against myself
This is today's kernel. Should I test with -DDEBUG_LOCKS?
-
panic: lockmgr: draining against myself
cpuid = 1; lapic.id = 0100
Debugger(panic)
Stopped at Debugger+0x41: xorl%eax,%eax
db trace
Debugger(c029d1ba) at Debugger+0x41
panic(c029ae60,e908e780,e325cd50,0,0) at panic+0xd8
lockmgr(e908e828,10007,e908e7e8,e325cd50,e326099c) at lockmgr+0x3ef
vop_stdlock(e32609d0,e32609e0,c01c51f6,e32609d0,e908e780) at vop_stdlock+0x1f
ufs_vnoperate(e32609d0) at ufs_vnoperate+0x15
vclean(e908e780,8,e325cd50,e908e780,e3260a10) at vclean+0x62
vgonel(e908e780,e325cd50,e908e780,e909b300,e3260a48) at vgonel+0x37
vrecycle(e908e780,0,e325cd50,e908e780,e325cd50) at vrecycle+0x4b
ufs_inactive(e3260a68,e3260a78,c01c4da4,e3260a68,e8482580) at ufs_inactive+0x160
ufs_vnoperate(e3260a68) at ufs_vnoperate+0x15
vput(e908e780) at vput+0xe4
handle_workitem_freeblocks(e8482580,0,e909b300,e909b300,e325cd50) at
handle_workitem_freeblocks+0x193
softdep_setup_freeblocks(e909b300,0,0,e908e780,e909b300) at
softdep_setup_freeblocks+0x31f
ffs_truncate(e908e780,0,0,0,0) at ffs_truncate+0x240
ufs_inactive(e3260c60,e3260c70,c01c4da4,e3260c60,0) at ufs_inactive+0x91
ufs_vnoperate(e3260c60) at ufs_vnoperate+0x15
vput(e908e780,c02e3bdc,e7f65f40,e79d8000,0) at vput+0xe4
handle_workitem_remove(e7f65f40,0,e325cd50,0,0) at handle_workitem_remove+0x15f
process_worklist_item(0,0) at process_worklist_item+0x113
softdep_process_worklist(0) at softdep_process_worklist+0x106
sched_sync(0,e3260d48,e325cd50,c01c414c,0) at sched_sync+0x190
fork_exit(c01c414c,0,e3260d48) at fork_exit+0x88
fork_trampoline() at fork_trampoline+0x37
-
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc0188e4c in boot (howto=260) at ../../../kern/kern_shutdown.c:346
#2 0xc018905d in panic (fmt=0xc028c74a from debugger)
at ../../../kern/kern_shutdown.c:490
#3 0xc012f591 in db_panic (addr=-1071235275, have_addr=0, count=-1,
modif=0xe3260804 ) at ../../../ddb/db_command.c:449
#4 0xc012f52f in db_command (last_cmdp=0xc02c8fc4, cmd_table=0xc02c8de4,
aux_cmd_tablep=0xc02c31c8, aux_cmd_tablep_end=0xc02c31cc)
at ../../../ddb/db_command.c:345
#5 0xc012f5fb in db_command_loop () at ../../../ddb/db_command.c:471
#6 0xc013198f in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:72
#7 0xc0263c76 in kdb_trap (type=3, code=0, regs=0xe3260900)
at ../../../i386/i386/db_interface.c:161
#8 0xc0277c5c in trap (frame={tf_fs = -385351656, tf_es = -484048880,
tf_ds = -1072168944, tf_edi = 7, tf_esi = 256, tf_ebp = -484046520,
tf_isp = -484046548, tf_ebx = -1071010208, tf_edx = -484061872,
tf_ecx = 1, tf_eax = 18, tf_trapno = 3, tf_err = 0,
tf_eip = -1071235275, tf_cs = 8, tf_eflags = 582, tf_esp = -1070878077,
tf_ss = -1071001158}) at ../../../i386/i386/trap.c:585
#9 0xc0263f35 in Debugger (msg=0xc029d1ba panic) at machine/cpufunc.h:68
#10 0xc0189048 in panic (fmt=0xc029ae60 lockmgr: draining against myself)
at ../../../kern/kern_shutdown.c:477
#11 0xc017ef37 in lockmgr (lkp=0xe908e828, flags=65543, interlkp=0xe908e7e8,
td=0xe325cd50) at ../../../kern/kern_lock.c:427
#12 0xc01c0bef in vop_stdlock (ap=0xe32609d0)
at ../../../kern/vfs_default.c:282
#13 0xc02396bd in ufs_vnoperate (ap=0xe32609d0)
at ../../../ufs/ufs/ufs_vnops.c:2660
...
(kgdb) up 11
#11 0xc017ef37 in lockmgr (lkp=0xe908e828, flags=65543, interlkp=0xe908e7e8,
td=0xe325cd50) at ../../../kern/kern_lock.c:427
427 panic(lockmgr: draining against myself);
(kgdb) list
422 * never drain if we do. Unfortunately, we have no way to
423 * check for holding a shared lock, but at least we can
424 * check for an exclusive one.
425 */
426 if (lkp-lk_lockholder == pid)
427 panic(lockmgr: draining against myself);
428
429 error = acquiredrain(lkp, extflags);
430 if (error)
431 break;
(kgdb) up
#12 0xc01c0bef in vop_stdlock (ap=0xe32609d0)
at ../../../kern/vfs_default.c:282
282 return (lockmgr(vp-v_lock, ap-a_flags, vp-v_interlock, ap-a_td));
(kgdb) list
277 } */ *ap;
278 {
279 struct vnode *vp = ap-a_vp;
280
281 #ifndef DEBUG_LOCKS
282 return (lockmgr(vp-v_lock, ap-a_flags, vp-v_interlock, ap-a_td));
283 #else
284 return (debuglockmgr(vp-v_lock, ap-a_flags, vp-v_interlock,
285 ap-a_td, vop_stdlock, vp-filename, vp-line));
286 #endif
--
Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc.
[EMAIL PROTECTED] // FreeBSD Project
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
OT: FreeBSD-current works great!
Not really on any topic at all, so please ignore this message if you've got better things to do, but I just wanted to express my admiration of the hard-working developers and contributers of the FreeBSD project. I've mentioned my annoying workstation of weirdness (the one with the tricked up vinum volume on an ATA raid controller, among other fun things :) before, and it's been giving me USB problems running -stable, so a couple of weeks ago I decided to live on the edge and give current a try on it. After I finished the installworld, the first thing I noticed upon bootup was: Preloaded elf module acpi.ko at 0xc04960a8 acpi0: SUPERM SUPERTBL on motherboard acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi1 WTF?! I knew that ACPI on SMP systems was written in to the spec, but I've never EVER seen it actually WORK before. Even though Win2k claims to support it, it would always install using the standard MPS HAL and crap out (i.e. become a totally unusable brick needing reinstall) if I tried to manually select the ACPI one. Simply amazing! On top of the neato feature of being able to do a graceful shutdown by hitting the power button, now it actually turns itself off upon a shutdown -p, which I've also never seen work on an SMP system. I only very rarely turn this machine off anyway, but it's still very cool. My USB modem is working perfectly now, too. I had to (as usual) manually put device umodem in the kernel config, since usbd doesn't seem to know about it. Even if the usbd.conf file is fixed, it gets attached as a ugen before usbd can run and never re-attached as umodem, which is why I haven't submitted a patch for it. But at least it's working again :) My only trouble so far has been mount_smbfs panicking the machine when connecting to certain servers (but not others, weird). I'm compiling a debug kernel now and will attempt to get a good backtrace to post. Anyway, sorry for rambling and taking up everybody's time, but I'm just ecstatic that a development and unstable branch is working so well. I've been running on it for over two weeks without major incident (except for smbfs, for which the doctor says, well don't do that!). Guess I should be careful when I cvsup, huh? :) Oh, yeah. devfs rocks! cb To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-current buildworld breakage?
On Thu, Apr 18, 2002 at 10:29:23AM +0900, Makoto Matsushita wrote: Using 5-current code as of Apr/17/2002 15:00:00 GMT: # pwd /usr/src/gnu/usr.bin/groff/src/preproc/eqn # ident Makefile Makefile: $FreeBSD: src/gnu/usr.bin/groff/src/preproc/eqn/Makefile,v 1.3 2002/04/11 11:06:03 ru Exp $ # make -n neqn make: don't know how to make neqn. Stop # Anybody have seen this? or it's my local problem? Yeah, your make is broken, try rebuilding make by itself and install it then try the buildworld again -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: USB detach trouble
Hmm... I investigated the trouble a bit deeper. Now I found kernel.debug with totally same configuration can safely attach/detach all devices. Is it a matter of timing or delay stuff? FUJIMOTO Kou wrote: Hello, I CVSuped kernel src at Apr. 9 and met a trouble that I cannot detach USB devices except an UHID device... -- FUJIMOTO Kou, Tokyo Denki University To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Fatal trap 9: general protection fault while in kernel mode
Same configuration as before: netbooted dual processor box, local /usr/obj, swap, and nfs-mounted everything else. World build -j 8. crash1# make -j 8 buildworld /tmp/build.out lock order reversal 1st 0xc8e9c984 DIRHASH (UMA zone) @ ../../../vm/uma_core.c:533 2nd 0xc082aa94 PCPU KMAP ENTRY (UMA cpu) @ ../../../vm/uma_core.c:1301 Debugger(witness_lock) kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault while in kernel mode cpuid = 0; lapic.id = instruction pointer = 0x8:0xc0385dee stack pointer = 0x10:0xc9e59d40 frame pointer = 0x10:0xc9e59d78 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 10305 (cc1) kernel: type 9 trap, code=0 I believe the lock order reversal and the panic may not be related. Unfortunately, the instruction pointer provided here does not appear to correspond with any code, and I couldn't drop into the debugger so couldn't get any more information. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
WITNESS_DDB (was: Re: Fatal trap 9: general protection fault while in kernel mode)
Ah, a useful data point I forgot: the kernel has WITNESS_DDB compiled in, so it is related: Witness attempted to enter the debugger, and failed spectacularly. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Wed, 17 Apr 2002, Robert Watson wrote: Same configuration as before: netbooted dual processor box, local /usr/obj, swap, and nfs-mounted everything else. World build -j 8. crash1# make -j 8 buildworld /tmp/build.out lock order reversal 1st 0xc8e9c984 DIRHASH (UMA zone) @ ../../../vm/uma_core.c:533 2nd 0xc082aa94 PCPU KMAP ENTRY (UMA cpu) @ ../../../vm/uma_core.c:1301 Debugger(witness_lock) kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault while in kernel mode cpuid = 0; lapic.id = instruction pointer = 0x8:0xc0385dee stack pointer = 0x10:0xc9e59d40 frame pointer = 0x10:0xc9e59d78 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 10305 (cc1) kernel: type 9 trap, code=0 I believe the lock order reversal and the panic may not be related. Unfortunately, the instruction pointer provided here does not appear to correspond with any code, and I couldn't drop into the debugger so couldn't get any more information. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services 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: panic: lockmgr: draining against myself
I just got the same panic on my -current box from yesterday, also:
crash1# panic: lockmgr: draining against myself
cpuid = 0; lapic.id =
Debugger(panic)
Stopped at Debugger+0x41: xorl%eax,%eax
db trace
Debugger(c03dd41a) at Debugger+0x41
panic(c03dadc0,c9f35c30,c8f06418,0,0) at panic+0xd8
lockmgr(c9f35cd8,10007,c9f35c98,c8f06418,c8f16994) at lockmgr+0x3ef
vop_stdlock(c8f169c8,c8f169d8,c028d1b0,c8f169c8,c9f35c30) at
vop_stdlock+0x1f
ufs_vnoperate(c8f169c8) at ufs_vnoperate+0x15
vclean(c9f35c30,8,c8f06418,c9f35c30,c8f16a08) at vclean+0x64
vgonel(c9f35c30,c8f06418,c9f35c30,c9cc3000,c8f16a40) at vgonel+0x37
vrecycle(c9f35c30,0,c8f06418,c9f35c30,c8f06418) at vrecycle+0x4b
ufs_inactive(c8f16a60,c8f16a70,c028cd5e,c8f16a60,ca015600) at
ufs_inactive+0x185
ufs_vnoperate(c8f16a60) at ufs_vnoperate+0x15
vput(c9f35c30) at vput+0xea
handle_workitem_freeblocks(ca015600,0,c9cc3000,c9cc3000,c8f16c60) at
handle_workitem_freeblocks+0x193
softdep_setup_freeblocks(c9cc3000,0,0,c9f35c30,c9cc3000) at
softdep_setup_freeblocks+0x32f
ffs_truncate(c9f35c30,0,0,0,0) at ffs_truncate+0x264
ufs_inactive(c8f16c60,c8f16c70,c028cd5e,c8f16c60,0) at ufs_inactive+0xa9
ufs_vnoperate(c8f16c60) at ufs_vnoperate+0x15
vput(c9f35c30,c045bf3c,c9a47400,c982d600,0) at vput+0xea
handle_workitem_remove(c9a47400,0,c8f06418,0,0) at
handle_workitem_remove+0x172
process_worklist_item(0,0) at process_worklist_item+0x113
softdep_process_worklist(0) at softdep_process_worklist+0x106
sched_sync(0,c8f16d48,c8f06418,c028c0fc,0) at sched_sync+0x194
fork_exit(c028c0fc,0,c8f16d48) at fork_exit+0x88
fork_trampoline() at fork_trampoline+0x37
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
On Thu, 18 Apr 2002, Jun Kuriyama wrote:
This is today's kernel. Should I test with -DDEBUG_LOCKS?
-
panic: lockmgr: draining against myself
cpuid = 1; lapic.id = 0100
Debugger(panic)
Stopped at Debugger+0x41: xorl%eax,%eax
db trace
Debugger(c029d1ba) at Debugger+0x41
panic(c029ae60,e908e780,e325cd50,0,0) at panic+0xd8
lockmgr(e908e828,10007,e908e7e8,e325cd50,e326099c) at lockmgr+0x3ef
vop_stdlock(e32609d0,e32609e0,c01c51f6,e32609d0,e908e780) at vop_stdlock+0x1f
ufs_vnoperate(e32609d0) at ufs_vnoperate+0x15
vclean(e908e780,8,e325cd50,e908e780,e3260a10) at vclean+0x62
vgonel(e908e780,e325cd50,e908e780,e909b300,e3260a48) at vgonel+0x37
vrecycle(e908e780,0,e325cd50,e908e780,e325cd50) at vrecycle+0x4b
ufs_inactive(e3260a68,e3260a78,c01c4da4,e3260a68,e8482580) at ufs_inactive+0x160
ufs_vnoperate(e3260a68) at ufs_vnoperate+0x15
vput(e908e780) at vput+0xe4
handle_workitem_freeblocks(e8482580,0,e909b300,e909b300,e325cd50) at
handle_workitem_freeblocks+0x193
softdep_setup_freeblocks(e909b300,0,0,e908e780,e909b300) at
softdep_setup_freeblocks+0x31f
ffs_truncate(e908e780,0,0,0,0) at ffs_truncate+0x240
ufs_inactive(e3260c60,e3260c70,c01c4da4,e3260c60,0) at ufs_inactive+0x91
ufs_vnoperate(e3260c60) at ufs_vnoperate+0x15
vput(e908e780,c02e3bdc,e7f65f40,e79d8000,0) at vput+0xe4
handle_workitem_remove(e7f65f40,0,e325cd50,0,0) at handle_workitem_remove+0x15f
process_worklist_item(0,0) at process_worklist_item+0x113
softdep_process_worklist(0) at softdep_process_worklist+0x106
sched_sync(0,e3260d48,e325cd50,c01c414c,0) at sched_sync+0x190
fork_exit(c01c414c,0,e3260d48) at fork_exit+0x88
fork_trampoline() at fork_trampoline+0x37
-
(kgdb) where
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc0188e4c in boot (howto=260) at ../../../kern/kern_shutdown.c:346
#2 0xc018905d in panic (fmt=0xc028c74a from debugger)
at ../../../kern/kern_shutdown.c:490
#3 0xc012f591 in db_panic (addr=-1071235275, have_addr=0, count=-1,
modif=0xe3260804 ) at ../../../ddb/db_command.c:449
#4 0xc012f52f in db_command (last_cmdp=0xc02c8fc4, cmd_table=0xc02c8de4,
aux_cmd_tablep=0xc02c31c8, aux_cmd_tablep_end=0xc02c31cc)
at ../../../ddb/db_command.c:345
#5 0xc012f5fb in db_command_loop () at ../../../ddb/db_command.c:471
#6 0xc013198f in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:72
#7 0xc0263c76 in kdb_trap (type=3, code=0, regs=0xe3260900)
at ../../../i386/i386/db_interface.c:161
#8 0xc0277c5c in trap (frame={tf_fs = -385351656, tf_es = -484048880,
tf_ds = -1072168944, tf_edi = 7, tf_esi = 256, tf_ebp = -484046520,
tf_isp = -484046548, tf_ebx = -1071010208, tf_edx = -484061872,
tf_ecx = 1, tf_eax = 18, tf_trapno = 3, tf_err = 0,
tf_eip = -1071235275, tf_cs = 8, tf_eflags = 582, tf_esp = -1070878077,
tf_ss = -1071001158}) at ../../../i386/i386/trap.c:585
#9 0xc0263f35 in Debugger (msg=0xc029d1ba panic) at machine/cpufunc.h:68
#10 0xc0189048 in panic (fmt=0xc029ae60 lockmgr: draining against myself)
at ../../../kern/kern_shutdown.c:477
#11 0xc017ef37 in lockmgr (lkp=0xe908e828, flags=65543, interlkp=0xe908e7e8,
td=0xe325cd50) at
Heads up: -current sucks today :-)
I've had four seperate and distinct panics on my -current box from yesterday in the last twenty minutes. -CURRENT appears to be somewhat unstable. Yes, this is -CURRENT; please wear a hard hat and avoid manipulating critical data using you -CURRENT box until things settle down. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-current buildworld breakage?
dwcjr Yeah, your make is broken, try rebuilding make by itself and dwcjr install it then try the buildworld again Ah, sorry. I've missed what src/usr.bin/make/str.c rev 1.19 said. I just rebuilt make(1) and confirmed that it works again. Thanks. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
