Machine panics when mount_smb fs is run
Trying to mount a cdrom from my XP box using mount_smbfs //jason@desktop/cdrom /cdrom Causes my machine to panic and die. Below is hopefully some info that will help resolve the problem Included as an attachment in plain text format the boot sequence showing my hardware. The motherboard itself is An Asus CUV4X I will keep the core file itself for a few days under the name smbfs.smp-kernel.core (I seem to generate a boatload Of core files, and even on a 40 gig drive I'm running outa space fast) if anyone needs more info. grim# gdb -k /boot/kernel/kernel.debug af4e67719bcbc259bfe24101757d16e8.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 0x0043a000 initial pcb at physical address 0x00343ca0 panicstr: bremfree: bp 0xc85c52d8 not locked panic messages: --- Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x8:0xc01d2b00 stack pointer = 0x10:0xcfe82bbc frame pointer = 0x10:0xcfe82bc4 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 = 280 (smbiod0) trap number = 12 panic: page fault cpuid = 1; lapic.id = boot() called on cpu#1 syncing disks... panic: bremfree: bp 0xc85c52d8 not locked cpuid = 1; lapic.id = boot() called on cpu#1 Uptime: 1m22s Dumping 287 MB ata0: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 --- #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213 213 dumping++; (kgdb) where #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213 #1 0xc01b9088 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:346 #2 0xc01b9299 in panic (fmt=0xc02d9e9d "bremfree: bp %p not locked") at /usr/src/sys/kern/kern_shutdown.c:490 #3 0xc01e8fa1 in bremfree (bp=0xc85c52d8) at /usr/src/sys/kern/vfs_bio.c:619 #4 0xc01ea697 in vfs_bio_awrite (bp=0xc85c52d8) at /usr/src/sys/kern/vfs_bio.c:1593 #5 0xc0195198 in spec_fsync (ap=0xcfe82a70) at /usr/src/sys/fs/specfs/spec_vnops.c:403 #6 0xc0194d85 in spec_vnoperate (ap=0xcfe82a70) at /usr/src/sys/fs/specfs/spec_vnops.c:121 #7 0xc0253c2d in ffs_sync (mp=0xcf2c6200, waitfor=2, cred=0xc8571300, td=0xc0309220) at vnode_if.h:441 #8 0xc01f7257 in sync (td=0xc0309220, uap=0x0) at /usr/src/sys/kern/vfs_syscalls.c:1217 #9 0xc01b8cda in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:254 #10 0xc01b9299 in panic (fmt=0xc02f413e "%s") at /usr/src/sys/kern/kern_shutdown.c:490 #11 0xc02a4b83 in trap_fatal (frame=0xcfe82b7c, eva=0) at /usr/src/sys/i386/i386/trap.c:841 #12 0xc02a48a1 in trap_pfault (frame=0xcfe82b7c, usermode=0, eva=0) at /usr/src/sys/i386/i386/trap.c:755 #13 0xc02a442b in trap (frame={tf_fs = -806485992, tf_es = -806879216, tf_ds = -1071972336, tf_edi = 0, tf_esi = -806910956, tf_ebp = -806868028, tf_isp = -806868056, tf_ebx = -806466332, tf_edx = 1, tf_ecx = -1070532736, tf_eax = 0, tf_trapno = 12, tf_err = 2, tf_eip = -1071830272, tf_cs = 8, tf_eflags = 66118, tf_esp = -806466432, tf_ss = 1}) at /usr/src/sys/i386/i386/trap.c:426 #14 0xc01d2b00 in selrecord (selector=0xcfe78414, sip=0xcfee4ce4) at /usr/src/sys/kern/sys_generic.c:1173 #15 0xc01e347b in sopoll (so=0xcfee4c80, events=1, cred=0x0, td=0xcfe78414) at /usr/src/sys/kern/uipc_socket.c:1562 #16 0xd01c8d55 in ?? () #17 0xd01c919a in ?? () #18 0xd01c9773 in ?? () #19 0xd01ccc1f in ?? () #20 0xd01cd9dd in ?? () #21 0xc01aab0c in fork_exit (callout=0xd01cd934, arg=0xcfe09b00, frame=0xcfe82d48) at /usr/src/sys/kern/kern_fork.c:808 Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #16: Mon Apr 15 02:25:55 EDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GRIM Preloaded elf kernel "/boot/kernel/kernel" at 0xc041b000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc041b0a8. Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (870.58-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x387fbff real memory = 301973504 (294896K bytes) avail memory = 288686080 (281920K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 3, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 0, version:
Re: PAM broke?
On Tue, 2002-04-16 at 13:43, Daniel Eischen wrote: > On 16 Apr 2002, Benno Rice wrote: > > On Tue, 2002-04-16 at 10:07, Dan Eischen wrote: > > > Fresh cvsup and buildworld from today's -current seems to have > > > broken pam logins for telnet and ssh. Fresh mergemaster too. > > > > [snip] > > > > > Any clues? > > > > Remove -DYP from the CFLAGS in /usr/lib/libpam/modules/pam_unix/Makefile > > and rebuild/reinstall libpam. > > Thanks, that did the trick. > > Anyone know if this is the correct fix? It shouldn't be left > broken. 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. -- Benno Rice [EMAIL PROTECTED] Index: contrib/openpam/lib/openpam_dynamic.c === RCS file: /home/ncvs/src/contrib/openpam/lib/openpam_dynamic.c,v retrieving revision 1.1.1.2 diff -u -r1.1.1.2 openpam_dynamic.c --- contrib/openpam/lib/openpam_dynamic.c 7 Mar 2002 19:24:22 - 1.1.1.2 +++ contrib/openpam/lib/openpam_dynamic.c 16 Apr 2002 03:49:27 - @@ -67,6 +67,7 @@ *strrchr(vpath, '.') = '\0'; if ((dlh = dlopen(vpath, RTLD_NOW)) == NULL) { free(module); + openpam_log(PAM_LOG_ERROR, "%s", dlerror()); return (NULL); } } signature.asc Description: This is a digitally signed message part
Re: PAM broke?
On 16 Apr 2002, Benno Rice wrote: > On Tue, 2002-04-16 at 10:07, Dan Eischen wrote: > > Fresh cvsup and buildworld from today's -current seems to have > > broken pam logins for telnet and ssh. Fresh mergemaster too. > > [snip] > > > Any clues? > > Remove -DYP from the CFLAGS in /usr/lib/libpam/modules/pam_unix/Makefile > and rebuild/reinstall libpam. Thanks, that did the trick. Anyone know if this is the correct fix? It shouldn't be left broken. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PAM broke?
On Tue, 2002-04-16 at 10:07, Dan Eischen wrote: > Fresh cvsup and buildworld from today's -current seems to have > broken pam logins for telnet and ssh. Fresh mergemaster too. [snip] > Any clues? Remove -DYP from the CFLAGS in /usr/lib/libpam/modules/pam_unix/Makefile and rebuild/reinstall libpam. This took me about an hour to track down. =( -- Benno Rice [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Bluetooth stack for FreeBSD
On Mon, 15 Apr 2002, Julian Elischer wrote: > > [out of time for now.. will read more later] > > Julian > ok, read a bit more: you say: 2) Locking/SMP External code now uses ng_send_fn to inject data into Netgraph, so it should be fine as long as Netgraph is SMP safe. Just need to verify it. yes this is correct While Netgraph is not completely SMP safe yet, this is only because there are several nodes that do not do what you do here. By doing it corectly here you have ensured that this will not be one of the nodes that needs to be reworked when this becomes important. (soon). 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'. --- 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.. --- /* 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.. -- > > > > On Mon, 15 Apr 2002, Maksim Yevmenkin wrote: > > > Folks, > > > > [probably should be cc'd to -mobile as well] > > > > An engineering release of Bluetooth stack for -current FreeBSD > > is available for download at > > > > http://www.geocities.com/m_evmenkin/ngbt-fbsd-20020415.tar.gz > > > > i'm interested to hear from people who familiar with FreeBSD > > kernel, Netgraph and/or Bluetooth. all your questions/comments/ > > suggestions are accepted and greatly appreciated. this is my > > first Netgraph stack, so please don't me hard :) > > > > thanks, > > max > > > > 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 > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PAM broke?
Fresh cvsup and buildworld from today's -current seems to have broken pam logins for telnet and ssh. Fresh mergemaster too. Apr 15 19:59:14 rigel telnetd[285]: in openpam_load_module(): no pam_unix.so found Apr 15 19:59:14 rigel telnetd[285]: in openpam_load_module(): no pam_unix.so found Apr 15 19:59:14 rigel telnetd[285]: pam_start: failed to load module Apr 15 19:59:17 rigel telnetd[285]: in openpam_load_module(): no pam_unix.so found Apr 15 19:59:17 rigel telnetd[285]: in openpam_load_module(): no pam_unix.so found Apr 15 19:59:17 rigel telnetd[285]: pam_start: failed to load module Apr 15 19:59:27 rigel sshd[287]: in openpam_load_module(): no pam_unix.so found Apr 15 19:59:27 rigel sshd[287]: in openpam_load_module(): no pam_unix.so found Apr 15 19:59:27 rigel sshd[287]: fatal: PAM initialisation failed[1]: failed to load module -- # No pamd.conf bash-2.02$ cat /etc/pamd.conf cat: /etc/pamd.conf: No such file or directory -- bash-2.02$ cat /etc/pam.d/sshd # # $FreeBSD: src/etc/pam.d/sshd,v 1.4 2002/04/15 02:46:24 des Exp $ # # PAM configuration for the "sshd" service # # auth authrequiredpam_nologin.so no_warn authrequiredpam_unix.so no_warn try_first_pass # account account requiredpam_login_access.so account requiredpam_unix.so # session session requiredpam_lastlog.so session requiredpam_permit.so # password passwordrequiredpam_permit.so -- bash-2.02$ cat /etc/pam.d/telnetd # # $FreeBSD: src/etc/pam.d/telnetd,v 1.2 2001/12/05 21:26:00 des Exp $ # # PAM configuration for the "telnetd" service # # auth authrequiredpam_nologin.so no_warn authrequiredpam_unix.so no_warn try_first_pass # account account requiredpam_unix.so -- bash-2.02$ ls -l /usr/lib/pam*.so.2 -r--r--r-- 1 root wheel 3180 Apr 15 19:14 /usr/lib/pam_deny.so.2 -r--r--r-- 1 root wheel 5260 Apr 15 19:14 /usr/lib/pam_ftp.so.2 -r--r--r-- 1 root wheel 4840 Apr 15 19:14 /usr/lib/pam_lastlog.so.2 -r--r--r-- 1 root wheel 6684 Apr 15 19:14 /usr/lib/pam_login_access.so.2 -r--r--r-- 1 root wheel 4436 Apr 15 19:14 /usr/lib/pam_nologin.so.2 -r--r--r-- 1 root wheel 4700 Apr 15 19:14 /usr/lib/pam_opie.so.2 -r--r--r-- 1 root wheel 3852 Apr 15 19:14 /usr/lib/pam_opieaccess.so.2 -r--r--r-- 1 root wheel 39436 Apr 15 19:14 /usr/lib/pam_passwdqc.so.2 -r--r--r-- 1 root wheel 3164 Apr 15 19:14 /usr/lib/pam_permit.so.2 -r--r--r-- 1 root wheel 7432 Apr 15 19:14 /usr/lib/pam_radius.so.2 -r--r--r-- 1 root wheel 3552 Apr 15 19:14 /usr/lib/pam_rhosts.so.2 -r--r--r-- 1 root wheel 3408 Apr 15 19:14 /usr/lib/pam_rootok.so.2 -r--r--r-- 1 root wheel 3940 Apr 15 19:14 /usr/lib/pam_securetty.so.2 -r--r--r-- 1 root wheel 3668 Apr 15 19:14 /usr/lib/pam_self.so.2 -r--r--r-- 1 root wheel 9812 Apr 15 19:14 /usr/lib/pam_ssh.so.2 -r--r--r-- 1 root wheel 7276 Apr 15 19:14 /usr/lib/pam_tacplus.so.2 -r--r--r-- 1 root wheel 14972 Apr 15 19:14 /usr/lib/pam_unix.so.2 -r--r--r-- 1 root wheel 5052 Apr 15 19:14 /usr/lib/pam_wheel.so.2 Any clues? -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mouse in Xfree86 4.2.0
On Mon, Apr 15, 2002 at 03:25:12PM -0700, David O'Brien wrote: > I have requested of both the XFree86-4 Server and of Portmgr to make the > default mouse device /dev/sysmouse. But my emails have gone unanswered. They did not go unanswered. I said it was a good idea and that I would do it, but due to lack of time I haven't done it yet. This does not stop you from doing. -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm?
At 04:30 PM 4/15/2002 +0100, you wrote: >--- John Angelmo <[EMAIL PROTECTED]> wrote: > > I wonder how the pcm sound support is in 5.0? > >Hmm, I am using the emu10k1 aka Sound Blaster 1024 Live!, which has some >locking problems, but apart from that I dont think there is any other >problems AFAIK. :) > > > I didn't get it working in 4.5 but perhaps theres better support in > > 5.0 but I didn't find any info in NOTES > >What problem did you exactly have in 4.5 with the pcm support? > >Regards. > >-- >Hiten Pandya >Finger [EMAIL PROTECTED] for PGP public key >--- 4FB9 C4A9 4925 CF97 9BF3 ADDA 861D 5DBD E4E3 03C3 --- I am trying to get my SB Audigy working under -CURRENT as well. Is there going to be any support for it? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic (swp_pager_meta_ctl+0x67) in today's -CURRENT
>Date: Mon, 15 Apr 2002 15:47:32 -0700 (PDT) >From: David Wolfskill <[EMAIL PROTECTED]> >Have had a touch more turbulence than usual in -CURRENT-land today. >Finally got it built; re-booted, and got the following panic while >setting up an md-resident file system (for /tmp): [Panic stuff elided...] I was able to rebuild a kernel after backing src/sys/kern/kern_malloc.c from rev. 1.99 to 1.98; once I did that, constructing the md-resident /tmp works fine: freebeast(5.0-C)[1] uname -a FreeBSD freebeast.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #51: Mon Apr 15 16:36:21 PDT 2002 [EMAIL PROTECTED]:/common/S4/obj/usr/src/sys/FREEBEAST i386 freebeast(5.0-C)[2] df -k Filesystem 1K-blocksUsedAvail Capacity Mounted on /dev/ad0s4a158767 920625400463%/ devfs 1 10 100%/dev /dev/ad0s4e 1872759 718180 100475942%/usr /dev/ad0s4h 27728233 9500972 1600900337%/common /dev/ad0s4g 2032839 487178 138303426%/var procfs 4 40 100%/proc /dev/md10c 492972 4 453532 0%/tmp freebeast(5.0-C)[3] Since I'm running with INVARIANTS, I suppose that this was a demonstration of the truth of: ... The intent of this code is to gather statistics for tuning the malloc bucket sizes. It is not intended to be run with INVARIANTS and it is not entirely mp safe. It can be enabled via 'options MALLOC_PROFILE' which was commited earlier. --- Hmmm Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] Based on my experience as a computing professional, I consider the use of Microsoft products as components of computing systems to be just as advisable as using green wood to frame a house... and expect similar results. 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: > I still have an old FreeBSD Test-Installation (45GB are big enough :-) > with a 4.4-STABLE as of Okt 23, 2001... > > It boots off the DTLA, uses tagged-queuing and connects using UDMA100... > ... and doesn't have any problems!! > > So, to bring some of you down to earth again, the DTLA may be a > horrible disk and I'm one of the last to praise ATA at all (My machine > has two SCSI host adaptors, five SCSI-Disks and several other SCSI > Devices), but it once worked! I think we all already agree, though, that the tagged command queuing problem comes from a code change. That doesn't identify it very closely (or you would have included a patch ;^)). It may be that the OS is slower in older revisions (one would hope that was the case), and that now the code is faster, it's too fast for the hardware. It may also be that the switches between write caching on/off by default in various versions have remove stall points in the write code path which would have otherwise protected the drive from being overwhelmed by the host OS. There are a lot of possibilities for timing problems having been introduced, that don't require that Soren's code be wrong, and that it's impossible to blame the problem on the hardware. On the theory that it is an off-by-one error, introduced either by increased concurrency in an error path, or a direct off-by-one, I've suggested dropping the effective number of tagged commands supported by the drive. That way, if you exceed this number for whatever coding error reason, you won't exceed the capicty of the drive. 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? > I really, really don't want to blame Søren, he's doing a great job and > everybody, who makes something makes occasionally some errors, but (at > least for me) it doesn't seem to be a fundamental technical problem, > because *it once worked* - sorry, but it's true. > > And maybe it isn't related to tagged queuing and the DTLA at all - if I > correctly understand Giorgos' mail... 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 Until you try all three of these and report back, you can't say that the problem is Soren's. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bluetooth stack for FreeBSD
Hi... I have been reading the (well actually, "looking at" may be more acurate.. some minor comments.. 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... (I think) 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. 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. 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. There are transitional moments (during shutdown for example) when a message may arrive without a hook, in fact a malicious user might force that to happen at any time by simply send ing that message directly to the ID of the node. For messages passed by a neighbour via a hokk the hook field will be filled in but there are other ways that you may get a message. [out of time for now.. will read more later] Julian On Mon, 15 Apr 2002, Maksim Yevmenkin wrote: > Folks, > > [probably should be cc'd to -mobile as well] > > An engineering release of Bluetooth stack for -current FreeBSD > is available for download at > > http://www.geocities.com/m_evmenkin/ngbt-fbsd-20020415.tar.gz > > i'm interested to hear from people who familiar with FreeBSD > kernel, Netgraph and/or Bluetooth. all your questions/comments/ > suggestions are accepted and greatly appreciated. this is my > first Netgraph stack, so please don't me hard :) > > thanks, > max > > 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
Panic (swp_pager_meta_ctl+0x67) in today's -CURRENT
Have had a touch more turbulence than usual in -CURRENT-land today. Finally got it built; re-booted, and got the following panic while setting up an md-resident file system (for /tmp): ... add net default: gateway 172.16.8.1 Additional routing options:. Routing daemons:. Additional daemons: syslogdApr 15 15:22:09 freebeast syslogd: kernel boot file is /boot/kernel/kernel . Doing additionalO network setup: lntpdated: time_adjtime = 0.00 0 New: time_adjtime = 0.290799 290799 ntpd rpcbind. Starting final network daemons: mountdApr 15 15:22:09 freebeast mountd[182]: bad exports list line /S1/usr Apr 15 15:22:09 freebeast mountd[182]: bad exports list line /S2/usr Apr 15 15:22:09 freebeast mountd[182]: bad exports list line /S3/usr Apr 15 15:22:09 freebeast mountd[182]: bad exports list line /S4/usr Apr 15 15:22:10 freebeast mountd[182]: could not remount /cdrom: Invalid argument Apr 15 15:22:10 freebeast mountd[182]: bad exports list line /cdrom-ro -alldirs nfsd NFS access cache time=2. ELF ldconfig path: /usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/lib a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout /usr/X11R6/lib/aout Starting standard daemons: inetd cron sshd sendmail-submit sendmail-clientmqueue. Recovering vi editor sessions:. Initial rc.i386 initialization:. Configuring syscons: blanktime. Additional ABI support:. Local package initiCalization:reating DISK md10 md10: invalid primary partition table: no magic md10: invalid primary partition table: no magic er inode restric group to 6. per /dev/md10c: 1048F576 sectors in 3a2 cylinders of 1t tracks, 32768 saectors l trap 12: page fault while in kernel mode cpuid = 0; lapic.id = fault virtual address = 0x8 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0283ba7 stack pointer = 0x10:0xd911cb00 frame pointer = 0x10:0xd911cb10 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 = 229 (newfs) kernel: type 12 trap, code=0 Stopped at swp_pager_meta_ctl+0x67:cmpl%ebx,0x4(%eax) db> trace swp_pager_meta_ctl(d91363c0,1,0,ce59de70,d9120c00) at swp_pager_meta_ctl+0x67 swap_pager_strategy(d91363c0,ce59de70,d911cb60,c01492b0,d91363c0) at swap_pager_strategy+0xdf vm_pager_strategy(d91363c0,ce59de70,d911cb7c,c0149427,d9120c00) at vm_pager_strategy+0x21 mdstart_swap(d9120c00,ce59de70) at mdstart_swap+0x30 mdstrategy(ce59de70,0,ce59de70,d911cbb8,c01a2fb3) at mdstrategy+0x16f diskstrategy(ce59de70,d912bc00) at diskstrategy+0xa1 physio(d912bc00,d911cc90,1,d912bc00,d913f0f0) at physio+0x273 spec_write(d911cc24,d911cc38,c01ee513,d911cc24,1000) at spec_write+0x5d spec_vnoperate(d911cc24,1000,d911cd20,0,1) at spec_vnoperate+0x15 vn_write(d8fd2b04,d911cc90,ce51c300,0,d8fe0728) at vn_write+0x1bb dofilewrite(d8fe0728,d8fd2b04,3,808c0e0,1000) at dofilewrite+0xb6 write(d8fe0728,d911cd20,0,1000,4000) at write+0x3b syscall(2f,2f,2f,4000,1000) at syscall+0x24f syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (4, FreeBSD ELF, write), eip = 0x804cddf, esp = 0xbfbffb1c, ebp = 0xbfbffb38 --- db> Context switches not allowed in the debugger. db> Some notes: * I was able to bring it up in single-user mode OK. * The whines about inability to mount certain file systems are just that -- whines. I have the system set up to boot from any of several slices, and I have /etc/fstab set up as a symlink to the appropriate one for the slice in question (to make "cloning a slice" easier). I didn't bother also making separate /etc/exports files, figuring that the system would whine, but that the whines would be otherwise benign. So I don't advise getting too hung up on these. [Move along, now; nothing here to see] * This is my build machine, so until fairly late tonight, it doesn't have anything else to do. Thus, I can re-create the problem & poke at it, try things out, * Here's the recent CVSup activity: # tail /var/log/cvsup-history.log CVSup begin from cvsup14.freebsd.org at Fri Apr 12 06:34:50 PDT 2002 CVSup ended from cvsup14.freebsd.org at Fri Apr 12 06:41:34 PDT 2002 CVSup begin from cvsup14.freebsd.org at Sat Apr 13 03:47:02 PDT 2002 CVSup ended from cvsup14.freebsd.org at Sat Apr 13 03:55:58 PDT 2002 CVSup begin from cvsup14.freebsd.org at Sun Apr 14 03:47:02 PDT 2002 CVSup ended from cvsup14.freebsd.org at Sun Apr 14 03:53:45 PDT 2002 CVSup begin from cvsup14.freebsd.org at Mon Apr 15 03:47:02 PDT 2002 CVSup ended from cvsup14.freebsd.org at Mon Apr 15 03:53:59 PDT 2002 CVSup begin from cvsup14.freebsd.org at Mon Apr 15 12:54:16 PDT 2002 CVSup ended from cvsup14.freebsd.org at Mon Apr 15 13:00:59 PDT 2002 * The laptop is still building "everything" as I type; I don't see much point in repeating this message for it (once -CURRENT finishes buildi
Re: Mouse in Xfree86 4.2.0
On Mon, Apr 15, 2002 at 10:02:33AM +0200, John Angelmo wrote: > When I start XFree86 I get the error that /dev/mouse can't be found, OK > devfs seems to be installd so MAKEDEV dosn't exist anymore, is there > anyway to get /dev/mouse working as in FreeBSD 4? I have requested of both the XFree86-4 Server and of Portmgr to make the default mouse device /dev/sysmouse. But my emails have gone unanswered. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Vinum problems
On Mon, Apr 15, 2002 at 04:08:43PM -0500, Patrick Hartling wrote: > Bernd, > This sounds very promising, but I want to make sure I do this > correctly. When you say to remove the plexes, that means to use 'vinum rm' > with appropriate options, correct? As far as reconfiguring, can I use the > output from 'vinum printconfig' as the input configuration file? > Thanks very much for your help. You have to reduce the printconfig output to configure only the plex with the reference data first. Once it's mountable you can add the second plex as well. And don't forget to look for the reason it failed originaly. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sort and gperf
On Sat, 13 Apr 2002, Clive Lin wrote: > Hi, sort and gperf was not installed after make world. > > I think sort is easy to deal with, but I have no idea about gperf. Does > this intend to be ? (On regular i386 platform, of course) > ... > gperf: (Only gperf.info.gz installed !?) > /usr/src/gnu/usr.bin/gperf# make install > ===> doc > install-info --quiet --defsection="Programming & development tools." > --defentry="* Gperf: (gperf).The GNU perfect hash function > generator." gperf.info /usr/share/info/dir > install -c -o root -g wheel -m 444 gperf.info.gz /usr/share/info > /usr/src/gnu/usr.bin/gperf# gperf is still broken (mostly not even built). This patch has not been tested by makeworld. %%% Index: Makefile === RCS file: /home/ncvs/src/gnu/usr.bin/gperf/Makefile,v retrieving revision 1.8 diff -u -2 -r1.8 Makefile --- Makefile11 Apr 2002 11:06:06 - 1.8 +++ Makefile15 Apr 2002 21:13:30 - @@ -7,5 +7,5 @@ SUBDIR=doc -PROG_GCC= gperf +PROG_CXX= gperf SRCS= bool-array.cc gen-perf.cc hash-table.cc iterator.cc key-list.cc \ list-node.cc main.cc new.cc options.cc read-line.cc trace.cc \ %%% Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Vinum problems
Bernd, This sounds very promising, but I want to make sure I do this correctly. When you say to remove the plexes, that means to use 'vinum rm' with appropriate options, correct? As far as reconfiguring, can I use the output from 'vinum printconfig' as the input configuration file? Thanks very much for your help. -Patrick Bernd Walter wrote: > On Fri, Apr 12, 2002 at 05:46:29PM -0500, Patrick Hartling wrote: > >>I suffered a system crash earlier today running -current from April 10. >> I have a Vinum volume set up as a mirror, and during the reboot, I had >>to fsck it. Everything seemed normal (at least that's what I thought), >>but now my volume cannot be mounted. The output from 'vinum list' is as >>follows: >> >>2 drives: >>D a State: up /dev/da3s1e A: 0/12288 MB (0%) >>D b State: up /dev/da4s1e A: 0/12288 MB (0%) >> >>1 volumes: >>V mirrorState: down Plexes: 2 Size: 11 GB >> >>2 plexes: >>P mirror.p0 C State: faulty Subdisks: 1 Size: 11 GB >>P mirror.p1 C State: faulty Subdisks: 1 Size: 11 GB >> >>2 subdisks: >>S mirror.p0.s0 State: crashed D: aSize: 11 GB >>S mirror.p1.s0 State: crashed D: bSize: 11 GB >> >>The fact that it says the drives have 0% used greatly concerns me. >>Before I delve into this any further, is that a sign that everything I >>had is just gone? Or is there some hope of recovery? There is nothing >>in /var/log/vinum_hitsory or /var/log/messages that gives me any insight >>into what went wrong. > > > You have *both* plexes faulty which means that you either have waited > too long running with only one disk left or that both failed a once. > For the second point can be channel or power supply issues if they > share a single resource in common. > You will find it out by reading your log files. > Of course you should fix the failure reason before doing anything else. > > I have made a bad expirience once in that if you revive one plex > now you will get zeros written because there is no reference plex left. > Greg: It's long ago but I forgot to tell you. > Do you remember anything about such a bug got fixed? > > The shure way is to store the vinum printconfig output and then > remove both plexes. > finaly reconfigure them both beginning using the values from printconfig > and start with the drive which run at last, because it has the most > recent data. > -- Patrick L. Hartling | Research Assistant, VRAC [EMAIL PROTECTED] | 2624 Howe Hall -- (515)294-4916 http://www.137.org/patrick/ | http://www.vrac.iastate.edu/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Bluetooth stack for FreeBSD
Folks, [probably should be cc'd to -mobile as well] An engineering release of Bluetooth stack for -current FreeBSD is available for download at http://www.geocities.com/m_evmenkin/ngbt-fbsd-20020415.tar.gz i'm interested to hear from people who familiar with FreeBSD kernel, Netgraph and/or Bluetooth. all your questions/comments/ suggestions are accepted and greatly appreciated. this is my first Netgraph stack, so please don't me hard :) 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
I'm very sorry if I will be a bit unpolite, but I have to mail the following statement concerning the DTLA-Disks and FreeBSD: It may be all true and horrible, but - I still have an old FreeBSD Test-Installation (45GB are big enough :-) with a 4.4-STABLE as of Okt 23, 2001... It boots off the DTLA, uses tagged-queuing and connects using UDMA100... ... and doesn't have any problems!! So, to bring some of you down to earth again, the DTLA may be a horrible disk and I'm one of the last to praise ATA at all (My machine has two SCSI host adaptors, five SCSI-Disks and several other SCSI Devices), but it once worked! I really, really don't want to blame Søren, he's doing a great job and everybody, who makes something makes occasionally some errors, but (at least for me) it doesn't seem to be a fundamental technical problem, because *it once worked* - sorry, but it's true. And maybe it isn't related to tagged queuing and the DTLA at all - if I correctly understand Giorgos' mail... -- 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: plug aue ethernet goes to panic
On Mon, Apr 15, 2002 at 21:57 +0900, Makoto Matsushita wrote: > > But unfortunately, my kernel.debug prints > > uhub0: device problem, disabling port 2 > > and doesn't panic :-( Oh, how I know this message ... :) Does http://www.FreeBSD.org/cgi/query-pr.cgi?pr=33004 help you here? It has patches for uhci as well as ohci to make this message disappear. At least it worked for me and the PR's originator. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: plug aue ethernet goes to panic
On Mon, Apr 15, 2002 at 12:35:46PM -0500, Will Andrews wrote: > On Mon, Apr 15, 2002 at 11:11:36AM +0200, Nick Hibma wrote: > > device_set_ivars is always called (in usbd_probe_and_attach) with as an > > argument a stack variable. Also, the ivar is not stored or anything in > > the if_aue.c driver. So this problem sounds like a problem in revisions > > of various files. > > > > Please check that your kernel modules kernel are in sync. Do this by > > rebuilding the kernel and the modules from scratch. > > > > Also, after you've installed your kernel check that all your kernel > > files have been updated. Do you by any chance have a stale /modules or > > /boot/modules directory lying around? You should have only kernel > > modules in /boot/kernel*/ and NOT in /modules* or /boot/modules*. > > > > If the problem persists, please mail me the output of > > > > ident /sys/dev/usb/*.[ch] > > find /modules /boot -type f -ls > > Nick, > > You really should talk to Joe Karthauser. He's already confirmed > that it *is* an issue in the code (and not any kind of > misconfiguration on my part). I've already spent enough time > debugging the problem. I recently MFC'd the support for my > device to -stable so I could use the machine on the network > without it panicking on me. However, when Joe fixes the problem > I will give it another shot [same machine has -CURRENT on another > partition that I use for occasional hacking]. Nick, I've introduced a probe and attach bug somewhere with aue, and I'm guessing with cue and kue too. I'm gradually getting to the bottom of it, but this is the first time I've gone near the attach code so it's taking me longer than it should. Joe msg37291/pgp0.pgp Description: PGP signature
Re: plug aue ethernet goes to panic
On Mon, Apr 15, 2002 at 11:11:36AM +0200, Nick Hibma wrote: > device_set_ivars is always called (in usbd_probe_and_attach) with as an > argument a stack variable. Also, the ivar is not stored or anything in > the if_aue.c driver. So this problem sounds like a problem in revisions > of various files. > > Please check that your kernel modules kernel are in sync. Do this by > rebuilding the kernel and the modules from scratch. > > Also, after you've installed your kernel check that all your kernel > files have been updated. Do you by any chance have a stale /modules or > /boot/modules directory lying around? You should have only kernel > modules in /boot/kernel*/ and NOT in /modules* or /boot/modules*. > > If the problem persists, please mail me the output of > > ident /sys/dev/usb/*.[ch] > find /modules /boot -type f -ls Nick, You really should talk to Joe Karthauser. He's already confirmed that it *is* an issue in the code (and not any kind of misconfiguration on my part). I've already spent enough time debugging the problem. I recently MFC'd the support for my device to -stable so I could use the machine on the network without it panicking on me. However, when Joe fixes the problem I will give it another shot [same machine has -CURRENT on another partition that I use for occasional hacking]. Thanks for the suggestions, though. Regards, -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm?
Hiten Pandya wrote: > --- John Angelmo <[EMAIL PROTECTED]> wrote: > >>I wonder how the pcm sound support is in 5.0? > > > Hmm, I am using the emu10k1 aka Sound Blaster 1024 Live!, which has some > locking problems, but apart from that I dont think there is any other > problems AFAIK. :) > > >>I didn't get it working in 4.5 but perhaps theres better support in >>5.0 but I didn't find any info in NOTES > > > What problem did you exactly have in 4.5 with the pcm support? > Well I don't have any dmesg log from my old install. I use ac97 > Regards. > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA errors on recent -current
Giorgos Keramidas wrote: > On 2002-04-14 23:46, Terry Lambert wrote: > > Is your drive perchance an IBM DTLA? > > It's known to have these problems. > > Nay. A Western Digital disk I bought about 2.5 years ago. Well that shoots that idea down. Try hacking the code to limit it to 3/4ths the number of tagged commands as reported by the drive. It may be that the code is using more tags than it's allowed to because of some error handling or other condition (e.g. soft interrupt, etc.). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Build busted?
On Mon, 15 Apr 2002, M. Warner Losh wrote: :In message: <[EMAIL PROTECTED]> :Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes: :: Check that your Makefile.inc1 is up to date. : :ah, looks like I didn't. Will update and try again. : -- Andrew R. Reiter [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm?
--- John Angelmo <[EMAIL PROTECTED]> wrote: > I wonder how the pcm sound support is in 5.0? Hmm, I am using the emu10k1 aka Sound Blaster 1024 Live!, which has some locking problems, but apart from that I dont think there is any other problems AFAIK. :) > I didn't get it working in 4.5 but perhaps theres better support in > 5.0 but I didn't find any info in NOTES What problem did you exactly have in 4.5 with the pcm support? Regards. -- Hiten Pandya Finger [EMAIL PROTECTED] for PGP public key --- 4FB9 C4A9 4925 CF97 9BF3 ADDA 861D 5DBD E4E3 03C3 --- msg37284/pgp0.pgp Description: PGP signature
Re: Build busted?
In message: <[EMAIL PROTECTED]> Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes: : Check that your Makefile.inc1 is up to date. ah, looks like I didn't. Will update and try again. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Build busted?
"M. Warner Losh" <[EMAIL PROTECTED]> writes: > make: don't know how to make /usr/obj/home/imp/FreeBSD/src/i386/usr/lib/libypcln Check that your Makefile.inc1 is up to date. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Build busted?
===> libpam/modules/pam_unix cc -fpic -DPIC -O -pipe -DYP -I. -I/home/imp/FreeBSD/src/lib/libpam/modules/pam_unix/../../../../usr.sbin/vipw -I/home/imp/FreeBSD/src/lib/libpam/modules/pam_unix/../../../../usr.bin/chpass -I/home/imp/FreeBSD/src/lib/libpam/modules/pam_unix/../../../../lib/libc/gen -I/home/imp/FreeBSD/src/lib/libpam/modules/pam_unix/../../../../contrib/openpam/include -I/home/imp/FreeBSD/src/lib/libpam/modules/pam_unix/../../libpam -Werror -Wall -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /home/imp/FreeBSD/src/lib/libpam/modules/pam_unix/../../../../usr.sbin/vipw/pw_util.c -o pw_util.So make: don't know how to make /usr/obj/home/imp/FreeBSD/src/i386/usr/lib/libypcln This is on a 4.5-PRERELEASE (RELEASE - 2 days) system building -current. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA errors on recent -current
On 2002-04-15 15:56, S&psgr;ren Schmidt wrote: > It seems Giorgos Keramidas wrote: > > On 2002-04-14 23:46, Terry Lambert wrote: > > > Is your drive perchance an IBM DTLA? > > > It's known to have these problems. > > > > Nay. A Western Digital disk I bought about 2.5 years ago. > > Hmm, AFAIK WD newer had a disk that worked right with tags, > and I've newer been able to find a workaround on those I > have here in the lab It doesn't. You're right. I had posted that message before checking with `atacontrol cap'. My problems with the disk are obviously caused by something else that's broken in my local setup. Sorry for jumping up and making noise :) The console messages I'm getting were similar: | Apr 12 00:09:27 hades kernel: ad0: READ command timeout tag=0 serv=0 - resetting | Apr 12 00:09:28 hades kernel: ata0: resetting devices .. ata0-slave: ATA identify |retries exceeded | Apr 12 00:09:28 hades kernel: done This is caused by something else, as I've found out later. Tags have nothing to do with what I'm seeing. Before saying "hey, this is a bug" I want to do further tests to make sure that it's not the hardware's fault. Giorgos. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
pcm?
I wonder how the pcm sound support is in 5.0? I didn't get it working in 4.5 but perhaps theres better support in 5.0 but I didn't find any info in NOTES /John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mouse in Xfree86 4.2.0
Hiten Pandya wrote: > --- Gary Stanley <[EMAIL PROTECTED]> wrote: > >>Sysinstall - post configure and re-do your mouse. The only workaround I >>have found. > > > The other way, is to edit your XF86Config to point to > /dev/pcm0 (if you are using a PS2 mouse), or /dev/sioN (N being the COM port > number), which gives XFree86 direct access to your mouse. But remember, if > you do this, you will need to disable the moused from Sysinstall. > > >>>When I start XFree86 I get the error that /dev/mouse can't be found, OK >>>devfs seems to be installd so MAKEDEV dosn't exist anymore, is there >>>anyway to get /dev/mouse working as in FreeBSD 4? >> > > Technically the MAKEDEV script still exists in src/etc/MAKEDEV*, but it > is only copied to /dev if you have disabled the DEVFS k-option, afaik. > > -- Hiten Pandya > -- <[EMAIL PROTECTED]> > > __ > Do You Yahoo!? > Yahoo! Tax Center - online filing with TurboTax > http://taxes.yahoo.com/ > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message /dev/sysmouse woked best for me since I have both a USB mouse and a touchpad so with /dev/sysmouse both works. /John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mouse in Xfree86 4.2.0
--- Gary Stanley <[EMAIL PROTECTED]> wrote: > Sysinstall - post configure and re-do your mouse. The only workaround I > have found. The other way, is to edit your XF86Config to point to /dev/pcm0 (if you are using a PS2 mouse), or /dev/sioN (N being the COM port number), which gives XFree86 direct access to your mouse. But remember, if you do this, you will need to disable the moused from Sysinstall. > >When I start XFree86 I get the error that /dev/mouse can't be found, OK > >devfs seems to be installd so MAKEDEV dosn't exist anymore, is there > >anyway to get /dev/mouse working as in FreeBSD 4? Technically the MAKEDEV script still exists in src/etc/MAKEDEV*, but it is only copied to /dev if you have disabled the DEVFS k-option, afaik. -- Hiten Pandya -- <[EMAIL PROTECTED]> __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Testers for an icc compiled kernel wanted
--- Alexander Leidinger <[EMAIL PROTECTED]> wrote: > Hi, > > I've got a lot of LINT compiled with icc. If someone feels > adventuresomely he may grab > http://www.leidinger.net/FreeBSD/icc_20020415.diff, apply it, and do a FYI, You need to rename your online patch from icc_2020415.diff to icc_20020415.diff. ;) I accessed with the below URL: http://www.leidinger.net/FreeBSD/icc_2020415.diff Hope that helps. Regards, -- Hiten __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mouse in Xfree86 4.2.0
I had this similiar problem. Sysinstall - post configure and re-do your mouse. The only workaround I have found. /ges At 10:02 AM 4/15/2002 +0200, John Angelmo wrote: >Hello > >When I start XFree86 I get the error that /dev/mouse can't be found, OK >devfs seems to be installd so MAKEDEV dosn't exist anymore, is there >anyway to get /dev/mouse working as in FreeBSD 4? > >Thanks > >/John > > >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
Testers for an icc compiled kernel wanted
Hi, I've got a lot of LINT compiled with icc. If someone feels adventuresomely he may grab http://www.leidinger.net/FreeBSD/icc_20020415.diff, apply it, and do a cd /sys/i386/compile/ make clean && make depend make -i CWARNFLAGS="" NO_WARNS="YES" USE_ICC="YES" I'm interested in everything he may find out (no need to report things I already know: http://www.leidinger.net/FreeBSD/LINT_with_icc_20020415.log.bz2), even the good ones (e.g. a working kernel :-) ). Patches welcome, off course. If someone has some spare time he wants to spend to making the kernel compilable with icc: find places where opt_global.h is needed and add an include directive (it has to be the first one) for it. Bye, Alexander. -- It's not a bug, it's tradition! 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
It seems Giorgos Keramidas wrote: > On 2002-04-14 23:46, Terry Lambert wrote: > > Is your drive perchance an IBM DTLA? > > It's known to have these problems. > > Nay. A Western Digital disk I bought about 2.5 years ago. Hmm, AFAIK WD newer had a disk that worked right with tags, and I've newer been able to find a workaround on those I have here in the lab -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA errors on recent -current
On 15 Apr, Giorgos Keramidas wrote: >> Is your drive perchance an IBM DTLA? >> It's known to have these problems. > > Nay. A Western Digital disk I bought about 2.5 years ago. And it does tagged queing? I thought IBM is the only manufacturer of such IDE drives... Bye, Alexander. -- The dark ages were caused by the Y1K problem. 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
Error on make
Good afternoon After upgrading FREEBSD to version 4.5 STABLE can't make any port. Always it's stoped with error: Error: your port uses an old layout. Please update it to match this bsd.port.mk . If you have updated your ports collection via cvsup and are still getting thi s error, see Q12 and Q13 in the cvsup FAQ on http://www.polstra.com for further information. *** Error code 1 I've downloaded new ports by CVSUP but problem remains. supfile: *default host=cvsup2.ca.FreeBSD.org *default base=/usr *default prefix=/usr *default release=cvs tag=. *default delete use-rel-suffix *default compress ports-all release=cvs How can I fix this problem? -- Best regards, Vadim Zaychenko mailto:[EMAIL PROTECTED] ICQ: 92369162 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA errors on recent -current
On 2002-04-14 23:46, Terry Lambert wrote: > Is your drive perchance an IBM DTLA? > It's known to have these problems. Nay. A Western Digital disk I bought about 2.5 years ago. G. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: This mornings world broken in libpam modules.
Le 2002-04-15, Edwin Culp écrivait : > This could already be fixed but if not, mine broke at: It is fixed in Makefile.inc1 rev. 1.256. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
This mornings world broken in libpam modules.
This could already be fixed but if not, mine broke at: /lib/libpam/modules/pam_unix/../../../../contrib/openpam/include -I/usr/src/lib/libpam/modules/pam_unix/../../libpam -Werror -Wall -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /usr/src/lib/libpam/modules/pam_unix/../../../../usr.sbin/vipw/pw_util.c -o pw_util.So make: don't know how to make /usr/obj/usr/src/i386/usr/lib/libypclnt.a. Stop *** Error code 2 Stop in /usr/src/lib/libpam/modules. *** Error code 1 Stop in /usr/src/lib/libpam. *** Error code 1 ed - http://insourcery.com - Mergence of Business and Technology a "Griffin Plaza Partners, LLC" Company To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA errors on recent -current
On 15 Apr, Søren Schmidt wrote: > Again that has *nothing* to do with the DTLA drives and DMA speed > and the phase of the moon... But perhaps it depends on the distance between the drive and the nordpole... the ones with the problems are all more far away from it than you... ;-) > But it shows (as we already know) that using tags on any drive > that supports it, can fail on some systems. More strangely: it worked for me a lot longer than for other people. The first kernel which showed the problem to me was a Apr 8(?) kernel, Martin Schündehütte complained already with a Mar xx (xx < 28) kernel in de.comp.os.unix.bsd. >> I wonder if limiting outstanding tagged commands to less than the >> number advertised by the drive would also work... can't be worse >> than the initialization reordering patch that failed (e.g the >> worst case is it still has the problems). A lot safer than banging >> bits in the firmware, I'm sure, though... >> >> Limiting the outstanding tagged commands to less than the advertised >> amount would actually be my first choice of a hack for a software >> workaround. > > Thats not the problem either, the problem is that I apparently > changed some subtle bits that make it fail on some systems, regardless > of controller and disk type, but which is marginal enough that I > cant reproduce the problem here in the lab... What about Brian's offer to give you access to his machine? Isn't this enough in this case to play a little bit? Bye, Alexander. -- The best things in life are free, but the expensive ones are still worth a look. 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
On 15 Apr, Terry Lambert wrote: > Obviously, turning off tagged commands works, according to at least > one person who is reporting the problem. It helps every one I know of. [...] > Limiting the outstanding tagged commands to less than the advertised > amount would actually be my first choice of a hack for a software > workaround. > > Can you do that with "sysctl hw.ata.tags=XXX"? Or is that just a 1/0 > thing? A scan doesn't indicate documentation, but I'm probably just > not looking very hard... It's only a 1/0 thing (at least at the moment). Bye, Alexander. -- To boldly go where I surely don't belong. 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
It seems Terry Lambert wrote: > "Søren Schmidt" wrote: > > > For a more "scientific test", downloading the firmware tool and > > > setting the DMA transfer rate down, and checking for problems, > > > would be pretty overwhelming evidence. Personally, I don't have > > > any of the buggers lying around to test with any more. > > > > Why on earth would you do that ? (hint man atacontrol) > > > > Besides I dont see this as any evidence at all, but thats another matter... > > If it fixes the problem, then the problem is most likely related > to what firmware setting the tool changes. AFAIK it only set the maximum DMA speed the drive will allow, that you can do with atacontrol as well... > Obviously, turning off tagged commands works, according to at least > one person who is reporting the problem. Again that has *nothing* to do with the DTLA drives and DMA speed and the phase of the moon... But it shows (as we already know) that using tags on any drive that supports it, can fail on some systems. > I wonder if limiting outstanding tagged commands to less than the > number advertised by the drive would also work... can't be worse > than the initialization reordering patch that failed (e.g the > worst case is it still has the problems). A lot safer than banging > bits in the firmware, I'm sure, though... > > Limiting the outstanding tagged commands to less than the advertised > amount would actually be my first choice of a hack for a software > workaround. Thats not the problem either, the problem is that I apparently changed some subtle bits that make it fail on some systems, regardless of controller and disk type, but which is marginal enough that I cant reproduce the problem here in the lab... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: plug aue ethernet goes to panic
jhb> Can you get a backtrace in ddb? It looks like a null pointer jhb> dereference, and knowing where it happened would help. Backtrace told me that the panic was occured when usbd_get_interface_descriptor() is called from aue_attach(). jhb> Finding the file and line of the instruction pointer using jhb> addr2line on kernel.debug would be helpful as well. But unfortunately, my kernel.debug prints uhub0: device problem, disabling port 2 and doesn't panic :-( *** I've confirmed that kernel and its module are in sync. There no /modules directory since this machine was born as 5-current box, and /boot/modules directory is empty. ident(1) output of src/sys/dev/usb is attached below. -- - Makoto `MAR' Matsushita /sys/dev/usb/dsbr100io.h: $FreeBSD: src/sys/dev/usb/dsbr100io.h,v 1.1 2002/03/04 03:51:19 alfred Exp $ /sys/dev/usb/hid.c: $NetBSD: hid.c,v 1.17 2001/11/13 06:24:53 lukem Exp $ $FreeBSD: src/sys/dev/usb/hid.c,v 1.18 2002/04/07 17:53:58 joe Exp $ /sys/dev/usb/hid.h: $NetBSD: hid.h,v 1.6 2000/06/01 14:28:57 augustss Exp $ $FreeBSD: src/sys/dev/usb/hid.h,v 1.11 2002/04/01 19:01:08 joe Exp $ /sys/dev/usb/if_aue.c: $FreeBSD: src/sys/dev/usb/if_aue.c,v 1.56 2002/04/07 12:19:50 joe Exp $ $FreeBSD: src/sys/dev/usb/if_aue.c,v 1.56 2002/04/07 12:19:50 joe Exp $ /sys/dev/usb/if_auereg.h: $FreeBSD: src/sys/dev/usb/if_auereg.h,v 1.13 2002/04/07 12:04:01 joe Exp $ /sys/dev/usb/if_cue.c: $FreeBSD: src/sys/dev/usb/if_cue.c,v 1.28 2002/04/07 12:19:50 joe Exp $ $FreeBSD: src/sys/dev/usb/if_cue.c,v 1.28 2002/04/07 12:19:50 joe Exp $ /sys/dev/usb/if_cuereg.h: $FreeBSD: src/sys/dev/usb/if_cuereg.h,v 1.10 2002/04/07 12:04:01 joe Exp $ /sys/dev/usb/if_kue.c: $FreeBSD: src/sys/dev/usb/if_kue.c,v 1.40 2002/04/07 12:19:50 joe Exp $ $FreeBSD: src/sys/dev/usb/if_kue.c,v 1.40 2002/04/07 12:19:50 joe Exp $ /sys/dev/usb/if_kuereg.h: $FreeBSD: src/sys/dev/usb/if_kuereg.h,v 1.10 2002/04/07 12:04:02 joe Exp $ /sys/dev/usb/kue_fw.h: $FreeBSD: src/sys/dev/usb/kue_fw.h,v 1.2 2000/04/03 20:58:23 n_hibma Exp $ /sys/dev/usb/ohci.c: $NetBSD: ohci.c,v 1.121 2002/03/16 16:11:18 tsutsui Exp $ $FreeBSD: src/sys/dev/usb/ohci.c,v 1.102 2002/04/07 16:36:30 joe Exp $ /sys/dev/usb/ohcireg.h: $NetBSD: ohcireg.h,v 1.17 2000/04/01 09:27:35 augustss Exp $ $FreeBSD: src/sys/dev/usb/ohcireg.h,v 1.18 2002/04/01 13:21:43 joe Exp $ /sys/dev/usb/ohcivar.h: $NetBSD: ohcivar.h,v 1.30 2001/12/31 12:20:35 augustss Exp $ $FreeBSD: src/sys/dev/usb/ohcivar.h,v 1.32 2002/04/07 15:16:31 joe Exp $ /sys/dev/usb/rio500_usb.h: $FreeBSD: src/sys/dev/usb/rio500_usb.h,v 1.1 2000/04/08 17:02:13 n_hibma Exp $ /sys/dev/usb/ucom.c: $NetBSD: ucom.c,v 1.39 2001/08/16 22:31:24 augustss Exp $ $FreeBSD: src/sys/dev/usb/ucom.c,v 1.16 2002/04/01 21:30:36 jhb Exp $ /sys/dev/usb/ucomvar.h: $NetBSD: ucomvar.h,v 1.9 2001/01/23 21:56:17 augustss Exp $ $FreeBSD: src/sys/dev/usb/ucomvar.h,v 1.1 2002/03/18 18:23:39 joe Exp $ /sys/dev/usb/udbp.c: $FreeBSD: src/sys/dev/usb/udbp.c,v 1.14 2002/04/04 21:03:17 jhb Exp $ /sys/dev/usb/udbp.h: $FreeBSD: src/sys/dev/usb/udbp.h,v 1.1 2000/05/01 22:48:22 n_hibma Exp $ /sys/dev/usb/ufm.c: $FreeBSD: src/sys/dev/usb/ufm.c,v 1.4 2002/03/11 16:38:53 imp Exp $ /sys/dev/usb/ugen.c: $NetBSD: ugen.c,v 1.51 2001/11/13 07:59:32 augustss Exp $ $FreeBSD: src/sys/dev/usb/ugen.c,v 1.59 2002/03/11 16:22:15 joe Exp $ /sys/dev/usb/ugraphire_rdesc.h: $NetBSD: usb/ugraphire_rdesc.h,v 1.1 2000/12/29 01:47:49 augustss Exp $ $FreeBSD: src/sys/dev/usb/ugraphire_rdesc.h,v 1.1 2002/04/07 17:04:01 joe Exp $ /sys/dev/usb/uhci.c: $NetBSD: uhci.c,v 1.158 2002/03/17 18:02:53 augustss Exp $ $FreeBSD: src/sys/dev/usb/uhci.c,v 1.119 2002/04/07 18:33:12 joe Exp $ /sys/dev/usb/uhcireg.h: $NetBSD: uhcireg.h,v 1.15 2002/02/11 11:41:30 augustss Exp $ $FreeBSD: src/sys/dev/usb/uhcireg.h,v 1.20 2002/04/07 18:06:34 joe Exp $ /sys/dev/usb/uhcivar.h: $NetBSD: uhcivar.h,v 1.33 2002/02/11 11:41:30 augustss Exp $ $FreeBSD: src/sys/dev/usb/uhcivar.h,v 1.33 2002/04/07 18:06:34 joe Exp $ /sys/dev/usb/uhid.c: $NetBSD: uhid.c,v 1.45 2001/10/26 17:58:21 augustss Exp $ $FreeBSD: src/sys/dev/usb/uhid.c,v 1.49 2002/04/07 17:13:00 joe Exp $ /sys/dev/usb/uhub.c: $NetBSD: uhub.c,v 1.57 2001/11/20 16:08:37 augustss Exp $ $FreeBSD: src/sys/dev/usb/uhub.c,v 1.42 2002/04/07 11:29:31 joe Exp $ /sys/dev/usb/ukbd.c: $FreeBSD: src/sys/dev/usb/ukbd.c,v 1.37 2002/04/07 13:16:17 joe Exp $ /sys/dev/usb/ulpt.c: $NetBSD: ulpt.c,v 1.46 2001/12/31 12:15:21 augustss Exp $ $FreeBSD: src/sys/dev/usb/ulpt.c,v 1.43 2002/03/11 16:22:15 joe Exp $ /sys/dev/usb/umass.c: $FreeBSD: src/sys/dev/usb/umass.c,v 1.60 2002/04/11 21:09:41 jhb Exp $ $NetBSD: umass.c,v 1.28 2000/04/02 23:46:53 augustss Exp $ /sys/dev/usb/umodem.c: $NetBSD: umodem.c,v 1.5 1999/0
Re: ATA errors on recent -current
"Søren Schmidt" wrote: > > For a more "scientific test", downloading the firmware tool and > > setting the DMA transfer rate down, and checking for problems, > > would be pretty overwhelming evidence. Personally, I don't have > > any of the buggers lying around to test with any more. > > Why on earth would you do that ? (hint man atacontrol) > > Besides I dont see this as any evidence at all, but thats another matter... If it fixes the problem, then the problem is most likely related to what firmware setting the tool changes. 8-). From my reading of the FreeBSD man pages, it can't blow the flash byte that controls the DMA speed, like the IBM provided utility does. Obviously, turning off tagged commands works, according to at least one person who is reporting the problem. I wonder if limiting outstanding tagged commands to less than the number advertised by the drive would also work... can't be worse than the initialization reordering patch that failed (e.g the worst case is it still has the problems). A lot safer than banging bits in the firmware, I'm sure, though... Limiting the outstanding tagged commands to less than the advertised amount would actually be my first choice of a hack for a software workaround. Can you do that with "sysctl hw.ata.tags=XXX"? Or is that just a 1/0 thing? A scan doesn't indicate documentation, but I'm probably just not looking very hard... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA errors on recent -current
The models with lines looking like: ad0: 19073MB [38752/16/63] at ata0-master UDMA100 are of the 60GXP range, the DTLA model numbers indicate the 75GXP range, one of which has already died on me personally. hth Andrew - Original Message - From: "Terry Lambert" <[EMAIL PROTECTED]> To: "Alexander Leidinger" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, April 15, 2002 12:53 PM Subject: Re: ATA errors on recent -current > Alexander Leidinger wrote: > > >> >> Some people see this after the "mega" MFC on -stable too. > > >> > Could I have you guys try this simple patch ? > > >> Does not work. > > > No change or breaks completely (if so how)... > > Sorry: "No change". > > Download the Windows executable I pointed to in a previous posting. > Run it. It will create a floppy disk. > > Using the floppy, set the DMA transfer rate slower on the drive. > > STANDARD WARNINGS APPLY! MAY HOSE YOUR DISK FIRMWARE IRRETRIEVABLY > IF NOT USED CORRECTLY! FOLLOW THE IBM SUPPLIED INSTRUCTIONS TO THE > LETTER! I AM NOT RESPONSIBLE FOR WHA?T HAPPENS TO YOUR DISK IF YOU > USE THE TOOL! > > -- Terry > > 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: ATA errors on recent -current
It seems Terry Lambert wrote: > > > IBM DTLA drives are known to be problematic. If you use that > > > in a search engine, it will find numerous references to the > > > drive electronics being too slow for sustained access to the > > > sectors closes to the spindle. > > > > This thread is about tagged queueing problems on IBM drives since they > > are the only ones that supports it, it is not specific to the DTLA > > series at all, which this thread has already explained. > > So Terry, do you have anything to share, or just noise like this ? > > > > (I dont care about if the DTLA may have other problems) > > Sorry; all I can give you is hear-say, which I guess you could > consider to be noise, except we confirmed that the problem disk > in this case was an IBM drive, which tends to support the theory. Indeed, the problem at hand here show up on *any* tagged queueing capable drive, it is not specific to a certain model. > For a more "scientific test", downloading the firmware tool and > setting the DMA transfer rate down, and checking for problems, > would be pretty overwhelming evidence. Personally, I don't have > any of the buggers lying around to test with any more. Why on earth would you do that ? (hint man atacontrol) Besides I dont see this as any evidence at all, but thats another matter... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA errors on recent -current
"Søren Schmidt" wrote: > > Is your drive perchance an IBM DTLA? > > > > It's known to have these problems. > > Cool! would you like to share where that information is available so > I can possibly work around the problem ?? IBM DTLA drives are known to be problematic. If you use that in a search engine, it will find numerous references to the drive electronics being too slow for sustained access to the sectors closes to the spindle. The place I first read about the problem was Tom's hardware. The generally accepted fix is "don't use the cylinders nearest the spindle" and/or "replace the drive". Here's the most complete (if biased) web reference I found: http://www.goldengate.net/~dlpeters/IBMSucks/ This has been discussed on the FreeBSD lists before... the supposed problem cited was "the electronics could not keep up with the data rate on the interior cylinders". Supposely, one of the utilities on this page: http://www.axiontech.com/cgi-local/download.asp?product=hdibmutil&hard_drives can work around the problem (depending on the drive you have) by changing some firmware settings on the drive. If you are interested, get them while you can: this is a mirror of an IBM set of downloads which are no longer available from the IBM URLs where they used to be located. The workaround works by setting a lower DMA transfer rate. Here is a PDF about the drives, which mentions the tool and its use: http://vendors.asbis.com/download/D60GXP_ht20.pdf Again, this is mirrored from an IBM URL that is no longer available, so if you intend to grab it, grab it now. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA errors on recent -current
"Søren Schmidt" wrote: > It seems Terry Lambert wrote: > > "Søren Schmidt" wrote: > > > > Is your drive perchance an IBM DTLA? > > > > > > > > It's known to have these problems. > > > > > > Cool! would you like to share where that information is available so > > > I can possibly work around the problem ?? > > > > IBM DTLA drives are known to be problematic. If you use that > > in a search engine, it will find numerous references to the > > drive electronics being too slow for sustained access to the > > sectors closes to the spindle. > > This thread is about tagged queueing problems on IBM drives since they > are the only ones that supports it, it is not specific to the DTLA > series at all, which this thread has already explained. > So Terry, do you have anything to share, or just noise like this ? > > (I dont care about if the DTLA may have other problems) Sorry; all I can give you is hear-say, which I guess you could consider to be noise, except we confirmed that the problem disk in this case was an IBM drive, which tends to support the theory. On the Linux kernel list, they suggested that the electronics that were too slow near the spindle were too slow at the rim, too, if you used tagged command queueing to increase the host load on the drive to the point that it was always dealing with back-to-back transfers. In other words, you *would* overwhelm the drive at the spindle, and you *could* overwhelm it at the rim, if you did it right, according to the posters. Basically, all I'm doing is repeating some arguments I saw elsewhere, not my personal experience with the beasts. My own personal experience with DTLA drive problems is limited to seeing some data corruption problems, reading the Linux lists, and then repartitioning the disks to not use the area near the spindle, which seemed to fix the problem to the point I could ignore investigating it further, and switch vendors when the in-stock DTLA's ran out. From a strictly "scientific proof" point of view, I might as well have waved a dead chicken over the things, and attributed the non-observation of problems afterward to that. On the other hand, "anything that works is better than anything that doesn't work"... 8-) 8-). For a more "scientific test", downloading the firmware tool and setting the DMA transfer rate down, and checking for problems, would be pretty overwhelming evidence. Personally, I don't have any of the buggers lying around to test with any more. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA errors on recent -current
It seems Terry Lambert wrote: > "Søren Schmidt" wrote: > > > Is your drive perchance an IBM DTLA? > > > > > > It's known to have these problems. > > > > Cool! would you like to share where that information is available so > > I can possibly work around the problem ?? > > IBM DTLA drives are known to be problematic. If you use that > in a search engine, it will find numerous references to the > drive electronics being too slow for sustained access to the > sectors closes to the spindle. This thread is about tagged queueing problems on IBM drives since they are the only ones that supports it, it is not specific to the DTLA series at all, which this thread has already explained. So Terry, do you have anything to share, or just noise like this ? (I dont care about if the DTLA may have other problems) -Søren 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: > >> >> Some people see this after the "mega" MFC on -stable too. > >> > Could I have you guys try this simple patch ? > >> Does not work. > > No change or breaks completely (if so how)... > Sorry: "No change". Download the Windows executable I pointed to in a previous posting. Run it. It will create a floppy disk. Using the floppy, set the DMA transfer rate slower on the drive. STANDARD WARNINGS APPLY! MAY HOSE YOUR DISK FIRMWARE IRRETRIEVABLY IF NOT USED CORRECTLY! FOLLOW THE IBM SUPPLIED INSTRUCTIONS TO THE LETTER! I AM NOT RESPONSIBLE FOR WHA?T HAPPENS TO YOUR DISK IF YOU USE THE TOOL! -- Terry 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: > On 14 Apr, Terry Lambert wrote: > > Is your drive perchance an IBM DTLA? > > > > It's known to have these problems. > > Does this also apply to other IBM drives? Potentially. IBM renamed the part number when the drives got known to be dogs. I thought they also defaulted the firmware to get around the problem. You would have to check the full threads complaining about the DTLA parts to be certain; I didn't follow the problem closely enough except to recommend using the outer cylinders only for the FS and OS data for an embedded system I worked on at one time (no, not the InterJet). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Mouse in Xfree86 4.2.0
Whats about editing /etc/rc.devfs and inserting a symlink from /dev/mouse to /dev/sysmouse ? On Mon, 2002-04-15 at 08:26, Munish Chopra wrote: > On Mon, Apr 15, 2002 at 10:02:33AM +0200, John Angelmo wrote: > > Hello > > > > When I start XFree86 I get the error that /dev/mouse can't be found, OK > > devfs seems to be installd so MAKEDEV dosn't exist anymore, is there > > anyway to get /dev/mouse working as in FreeBSD 4? > > > > Thanks > > > > /John > > Set your mouse as being /dev/sysmouse in your XF86Config. > > -- > Munish Chopra The FreeBSD NVIDIA Driver Initiative > http://nvidia.netexplorer.org > > 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: plug aue ethernet goes to panic
device_set_ivars is always called (in usbd_probe_and_attach) with as an argument a stack variable. Also, the ivar is not stored or anything in the if_aue.c driver. So this problem sounds like a problem in revisions of various files. Please check that your kernel modules kernel are in sync. Do this by rebuilding the kernel and the modules from scratch. Also, after you've installed your kernel check that all your kernel files have been updated. Do you by any chance have a stale /modules or /boot/modules directory lying around? You should have only kernel modules in /boot/kernel*/ and NOT in /modules* or /boot/modules*. If the problem persists, please mail me the output of ident /sys/dev/usb/*.[ch] find /modules /boot -type f -ls Thanks. Nick On Sat, 13 Apr 2002, Will Andrews wrote: > On Sat, Apr 13, 2002 at 12:44:36PM -0400, John Baldwin wrote: > > Can you get a backtrace in ddb? It looks like a null pointer dereference, and > > knowing where it happened would help. Finding the file and line of the > > instruction pointer using addr2line on kernel.debug would be helpful as well. > > It *is* a null pointer deref. Joe and I looked at this problem, > and it seems a function called device_get_ivars() isn't doing > its job in sys/dev/usb/usb_port.h. So the variable is getting > filled with a NULL pointer for the iface element and is later > deref'd. That's the limit of my debugging, and Joe is looking > into the problem actively. > > Regards, > -- [EMAIL PROTECTED] http://www.van-laarhoven.org/ [EMAIL PROTECTED]http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA errors on recent -current
On 15 Apr, =?x-unknown?Q?S=F8ren?= Schmidt wrote: >> >> Some people see this after the "mega" MFC on -stable too. >> > >> > Could I have you guys try this simple patch ? >> >> Does not work. > > As in: > > No change or breaks completely (if so how)... Sorry: "No change". Bye, Alexander. -- The best things in life are free, but the expensive ones are still worth a look. 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
It seems Alexander Leidinger wrote: > On 15 Apr, Søren Schmidt wrote: > > >> Some people see this after the "mega" MFC on -stable too. > > > > Could I have you guys try this simple patch ? > > Does not work. As in: No change or breaks completely (if so how)... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA errors on recent -current
On 15 Apr, Søren Schmidt wrote: >> Some people see this after the "mega" MFC on -stable too. > > Could I have you guys try this simple patch ? Does not work. Bye, Alexander. -- Actually, Microsoft is sort of a mixture between the Borg and the Ferengi. 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: Mouse in Xfree86 4.2.0
On Mon, Apr 15, 2002 at 10:02:33AM +0200, John Angelmo wrote: > Hello > > When I start XFree86 I get the error that /dev/mouse can't be found, OK > devfs seems to be installd so MAKEDEV dosn't exist anymore, is there > anyway to get /dev/mouse working as in FreeBSD 4? > > Thanks > > /John Set your mouse as being /dev/sysmouse in your XF86Config. -- Munish Chopra The FreeBSD NVIDIA Driver Initiative http://nvidia.netexplorer.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA errors on recent -current
On 15 Apr, =?x-unknown?Q?S=F8ren?= Schmidt wrote: >> Some people see this after the "mega" MFC on -stable too. > > Could I have you guys try this simple patch ? It failed to apply, applied it by hand. Compiling a new kernel now. Bye, Alexander. -- Where do you think you're going today? 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
On 14 Apr, Terry Lambert wrote: >> > Turn off tagged queing. S?ren knows about this error and tries to >> > reproduce it (but fails as far as I know). >> >> I've seen this quite a few times, but I can't reliably reproduce it >> yet. It seems to hit me a lot when the ad0 drive spins like crazy >> doing stuff that is heavy on disk I/O. Disabling tag queueing now to >> see if this fixes things. But even if it does, I think I should >> enable it again and help S?ren track this down, if I can. > > Is your drive perchance an IBM DTLA? > > It's known to have these problems. Does this also apply to other IBM drives? (7) root@ttyp2 # dmesg |grep ata Preloaded elf module "/boot/kernel/accf_data.ko" at 0xc04cbed8. atapci0: port 0xd000-0xd00f at device 7.1 on pci0 atapci0: Correcting VIA config for southbridge data corruption bug ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ad0: 58644MB [119150/16/63] at ata0-master UDMA100 afd0: 96MB [32/64/96] at ata1-master PIO0 Bye, Alexander. -- Press every key to continue. 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
It seems Alexander Leidinger wrote: > > I've seen this quite a few times, but I can't reliably reproduce it > > yet. It seems to hit me a lot when the ad0 drive spins like crazy > > doing stuff that is heavy on disk I/O. Disabling tag queueing now to > > see if this fixes things. But even if it does, I think I should > > enable it again and help S?ren track this down, if I can. > > There are a lot of people which want to help him... > > First I got it only once (as you in a heavy disk I/O situation). After > another new world I got it at every boot... > > Some people see this after the "mega" MFC on -stable too. Could I have you guys try this simple patch ? Index: ata-all.c === RCS file: /home/ncvs/src/sys/dev/ata/ata-all.c,v retrieving revision 1.149 diff -u -r1.149 ata-all.c --- ata-all.c 10 Apr 2002 11:18:07 - 1.149 +++ ata-all.c 15 Apr 2002 08:05:49 - @@ -1009,13 +1009,12 @@ rman_get_start(atadev->channel->r_io), command, lba, count, feature, flags); #endif - -/* select device */ -ATA_OUTB(atadev->channel->r_io, ATA_DRIVE, ATA_D_IBM | atadev->unit); - /* disable interrupt from device */ if (atadev->channel->flags & ATA_QUEUED) ATA_OUTB(atadev->channel->r_altio, ATA_ALTSTAT, ATA_A_IDS | ATA_A_4BIT); + +/* select device */ +ATA_OUTB(atadev->channel->r_io, ATA_DRIVE, ATA_D_IBM | atadev->unit); /* ready to issue command ? */ if (ata_wait(atadev, 0) < 0) { -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Mouse in Xfree86 4.2.0
Hello When I start XFree86 I get the error that /dev/mouse can't be found, OK devfs seems to be installd so MAKEDEV dosn't exist anymore, is there anyway to get /dev/mouse working as in FreeBSD 4? Thanks /John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA errors on recent -current
On 15 Apr, Giorgos Keramidas wrote: >> > I updated to -current today and am now getting these errors >> > >> > ad0: READ command timeout tag=1 serv=1 - resetting >> > ata0: resetting devices .. ad0: invalidating queued requests >> > done >> >> Turn off tagged queing. S?ren knows about this error and tries to >> reproduce it (but fails as far as I know). > > I've seen this quite a few times, but I can't reliably reproduce it > yet. It seems to hit me a lot when the ad0 drive spins like crazy > doing stuff that is heavy on disk I/O. Disabling tag queueing now to > see if this fixes things. But even if it does, I think I should > enable it again and help S?ren track this down, if I can. There are a lot of people which want to help him... First I got it only once (as you in a heavy disk I/O situation). After another new world I got it at every boot... Some people see this after the "mega" MFC on -stable too. Bye, Alexander. -- Give a man a fish and you feed him for a day; teach him to use the Net and he won't bother you for weeks. 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
It seems Terry Lambert wrote: > Giorgos Keramidas wrote: > > > > ad0: READ command timeout tag=1 serv=1 - resetting > > > > ata0: resetting devices .. ad0: invalidating queued requests > > > > done > > > > > > Turn off tagged queing. S?ren knows about this error and tries to > > > reproduce it (but fails as far as I know). > > > > I've seen this quite a few times, but I can't reliably reproduce it > > yet. It seems to hit me a lot when the ad0 drive spins like crazy > > doing stuff that is heavy on disk I/O. Disabling tag queueing now to > > see if this fixes things. But even if it does, I think I should > > enable it again and help S?ren track this down, if I can. > > Is your drive perchance an IBM DTLA? > > It's known to have these problems. Cool! would you like to share where that information is available so I can possibly work around the problem ?? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message