Re: ATA errors on recent -current
[...] Since you have one of these beasts, could you maybe try changing the number of tagged command queue entries you permit to be used at one time? Of course, I'll do it as soon as... 1) I'm at home again... ;-) 2) Someone tells me how to achive that. I looked at 'man 8 atacontrol' as well as 'man 4 ata', but I can't find anything that lets me set the queue depth nor inquire the advertised queue length... [...] As I said: it could be drive settings unrelated to the code itself being correct. I've given three suggestions to verify this, one way or the other: 1)Control the drive DMA speed down I *did* test with UDMA66 instead of UDMA100 and it was even worse... With UDMA100, the system switched back to PIO4 - with UDMA66 there was a system freeze after the second (well known) error message... :-( But I admit, this test was done some days ago, I'll try it again this evening (approx. 19:00 UTC)... 2)Pretend the maximum tagged command queue depth is smaller than it is How to? 3)Toggle the write caching on the drive OK - I'm running all my disks without write cache, but I'll check this too. Until you try all three of these and report back, you can't say that the problem is Soren's. This is a real misunderstanding! I thought I stated clearly enough that I don't want to blame Soren for this obviously highly complex issue! Shit happens - the only ensurance against that is to stay in bed (alone! :-) Ciao/BSD - Matthias To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PAM broke?
Benno Rice [EMAIL PROTECTED] writes: I think des's commit that removed the _use_yp variable from usr.sbin/vipw/pw_util.c fixed it. I managed to get an unresolved symbol error for _use_yp out of pam with the attached patch. I have a similar patch in my tree, but dlerror() keeps returning NULL, and I've been unable to find out why :( I ended up modifying _rtld_error() in rtld.c to actually print the error message. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
In file included from /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/stb.h:45, from /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/stb.c:91: /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:45: str-1t.h: No such file or directory /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:46: str-fo.h: No such file or directory /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:47: str-io.h: No such file or directory /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:48: str-nq.h: No such file or directory /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:49: str-ot.h: No such file or directory /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:50: str-op.h: No such file or directory /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:51: str-2t.h: No such file or directory In file included from /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/stc.h:46, from /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/stc.c:70: /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:45: str-1t.h: No such file or directory /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:46: str-fo.h: No such file or directory /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:47: str-io.h: No such file or directory /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:48: str-nq.h: No such file or directory /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:49: str-ot.h: No such file or directory /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:50: str-op.h: No such file or directory /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:51: str-2t.h: No such file or directory In file included from /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/std.h:45, from /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/std.c:36: /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:45: str-1t.h: No such file or directory /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:46: str-fo.h: No such file or directory /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:47: str-io.h: No such file or directory /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:48: str-nq.h: No such file or directory /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:49: str-ot.h: No such file or directory /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:50: str-op.h: No such file or directory /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:51: str-2t.h: No such file or directory In file included from /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/ste.h:45, from /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/ste.c:40: /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:45: str-1t.h: No such file or directory /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:46: str-fo.h: No such file or directory /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:47: str-io.h: No such file or directory /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:48: str-nq.h: No such file or directory /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:49: str-ot.h: No such file or directory /.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:50: str-op.h: No such file or directory
Re: ATA errors on recent -current
Hi Terry and you all, On Tuesday, 16. April 2002 01:48 you wrote: [...] As I said: it could be drive settings unrelated to the code itself being correct. I've given three suggestions to verify this, one way or the other: 1)Control the drive DMA speed down 2)Pretend the maximum tagged command queue depth is smaller than it is 3)Toggle the write caching on the drive 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? 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...??? What was consistent thru all test was, that the disk operates quite some time until the error occures the first time. After that, it is not possible to access the disk in UDMA-Mode any more, regardeless *which* UDMA-Mode it is. 'Quite some time' means approx. 50% of /usr/ports in the above mentioned 'test'. 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! But w/o Tagged Queuing the disk operates flawlessly, so I'm a bit in doubt, if the errors with WD-disks have the same source... but may be. So far - but still some data: CPU: AMD Duron(tm) processor (801.82-MHz 686-class CPU) real memory = 268369920 (262080K bytes) pcib1: VIA 8363 (Apollo KT133) PCI-PCI (AGP) bridge \ at device 1.0 on pci0 /* It's an EPoX 8KTA2 MoBo */ atapci0: VIA 82C686 ATA100 controller port 0xd000-0xd00f \ at device 7.1 on pci0 atapci0: Correcting VIA config for southbridge data corruption bug ad0: 43979MB IBM-DTLA-307045 [89355/16/63] at ata0-master UDMA100 ...and 'atacontrol cap 0 0' says: ATA channel 0, Master, device ad0: ATA/ATAPI revision5 device model IBM-DTLA-307045 firmware revision TX6OA50C cylinders 16383 heads 16 sectors/track 63 lba supported 90069840 sectors lba48 not supported dma supported overlap not supported Feature Support EnableValue Vendor write cacheyes no read ahead yes yes dma queued yes yes 31/1F SMART yes no microcode download no no security yes no power management yes yes advanced power management yes no 0/00 automatic acoustic management yes no 254/FE 128/80 That's it. -- 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
Two VM related crashes with yesterday's -CURRENT
Two panic's in a row, on a desktop workstation, with -CURRENT
kernel and world as of Apr. 15.
I am keeping the cores for now, if any further forensics are desired.
Thomas.
# gdb -k /usr/obj/usr/src/sys/SHALMANESER/kernel.debug
3dc44d47eaf2fa5efca6d587da113787.core
GNU gdb 4.18
Copyright 1998 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-unknown-freebsd...
IdlePTD at phsyical address 0x0049f000
initial pcb at physical address 0x00398440
panicstr: bwrite: buffer is not busy???
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x11
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01d5154
stack pointer = 0x10:0xc90338cc
frame pointer = 0x10:0xc90338d8
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 = 605 (fsck_ufs)
trap number = 12
panic: page fault
syncing disks... panic: bwrite: buffer is not busy???
Uptime: 5m22s
Dumping 127 MB
ata0: resetting devices .. done
16 32 48 64 80 96 112
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
213 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
#1 0xc01df201 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:346
#2 0xc01df39d in panic (fmt=0xc031942b bwrite: buffer is not busy???)
at /usr/src/sys/kern/kern_shutdown.c:490
#3 0xc0212d8d in bwrite (bp=0xc3bf3df8) at /usr/src/sys/kern/vfs_bio.c:747
#4 0xc021337e in bawrite (bp=0xc3bf3df8) at /usr/src/sys/kern/vfs_bio.c:1063
#5 0xc0297b3d in ffs_fsync (ap=0xc9033780)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:209
#6 0xc029620a in ffs_sync (mp=0xc8611c00, waitfor=2, cred=0xc3b6c900,
td=0xc03616a0) at vnode_if.h:441
#7 0xc0221828 in sync (td=0xc03616a0, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:1217
#8 0xc01dee03 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:254
#9 0xc01df39d in panic (fmt=0xc0331e7e %s)
at /usr/src/sys/kern/kern_shutdown.c:490
#10 0xc02dfbc3 in trap_fatal (frame=0xc903388c, eva=17)
at /usr/src/sys/i386/i386/trap.c:841
#11 0xc02df90d in trap_pfault (frame=0xc903388c, usermode=0, eva=17)
at /usr/src/sys/i386/i386/trap.c:755
#12 0xc02df387 in trap (frame={tf_fs = -926547944, tf_es = 16, tf_ds = 16,
tf_edi = -926996512, tf_esi = -1070188480, tf_ebp = -922535720,
tf_isp = -922535752, tf_ebx = 0, tf_edx = 3058, tf_ecx = -926998528,
tf_eax = 1, tf_trapno = 12, tf_err = 0, tf_eip = -1071820460, tf_cs = 8,
tf_eflags = 66050, tf_esp = 0, tf_ss = -1011252296})
---Type return to continue, or q return to quit---
at /usr/src/sys/i386/i386/trap.c:426
#13 0xc01d5154 in free (addr=0xc8bf27e0, type=0xc0363840)
at /usr/src/sys/vm/uma_int.h:326
#14 0xc028d235 in indiracct (snapvp=0xc8c6fe10, cancelvp=0xc8c6fe10, level=0,
blkno=414, lbn=-12, rlbn=12, remblks=63988, blksperindir=1, fs=0xc4237000,
acctfunc=0xc028d390 mapacct, expungetype=2)
at /usr/src/sys/ufs/ffs/ffs_snapshot.c:752
#15 0xc028ce9d in expunge (snapvp=0xc8c6fe10, cancelip=0xc9062d00,
fs=0xc4237000, acctfunc=0xc028d390 mapacct, expungetype=2)
at /usr/src/sys/ufs/ffs/ffs_snapshot.c:636
#16 0xc028c798 in ffs_snapshot (mp=0xc8611600,
snapfile=0x80b0460 /var/.fsck_snapshot)
at /usr/src/sys/ufs/ffs/ffs_snapshot.c:469
#17 0xc0294bcc in ffs_mount (mp=0xc8611600, path=0xc8fea900 /var,
data=0xbfbffccc `\004\013\b9m\005\bØ\b\013\b\035, ndp=0xc9033c18,
td=0xc902e100) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:289
#18 0xc0220df9 in vfs_mount (td=0xc902e100, fstype=0xc85a33c0 ffs,
fspath=0xc8fea900 /var, fsflags=268435456, fsdata=0xbfbffccc)
at /usr/src/sys/kern/vfs_syscalls.c:916
#19 0xc02206e6 in mount (td=0xc902e100, uap=0xc9033d20)
at /usr/src/sys/kern/vfs_syscalls.c:681
#20 0xc02dfe84 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 134955942, tf_esi = -1077936948, tf_ebp = -1077936836,
tf_isp = -922534540, tf_ebx = 134955852, tf_edx = 134955776,
---Type return to continue, or q return to quit---
tf_ecx = -1077937272, tf_eax = 21, tf_trapno = 12, tf_err = 2,
tf_eip = 134558071, tf_cs = 31, tf_eflags = 518, tf_esp = -1077937120,
tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1037
#21 0xc02d27bd in syscall_with_err_pushed ()
#22 0x804c2fd in ?? ()
#23 0x8048137 in ?? ()
(kgdb) fr 13
#13 0xc01d5154 in free (addr=0xc8bf27e0, type=0xc0363840)
at /usr/src/sys/vm/uma_int.h:326
326 SLIST_FOREACH(slab, hash-uh_slab_hash[hval], us_hlink) {
(kgdb) print slab
$1 = 0x0
(kgdb) print
Re: Bluetooth stack for FreeBSD
Julian,
thanks for the comments, as always i found them very useful :)
i have combined both e-mail into one and included my answers
inline.
ng_btsocket.c: unmodified: line 674
sbappendrecord(pcb-so-so_snd, m);
m = m_dup(m, M_TRYWAIT);
if (m == NULL) {
error = ENOBUFS;
goto drop1;
}
you are m_dup'ing an mbuf you have given away to the socket layer.
on an SMP system this may already be destroyed by the time
you do the m_dup() in fact if the sbappendrecord() fails
due to a full queue, it may already be invalid...
fixed. thanks.
also all functions should be 'prototype format'
e.g.
static int
ng_btsocket_peeraddr(so, nam)
struct socket*so;
struct sockaddr **nam;
{
should be:
static int
ng_btsocket_peeraddr(struct socket *so, struct sockaddr **nam)
{
also:
__P() is now deprecated and should not be used in new code.
i should read style(9) more often. i fixed my code.
Your idea of making a special bluetooth socket type, implemented by
a Netgraph node is interesting. Maybe we should it easier to do this
by extending the netgraph socket type with the ability to
make sockets of arbitrary types... i.e. register a node type that acts
as a 'subtype' of the 'socket' type, and inherrits generic
socket behaviour, but allow the 'child type' to specify
other parts to replace normal behaviour.. I guess we would need to see a
few more cases of this done before we could deduce what is
likely to be a good candidate for abstraction.
i must admit that current socket implementation is a mess :(
my original plan was to use Netgraph sockets only and then
write several user space libraries to perform actual connection.
of course that idea had its own disadvantages. so i wrote
sockets layer. i will try to clean up it a little bit (remove
mutexes etc.) and also there probably should be support for HCI
and raw L2CAP sockets as well.
you ask:
/*
* XXX FIXME/VERIFY i assume here that hook is a pointer
* to the local hook we have received message from. For
* L2CAP messages hook is required.
*/
This is true for 5.0
in 4.x there is no such thing as an arrival hook for a message.
You should however not assume that it is non-NULL. test it in
normal running code.. not in a KASSERT.
fixed.
ok, read a bit more:
[]
Any node that changes it's internal state with reception of DATA
(as opposed to control messages) should ensure that it by doing:
NG_NODE_FORCE_WRITER(node);
This is because in the default state, multiple data messages may
(under SMP) be transitting the node at a time, as they
only take out READER locks. If DATA can change some state variable or
similar then this becomes unsafe, and they should be serialised.
If only SOME data can do this, you have the option to takew reader-locks
and only after confirming that a message is a writer, upgrade to a writer
lock by 'requeueing' it as such. Alternatively teh sender can mark a
packet as 'writer'.
initially all nodes were WRITERs to release the stack, but then i
changed my strategy and now i'm serializing data at the edge of graph.
for example both bt3c and h4 nodes will NG_HOOK_FORCE_WRITER on
upstream hook. also i probably should should turn WRITER bit on ctl
hook for HCI node since it accepts data. L2CAP node accepts whole
L2CAP packet from upstream hook, so (i think) it should be fine unless
these packets gets re-ordered somehow. protocols that run over L2CAP
may not like it.
is it possible that SMP Netgraph can re-order data? if so then sockets
node probably should turn WRITER bit on downstream hooks too.
NG_NODE_PRIVATE(NG_HOOK_NODE(hook))
can be saved if you store information relavant to a hook in it's own
private data pointer..
In some nodes I store the same data in NG_HOOK_PRIVATE(hook)
as is in NG_NODE_PRIVATE(node), just to save the dereference
if it's going to be done per packet. Sometimes there are better things to
store there however..
i'm sorry, but i'm not sure what do you mean here. i use such calls
in several places (connect, disconnect, rcvdata) to get to the node
private structure, but (i think) it just a macros that expanded to a
couple pointer accesses.
/* Detach mbuf, discard item and process data */
NGI_GET_M(item, m);
NG_FREE_ITEM(item);
If there is any chance that you will need a new 'item' in a function or a
child function, then it's worth keeping them around to save teh expense of
re-allocating them..
I guess I shuld make a macro NG_FWD_DATA_HOOK() to make this easier to
do..
you right. i should not destroy item and use NG_FWD_ITEM_HOOK where
required.
again thank you for your comments, i'm looking forward to hear more :)
thanks,
max
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Bluetooth stack for FreeBSD
On Tue, 16 Apr 2002, Maksim Yevmenkin wrote: initially all nodes were WRITERs to release the stack, but then i changed my strategy and now i'm serializing data at the edge of graph. for example both bt3c and h4 nodes will NG_HOOK_FORCE_WRITER on upstream hook. also i probably should should turn WRITER bit on ctl hook for HCI node since it accepts data. L2CAP node accepts whole L2CAP packet from upstream hook, so (i think) it should be fine unless these packets gets re-ordered somehow. protocols that run over L2CAP may not like it. is it possible that SMP Netgraph can re-order data? if so then sockets node probably should turn WRITER bit on downstream hooks too. it is not likely that data is re-ordered, but remember that data may enter the graph from different edge nodes simultaneously on different processors so that a single node may be processing both incoming and outgoing data at the same time unless the node itself is marked as needing a writer lock. NG_NODE_PRIVATE(NG_HOOK_NODE(hook)) can be saved if you store information relavant to a hook in it's own private data pointer.. In some nodes I store the same data in NG_HOOK_PRIVATE(hook) as is in NG_NODE_PRIVATE(node), just to save the dereference if it's going to be done per packet. Sometimes there are better things to store there however.. i'm sorry, but i'm not sure what do you mean here. i use such calls in several places (connect, disconnect, rcvdata) to get to the node private structure, but (i think) it just a macros that expanded to a couple pointer accesses. It's not a serious comment. just that you should be aware that one can sometimes simplify code by using the per-hook private information as well. /* Detach mbuf, discard item and process data */ NGI_GET_M(item, m); NG_FREE_ITEM(item); If there is any chance that you will need a new 'item' in a function or a child function, then it's worth keeping them around to save teh expense of re-allocating them.. I guess I shuld make a macro NG_FWD_DATA_HOOK() to make this easier to do.. you right. i should not destroy item and use NG_FWD_ITEM_HOOK where required. Netgraph is not an unchangeable work.. If you have comments on things that may mek it easier to do what you need then please let us (archie me) know.. again thank you for your comments, i'm looking forward to hear more :) thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
[EMAIL PROTECTED] wrote:
As I said: it could be drive settings unrelated to the code
itself being correct. I've given three suggestions to verify
this, one way or the other:
1)Control the drive DMA speed down
I *did* test with UDMA66 instead of UDMA100 and it was even worse...
With UDMA100, the system switched back to PIO4 - with UDMA66 there was a system
freeze after the second (well known) error message... :-(
But I admit, this test was done some days ago, I'll try it again this evening
(approx. 19:00 UTC)...
Was this with the atacontrol, or was it with the manufacturer
supplied utility, ibmatarw.exe or ibmata66.exe?
2)Pretend the maximum tagged command queue depth is
smaller than it is
How to?
Modify the source code and compile a new kernel. The code has
changed, but, ~line 180 of /sys/dev/ata/ata-disk.c:
/* use tagged queueing if allowed and supported */
if (ata_tags ad_tagsupported(adp)) {
adp-num_tags = AD_PARAM-queuelen;
adp-flags |= AD_F_TAG_ENABLED;
adp-controller-flags |= ATA_QUEUED;
Change:
adp-num_tags = AD_PARAM-queuelen;
to:
adp-num_tags = AD_PARAM-queuelen / 2;
Or just set it to some known value less than the number supported
by your drive, as indicated by the proble message.
Note that there might have been changes to the ad_tagsupported(adp)
function, in the same file. If so, it may be showing a false
positive for your drive. Here is the old code:
static int
ad_tagsupported(struct ad_softc *adp)
{
const char *drives[] = {IBM-DPTA, IBM-DTLA, NULL};
int i = 0;
switch (adp-controller-chiptype) {
case 0x4d33105a: /* Promises before TX2 doesn't work with tagged queuing */
case 0x4d38105a:
case 0x0d30105a:
case 0x4d30105a:
return 0;
}
/* check that drive does DMA, has tags enabled, and is one we know works */
if (adp-controller-mode[ATA_DEV(adp-unit)] = ATA_DMA
AD_PARAM-support.queued AD_PARAM-enabled.queued) {
while (drives[i] != NULL) {
if (!strncmp(AD_PARAM-model, drives[i], strlen(drives[i])))
return 1;
i++;
}
/*
* check IBM's new obscure way of naming drives
* we want IC (IBM CORP) and AT or AV (ATA interface)
* but doesn't care about the other info (size, capacity etc)
*/
if (!strncmp(AD_PARAM-model, IC, 2)
(!strncmp(AD_PARAM-model + 8, AT, 2) ||
!strncmp(AD_PARAM-model + 8, AV, 2)))
return 1;
}
return 0;
}
3)Toggle the write caching on the drive
OK - I'm running all my disks without write cache, but I'll check this too.
Turning write caching off makes the drive work harder, as well as
making it more reliable (just like real life: the more reliable,
the harder it works 8-)). Write caching avoids some additional
work that might otherwise slow the drive electronics.
Until you try all three of these and report back, you can't say
that the problem is Soren's.
This is a real misunderstanding! I thought I stated clearly enough that I
don't want to blame Soren for this obviously highly complex issue!
Shit happens - the only ensurance against that is to stay in bed (alone! :-)
No problem. I just wanted it made clear. The circumstances were a
before it didn't happen/after it does happen, so it loked like
there was blame being tossed.
-- Terry
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: On Tuesday, 16. April 2002 01:48 you wrote: [...] As I said: it could be drive settings unrelated to the code itself being correct. I've given three suggestions to verify this, one way or the other: 1)Control the drive DMA speed down 2)Pretend the maximum tagged command queue depth is smaller than it is 3)Toggle the write caching on the drive 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. 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...??? I rather expected you to have *more* problems with write caching than without, not the other way around. I can't explain this. What was consistent thru all test was, that the disk operates quite some time until the error occures the first time. After that, it is not possible to access the disk in UDMA-Mode any more, regardeless *which* UDMA-Mode it is. 'Quite some time' means approx. 50% of /usr/ports in the above mentioned 'test'. 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! But w/o Tagged Queuing the disk operates flawlessly, so I'm a bit in doubt, if the errors with WD-disks have the same source... but may be. 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. My best guess is an off-by-one or an exceptional condition handler that was not an issue until recently, because of a FreeBSD interrupt architecture change having nothing to do with the driver itself (i.e. the reason it only happens under load, and didn't happen under the same load, before). -- 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-2002 Terry Lambert wrote: What was consistent thru all test was, that the disk operates quite some time until the error occures the first time. After that, it is not possible to access the disk in UDMA-Mode any more, regardeless *which* UDMA-Mode it is. 'Quite some time' means approx. 50% of /usr/ports in the above mentioned 'test'. 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! But w/o Tagged Queuing the disk operates flawlessly, so I'm a bit in doubt, if the errors with WD-disks have the same source... but may be. 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. My best guess is an off-by-one or an exceptional condition handler that was not an issue until recently, because of a FreeBSD interrupt architecture change having nothing to do with the driver itself (i.e. the reason it only happens under load, and didn't happen under the same load, before). Terry, we've had threaded interrupt handlers for over a year and a half now. If the had really broken things in this basic a fashion we wouldn't have made it this far with running systems. Your hypothesis about something busted in the tagged queueing code seems sound but blaiming this on interrupt threads doesn't make much sense to me. -- 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: ATA errors on recent -current
John Baldwin 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. My best guess is an off-by-one or an exceptional condition handler that was not an issue until recently, because of a FreeBSD interrupt architecture change having nothing to do with the driver itself (i.e. the reason it only happens under load, and didn't happen under the same load, before). Terry, we've had threaded interrupt handlers for over a year and a half now. If the had really broken things in this basic a fashion we wouldn't have made it this far with running systems. Your hypothesis about something busted in the tagged queueing code seems sound but blaiming this on interrupt threads doesn't make much sense to me. The problems don't show up, except under extreme loads, with particular drives. Therefore, it is still my hunch. ;^). Dropping the queue depth to 8 from 16 to attempt to verify my hunch won't hurt anything, and may find the problem. It could still be an off-by-one error in Soren's code, as well (but I don't think it is). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PAM broke?
Dag-Erling Smorgrav wrote: Benno Rice [EMAIL PROTECTED] writes: I think des's commit that removed the _use_yp variable from usr.sbin/vipw/pw_util.c fixed it. I managed to get an unresolved symbol error for _use_yp out of pam with the attached patch. I have a similar patch in my tree, but dlerror() keeps returning NULL, and I've been unable to find out why :( I ended up modifying _rtld_error() in rtld.c to actually print the error message. Ugh. It indicates that the dlerror() symbol wasn't foind un ld.so by the glue code. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
i386 tinderbox failure
In file included from /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/stb.h:45, from /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/stb.c:91: /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:45: str-1t.h: No such file or directory /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:46: str-fo.h: No such file or directory /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:47: str-io.h: No such file or directory /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:48: str-nq.h: No such file or directory /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:49: str-ot.h: No such file or directory /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:50: str-op.h: No such file or directory /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:51: str-2t.h: No such file or directory In file included from /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/stc.h:46, from /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/stc.c:70: /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:45: str-1t.h: No such file or directory /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:46: str-fo.h: No such file or directory /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:47: str-io.h: No such file or directory /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:48: str-nq.h: No such file or directory /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:49: str-ot.h: No such file or directory /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:50: str-op.h: No such file or directory /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:51: str-2t.h: No such file or directory In file included from /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/std.h:45, from /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/std.c:36: /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:45: str-1t.h: No such file or directory /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:46: str-fo.h: No such file or directory /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:47: str-io.h: No such file or directory /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:48: str-nq.h: No such file or directory /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:49: str-ot.h: No such file or directory /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:50: str-op.h: No such file or directory /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:51: str-2t.h: No such file or directory In file included from /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/ste.h:45, from /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/ste.c:40: /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:45: str-1t.h: No such file or directory /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:46: str-fo.h: No such file or directory /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:47: str-io.h: No such file or directory /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:48: str-nq.h: No such file or directory /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:49: str-ot.h: No such file or directory /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:50: str-op.h: No such file or directory /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:51: str-2t.h: No such file or directory In file included from /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.c:35: /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:45: str-1t.h: No such file or directory /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:46: str-fo.h: No such file or directory /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:47: str-io.h: No such file or directory /d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.h:48: str-nq.h: No such file or directory
toner cartridges
Warning Unable to process data: multipart/mixed;boundary==_NextPart_000_00A1_11D12G3I.I1343N65
