Anyone had luck with 3Com HomeConnect ADSL Modem Dual Link???
Hi... Has anyone on this list had any luck dealing with 3Com HomeConnect ADSL Modem Dual Link? I am stuck with this peace of hardware and please don't flame me ;) I connect the modem to an xl card sitting on the PC. I am running a fairly recent -CURRENT system. Here is my /etc/ppp/ppp.conf: default: set device PPPoE:xl0 set speed sync set mru 1492 set mtu 1492 set ctsrts off enable lqr set log Phase tun command add default HISADDR enable dns cbn: set authname [EMAIL PROTECTED] set authkey When I start ppp as root, and issue the dial command, here's what /var/log/ppp.log witness: Sep 25 15:34:27 adsl ppp[735]: Phase: Using interface: tun0 Sep 25 15:34:27 adsl ppp[735]: Phase: deflink: Created in closed state Sep 25 15:34:27 adsl ppp[735]: tun0: Command: default: add default HISADDR Sep 25 15:34:27 adsl ppp[735]: tun0: Command: default: enable dns Sep 25 15:34:27 adsl ppp[735]: tun0: Phase: PPP Started (interactive mode). Sep 25 15:34:34 adsl ppp[735]: tun0: Command: /dev/ttyp0: set log +debug Sep 25 15:34:35 adsl ppp[735]: tun0: Command: /dev/ttyp0: dial Sep 25 15:34:35 adsl ppp[735]: tun0: Phase: bundle: Establish Sep 25 15:34:35 adsl ppp[735]: tun0: Phase: deflink: closed - opening Sep 25 15:34:35 adsl ppp[735]: tun0: Debug: List of netgraph node ``xl0:'' (id 2) hooks: Sep 25 15:34:35 adsl ppp[735]: tun0: Debug: Found orphans - ethernet Sep 25 15:34:35 adsl ppp[735]: tun0: Debug: Connecting netgraph socket .:tun0 - [4]::tun0 Sep 25 15:34:35 adsl ppp[735]: tun0: Debug: Sending PPPOE_CONNECT to .:tun0 Sep 25 15:34:35 adsl ppp[735]: tun0: Phase: deflink: Connected! Sep 25 15:34:35 adsl ppp[735]: tun0: Phase: deflink: opening - dial Sep 25 15:34:35 adsl ppp[735]: tun0: Phase: deflink: dial - carrier Sep 25 15:34:35 adsl ppp[735]: tun0: Debug: Waiting for carrier Sep 25 15:34:36 adsl ppp[735]: tun0: Phase: Received NGM_PPPOE_SUCCESS (hook tun0) Sep 25 15:34:36 adsl ppp[735]: tun0: Phase: deflink: carrier - login Sep 25 15:34:36 adsl ppp[735]: tun0: Phase: deflink: login - lcp Sep 25 15:34:37 adsl ppp[735]: tun0: Debug: fsm_Output Sep 25 15:34:37 adsl ppp[735]: tun0: Debug: 01 01 00 16 01 04 05 d4 05 06 6b 60 c8 47 04 08 ..k`.G.. Sep 25 15:34:37 adsl ppp[735]: tun0: Debug: c0 25 00 00 0b b8 .% Sep 25 15:34:37 adsl ppp[735]: tun0: Debug: proto_LayerPush: Using 0xc021 Sep 25 15:34:37 adsl ppp[735]: tun0: Debug: link_PushPacket: Transmit proto 0xc021 Sep 25 15:34:37 adsl ppp[735]: tun0: Debug: m_enqueue: len = 1 Sep 25 15:34:37 adsl ppp[735]: tun0: Debug: m_dequeue: queue len = 1 Sep 25 15:34:37 adsl ppp[735]: tun0: Debug: link_Dequeue: Dequeued from queue 1, containing 0 more packets Sep 25 15:34:37 adsl ppp[735]: tun0: Debug: deflink: DescriptorWrite: wrote 24(24) to 3 Sep 25 15:34:40 adsl ppp[735]: tun0: Debug: fsm_Output Sep 25 15:34:40 adsl ppp[735]: tun0: Debug: 01 01 00 16 01 04 05 d4 05 06 6b 60 c8 47 04 08 ..k`.G.. Sep 25 15:34:40 adsl ppp[735]: tun0: Debug: c0 25 00 00 0b b8 .% Sep 25 15:34:40 adsl ppp[735]: tun0: Debug: proto_LayerPush: Using 0xc021 Sep 25 15:34:40 adsl ppp[735]: tun0: Debug: link_PushPacket: Transmit proto 0xc021 Sep 25 15:34:40 adsl ppp[735]: tun0: Debug: m_enqueue: len = 1 Sep 25 15:34:40 adsl ppp[735]: tun0: Debug: m_dequeue: queue len = 1 Sep 25 15:34:40 adsl ppp[735]: tun0: Debug: link_Dequeue: Dequeued from queue 1, containing 0 more packets Sep 25 15:34:40 adsl ppp[735]: tun0: Debug: deflink: DescriptorWrite: wrote 24(24) to 3 Sep 25 15:34:43 adsl ppp[735]: tun0: Debug: fsm_Output Sep 25 15:34:43 adsl ppp[735]: tun0: Debug: 01 01 00 16 01 04 05 d4 05 06 6b 60 c8 47 04 08 ..k`.G.. Sep 25 15:34:43 adsl ppp[735]: tun0: Debug: c0 25 00 00 0b b8 .% Sep 25 15:34:43 adsl ppp[735]: tun0: Debug: proto_LayerPush: Using 0xc021 Sep 25 15:34:43 adsl ppp[735]: tun0: Debug: link_PushPacket: Transmit proto 0xc021 Sep 25 15:34:43 adsl ppp[735]: tun0: Debug: m_enqueue: len = 1 Sep 25 15:34:43 adsl ppp[735]: tun0: Debug: m_dequeue: queue len = 1 Sep 25 15:34:43 adsl ppp[735]: tun0: Debug: link_Dequeue: Dequeued from queue 1, containing 0 more packets Sep 25 15:34:43 adsl ppp[735]: tun0: Debug: deflink: DescriptorWrite: wrote 24(24) to 3 Sep 25 15:34:46 adsl ppp[735]: tun0: Debug: fsm_Output Sep 25 15:34:46 adsl ppp[735]: tun0: Debug: 01 01 00 16 01 04 05 d4 05 06 6b 60 c8 47 04 08 ..k`.G.. Sep 25 15:34:46 adsl ppp[735]: tun0: Debug: c0 25 00 00 0b b8 .% Sep 25 15:34:46 adsl ppp[735]: tun0: Debug: proto_LayerPush: Using 0xc021 Sep 25 15:34:46 adsl ppp[735]: tun0: Debug: link_PushPacket: Transmit proto 0xc021 Sep 25 15:34:46 adsl ppp[735]: tun0: Debug: m_enqueue: len = 1 Sep 25 15:34:46 adsl ppp[735]: tun0: Debug: m_dequeue: queue len = 1 Sep 25 15:34:46 adsl ppp[735]: tun0: Debug: link_Dequeue: Dequeued from
Re: Seen this lock order reversal?
On Mon, 24 Sep 2001, Wilko Bulte wrote:
I did notice that the default Alpha beep is of a much higher frequency
than the x86 one. Any relation? (long shot... I suppose)
This bug is well known (including by your mailbox). From mail sent to
your mailbox:
% From [EMAIL PROTECTED] Mon Jun 18 17:40:56 2001 +1000
% Date: Mon, 18 Jun 2001 17:40:51 +1000 (EST)
% From: Bruce Evans [EMAIL PROTECTED]
% X-Sender: [EMAIL PROTECTED]
% To: Bill Fumerola [EMAIL PROTECTED]
% cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
% Subject: Re: alpha/17637: misconfigured syscons bell causes panic on alpha
% In-Reply-To: [EMAIL PROTECTED]
% Message-ID: [EMAIL PROTECTED]
% MIME-Version: 1.0
% Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
% Status: O
% X-Status:
% X-Keywords:
% X-UID: 2948
%
% On Mon, 18 Jun 2001, Bill Fumerola wrote:
%
% On Sun, Jun 17, 2001 at 01:14:59PM -0700, [EMAIL PROTECTED] wrote:
%
% Problem was fixed long ago, so let us also close the PR..
%
%
% revision 1.15
% date: 2000/03/30 22:39:48; author: billf; state: Exp; lines: +5 -3
% Avoid dividing by zero when beeping with a zero pitch. This was bad.
%
% PR: alpha/17637
% Submitted by: Bosko Milekic [EMAIL PROTECTED]
% Reported by:Dennis Lindroos [EMAIL PROTECTED]
%
% As I recall, bde had issues with my fix. I don't remember them, though.
%
% From my saved mail (only the initial reply):
%
% | Patches in PRs are rarely suitable for committing verbatim, and this one
% | was no exception :-). It has:
% |
% | 1) Style bugs on every line (2 if (foo) bar;'s and 2 gratuitous new
% |empty lines).
% | 2) Internally inconsistent code. The `pitch' arg is now loaded into the
% |timer counter unchanged in the pitch == 0 case.
% | 3) Doesn't fix the real bug, which is that `pitch' isn't actually the
% |pitch; it is a raw i8254 maximum count which must be loaded directly
% |into the i8254 counter, as it is in the i386 version of sysbeep().
% |Callers must convert from pitches in Hz to pitches in i8254 counts,
% |although this interface is Broken As Designed (AFAIK it is for bug
% |for bug compatibility with a BAD SCO interface). The conversion
% |is impossible to do correctly for alphas, since the necessary
% |conversion factor (timer_freq) is not exported from clock.c alphas.
% |The necessary conversion factor is not exported from the kernel
% |for any arch, so kbdcontrol(1) hard-codes it as 1193182. Fortunately
% |(?), this is almost correct for alphas. Note that 1193182 is close
% |to 10^6, so popular pitches near 1000 Hz have the magic property
% |of not being changed much by the conversion. This limits complaints
% |about bizarre beep frequencies. We use a default of BELL_PITCH =
% |800; this becomes 1193182 / 800 = 1491 on alphas.
% |
% | Perhaps users shouldn't be allowed to program bizarre i8254 counts of 0
% | and = 65536. Counts = 65536 are truncated modulo 65536. At least the
% | KDMKTONE ioctl does the truncation silently.
% |
% | The sysbeep() interface also confuses:
% | dev/mlx/mlx.c: hard-coded i8254 count of 500.
% | i386/isa/pcvt/*: hard-coded timer_freq of 1193182 and strange differences
% | in default pitches 1493 and 1500.
% | i386/i386/trap.c: hard-coded timer_freq of TIMER_FREQ.
% | pccard/pccard_beep.c: hard-coded i8254 counts of 1600, 1200, 3200 are named
% | as pitches.
% End of old mail
%
% Even kbdcontrol.c is confused about this:
%
% | void
% | set_bell_values(char *opt)
% | {
% | int bell, duration, pitch;
% |
% | bell = 0;
% | if (!strncmp(opt, quiet., 6)) {
% | bell = 2;
% | opt += 6;
% | }
% | if (!strcmp(opt, visual))
% | bell |= 1;
% | else if (!strcmp(opt, normal))
% | duration = 5, pitch = 800;
% | else if (!strcmp(opt, off))
% | duration = 0, pitch = 0;
% | else {
% | char*v1;
% |
% | bell = 0;
% | duration = strtol(opt, v1, 0);
% | if ((duration 0) || (*v1 != '.'))
% | goto badopt;
% | opt = ++v1;
% | pitch = strtol(opt, v1, 0);
% | if ((pitch 0) || (*opt == '\0') || (*v1 != '\0')) {
% | badopt:
% | warnx(argument to -b must be duration.pitch or
[quiet.]visual|normal|off);
% | return;
% | }
%
% `pitch' is now actually in Hz.
%
% | if (pitch != 0)
% | pitch = 1193182 / pitch;/* in Hz */
%
% Bogus comment. `pitch' is NOT in Hz. It is now a dimensionless number.
%
% | duration /= 10; /* in 10 m sec */
% | }
% |
% | ioctl(0, CONS_BELLTYPE, bell);
% | if ((bell ~2) == 0)
% | fprintf(stderr, [=%d;%dB, pitch, duration);
% | }
%
% Bruce
%
%
% From [EMAIL PROTECTED] Tue Jun 19 16:43:28 2001 +1000
% Date: Tue, 19 Jun 2001 16:43:24
Re: Is it possible to make 4.4-REELASE on the -CURRENT ?
On Tue, 25 Sep 2001 08:32:50 +0700, Nickolay Dudorov wrote: Does this means that there is NO correct way to make 4.4-RELEASE on the latest -CURRENT ? No easy and correct way, yes. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seen this lock order reversal?
On Mon, 24 Sep 2001, John Baldwin wrote:
Hmm, that first one is in sysbeep() (the clk one) Ah!
if (!beeping) {
/* enable counter2 output to speaker */
if (pitch) outb(IO_PPI, inb(IO_PPI) | 3);
beeping = period;
timeout(sysbeepstop, (void *)NULL, period);
}
This is the problem code. Hmmm. The i386 code seems b0rked. It doesn't have
enough locks! Eck. hmm, the pc98 code doesn't even _use_ the mutex but still
depends on disable/enable intr. Eek. I'll work at this later on today.
Better yet, even the i386 code doesn't even use disable/enable_intr() or
splhigh/splx()() in sysbeepstop(). However, since nothing much accesses
the PPI register, I think there is only an unimportant race between
sysbeep() and sysbeepstop().
There are some more interesting races in clock.c. E.g., rtcin() is locked
by splhigh(), so calling it from the fast interrupt handler rtcintr() would
be invalid even if splhigh() were not a no-op.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Anyone had luck with 3Com HomeConnect ADSL Modem Dual Link???
Hi... Has anyone on this list had any luck dealing with 3Com HomeConnect ADSL Modem Dual Link? I am stuck with this peace of hardware and please don't flame me ;) I connect the modem to an xl card sitting on the PC. I am running a fairly recent -CURRENT system. Here is my /etc/ppp/ppp.conf: [.] I have set net.graph.nonstandard_pppoe=1 You could try running ``tcpdump -i xl0 -e -l not ip'' to see if any of your traffic is being replied to (and to ensure it goes out with the dodgy header numbers). Any tips? tq... /john Live Free OR Die -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour ! brian@[uk.]OpenBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: lock (sleep mutex) vnode interlock on Alpga
I'm not sure if this is new, but anyway on -current as of yesterday evening: acd0: CDROM TOSHIBA CD-ROM XM-6302B at ata0-master PIO4 Waiting 15 seconds for SCSI devices to settle Mounting root from ufs:/dev/da1a panic: lock (sleep mutex) vnode interlock not locked @ /usr/src/sys/kern/vfs_default.c:460 panic Stopped at Debugger+0x34: zapnot v0,#0xf,a0 v0=0x0,a0=0x6 db trace Debugger() at Debugger+0x34 panic() at panic+0x100 witness_unlock() at witness_unlock+0x2a4 _mtx_unlock_flags() at _mtx_unlock_flags+0x98 vop_nolock() at vop_nolock+0x38 vop_defaultop() at vop_defaultop+0x2c vn_lock() at vn_lock+0x15c ffs_mountfs() at ffs_mountfs+0xd8 ffs_mount() at ffs_mount+0x9c vfs_mountroot_try() at vfs_mountroot_try+0x200 vfs_mountroot() at vfs_mountroot+0x9c mi_startup() at mi_startup+0x154 locorestart() at locorestart+0x68 --- root of call graph --- db -- | / o / /_ _ email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: lock (sleep mutex) vnode interlock on Alpga
I'm getting the same thing from a kernel I built this morning on i386. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Tue, 25 Sep 2001, Wilko Bulte wrote: I'm not sure if this is new, but anyway on -current as of yesterday evening: acd0: CDROM TOSHIBA CD-ROM XM-6302B at ata0-master PIO4 Waiting 15 seconds for SCSI devices to settle Mounting root from ufs:/dev/da1a panic: lock (sleep mutex) vnode interlock not locked @ /usr/src/sys/kern/vfs_default.c:460 panic Stopped at Debugger+0x34: zapnot v0,#0xf,a0 v0=0x0,a0=0x6 db trace Debugger() at Debugger+0x34 panic() at panic+0x100 witness_unlock() at witness_unlock+0x2a4 _mtx_unlock_flags() at _mtx_unlock_flags+0x98 vop_nolock() at vop_nolock+0x38 vop_defaultop() at vop_defaultop+0x2c vn_lock() at vn_lock+0x15c ffs_mountfs() at ffs_mountfs+0xd8 ffs_mount() at ffs_mount+0x9c vfs_mountroot_try() at vfs_mountroot_try+0x200 vfs_mountroot() at vfs_mountroot+0x9c mi_startup() at mi_startup+0x154 locorestart() at locorestart+0x68 --- root of call graph --- db -- | / o / /_ _ email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: lock (sleep mutex) vnode interlock on Alpga
On Tue, Sep 25, 2001 at 07:25:04PM +0200, Wilko Bulte wrote: I'm not sure if this is new, but anyway on -current as of yesterday evening: acd0: CDROM TOSHIBA CD-ROM XM-6302B at ata0-master PIO4 Waiting 15 seconds for SCSI devices to settle Mounting root from ufs:/dev/da1a panic: lock (sleep mutex) vnode interlock not locked @ /usr/src/sys/kern/vfs_default.c:460 panic Stopped at Debugger+0x34: zapnot v0,#0xf,a0 v0=0x0,a0=0x6 db trace Debugger() at Debugger+0x34 panic() at panic+0x100 witness_unlock() at witness_unlock+0x2a4 _mtx_unlock_flags() at _mtx_unlock_flags+0x98 vop_nolock() at vop_nolock+0x38 vop_defaultop() at vop_defaultop+0x2c vn_lock() at vn_lock+0x15c ffs_mountfs() at ffs_mountfs+0xd8 ffs_mount() at ffs_mount+0x9c vfs_mountroot_try() at vfs_mountroot_try+0x200 vfs_mountroot() at vfs_mountroot+0x9c mi_startup() at mi_startup+0x154 locorestart() at locorestart+0x68 --- root of call graph --- db Yep, I get exactly the same problem here. -- Simon Dick [EMAIL PROTECTED] Why do I get this urge to go bowling everytime I see Tux? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on mount
On 25-Sep-01 Bill Fenner wrote: I also started getting this error with recent kernels (in the last day or so). It looks like the mutex is really held since the mtx_assert before witness_unlock didn't trigger. You can try turning witness off for the time being as a workaround. I'm not sure why witness would be broken, however. Mounting root from ufs:/dev/ad0s1a panic: lock (sleep mutex) vnode interlock not locked @ /usr/src/sys/kern/vfs_default.c:460 Debugger(panic) Stopped at Debugger+0x44: pushl %ebx db t Debugger(c03c5bbb) at Debugger+0x44 panic(c03c8c40,c03c4b80,c03ccf20,c03cc8a0,1cc) at panic+0x70 witness_unlock(c7765f2c,8,c03cc8a0,1cc,c7765f2c,1,c03c4ba0,f6) at witness_unlock+0x1d0 _mtx_unlock_flags(c7765f2c,0,c03cc8a0,1cc,c0567bd0) at _mtx_unlock_flags+0x59 vop_nolock(c0567be8,c0567bf8,c02920c2,c0567be8,c0567d4c) at vop_nolock+0x24 vop_defaultop(c0567be8) at vop_defaultop+0x15 vn_lock(c7765ec0,20002,c049f7c4,c0567d4c,c1346680) at vn_lock+0xca ffs_mountfs(c7765ec0,c1351600,c049f7c4,c0446900,c0567d4c) at ffs_mountfs+0x7e ffs_mount(c1351600,0,0,0,c049f7c4) at ffs_mount+0x67 vfs_mountroot_try(c05447a8,c03cc48c) at vfs_mountroot_try+0x14e vfs_mountroot(0,564c00,564000,0,c012caac) at vfs_mountroot+0x5a mi_startup() at mi_startup+0x90 begin() at begin+0x43 I dunno how to get a dump from this point since kern.dumpdev hasn't been set.. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc 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: panic: lock (sleep mutex) vnode interlock on Alpga
On 25-Sep-01 Wilko Bulte wrote: I'm not sure if this is new, but anyway on -current as of yesterday evening: Ok, can you try building a new kernel from scratch and see if you still have the same problem? If so, can you back out my latest set of changes to kern_mutex.c and sys/mutex.h and see if that fixes things? It looks like witness is somehow getting out of sync. One cause could be stale .o files that aren't being recompiled. Perhaps you haven't run make depend in a while? -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc 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: panic on mount
In message [EMAIL PROTECTED], John Baldwin writes: It looks like the mutex is really held since the mtx_assert before witness_unlock didn't trigger. You can try turning witness off for the time being as a workaround. I'm not sure why witness would be broken, however. Revision 1.41 of sys/mutex.h seems to be the culprit. Before 1.41, the defined(LOCK_DEBUG) and !defined(LOCK_DEBUG) cases were identical except that with LOCK_DEBUG defined, the function versions of _mtx_*lock_* were used. After 1.41, the !defined(LOCK_DEBUG) case misses all the MPASS/KASSERT/LOCK_LOG/WITNESS bits. A simple workaround that seems to stop the panics is below. Ian Index: mutex.h === RCS file: /dump/FreeBSD-CVS/src/sys/sys/mutex.h,v retrieving revision 1.41 diff -u -r1.41 mutex.h --- mutex.h 2001/09/22 21:19:55 1.41 +++ mutex.h 2001/09/26 00:46:09 @@ -238,7 +238,7 @@ #define mtx_unlock(m) mtx_unlock_flags((m), 0) #define mtx_unlock_spin(m) mtx_unlock_spin_flags((m), 0) -#ifdef LOCK_DEBUG +#if 1 #definemtx_lock_flags(m, opts) \ _mtx_lock_flags((m), (opts), LOCK_FILE, LOCK_LINE) #definemtx_unlock_flags(m, opts) \ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: panic: lock (sleep mutex) vnode interlock on Alpga
John/all: For what it's worth... I started experiencing this panic problem as described .. After a make depend and then building/installing the kernel the problem is gone. This was from a cvsup ~9:30 EST 9/25/01 --mikej Michael Jung [EMAIL PROTECTED] On 25-Sep-01 Wilko Bulte wrote: I'm not sure if this is new, but anyway on -current as of yesterday evening: Ok, can you try building a new kernel from scratch and see if you still have the same problem? If so, can you back out my latest set of changes to kern_mutex.c and sys/mutex.h and see if that fixes things? It looks like witness is somehow getting out of sync. One cause could be stale .o files that aren't being recompiled. Perhaps you haven't run make depend in a while? -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc 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 [EMAIL PROTECTED] ../mailto.html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: lock (sleep mutex) vnode interlock on Alpga
On Tue, Sep 25, 2001 at 02:49:41PM -0700, John Baldwin wrote: On 25-Sep-01 Wilko Bulte wrote: I'm not sure if this is new, but anyway on -current as of yesterday evening: Ok, can you try building a new kernel from scratch and see if you still have the same problem? If so, can you back out my latest set of changes to kern_mutex.c and sys/mutex.h and see if that fixes things? It looks like witness is somehow getting out of sync. One cause could be stale .o files that aren't being recompiled. Perhaps you haven't run make depend in a while? FWIW: the kernel that shows this behaviour was built using make buildkernel just after a make buildworld. That should ensure a make depend. But I'll try your suggestions and see what happens next. -- | / o / /_ _ email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Suggestion: move rc.devfs invocation up in rc
On Sun, Sep 23, 2001 at 11:36:32AM -0700, Jos Backus wrote: run before rc.devfs, i.e. before the symlink is created. Could rc.devfs not be moved up in rc so this does work? done To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: how to make acpi go away.
Donny Lee wrote: Alfred Perlstein wrote: Can someone please share with us the magic to disable acpi and add it to src/UPDATING, my sound fell victim to acpi and i think I just lost my mouse to it. Now I have a lapbrick that consumes less power... try adding a line hint.acpi.0.disable=1 ahh to /boot/device.hints, or disable it at boot time unset acpi_load I only found this out today when my Dell inspiron7500 refused to boot past the ACPI message.. Surprised me a bit as Mike has one of these. then boot as usual. -- // Donny -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +--x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ISO-IMAGE of -CURRENT
Hi, maybe I just missed it (as I track mainly -STABLE), but why there are no ISOs of -CURRENT on current.freebsd.org, although there is directory for it? Buki To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: moused problems, not related to acpi
Please type boot -v at the loader prompt and send me dmesg's output after the system has started. I would also like to know more about your mouse: manufacturer, product name, model No, a URL which lists this mouse, etc. Thank you, Kazu -current as of yesterday. I've got a new mouse, but it isn't compatible with moused: I get psmintr: out of sync (00c0 != ). and any cursor movement moves the cursor to the upper right edge of the screen. Further mouse movement results in virtual button presses. Attached is the output of moused -p /dev/psm0 -d -f. The output shows in this order: - move to the left - move to the right - move forward - move backward - push left button - push right button - push middle button - scroll wheel forward - scroll wheel backward - push the second left button (yes, there's a second button behind the left button) - push the second right button The mouse is labeled as a 600dpi mouse (-r 600 didn't changes the behavior). Win2k has no problems with it, unset acpi_load at the loader prompt didn't changes the behavior. Bye, Alexander. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: how to make acpi go away.
* Donny Lee [EMAIL PROTECTED] [010925 03:40] wrote: Alfred Perlstein wrote: Can someone please share with us the magic to disable acpi and add it to src/UPDATING, my sound fell victim to acpi and i think I just lost my mouse to it. Now I have a lapbrick that consumes less power... try adding a line hint.acpi.0.disable=1 to /boot/device.hints, or disable it at boot time unset acpi_load then boot as usual. Thank you, that fixed everything. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: moused problems, not related to acpi
On 25 Sep, Kazutaka YOKOTA wrote: Please type boot -v at the loader prompt and send me dmesg's output after the system has started. Omitted in the mail to -current. I would also like to know more about your mouse: manufacturer, product name, model No, a URL which lists this mouse, etc. NoName 4D Browser Mouse ??? (FCC ID:10WCM-B700) ^^ either '1' or 'I' and '0' or 'O' ??? (got it in a local store for DEM 20 (~$10?)) Additional info: - made in china - 5 buttons + wheel - 600 dpi - tracking speed: 250mm/sec - it's also available as a serial or USB mouse and with 400 dpi My old mouse died either while unplugging it from a running system or by plugging it into another running system (yes I know, PS/2 isn't hot-pluggable). The new mouse works with W2K in the first system, the second system refuses to boot if the new mouse is plugged in. I try it with another mouse later, to determine if the second system (Asus P2L97-S) is damaged or not. And I try the new mouse with a 3rd system. 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: moused problems, not related to acpi
On 25 Sep, Kazutaka YOKOTA wrote: Please type boot -v at the loader prompt and send me dmesg's output after the system has started. Omitted in the mail to -current. Thank you. Hmmm, the output doesn't show anything suspicious. It looks like that the mouse is just an ordinary one... psm0: current command byte:0047 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:, flags:, packet size:3 psm0: syncmask:c0, syncbits:00 We need some more tests. Would you add the following lines to your kernel configuration file, rebuild the kernel, and do 'boot -v' again? options KBDIO_DEBUG=2 options PSM_DEBUG=2 Kazu I would also like to know more about your mouse: manufacturer, product name, model No, a URL which lists this mouse, etc. NoName 4D Browser Mouse ??? (FCC ID:10WCM-B700) ^^ either '1' or 'I' and '0' or 'O' ??? (got it in a local store for DEM 20 (~$10?)) Additional info: - made in china - 5 buttons + wheel - 600 dpi - tracking speed: 250mm/sec - it's also available as a serial or USB mouse and with 400 dpi My old mouse died either while unplugging it from a running system or by plugging it into another running system (yes I know, PS/2 isn't hot-pluggable). The new mouse works with W2K in the first system, the second system refuses to boot if the new mouse is plugged in. I try it with another mouse later, to determine if the second system (Asus P2L97-S) is damaged or not. And I try the new mouse with a 3rd system. Bye, Alexander. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ISO-IMAGE of -CURRENT
On Tue, Sep 25, 2001 at 02:09:09PM +0200, Kozlovsky, Marek wrote: Hi, maybe I just missed it (as I track mainly -STABLE), but why there are no ISOs of -CURRENT on current.freebsd.org, although there is directory for it? Because they're not created. IMO they'd be a waste of space. Kris msg32078/pgp0.pgp Description: PGP signature
Window of badness?
I seem to have cvsupp'd at a bad moment.. various older ( e.g. Netscape) have the following problem: /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined symbol __stderrp /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined symbol __stderrp /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined symbol __stderrp /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined symbol __stderrp /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined symbol __stderrp /usr/libexec/ld-elf.so.1: /usr/lib/libm.so.2: Undefined symbol __stderrp /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined symbol __stderrp /usr/libexec/ld-elf.so.1: /usr/lib/libm.so.2: Undefined symbol __stderrp so I figure: I'll cvsup again.. but: + /usr/local/bin/cvsup -L1 -P - /tmp/501.supfile /usr/libexec/ld-elf.so.1: /usr/lib/libutil.so.3: Undefined symbol __stdoutp Is here a quick workaround? (I still have connectivity and CVS just no netscape, KDE or cvsup..) (by workaround I mean a manual patch I should apply somewhere to get me up and going again after another buildworld). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ISO-IMAGE of -CURRENT
Kozlovsky, Marek [EMAIL PROTECTED] wrote: Hi, maybe I just missed it (as I track mainly -STABLE), but why there are no ISOs of -CURRENT on current.freebsd.org, although there is directory for it? There are -current snapshots at ftp://current.jp.freebsd.org/pub/FreeBSD/snapshots/i386 -- Benedikt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: how to make acpi go away.
On 25-Sep-01 Julian Elischer wrote: Donny Lee wrote: Alfred Perlstein wrote: Can someone please share with us the magic to disable acpi and add it to src/UPDATING, my sound fell victim to acpi and i think I just lost my mouse to it. Now I have a lapbrick that consumes less power... try adding a line hint.acpi.0.disable=1 ahh to /boot/device.hints, or disable it at boot time unset acpi_load I only found this out today when my Dell inspiron7500 refused to boot past the ACPI message.. Surprised me a bit as Mike has one of these. The Inspiron needs this line in loader.conf: debug.acpi.avoid=_SB_.PCI0.PX40.SIO_ Then it will probably work. My Inspiron 5000e needs this. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc 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: Window of badness?
Julian Elischer wrote: I seem to have cvsupp'd at a bad moment.. No, read -current.. set COMPAT4X=yes in /etc/make.conf. You can hurry it up with a cd /usr/lib/compat; make obj ; make all install This will update the ancient libc.so.4 that you have. various older ( e.g. Netscape) have the following problem: /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined symbol __stderrp /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined symbol __stderrp /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined symbol __stderrp /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined symbol __stderrp /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined symbol __stderrp /usr/libexec/ld-elf.so.1: /usr/lib/libm.so.2: Undefined symbol __stderrp /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined symbol __stderrp /usr/libexec/ld-elf.so.1: /usr/lib/libm.so.2: Undefined symbol __stderrp so I figure: I'll cvsup again.. but: + /usr/local/bin/cvsup -L1 -P - /tmp/501.supfile /usr/libexec/ld-elf.so.1: /usr/lib/libutil.so.3: Undefined symbol __stdoutp Is here a quick workaround? (I still have connectivity and CVS just no netscape, KDE or cvsup..) (by workaround I mean a manual patch I should apply somewhere to get me up and going again after another buildworld). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: how to make acpi go away.
Alfred Perlstein wrote: * Donny Lee [EMAIL PROTECTED] [010925 03:40] wrote: Alfred Perlstein wrote: Can someone please share with us the magic to disable acpi and add it to src/UPDATING, my sound fell victim to acpi and i think I just lost my mouse to it. Now I have a lapbrick that consumes less power... try adding a line hint.acpi.0.disable=1 to /boot/device.hints, or disable it at boot time unset acpi_load then boot as usual. Thank you, that fixed everything. Also, this works too: echo NO_MODULES=yes /etc/make.conf; rm /boot/kernel/acpi.ko :-) Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rshd broken on -CURRENT
I don't know why Mark does not fix this. I have reported this yet back in May, please see attached. While pam_rhosts_auth.so is unavailable, I suggest we commit the following: Index: pam.conf === RCS file: /home/ncvs/src/etc/pam.conf,v retrieving revision 1.19 diff -u -r1.19 pam.conf --- pam.conf2001/08/26 18:15:32 1.19 +++ pam.conf2001/09/25 08:21:28 @@ -63,7 +63,8 @@ login password required pam_unix.so no_warn try_first_pass rshauthrequiredpam_nologin.so no_warn -rshauthrequiredpam_permit.so no_warn +rshauthrequiredpam_deny.so no_warn +#rsh authrequiredpam_rhosts_auth.so rshaccount requiredpam_unix.so rshsession requiredpam_permit.so On Tue, Sep 25, 2001 at 02:44:38PM +0930, Thyer, Matthew wrote: Why can I rcp to my FreeBSD-CURRENT box (built Sept 19th) with no password when I dont even have a .rhosts file (I dont have an /etc/hosts.equiv either). I can also rsh freebie command with no prompt for password. I assume this is due to the upgrade of PAM. Looking on a RedHat 7.1 system I see they have the following in /etc/pam.d/rsh: #%PAM-1.0 # For root login to succeed here with pam_securetty, rsh must be # listed in /etc/securetty. auth required /lib/security/pam_nologin.so auth required /lib/security/pam_securetty.so auth required /lib/security/pam_env.so auth required /lib/security/pam_rhosts_auth.so accountrequired /lib/security/pam_stack.so service=system-auth sessionrequired /lib/security/pam_stack.so service=system-auth My FreeBSD-CURRENT box has this for rsh: rsh authrequiredpam_nologin.so no_warn rsh authrequiredpam_permit.so no_warn rsh account requiredpam_unix.so rsh session requiredpam_permit.so It seems that we dont have a /usr/lib/pam_rhosts_auth.so. -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age ---BeginMessage--- This is JFYI that the default (as given in /etc/pam.conf) PAM configuration for rshd(8) currently results in a root compromise, if rshd(8) is enabled in /etc/inetd.conf. rshd is a root compromise anyway :-) It is obvious that we can't have a conversation with the client over the rsh connection, but using pam_permit is certainly a bad idea. If this behavior was planned when committed, /etc/pam.conf should at least warn about this. Agreed. I'll do that. M -- Mark Murray Warning: this .sig is umop ap!sdn ---End Message---
Re: how to make acpi go away.
Alfred Perlstein wrote: Can someone please share with us the magic to disable acpi and add it to src/UPDATING, my sound fell victim to acpi and i think I just lost my mouse to it. Now I have a lapbrick that consumes less power... try adding a line hint.acpi.0.disable=1 to /boot/device.hints, or disable it at boot time unset acpi_load then boot as usual. -- // Donny To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
how to make acpi go away.
Can someone please share with us the magic to disable acpi and add it to src/UPDATING, my sound fell victim to acpi and i think I just lost my mouse to it. Now I have a lapbrick that consumes less power... yay -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
