new -current panic

2003-10-20 Thread Soren Schmidt
Just got this one (using bsd scheduler):

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x24
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc04b8f3b
stack pointer   = 0x10:0xcd619bc4
frame pointer   = 0x10:0xcd619bd8
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 = 3 (g_up)
kernel: type 12 trap, code=0
Stopped at  propagate_priority+0x8b:cmpl0x24(%ebx),%ecx
db> trace
propagate_priority(c0ebfe40,c25983c0,c2512400,cd619c14,c04cc9d1) at propagate_pr
iority+0x8b
_mtx_lock_sleep(c069c340,0,0,0,c0698700) at _mtx_lock_sleep+0x249
bufdonebio(c7675b68,cd619c44,c048d612,c084c540,c259f990) at bufdonebio+0x47
biodone(c7675b68,c06411ba,c259f990,c7675b68,0) at biodone+0xbc
g_dev_done(c259f990,c0ebfe40,1,0,4) at g_dev_done+0x8a
biodone(c259f990,0,24c,c0640b45,a) at biodone+0xbc
g_io_schedule_up(c0ebfe40,c0ebe1e4,cd619d34,c04acae1,0) at g_io_schedule_up+0xb8
g_up_procbody(0,cd619d48,0,0,0) at g_up_procbody+0x28
fork_exit(c048df60,0,cd619d48) at fork_exit+0xb1
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xcd619d7c, ebp = 0 ---
db> 
-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Help saving my system

2003-10-20 Thread Mark Murray
"Scott M. Likens" writes:
> Ah, such a strong comment from such a strong member.  I would have thought 
> you were to high to stoop that low?
> 
> But I guess it's good to be flamed for being honest? is it not?

Please don't encourage flames and flamers by responding to them.

M
--
Mark Murray
iumop ap!sdn w,I idlaH
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: DISCUSSION: /dev/fd%d.%d and /dev/{a}cd%d[ac] to be discontinued ?

2003-10-20 Thread Poul-Henning Kamp
In message <[EMAIL PROTECTED]>, Andrew Gallatin 
writes:
>
>Poul-Henning Kamp writes:
> > 
> > As soon as these uses of cloning code has been removed, I will move
> > the floppy and CD drivers under GEOM, paving the way for the
> > significant changes to the buf/VM system which some of you have
> > already heard rumours about.  (more will emerge after BSDcon'03)
> > 
> > And now comes the bit which I would like to offer for discussion:
> > 
> > Should we do this for 5.2 instead ?
> > 
>
>I think this sounds good.
>
>Can you give a hint as to what you mean by the significant buf/VM
>system changes?  Are you talking about removing the vnode detour for
>drivers and giving drivers who want it access to the struct file?

... and all that stuff yes.

It's been discussed in various emails in the past.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Random signals in {build,install}world recently?

2003-10-20 Thread Vallo Kallaste
Hi

It seems to be a recent problem. The hardware is OK, both Windows XP
(which I use very seldom) and Gentoo Linux do not exhibit any
problems.
Basically one will get random signals as I have got in build- and
installworld. It's impossible to complete make -j2 buildworld on my
machine, but sometimes non-parallel buildworld will do, only to die
later in installworld.
This is on two-processor AMD 2400+ MP system, ASUS A7M-266D mobo and
1GB ECC memory, ATA disks and CD/RW-DVD only. 4BSD scheduler if it
matters.
-- 
Vallo Kallaste
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Random signals in {build,install}world recently?

2003-10-20 Thread Harti Brandt
On Mon, 20 Oct 2003, Vallo Kallaste wrote:

VK>Hi
VK>
VK>It seems to be a recent problem. The hardware is OK, both Windows XP
VK>(which I use very seldom) and Gentoo Linux do not exhibit any
VK>problems.
VK>Basically one will get random signals as I have got in build- and
VK>installworld. It's impossible to complete make -j2 buildworld on my
VK>machine, but sometimes non-parallel buildworld will do, only to die
VK>later in installworld.
VK>This is on two-processor AMD 2400+ MP system, ASUS A7M-266D mobo and
VK>1GB ECC memory, ATA disks and CD/RW-DVD only. 4BSD scheduler if it
VK>matters.

I have the same MB just with 1800+ processors. I had to reduce the CPU
frequency by about 10% in the BIOS setup to get the machine stable. I
assume the problem is actually the memory.

harti

-- 
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: __fpclassifyd problem

2003-10-20 Thread John Angelmo
Steve Kargl wrote:

On Sun, Oct 19, 2003 at 03:48:58PM -0700, Kris Kennaway wrote:

On Sun, Oct 19, 2003 at 03:13:41PM -0700, Steve Kargl wrote:


I sent in an email *along time ago* about this type 
of problem.  See the fallout due to revision 1.24
of lib/libc/stdio/findfp.c.  IMHO, all shared libraries
versions should have been bumped in going from 4.x to
5.0. 
You don't want to do it before you have to, because this creates more
pain for people when you make a change that breaks backwards compat
(given the policy/preference of only bumping once per major release).
I'm working on a script that will detect the kind of backwards
compatibility breakage we're seeing here by comparing the symbols in
4.x and 5.x versions of libraries with the same major revision.  We
can then run this once a day/week/whatever somewhere to catch these
problems as soon as they occur in future.


You and I participated in the first go around in the
library versioning problem.  For one of my attempts
to discuss this problem, see
http://www.freebsd.org/cgi/getmsg.cgi?fetch=1981830+1986079+/usr/local/www/db/text/2002/freebsd-current/20021103.freebsd-current

Are there any hints how to solve my problem, I'm willing to give it a 
shot ;)

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: __fpclassifyd problem

2003-10-20 Thread Kris Kennaway
On Mon, Oct 20, 2003 at 10:51:50AM +0200, John Angelmo wrote:

> Are there any hints how to solve my problem, I'm willing to give it a 
> shot ;)

We're discussing it, please be patient.

kris


pgp0.pgp
Description: PGP signature


802.11g PCMCIA card mode

2003-10-20 Thread wintran
Hi,
I have Proxim Orinoco 802.11b/g card, Atheros 5212. I need set ad-hoc mode 
(ifconfig ath0 mode 11g mediaopt adhoc), but it doesn't work. Is it supported this 
mode?

Tin 


Hugo Boss - Boss Intense
Nová vůně pro ženy. 
Zkus ji! 
http://www.email.cz/hugoboss

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: __fpclassifyd problem

2003-10-20 Thread M. Warner Losh
In message: <[EMAIL PROTECTED]>
Scott Long <[EMAIL PROTECTED]> writes:
: We need to resolve this before 5.2 in some fashion.  It looks like the
: easiest thing to do is bump libm.  Is this advisable?

The problem with bumping libm is that we also need, strictly speaking,
to bump all libarires that depend on libm, and that can be very ugly.
This moves the bump the major version from the trivial fix class to
something that we have to think real hard about.  In general one
cannot bump the major version of 'base' libaries like this w/o careful
thought and planning.  While we've done that in the past with libc, I
think we were wrong to do so in some classes of symbol tampering.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: __fpclassifyd problem

2003-10-20 Thread M. Warner Losh
In message: <[EMAIL PROTECTED]>
Steve Kargl <[EMAIL PROTECTED]> writes:
: I sent in an email *along time ago* about this type 
: of problem.  See the fallout due to revision 1.24
: of lib/libc/stdio/findfp.c.  IMHO, all shared libraries
: versions should have been bumped in going from 4.x to
: 5.0. 

I tend to agree due to some weirdness that forced the libc bump.
However, this would then have to includ all ports libraries too.
Bumping all ports libraries and having a viable ports system that
built on both 4.x and 5.x would then become nightmarish because you'd
not want to bump them on 4.x.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Slow Boot

2003-10-20 Thread M. Warner Losh
In message: <[EMAIL PROTECTED]>
Andre Guibert de Bruet <[EMAIL PROTECTED]> writes:
: What does pciconf -vl show on the affected machine(s)?

I think you'll find that not relevant.  I've seen this behavior with
the newer ata code and IDE controllers that had no IDE devices
connected to them...

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


this /rescue thing

2003-10-20 Thread C. Kukulies

/rescue is always causing trouble with me here. make world falls over 
with:

===> rescue/rescue
install -s -o root -g wheel -m 555   rescue /rescue
install -o root  -g wheel -m 555  nextboot_FIXED  /rescue/nextboot.sh
install: /rescue/nextboot.sh: Not a directory
*** Error code 71

Stop in /u/src/rescue/rescue.
*** Error code 1

Looking into / I see that /rescue is a file.

Why is this /rescue being created in /? It used to blow up and 
overflow the / filesystem (there were times when a 40 MB root FS was
sufficient).

What is the safe method to put /rescue elsewhere (in an area with enough
space). It also seems that it is being deleted by make world, at least I
seem to remember that putting a soft link into /rescue into / didn't
help either.

--
Chris Christoph P. U. Kukulies kuku_at_physik.rwth-aachen.de
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted

2003-10-20 Thread Andreas Klemm
Hi,

have severe problems accessing usb devices as non-root user.
In this case a Canon Powershot G5 camera.

I want to download pics from my digicam using digikam application
as user "andreas".

The devices that are being used by digikam:
[EMAIL PROTECTED] ~ lsof | grep digikam | grep /dev
digikam   1755root0u  VCHR5,2 0t19646 110 /dev/ttyp2
digikam   1755root1u  VCHR5,2 0t19646 110 /dev/ttyp2
digikam   1755root2u  VCHR5,2 0t19646 110 /dev/ttyp2
digikam   1755root   15u  VCHR 114,16 0t0 128 /dev/ugen1
digikam   1755root   16r  VCHR 114,17  0t7817 131 /dev/ugen1.1
digikam   1755root   17r  VCHR 114,190t16 133 /dev/ugen1.3

Running digikam with SUID root bit turned on doesn't work.
  [EMAIL PROTECTED] ~ digikam
  The KDE libraries are not designed to run with suid privileges.

Changing the permissions on /dev/ugen1* doesn't work either since

- even _if_ the devices are present after turning camera on and
- even _if_ permissions of /dev/ugen1 /dev/ugen1.1 ... 1.3 are
  being changed successfully to 666

the devices seems to be on the 1st access dynamically recreated,
since the permissions suddenly are *re-set* to root 644 automagically
after the 1st access of the digikam application as user.

To sum up: as normal user I'm unable to connect to the USB camera.

Is there a more generic approach to be able to use USB
devices as non-root user, that I overlooked up to now ?

Andreas ///

-- 
Andreas Klemm - Powered by FreeBSD 5.1-CURRENT
Need a magic printfilter today ? -> http://www.apsfilter.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: 802.11g PCMCIA card mode

2003-10-20 Thread Jiri Mikulas
Hi
~~~cut~~~
- Original Message - From: "Sam Leffler" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, October 18, 2003 11:02 AM
Subject: Fwd: cvs commit: src/sys/net80211 ieee80211_output.c
ieee80211_var.h
This fixes adhoc mode for wi devices.  Adhoc mode is still not working
correctly for ath devices.  No eta on fixing it.
Sam


~~~cut~~~

[EMAIL PROTECTED] napsal(a):

Hi,
I have Proxim Orinoco 802.11b/g card, Atheros 5212. I need set ad-hoc mode 
(ifconfig ath0 mode 11g mediaopt adhoc), but it doesn't work. Is it supported this mode?

Tin 
 

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted

2003-10-20 Thread Poul-Henning Kamp
In message <[EMAIL PROTECTED]>, Andreas Klemm wri
tes:
>Hi,
>
>have severe problems accessing usb devices as non-root user.
>In this case a Canon Powershot G5 camera.
>
>I want to download pics from my digicam using digikam application
>as user "andreas".

Use the devfs(8) command to request changes the owner or modes to
suit your needs.  This works a bit like "firewall rules" and when
the device is created the modes/owner is set.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


bug in NSS ?

2003-10-20 Thread Дейтер Александр Валерьевич
I have a problem with nss_ldap on FreeBSD.
After tranfer users from /etc/passwd to ldap directories my users cannot
send a mail via /usr/bin/mail | /usr/sbin/sendmail  program:

ldap_user$ id
uid=1000(test) gid=1000(test) groups=1000(test)

ldap_user$ pw usershow test
test:*:1000:1000::0:0:test:/tmp:/bin/sh

ldap_user$ ldapsearch -h server -b 'dc=komi,dc=mts,dc=ru' '(uid=test)'
dn: cn=test,dc=komi,dc=mts,dc=ru
cn: test
objectClass: posixAccount
objectClass: account
uid: test
userPassword: test
loginShell: /bin/csh
homeDirectory: /tmp
gecos: test
description: test
uidNumber: 1000
gidNumber: 1000

ldap_user$ date|mail -v root
root... Connecting to [127.0.0.1] via relay...
220 server.komi.mts.ru ESMTP Sendmail 8.12.10/8.12.10; Mon, 20 Oct 2003
13:58:12 +0400 (MSD)
>>> EHLO server.komi.mts.ru
250-server.komi.mts.ru Hello localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH CRAM-MD5 DIGEST-MD5 NTLM LOGIN PLAIN
250-DELIVERBY
250 HELP
>>> AUTH CRAM-MD5
334 PDUyMzg4MDAuOTY3OTM0N0BwYy1kYXYua29taS5tdHMucnU+
AUTH FAIL=needs user interaction (2)
>>> *
501 5.0.0 AUTH aborted
>>> MAIL From:<[EMAIL PROTECTED]> SIZE=39 [EMAIL PROTECTED]
250 2.1.0 <[EMAIL PROTECTED]>... Sender ok
>>> RCPT To:<[EMAIL PROTECTED]>
>>> DATA
250 2.1.5 <[EMAIL PROTECTED]>... Recipient ok
354 Enter mail, end with "." on a line by itself
>>> .
250 2.0.0 h9K9wCNK012427 Message accepted for delivery
root... Sent (h9K9wCNK012427 Message accepted for delivery)
Closing connection to [127.0.0.1]
>>> QUIT
221 2.0.0 server.komi.mts.ru closing connection

for user from /etc/passwd this work fine:

$ date|mail -v root
root... Connecting to [127.0.0.1] via relay...
220 server.komi.mts.ru ESMTP Sendmail 8.12.10/8.12.10; Mon, 20 Oct 2003
14:03:30 +0400 (MSD)
>>> EHLO server.komi.mts.ru
250-server.komi.mts.ru Hello localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH CRAM-MD5 DIGEST-MD5 NTLM LOGIN PLAIN
250-DELIVERBY
250 HELP
>>> AUTH CRAM-MD5
334 PDE4NDMxNzM5MTcuOTY3OTY2NUBwYy1kYXYua29taS5tdHMucnU+
>>> c21tc3AgZmQ4NGQwYzA3MzU0MzQ2NDU5ZjI1Y2QzZTgyMjg1YjE=
235 2.0.0 OK Authenticated
>>> MAIL From:<[EMAIL PROTECTED]> SIZE=39
[EMAIL PROTECTED]
250 2.1.0 <[EMAIL PROTECTED]>... Sender ok
>>> RCPT To:<[EMAIL PROTECTED]>
>>> DATA
250 2.1.5 <[EMAIL PROTECTED]>... Recipient ok
354 Enter mail, end with "." on a line by itself
>>> .
250 2.0.0 h9KA3UNK012452 Message accepted for delivery
root... Sent (h9KA3UNK012452 Message accepted for delivery)
Closing connection to [127.0.0.1]
>>> QUIT
221 2.0.0 server.komi.mts.ru closing connection

/etc/nsswitch.conf:
passwd: files ldap
group:  files ldap

sendmail configuration:

submit.mc:
divert(0)dnl
VERSIONID(`$Id: submit.mc,v 8.6.2.7 2003/09/10 22:11:56 ca Exp $')
define(`confCF_VERSION', `Submit')dnl
define(`__OSTYPE__',`')dnl dirty hack to keep proto.m4 from complaining
define(`_USE_DECNET_SYNTAX_', `1')dnl support DECnet
define(`confTIME_ZONE', `USE_TZ')dnl
define(`confDONT_INIT_GROUPS', `True')dnl
FEATURE(`authinfo', `hash -o /etc/mail/msp-authinfo')
FEATURE(`msp', `[127.0.0.1]')dnl

sendmail.mc:
divert(0)
VERSIONID(`$FreeBSD: mc,v 1.28 2003/04/18 01:25:41 gshapiro Exp $')
OSTYPE(freebsd5)
FEATURE(access_db, `hash -o -T /etc/mail/access')
FEATURE(blacklist_recipients)
FEATURE(local_lmtp)
FEATURE(mailertable, `hash -o /etc/mail/mailertable')
define(`confBIND_OPTS', `WorkAroundBroken')
define(`confNO_RCPT_ACTION', `add-to-undisclosed')
define(`confPRIVACY_FLAGS', `authwarnings,noexpn,novrfy')
define(`_REC_AUTH_', `_REC_FULL_AUTH_')
define(`confAUTH_MECHANISMS',`CRAM-MD5 DIGEST-MD5 NTLM LOGIN PLAIN')
TRUST_AUTH_MECH(`CRAM-MD5 DIGEST-MD5 NTLM LOGIN PLAIN')
MAILER(local)
MAILER(smtp)

LOCAL_RULESETS
SLocal_trust_auth
R$* $: $&{auth_authen}
Rsmmsp  $# OK

/etc/mail/msp-authinfo:
AuthInfo:127.0.0.1  "U:smmsp" "P:smmsp" "M:CRAM-MD5"

# sasldblistusers2
[EMAIL PROTECTED]: userPassword

On Solaris 8 (with same version cyrus-sasl, nss_ldap, openldap and sendmail)
the same user test can send mail success:

ldap_user$ id
uid=1000(test) gid=1000(test)

ldap_user$ ldapsearch -h server -b 'dc=komi,dc=mts,dc=ru' '(uid=test)'
cn=test,dc=komi,dc=mts,dc=ru
cn=test
objectClass=posixAccount
objectClass=account
uid=test
userPassword=test
loginShell=/bin/csh
homeDirectory=/tmp
gecos=test
description=test
uidNumber=1000
gidNumber=1000

ldap_user$ date|sendmail -v root
root... Connecting to [127.0.0.1] via relay...
220 sunos.komi.mts.ru ESMTP Sendmail 8.12.10/8.12.10; Mon, 20 Oct 2003
14:19:31 +0400 (MSD)
>>> EHLO sunos.komi.mts.ru
250-sunos.komi.mts.ru Hello localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH CRAM-MD5 DIGEST-MD5 NTLM LOGIN PLAIN
250-DELIVERBY
250 HELP
>>> AUTH CRAM-MD5
334 PDI3NzMzNDkwMzguOTY4MDYyN0BzaGl2YS5rb21pLm10cy5ydT4=
>>> c21tc3AgODU0MjcyYzBmODE1ZDI3MjM0Yjk3OWM4MjE1ZDQ

Re: Anyone working on a port of OpenBSD's CARP?

2003-10-20 Thread Max Laier
Hello Andre,

Monday, October 20, 2003, 4:07:40 AM, you wrote:
> I was just wondering if anyone was currently having a look at the
> possibility of porting OpenBSD's CARP. I have a bit of free time on my
> hands but wouldn't want to duplicate anyone's work...

we are working on a pf / pfsync port. There are crosslinks between
those two so it would be nice if you got into contact with us. I was
about to look into CARP as well (after following the discussion in
OpenBSD for a while) ...

Maybe that's something for net@ as well? CCed.

-- 
Best regards,
 Maxmailto:[EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


panic with unloading nvidia.ko

2003-10-20 Thread C. Kukulies

I just got a kernel panic after making /usr/ports/x11/nvidia-driver.
I did a make, make reinstall. Then I did a kldunload nvidia.ko
and got:

nvidia0: detached
panic: malloc(9)/free(9) confusion.
Probably freeing with wrong type, but maybe not here.
Debugger("panic")
Stopped at Debugger+0x54:  xchgl   %ebx, in_Debugger.0

trace shows:

Debugger
panic
free
os_free
__nvsym00022
__nvsym00638
__nvsym00678
__nvsym00723
rm_shutdown_rm
nvidia_modevent
driver_module_handler
module_unload
linker_file_unload
kld_unload
syscall
Xint0x80


--
Chris Christoph P. U. Kukulies kuku_at_physik.rwth-aachen.de

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Help saving my system

2003-10-20 Thread Dag-Erling Smørgrav
"Scott M. Likens" <[EMAIL PROTECTED]> writes:
> Ah, such a strong comment from such a strong member.  I would have
> thought you were to high to stoop that low?
>
> But I guess it's good to be flamed for being honest? is it not?

Pot, kettle, black.

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted

2003-10-20 Thread Andreas Klemm
On Mon, Oct 20, 2003 at 12:19:46PM +0200, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Andreas Klemm wri
> tes:
> >Hi,
> >
> >have severe problems accessing usb devices as non-root user.
> >In this case a Canon Powershot G5 camera.
> >
> >I want to download pics from my digicam using digikam application
> >as user "andreas".
> 
> Use the devfs(8) command to request changes the owner or modes to
> suit your needs.  This works a bit like "firewall rules" and when
> the device is created the modes/owner is set.

Good idea. But no success and inexpected results.

Well now I use both /etc/devfs.conf and "devfs rule add" in /etc/rc.local.

It was 1st unclear to me after reading the devfs(8) manpage, that
the
devfs rule add - command
1st needs a command like
devfs ruleset 100

So now I have

1) /etc/devfs.conf with:
permugen1   0666
permugen1.1 0666
permugen1.2 0666
permugen1.3 0666
and
2) devfs rule show
100 path ugen mode 666


I halted system, turned camera off and on
Booted FreeBSD.

1. Step, check permissions without having started any camersa application

ls -l /dev/ugen*
crw-r--r--  1 root  operator  114,   0 Oct 20 13:14 /dev/ugen0
crw-r--r--  1 root  operator  114,   2 Oct 20 13:14 /dev/ugen0.2
crw-rw-rw-  1 root  operator  114,  16 Oct 20 13:14 /dev/ugen1
crw-rw-rw-  1 root  operator  114,  17 Oct 20 13:14 /dev/ugen1.1
crw-rw-rw-  1 root  operator  114,  18 Oct 20 13:14 /dev/ugen1.2
crw-rw-rw-  1 root  operator  114,  19 Oct 20 13:14 /dev/ugen1.3

You see the camera is on, therefore the ugen1 devices have been
created. Good so far.

A bit strange is, that ugen0 (USB printer) still has mode 644,
this is the printer...
I would expect, that the devfs rule 100 would have been applied by
the system and it should be active for this device as well !

Note: And later we see, that even the permission of the ugen1 interface
change again to 644 after the 1st "access" or whatever !

Well lets repeat, the machine is freshly restarted, camera was
on and ugen1 devices have 0666.

2. step: start digikam as user

[EMAIL PROTECTED] ~ ls -l /dev/ugen*
crw-r--r--  1 root  operator  114,   0 Oct 20 13:14 /dev/ugen0
crw-r--r--  1 root  operator  114,   2 Oct 20 13:14 /dev/ugen0.2
crw-rw-rw-  1 root  operator  114,  16 Oct 20 13:14 /dev/ugen1
crw-rw-rw-  1 root  operator  114,  17 Oct 20 13:14 /dev/ugen1.1
crw-rw-rw-  1 root  operator  114,  18 Oct 20 13:14 /dev/ugen1.2
crw-rw-rw-  1 root  operator  114,  19 Oct 20 13:14 /dev/ugen1.3

The startup itself is "harmless" nothing happens and no access to camera.
The digikam application has a config files and presents the camera
found in the last session (from config file).

3. step, try to access camera
   by klick on the Canon PowerShot G5 line in digikam

"failed to initialize the camera"

[EMAIL PROTECTED] ~ ls -l /dev/ugen*
crw-r--r--  1 root  operator  114,   0 Oct 20 13:14 /dev/ugen0
crw-r--r--  1 root  operator  114,   2 Oct 20 13:14 /dev/ugen0.2
crw-rw-rw-  1 root  operator  114,  16 Oct 20 13:14 /dev/ugen1
crw-r--r--  1 root  operator  114,  17 Oct 20 13:14 /dev/ugen1.1
crw-r--r--  1 root  operator  114,  18 Oct 20 13:14 /dev/ugen1.2
crw-r--r--  1 root  operator  114,  19 Oct 20 13:14 /dev/ugen1.3

And voila, ther permission are wrong again.

Note:
I think the lpd daemon accesses the printer on startup.
Therefore the ugen0 device already had the new permission 644
which I observed in the previous step !

Any idea how to resolve this ?

And BTW, shouldn't the devfs(8) manpage have a reference
to devfs.conf ? I understand, that /etc/devfs.conf is only
used by the /etc/rc.d/devfs startup script, to setup permissions
via chmod commands and such  so no real relationship to the
devfs command.

But I'd find it useful to have a reference to it.

Or ... something like a devfs.conf(5) manpage is missing
and a SEE ALSO devfs.conf(5) in devfs(8) is missing, what
would probably be better ...

Or what do you think ?

-- 
Andreas Klemm - Powered by FreeBSD 5.1-CURRENT
Need a magic printfilter today ? -> http://www.apsfilter.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Intel 1000/PRO (em) problem

2003-10-20 Thread Terrence Koeman
Well, I tried the drivers from intel.com, but they are indeed for 4.x kernels and 
don't work on 5.1. An odd thing I noticed is that the driver in 5.1 has the same 
versionnumber as the driver on intel.com, but obviously isn't the same.

Sysctl hw.em0.rx_int_delay was already on 0, so that didn't help either. I think I'll 
write to Intel support.

-- 
Regards,
Terrence Koeman

MediaMonks B.V. (www.mediamonks.com)
Please quote all replies in correspondence.

-- Original Message --
From: "Will Froning" <[EMAIL PROTECTED]>
Date:  Sat, 18 Oct 2003 20:27:28 -0700 (PDT)

>Not sure if anyone has helped you on this, but I've been having this
>problem for a while on 4.x with select chipsets.  My solution is newer
>drivers from intel.com.
>
>Sadly I don't think the drivers on intel.com will work for 5.1, but they
>work great for 4.X.  I just copy them to /usr/src/sys/drv/em and rebuild. 
>I wish I had more help, but I haven't moved my production boxes to 5.1
>yet.
>
>HTH,
>Will
>
>
>> Hi,
>>
>> I'm experiencing a problem with the em driver in 5.1-CURRENT for my Intel
>> 1000/Pro fiber Gbit adapter.
>>
>> The following is recorded in the syslog:
>>
>> Oct 15 18:17:49 shaolin kernel: em0: watchdog timeout -- resetting
>> Oct 15 18:30:25 shaolin kernel: em0: watchdog timeout -- resetting
>> Oct 15 18:30:27 shaolin kernel: em0: Link is Down
>> Oct 15 18:30:27 shaolin kernel: em0: Link is up 1000 Mbps Full Duplex
>> Oct 15 18:31:14 shaolin kernel: em0: watchdog timeout -- resetting
>> Oct 15 18:44:35 shaolin kernel: em0: watchdog timeout -- resetting
>> Oct 15 18:44:37 shaolin kernel: em0: Link is Down
>> Oct 15 18:44:37 shaolin kernel: em0: Link is up 1000 Mbps Full Duplex
>> Oct 15 22:13:54 shaolin kernel: em0: watchdog timeout -- resetting
>> Oct 16 02:18:10 shaolin kernel: em0: watchdog timeout -- resetting
>> Oct 16 02:28:33 shaolin kernel: em0: watchdog timeout -- resetting
>> Oct 16 04:51:46 shaolin kernel: em0: watchdog timeout -- resetting
>> Oct 16 05:58:20 shaolin kernel: em0: watchdog timeout -- resetting
>> Oct 16 05:58:22 shaolin kernel: em0: Link is Down
>> Oct 16 05:58:22 shaolin kernel: em0: Link is up 1000 Mbps Full Duplex
>> Oct 16 08:06:26 shaolin kernel: em0: watchdog timeout -- resetting
>> Oct 16 12:10:01 shaolin kernel: em0: watchdog timeout -- resetting
>> Oct 16 12:10:03 shaolin kernel: em0: Link is Down
>> Oct 16 12:10:04 shaolin kernel: em0: Link is up 1000 Mbps Full Duplex
>> Oct 16 13:44:00 shaolin kernel: em0: watchdog timeout -- resetting
>> Oct 16 13:44:02 shaolin kernel: em0: Link is Down
>> Oct 16 13:44:02 shaolin kernel: em0: Link is up 1000 Mbps Full Duplex
>> Oct 16 14:25:31 shaolin kernel: em0: watchdog timeout -- resetting
>> Oct 16 14:27:01 shaolin kernel: em0: watchdog timeout -- resetting
>> Oct 16 14:28:41 shaolin kernel: em0: watchdog timeout -- resetting
>> Oct 16 14:28:43 shaolin kernel: em0: Link is Down
>> Oct 16 14:28:44 shaolin kernel: em0: Link is up 1000 Mbps Full Duplex
>> Oct 16 14:43:30 shaolin kernel: em0: watchdog timeout -- resetting
>> Oct 16 14:46:57 shaolin kernel: em0: watchdog timeout -- resetting
>> Oct 16 14:46:59 shaolin kernel: em0: Link is Down
>> Oct 16 14:46:59 shaolin kernel: em0: Link is up 1000 Mbps Full Duplex
>> Oct 16 14:51:17 shaolin kernel: em0: watchdog timeout -- resetting
>> Oct 16 14:51:43 shaolin kernel: em0: watchdog timeout -- resetting
>> Oct 16 14:51:45 shaolin kernel: em0: Link is Down
>> Oct 16 14:51:45 shaolin kernel: em0: Link is up 1000 Mbps Full Duplex
>> Oct 16 14:53:32 shaolin kernel: em0: watchdog timeout -- resetting
>> Oct 16 15:15:44 shaolin kernel: em0: watchdog timeout -- resetting
>> Oct 16 15:28:33 shaolin kernel: em0: watchdog timeout -- resetting
>>
>> Everytime it does that connectivity is lost for 2-3 minutes.
>>
>> I have found a similar problem at
>> http://lists.freebsd.org/pipermail/freebsd-stable/2003-April/000539.html
>> but that problem seems to be solved long ago, and the fix described in the
>> thread doesn't help me.
>>
>> I have tried to use some older drivers, but none would solve the problem.
>>
>> Does anyone have an idea how to solve this?
>>
>> Thanks in advance!
>>
>> dmesg:
>>
>> FreeBSD 5.1-CURRENT #12: Mon Oct 13 23:34:55 CEST 2003
>> [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SHAOLIN
>> Preloaded elf kernel "/boot/kernel/kernel" at 0xc040d000.
>> Preloaded elf module "/boot/kernel/acpi.ko" at 0xc040d1cc.
>> Timecounter "i8254" frequency 1193182 Hz quality 0
>> CPU: Intel Pentium III (601.37-MHz 686-class CPU)
>>   Origin = "GenuineIntel"  Id = 0x681  Stepping = 1
>>   
>> Features=0x383f9ff
>> real memory  = 1073725440 (1023 MB)
>> avail memory = 1038782464 (990 MB)
>> Pentium Pro MTRR support enabled
>> npx0: [FAST]
>> npx0:  on motherboard
>> npx0: INT 16 interface
>> acpi0:  on motherboard
>> pcibios: BIOS version 2.10
>> Using $PIR table, 8 entries at 0xc00f0e80
>> acpi0: Power Button (fixed)
>> Timecounter "ACPI-safe" frequency 3579545 Hz quality 100

Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted

2003-10-20 Thread Poul-Henning Kamp
In message <[EMAIL PROTECTED]>, Andreas Klemm writ
es:

>1) /etc/devfs.conf with:
>permugen1   0666
>permugen1.1 0666
>permugen1.2 0666
>permugen1.3 0666

I would probably just use a wildcard:

permugen* 0666

>1st needs a command like
>   devfs ruleset 100

This makes the rules only apply to devices arriving in the future,
you also need:

devfs rule applyset

to make them apply to currently available devices.

>3. step, try to access camera
>   by klick on the Canon PowerShot G5 line in digikam
>
>"failed to initialize the camera"
>
>[EMAIL PROTECTED] ~ ls -l /dev/ugen*
>crw-r--r--  1 root  operator  114,   0 Oct 20 13:14 /dev/ugen0
>crw-r--r--  1 root  operator  114,   2 Oct 20 13:14 /dev/ugen0.2
>crw-rw-rw-  1 root  operator  114,  16 Oct 20 13:14 /dev/ugen1
>crw-r--r--  1 root  operator  114,  17 Oct 20 13:14 /dev/ugen1.1
>crw-r--r--  1 root  operator  114,  18 Oct 20 13:14 /dev/ugen1.2
>crw-r--r--  1 root  operator  114,  19 Oct 20 13:14 /dev/ugen1.3
>
>And voila, ther permission are wrong again.

I have no idea what goes on here.

>And BTW, shouldn't the devfs(8) manpage have a reference
>to devfs.conf ? I understand, that /etc/devfs.conf is only
>used by the /etc/rc.d/devfs startup script, to setup permissions
>via chmod commands and such  so no real relationship to the
>devfs command.

Yes, probably a good idea.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


success (Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted)

2003-10-20 Thread Andreas Klemm
Poul-Henning,

many thanks for you kind guidance to the wonderful world of
devfs (which I never had to tweak in the past) ;-)

On Mon, Oct 20, 2003 at 01:44:50PM +0200, Poul-Henning Kamp wrote:
> I would probably just use a wildcard:
>   permugen* 0666

The wildcard feature is really fine ! Thanks for pointing
me into that direction.

> This makes the rules only apply to devices arriving in the future,
> you also need:
>   devfs rule applyset
> to make them apply to currently available devices.

Good hint ! Thanks !

Well and now things work like expected.

I put these devfs commands now into /etc/rc.local.

But since /etc/rc.local officially has gone, I think this
is not the best place ...

After a longer examination of /etc/devfs, /etc/rc.subr
/etc/defaults/devfs.rules and /etc/defaults/rc.conf
I got the clue, that I can put the statements into /etc/devfs.rules.

Hint: here again we seem to be missing a manpage: devfs.rules(5).

In /etc/rc.subr you see for example a reference to this manpage,
but it doesn't exist.

Andreas ///

-- 
Andreas Klemm - Powered by FreeBSD 5.1-CURRENT
Need a magic printfilter today ? -> http://www.apsfilter.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: success (Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted)

2003-10-20 Thread Poul-Henning Kamp
In message <[EMAIL PROTECTED]>, Andreas Klemm writ
es:

>Hint: here again we seem to be missing a manpage: devfs.rules(5).
>
>In /etc/rc.subr you see for example a reference to this manpage,
>but it doesn't exist.

I'm sure we'd be more than happy to see somebody (hint hint!)
send manual page text to us :-)

I personally end up less(1)'ing /etc/rc.d/* every time I want
to do something...

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


ad0: WARNING - WRITE_MUL write data underrun 8192>2048

2003-10-20 Thread Daryl Chance
I got this message while copying some files from my
windows box (via samba) to my FreeBSD box.  The files
were going to ad4/ad6 (vinum raid).  All I did was
cvsup src and ports during the copy and also, after
the cvsup was done, installed apache2.

uname:
FreeBSD mp3.earthlink.net 5.1-CURRENT FreeBSD
5.1-CURRENT #0: Tue Oct 14 00:33:48 EDT 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/MP3  i386

the only difference between GENERIC and my config is I
removed all cpu except for I686 and changed the ident.
 I attached my dmesg and config.

I also have another problem with my ad4 and ad6 drives
(the ones that are part of the vinum raid).  If I
leave DMA on, i can only copy about 30-50M of data
before i get timeouts and the machine locks up and I
have to do a reset.  Let me know if you need anymore
info (boot -v), or you need access to the machine.

__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.comCopyright (c) 1992-2003 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.1-CURRENT #0: Tue Oct 14 00:33:48 EDT 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/MP3
Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a0b000.
Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a0b21c.
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Athlon(tm) Processor (1311.69-MHz 686-class CPU)
  Origin = "AuthenticAMD"  Id = 0x644  Stepping = 4
  
Features=0x183f9ff
  AMD Features=0xc044
real memory  = 268353536 (255 MB)
avail memory = 251019264 (239 MB)
Pentium Pro MTRR support enabled
npx0: [FAST]
npx0:  on motherboard
npx0: INT 16 interface
acpi0:  on motherboard
pcibios: BIOS version 2.10
Using $PIR table, 9 entries at 0xc00f1750
acpi0: Power Button (fixed)
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0
acpi_cpu0:  on acpi0
acpi_button0:  on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pcib0: slot 4 INTD is routed to irq 12
pcib0: slot 4 INTD is routed to irq 12
pcib0: slot 9 INTA is routed to irq 12
pcib0: slot 12 INTA is routed to irq 11
pcib0: slot 17 INTA is routed to irq 10
agp0:  mem 0xe400-0xe7ff at 
device 0.0 on pci0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
isab0:  at device 4.0 on pci0
isa0:  on isab0
atapci0:  port 0xd800-0xd80f at device 4.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata0: [MPSAFE]
ata1: at 0x170 irq 15 on atapci0
ata1: [MPSAFE]
uhci0:  port 0xd400-0xd41f irq 12 at device 4.2 on pci0
usb0:  on uhci0
usb0: USB revision 1.0
uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1:  port 0xd000-0xd01f irq 12 at device 4.3 on pci0
usb1:  on uhci1
usb1: USB revision 1.0
uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
pci0:  at device 4.4 (no driver attached)
dc0: <82c169 PNIC 10/100BaseTX> port 0xa400-0xa4ff mem 0xe300-0xe3ff irq 12 at 
device 9.0 on pci0
dc0: Ethernet address: 00:a0:cc:53:6e:57
miibus0:  on dc0
bmtphy0:  on miibus0
bmtphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
pci0:  at device 12.0 (no driver attached)
atapci1:  port 
0x8800-0x883f,0x9000-0x9003,0x9400-0x9407,0x9800-0x9803,0xa000-0xa007 mem 
0xdb80-0xdb81 irq 10 at device 17.0 on pci0
atapci1: [MPSAFE]
ata2: at 0xa000 on atapci1
ata2: [MPSAFE]
ata3: at 0x9400 on atapci1
ata3: [MPSAFE]
fdc0:  port 0x3f7,0x3f2-0x3f5 
irq 6 drq 2 on acpi0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
atkbdc0:  port 0x64,0x60 irq 1 on acpi0
atkbd0:  flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
orm0:  at iomem 0xc8000-0xca7ff,0xc-0xc7fff on isa0
pmtimer0 on isa0
ppc0: parallel port not found.
sc0:  at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio0: configured irq 4 not in bitmap of probed irqs 0
sio0: port may not be enabled
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 8250 or not responding
sio1: configured irq 3 not in bitmap of probed irqs 0
sio1: port may not be enabled
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
Timecounter "TSC" frequency 1311691616 Hz quality 800
Timecounters tick every 10.000 msec
acpi_cpu: throttling enabled, 16 steps (100% to 6.2%), currently 100.0%
GEOM: create disk ad0 dp=0xc2e8e470
ad0: 9765MB  [19841/16/63] at ata0-master PIO4
acd0: CDROM  at ata0-slave PIO4
GEOM: create disk ad4 dp=0xc2ea4670
ad4: 29333MB  [59598/16/63] at ata2-master PIO4
GEOM: create disk ad6 dp=0xc2ea4570
ad6: 29333MB  [59598/16/63] at ata3-master PIO4
Mounting root from ufs:/dev/ad0s1a
dc0: failed to force tx and rx to idle state
dc0: failed to force tx and rx to idle state
dc0: failed to force tx and rx to idle state
ad0: WARNING - WRITE_MUL write data underrun 8192>4096
ad0: WARNING - WRITE_MUL write data und

Re: Random signals in {build,install}world recently?

2003-10-20 Thread Mark Santcroos
On Mon, Oct 20, 2003 at 10:27:38AM +0200, Harti Brandt wrote:
> On Mon, 20 Oct 2003, Vallo Kallaste wrote:
> 
> VK>Hi
> VK>
> VK>It seems to be a recent problem. The hardware is OK, both Windows XP
> VK>(which I use very seldom) and Gentoo Linux do not exhibit any
> VK>problems.
> VK>Basically one will get random signals as I have got in build- and
> VK>installworld. It's impossible to complete make -j2 buildworld on my
> VK>machine, but sometimes non-parallel buildworld will do, only to die
> VK>later in installworld.
> VK>This is on two-processor AMD 2400+ MP system, ASUS A7M-266D mobo and
> VK>1GB ECC memory, ATA disks and CD/RW-DVD only. 4BSD scheduler if it
> VK>matters.
> 
> I have the same MB just with 1800+ processors. I had to reduce the CPU
> frequency by about 10% in the BIOS setup to get the machine stable. I
> assume the problem is actually the memory.

Couldn't the following be of help here?

options DISABLE_PSE
options DISABLE_PG_G

Mark
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: __fpclassifyd problem

2003-10-20 Thread Daniel Eischen
On Mon, 20 Oct 2003, M. Warner Losh wrote:

> In message: <[EMAIL PROTECTED]>
> Scott Long <[EMAIL PROTECTED]> writes:
> : We need to resolve this before 5.2 in some fashion.  It looks like the
> : easiest thing to do is bump libm.  Is this advisable?
> 
> The problem with bumping libm is that we also need, strictly speaking,
> to bump all libarires that depend on libm, and that can be very ugly.
> This moves the bump the major version from the trivial fix class to
> something that we have to think real hard about.  In general one
> cannot bump the major version of 'base' libaries like this w/o careful
> thought and planning.  While we've done that in the past with libc, I
> think we were wrong to do so in some classes of symbol tampering.
> 
> Warner ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe,
> send any mail to "[EMAIL PROTECTED]"
> 

If it's just __fpclassifyd(), can you just add a compatability
hack to libm so it works with both libc 4.0 and 5.x?  You
can make __fpclassifyd a weak definition to the hack in libm.
I suppose you could also add __fpclassfyd() to libc 4.0.

-- 
Dan Eischen

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Random signals in {build,install}world recently?

2003-10-20 Thread Harti Brandt
On Mon, 20 Oct 2003, Mark Santcroos wrote:

MS>On Mon, Oct 20, 2003 at 10:27:38AM +0200, Harti Brandt wrote:
MS>> On Mon, 20 Oct 2003, Vallo Kallaste wrote:
MS>>
MS>> VK>Hi
MS>> VK>
MS>> VK>It seems to be a recent problem. The hardware is OK, both Windows XP
MS>> VK>(which I use very seldom) and Gentoo Linux do not exhibit any
MS>> VK>problems.
MS>> VK>Basically one will get random signals as I have got in build- and
MS>> VK>installworld. It's impossible to complete make -j2 buildworld on my
MS>> VK>machine, but sometimes non-parallel buildworld will do, only to die
MS>> VK>later in installworld.
MS>> VK>This is on two-processor AMD 2400+ MP system, ASUS A7M-266D mobo and
MS>> VK>1GB ECC memory, ATA disks and CD/RW-DVD only. 4BSD scheduler if it
MS>> VK>matters.
MS>>
MS>> I have the same MB just with 1800+ processors. I had to reduce the CPU
MS>> frequency by about 10% in the BIOS setup to get the machine stable. I
MS>> assume the problem is actually the memory.
MS>
MS>Couldn't the following be of help here?
MS>
MS>options DISABLE_PSE
MS>options DISABLE_PG_G

Is the processor bug that these options seem to circumvent dependend on
the actual operating frequency of the processor?

harti
-- 
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Random signals in {build,install}world recently?

2003-10-20 Thread Mark Santcroos
On Mon, Oct 20, 2003 at 03:29:04PM +0200, Harti Brandt wrote:
> MS>> I have the same MB just with 1800+ processors. I had to reduce the CPU
> MS>> frequency by about 10% in the BIOS setup to get the machine stable. I
> MS>> assume the problem is actually the memory.
> MS>
> MS>Couldn't the following be of help here?
> MS>
> MS>options DISABLE_PSE
> MS>options DISABLE_PG_G
> 
> Is the processor bug that these options seem to circumvent dependend on
> the actual operating frequency of the processor?

That won't surprise me, as afaik it's a timing thing.
Note that due to all vagueness around this issue I could be wrong, but
it's worth a try I guess.

Mark
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Random signals in {build,install}world recently?

2003-10-20 Thread Vallo Kallaste
On Mon, Oct 20, 2003 at 10:27:38AM +0200, Harti Brandt
<[EMAIL PROTECTED]> wrote:

> VK>It seems to be a recent problem. The hardware is OK, both Windows XP
> VK>(which I use very seldom) and Gentoo Linux do not exhibit any
> VK>problems.
> VK>Basically one will get random signals as I have got in build- and
> VK>installworld. It's impossible to complete make -j2 buildworld on my
> VK>machine, but sometimes non-parallel buildworld will do, only to die
> VK>later in installworld.
> VK>This is on two-processor AMD 2400+ MP system, ASUS A7M-266D mobo and
> VK>1GB ECC memory, ATA disks and CD/RW-DVD only. 4BSD scheduler if it
> VK>matters.
> 
> I have the same MB just with 1800+ processors. I had to reduce the CPU
> frequency by about 10% in the BIOS setup to get the machine stable. I
> assume the problem is actually the memory.

I'm in doubt in this matter, because it's been absolutely stable so
far and is as stable as before under Linux and XP. Also, my problems
very much coincidence with some list traffic about the same
problem, follow the thread:
Subject: Seeing system-lockups on recent current
Message-ID: <[EMAIL PROTECTED]>
I also managed to panic the system after repeated attempts to get
through the installworld (which all failed). The panic string is
"panic: pmap_enter: attempted pmap_enter on 4MB page" and is also
described by the message:
Subject: panic: pmap_enter: attempted pmap_enter on 4MB page
Message-ID: <[EMAIL PROTECTED]>
I have debug kernel, but the system locked up after the message and
I had to drive home and reset the system. All those problematic
systems seem to be AMD based.
-- 
Vallo Kallaste
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Random signals in {build,install}world recently?

2003-10-20 Thread Barney Wolff
On Mon, Oct 20, 2003 at 03:20:56PM +0200, Mark Santcroos wrote:
> On Mon, Oct 20, 2003 at 10:27:38AM +0200, Harti Brandt wrote:
> > On Mon, 20 Oct 2003, Vallo Kallaste wrote:
> > 
> > VK>Hi
> > VK>
> > VK>It seems to be a recent problem. The hardware is OK, both Windows XP
> > VK>(which I use very seldom) and Gentoo Linux do not exhibit any
> > VK>problems.
> > VK>Basically one will get random signals as I have got in build- and
> > VK>installworld. It's impossible to complete make -j2 buildworld on my
> > VK>machine, but sometimes non-parallel buildworld will do, only to die
> > VK>later in installworld.
> > VK>This is on two-processor AMD 2400+ MP system, ASUS A7M-266D mobo and
> > VK>1GB ECC memory, ATA disks and CD/RW-DVD only. 4BSD scheduler if it
> > VK>matters.
> > 
> > I have the same MB just with 1800+ processors. I had to reduce the CPU
> > frequency by about 10% in the BIOS setup to get the machine stable. I
> > assume the problem is actually the memory.
> 
> Couldn't the following be of help here?
> 
> options DISABLE_PSE
> options DISABLE_PG_G

I don't think so.  I tried that on my A7M266D with no effect.  I believe
something in recent pmap code doesn't like this mobo, or maybe dual
athlons in general.  I can run RELENG_5_1 rock solid, and -current from
9/24/03 rock solid, but -current from 10/3 or later gets random sigs
and eventually panics.  I have scsi disks so it's not ata.

-- 
Barney Wolff http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: success (Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted)

2003-10-20 Thread David O'Brien
On Mon, Oct 20, 2003 at 02:40:00PM +0200, Poul-Henning Kamp wrote:
> >Hint: here again we seem to be missing a manpage: devfs.rules(5).
> >
> >In /etc/rc.subr you see for example a reference to this manpage,
> >but it doesn't exist.
> 
> I'm sure we'd be more than happy to see somebody (hint hint!)
> send manual page text to us :-)

That's not the right attitude for something that is 100% your baby.
You've added a completely new subsystem to FreeBSD, one that people have
no choice but to deal with when they move from 4.x to 5.x since you
made devfs mandatory.  It is YOUR responsibility to document it.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: this /rescue thing

2003-10-20 Thread David O'Brien
On Mon, Oct 20, 2003 at 11:55:57AM +0200, C. Kukulies wrote:
> ===> rescue/rescue
> install -s -o root -g wheel -m 555   rescue /rescue
> install -o root  -g wheel -m 555  nextboot_FIXED  /rescue/nextboot.sh
> install: /rescue/nextboot.sh: Not a directory
> *** Error code 71
> 
> Stop in /u/src/rescue/rescue.
> *** Error code 1
> 
> Looking into / I see that /rescue is a file.

There was some pilot error in the order in which you updated your system
after we added 'rescue'.  You need to 'rm -rf /rescue ; mkdir /rescue'
and then rebuild and install it.

> What is the safe method to put /rescue elsewhere (in an area with enough
> space). It also seems that it is being deleted by make world, at least I
> seem to remember that putting a soft link into /rescue into / didn't
> help either.

You're missing the point of /rescue.  It MUST be in / to be of any use.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Random signals in {build,install}world recently?

2003-10-20 Thread Christian Brueffer
On Mon, Oct 20, 2003 at 10:50:02AM -0400, Barney Wolff wrote:
> On Mon, Oct 20, 2003 at 03:20:56PM +0200, Mark Santcroos wrote:
> > On Mon, Oct 20, 2003 at 10:27:38AM +0200, Harti Brandt wrote:
> > > On Mon, 20 Oct 2003, Vallo Kallaste wrote:
> > > 
> > > VK>Hi
> > > VK>
> > > VK>It seems to be a recent problem. The hardware is OK, both Windows XP
> > > VK>(which I use very seldom) and Gentoo Linux do not exhibit any
> > > VK>problems.
> > > VK>Basically one will get random signals as I have got in build- and
> > > VK>installworld. It's impossible to complete make -j2 buildworld on my
> > > VK>machine, but sometimes non-parallel buildworld will do, only to die
> > > VK>later in installworld.
> > > VK>This is on two-processor AMD 2400+ MP system, ASUS A7M-266D mobo and
> > > VK>1GB ECC memory, ATA disks and CD/RW-DVD only. 4BSD scheduler if it
> > > VK>matters.
> > > 
> > > I have the same MB just with 1800+ processors. I had to reduce the CPU
> > > frequency by about 10% in the BIOS setup to get the machine stable. I
> > > assume the problem is actually the memory.
> > 
> > Couldn't the following be of help here?
> > 
> > options DISABLE_PSE
> > options DISABLE_PG_G
> 
> I don't think so.  I tried that on my A7M266D with no effect.  I believe
> something in recent pmap code doesn't like this mobo, or maybe dual
> athlons in general.  I can run RELENG_5_1 rock solid, and -current from
> 9/24/03 rock solid, but -current from 10/3 or later gets random sigs
> and eventually panics.  I have scsi disks so it's not ata.
> 

I have the same experiences.  Also AMD A7M-266D with two 1800+ Athlons here.
Used to work fine, but got random signals with my latest builds.

- Christian

-- 
Christian Brueffer  [EMAIL PROTECTED]   [EMAIL PROTECTED]
GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc
GPG Fingerprint: A5C8 2099 19FF AACA F41B  B29B 6C76 178C A0ED 982D


pgp0.pgp
Description: PGP signature


Re: Random signals in {build,install}world recently?

2003-10-20 Thread Harti Brandt
On Mon, 20 Oct 2003, Christian Brueffer wrote:

CB>On Mon, Oct 20, 2003 at 10:50:02AM -0400, Barney Wolff wrote:
CB>> On Mon, Oct 20, 2003 at 03:20:56PM +0200, Mark Santcroos wrote:
CB>> > On Mon, Oct 20, 2003 at 10:27:38AM +0200, Harti Brandt wrote:
CB>> > > On Mon, 20 Oct 2003, Vallo Kallaste wrote:
CB>> > >
CB>> > > VK>Hi
CB>> > > VK>
CB>> > > VK>It seems to be a recent problem. The hardware is OK, both Windows XP
CB>> > > VK>(which I use very seldom) and Gentoo Linux do not exhibit any
CB>> > > VK>problems.
CB>> > > VK>Basically one will get random signals as I have got in build- and
CB>> > > VK>installworld. It's impossible to complete make -j2 buildworld on my
CB>> > > VK>machine, but sometimes non-parallel buildworld will do, only to die
CB>> > > VK>later in installworld.
CB>> > > VK>This is on two-processor AMD 2400+ MP system, ASUS A7M-266D mobo and
CB>> > > VK>1GB ECC memory, ATA disks and CD/RW-DVD only. 4BSD scheduler if it
CB>> > > VK>matters.
CB>> > >
CB>> > > I have the same MB just with 1800+ processors. I had to reduce the CPU
CB>> > > frequency by about 10% in the BIOS setup to get the machine stable. I
CB>> > > assume the problem is actually the memory.
CB>> >
CB>> > Couldn't the following be of help here?
CB>> >
CB>> > options DISABLE_PSE
CB>> > options DISABLE_PG_G
CB>>
CB>> I don't think so.  I tried that on my A7M266D with no effect.  I believe
CB>> something in recent pmap code doesn't like this mobo, or maybe dual
CB>> athlons in general.  I can run RELENG_5_1 rock solid, and -current from
CB>> 9/24/03 rock solid, but -current from 10/3 or later gets random sigs
CB>> and eventually panics.  I have scsi disks so it's not ata.
CB>>
CB>
CB>I have the same experiences.  Also AMD A7M-266D with two 1800+ Athlons here.
CB>Used to work fine, but got random signals with my latest builds.

I have no problems with the -current, but, as I've said, I have tuned
speed down. If I remember correctly they running slower than their nominal
speed. Dmesg shows 1380.01MHz, although they're 1800+. This is tuneable in
the BIOS.

harti
-- 
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: new -current panic

2003-10-20 Thread Bernd Walter
On Mon, Oct 20, 2003 at 09:09:47AM +0200, Soren Schmidt wrote:
> Just got this one (using bsd scheduler):
> 
> Fatal trap 12: page fault while in kernel mode
> fault virtual address   = 0x24
> fault code  = supervisor read, page not present
> instruction pointer = 0x8:0xc04b8f3b
> stack pointer   = 0x10:0xcd619bc4
> frame pointer   = 0x10:0xcd619bd8
> 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 = 3 (g_up)
> kernel: type 12 trap, code=0
> Stopped at  propagate_priority+0x8b:cmpl0x24(%ebx),%ecx
> db> trace
> propagate_priority(c0ebfe40,c25983c0,c2512400,cd619c14,c04cc9d1) at propagate_pr
> iority+0x8b
> _mtx_lock_sleep(c069c340,0,0,0,c0698700) at _mtx_lock_sleep+0x249
> bufdonebio(c7675b68,cd619c44,c048d612,c084c540,c259f990) at bufdonebio+0x47
> biodone(c7675b68,c06411ba,c259f990,c7675b68,0) at biodone+0xbc
> g_dev_done(c259f990,c0ebfe40,1,0,4) at g_dev_done+0x8a
> biodone(c259f990,0,24c,c0640b45,a) at biodone+0xbc
> g_io_schedule_up(c0ebfe40,c0ebe1e4,cd619d34,c04acae1,0) at g_io_schedule_up+0xb8
> g_up_procbody(0,cd619d48,0,0,0) at g_up_procbody+0x28
> fork_exit(c048df60,0,cd619d48) at fork_exit+0xb1
> fork_trampoline() at fork_trampoline+0x8
> --- trap 0x1, eip = 0, esp = 0xcd619d7c, ebp = 0 ---
> db> 

I can remember having seen a similar panic several month ago - maybe
even in jan or feb.

-- 
B.Walter   BWCThttp://www.bwct.de
[EMAIL PROTECTED]  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted

2003-10-20 Thread Bernd Walter
On Mon, Oct 20, 2003 at 01:44:50PM +0200, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Andreas Klemm writ
> es:
> >[EMAIL PROTECTED] ~ ls -l /dev/ugen*
> >crw-r--r--  1 root  operator  114,   0 Oct 20 13:14 /dev/ugen0
> >crw-r--r--  1 root  operator  114,   2 Oct 20 13:14 /dev/ugen0.2
> >crw-rw-rw-  1 root  operator  114,  16 Oct 20 13:14 /dev/ugen1
> >crw-r--r--  1 root  operator  114,  17 Oct 20 13:14 /dev/ugen1.1
> >crw-r--r--  1 root  operator  114,  18 Oct 20 13:14 /dev/ugen1.2
> >crw-r--r--  1 root  operator  114,  19 Oct 20 13:14 /dev/ugen1.3
> >
> >And voila, ther permission are wrong again.
> 
> I have no idea what goes on here.

An USB device can be switched between several alternative
configurations.
If such a change is requested (USB_SET_CONFIG) the devicenode for
everything but the control channel is recreated.

-- 
B.Walter   BWCThttp://www.bwct.de
[EMAIL PROTECTED]  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted

2003-10-20 Thread Poul-Henning Kamp
In message <[EMAIL PROTECTED]>, Bernd Walter writes:
>On Mon, Oct 20, 2003 at 01:44:50PM +0200, Poul-Henning Kamp wrote:
>> In message <[EMAIL PROTECTED]>, Andreas Klemm writ
>> es:
>> >[EMAIL PROTECTED] ~ ls -l /dev/ugen*
>> >crw-r--r--  1 root  operator  114,   0 Oct 20 13:14 /dev/ugen0
>> >crw-r--r--  1 root  operator  114,   2 Oct 20 13:14 /dev/ugen0.2
>> >crw-rw-rw-  1 root  operator  114,  16 Oct 20 13:14 /dev/ugen1
>> >crw-r--r--  1 root  operator  114,  17 Oct 20 13:14 /dev/ugen1.1
>> >crw-r--r--  1 root  operator  114,  18 Oct 20 13:14 /dev/ugen1.2
>> >crw-r--r--  1 root  operator  114,  19 Oct 20 13:14 /dev/ugen1.3
>> >
>> >And voila, ther permission are wrong again.
>> 
>> I have no idea what goes on here.
>
>An USB device can be switched between several alternative
>configurations.
>If such a change is requested (USB_SET_CONFIG) the devicenode for
>everything but the control channel is recreated.

But the devfs rules should still set the mode when it is recreated...

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


ethercons: ethernet console driver for 5-current

2003-10-20 Thread Robert Watson

I had a fair amount of time over the last week running in disconnected
operation, and realized I had too many cables under my desk, so I spent a
bit of time exploring the FreeBSD console code.  After reading a FREENIX
paper this summer on a Linux ethernet console driver, I took a pass at
implementing ethernet console support for FreeBSD.  This driver is similar
to the Linux driver, although not binary-compatible on the wire, as this
driver supports both input and output, while the Linux driver supports
only output monitoring (and the protocol can't represent bi-directional
communication well).  There are some potential work-arounds for this,
which I'll explore at some point.  In general, the wire protocol is
probably the weakest part of the endeavor, but I'm having trouble finding
documentation for a decent wire console protocol that doesn't come with an
entire network stack attached.

As with the Linux driver, communication happens at the ethernet link
layer, using protocol number 0x0666 (entertaining choice).  The contents
consist of a little meta-data (not found in Linux), and a nul-terminated
string, although the kernel code currently generates only single
characters due to the nature of the console code.  ethercons implements
both a low level putc() console interface, and a high-level pseudo-tty
appropriate for /dev/console redirection and getty/login.  Unlike the
other low-level console drivers, ethercons does not implement low-level
input checkc/getc, as ethercons is interrupt driven, and that interface is
a polled interface that conflicts with the tty code.  I'm considering
adopting a timeout-driven model as done in ofw_console, but haven't
convinced myself that is entirely desirable.  In addition, the ethercons
device is not available for I/O when in the debugger context, due to its
use of the network stack.  To support this, I recently added a flags field
to the console definition, and a NODEBUGGER flag.

To enable support for ethercons, add "options ETHERCONS" to your kernel
configuration.  A series of tunables and sysctls is available to tune the
behavior of ethercons:

kern.ethercons.ifnet_raise  "ifconfig up" the interface prior to
reaching init so that ethercons may be
used in single usermode.  Otherwise,
ethercons only becomes available when the
interface is brought up later by
dhclient/ifconfig/...  Alternatively, for
network booted environments, the interface
may already be up.

kern.ethercons.interface_preference Interface name preference, if any.
Otherwise, the default is the first
ethernet interface.  The most
recently used interface is
available read-only via
kern.ethercons.interface.

kern.ethercons.target   Target ethernet address for the console target.
Otherwise, the default is ff:ff:ff:ff:ff:ff. 

The ethercons client uses bpf; it's a fairly limited tool in its current
form.  It has several modes of operation:

log Follow the console output of all ethernet consoles,
logging the output to various log files, named by the
source ethernet address of the messages (specified by
interface).

minitermA minimalist interactive terminal program to be pointed
at a specific ethernet interface and hardware address.

sendSend a string to a remote console as input (specified
by interface, target address).

sendcr  Send a string to the remote console as input, along
with a carriage return (specified by interface, target
address).

tailFollow the console output of a particular ethernet console
(specified by interface and source address).

tailall Follow the console output of all ethernet consoles, even
though the results are potentially messy (specified by
interface).

It should be possible to create a more complete client for easier
interactive use; alternatively, the firewire console code binds a socket
for use with a telnet client, which could be done for ethercons, which
might be a better approach than writing more interactive code of that
sort. 

You can set up a getty/login session on /dev/ethercons using /etc/ttys:

  ethercons   "/usr/libexec/getty Pc" xterm   on secure

The changes consist of three parts: two new kernel files
(src/sys/dev/{ethercons.c, ethercons.h}), a kernel patch (ethercons.diff),
and a userland tool for monitoring/logging/communicating with the ethernet
console (src/usr.sbin/ethercons/{ethercons.c,eth

Re: bug in NSS ?

2003-10-20 Thread Scot W. Hetzel
From: "Дейтер Александр Валерьевич" <[EMAIL PROTECTED]>
> I have a problem with nss_ldap on FreeBSD.
> After tranfer users from /etc/passwd to ldap directories my users cannot
> send a mail via /usr/bin/mail | /usr/sbin/sendmail  program:
>
:
> Any ideas ?
>
What are the contents of the /usr/local/lib/sasl*/Sendmail.conf file?

Is pwcheck_method set to saslauthd, or sasldb?

If it is set to saslauthd, what flags do you use for it (-a pam or -a ldap)?

Scot

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: sata + vinum + Asus p4p800 = :(

2003-10-20 Thread Alexander Leidinger
Greg 'groggy' Lehey schrieb:

Provide a dump?  Analyse the problem yourself?  This *is* -CURRENT,
after all.  
I can reproduce this here (same MB). I don't think it's a vinum problem, 
but vinum seems to be a good way to reproduce the bug. I set up a stripe 
over 2 SATA disks, newfs it, run "iozone -a" and BOOM.

Using just one disk without vinum doesn't result in a panic, but with a 
verbose boot I see a lot of spurious interrupt messages while running 
iozone on one disk.

The panic is:
panic: ata_dmasetup: transfer active on this disk.
Backtrace:
ata_dmastart
ata_pci_dmastart
ata_transaction
ata_start
g_disk_start
g_io_schedule_down
g_down_procbody
fork_exit
fork_trampoline
Trying to write a dump results in a hard hang of the system.

The backtrace is with todays kernel source:
ata-lowlevel 1.20
ata-pci.c 1.69
ata-queue.c 1.11
atapi-cd.c 1.149
Verbose dmesg attached (booted with an oct 17 kernel, if it's not 
enough, I rebuild the kernel with a larger message buffer).

Greg, I don't know if the following is ATA related:
I'm able to fdisk and disklabel the disks without any prolems, and the 
label survives a reboot, but rebooting after setting up the stripe 
results in a lost configuration, only the names of the drives show up 
with "vinum l", everything else is "clean" (0 volumes, 0 plexes, 0 
subdisks). The config is:
---snip---
drive SATA1 device /dev/ad1s1a
drive SATA2 device /dev/ad2s1a
volume space setupstate
	plex org striped 279k
		sd length 0 drive SATA1
		sd length 0 drive SATA2
---snip---

S/oren, one additional datapoint: With the oct 17 kernel I've seen the 
following output with a verbose boot before it hunged hard (I had 
DDB_UNATTENDED in the oct 17 kernel):
- spurious interrupt messages for ata 0 and 2
- WARNING FLUSHCASHE for ad0
- WARNING WRITE_DMA recovered from missing int for ad1
- TIMEOUT WRITE_DMA retrying for ad2
- ata3 reset tp1 mask=03 ostat0=d0 ostat1=00
---snip---

Feel free to use me as an testing-ape, I also can provide a root login 
to this machine if needed (just tell me and I grab the ssh key from 
freefall).

Bye,
Alexander.
ngnt=0x00 (0 ns), maxlat=0x00 (0 ns)
found-> vendor=0x8086, dev=0x2571, revid=0x02
bus=0, slot=1, func=0
class=06-04-00, hdrtype=0x01, mfdev=0
cmdreg=0x0107, statreg=0x00a0, cachelnsz=0 (dwords)
lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns)
map[20]: type 4, range 32, base ef00, size  5, enabled
pcib0: matched entry for 0.29.INTA (source \\_SB_.LNKA)
pcib0: slot 29 INTA is routed to irq 10
found-> vendor=0x8086, dev=0x24d2, revid=0x02
bus=0, slot=29, func=0
class=0c-03-00, hdrtype=0x00, mfdev=1
cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=10
map[20]: type 4, range 32, base ef20, size  5, enabled
pcib0: matched entry for 0.29.INTB (source \\_SB_.LNKD)
pcib0: slot 29 INTB is routed to irq 5
found-> vendor=0x8086, dev=0x24d4, revid=0x02
bus=0, slot=29, func=1
class=0c-03-00, hdrtype=0x00, mfdev=0
cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=b, irq=5
map[20]: type 4, range 32, base ef40, size  5, enabled
pcib0: matched entry for 0.29.INTC (source \\_SB_.LNKC)
pcib0: slot 29 INTC is routed to irq 5
found-> vendor=0x8086, dev=0x24d7, revid=0x02
bus=0, slot=29, func=2
class=0c-03-00, hdrtype=0x00, mfdev=0
cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=c, irq=5
map[20]: type 4, range 32, base ef80, size  5, enabled
pcib0: matched entry for 0.29.INTA (source \\_SB_.LNKA)
pcib0: slot 29 INTA is routed to irq 10
found-> vendor=0x8086, dev=0x24de, revid=0x02
bus=0, slot=29, func=3
class=0c-03-00, hdrtype=0x00, mfdev=0
cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=10
map[10]: type 1, range 32, base febff800, size 10, enabled
pcib0: matched entry for 0.29.INTD (source \\_SB_.LNKH)
pcib0: slot 29 INTD is routed to irq 11
found-> vendor=0x8086, dev=0x24dd, revid=0x02
bus=0, slot=29, func=7
class=0c-03-20, hdrtype=0x00, mfdev=0
cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=d, irq=11
powerspec 2  supports D0 D3  current D0
found-> vendor=0x8086, dev=0x244e, revid=0xc2
bus=0, slot=30, func=0
class=06-04-00, hdrtype=0x01, mfdev=0
cmdreg=0x0107, statreg=0x0080, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns)
found-> vendor=0x8086, dev=0x24d0, revid=0x02
bus=0, slot=31, func=0

Re: ethercons: ethernet console driver for 5-current

2003-10-20 Thread Steve Kargl
On Mon, Oct 20, 2003 at 12:13:27PM -0400, Robert Watson wrote:
> 
> I had a fair amount of time over the last week running in disconnected
> operation, and realized I had too many cables under my desk, so I spent a
> bit of time exploring the FreeBSD console code.  After reading a FREENIX
> paper this summer on a Linux ethernet console driver, I took a pass at
> implementing ethernet console support for FreeBSD.

Robert,

This looks very interesting!  Can we run ddb over the
ethercon to debug a wedged machine?

-- 
Steve
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


[current tinderbox] failure on alpha/alpha

2003-10-20 Thread Tinderbox
TB --- 2003-10-20 16:00:01 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org
TB --- 2003-10-20 16:00:01 - starting CURRENT tinderbox run for alpha/alpha
TB --- 2003-10-20 16:00:01 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-10-20 16:01:56 - building world
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src
TB --- /usr/bin/make -B buildworld
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: populating 
>>> /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything..
TB --- 2003-10-20 17:04:33 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
>>> Kernel build for GENERIC started on Mon Oct 20 17:04:33 GMT 2003
[...]
cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -g -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
-mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror  
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/amr/amr_cam.c
cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -g -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
-mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror  
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/amr/amr.c
cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -g -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
-mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror  
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/amr/amr_disk.c
cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -g -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
-mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror  
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/amr/amr_pci.c
cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -g -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath 
-I/v

pcm & exclusive sleep mutex with Oct19 CURRENT

2003-10-20 Thread Paolo Pisati

from my dmesg:
[snip]
pcm0:  port 0xb800-0xb8ff irq 5 at device 1.0 on pci2
pcm0: failed to enable memory mapping!
pcm0: 
malloc() of "64" with the following non-sleepable locks held:
exclusive sleep mutex pcm0:mixer (pcm mixer) r = 0 (0xc2d34540) locked @ 
/usr/src/sys/dev/sound/pcm/mixer.c:322
malloc() of "16" with the following non-sleepable locks held:
exclusive sleep mutex pcm0:mixer (pcm mixer) r = 0 (0xc2d34540) locked @ 
/usr/src/sys/dev/sound/pcm/mixer.c:322
malloc() of "16" with the following non-sleepable locks held:
exclusive sleep mutex pcm0:mixer (pcm mixer) r = 0 (0xc2d34540) locked @ 
/usr/src/sys/dev/sound/pcm/mixer.c:322
malloc() of "16" with the following non-sleepable locks held:
exclusive sleep mutex pcm0:mixer (pcm mixer) r = 0 (0xc2d34540) locked @ 
/usr/src/sys/dev/sound/pcm/mixer.c:322
malloc() of "64" with the following non-sleepable locks held:
exclusive sleep mutex pcm0:mixer (pcm mixer) r = 0 (0xc2d34540) locked @ 
/usr/src/sys/dev/sound/pcm/mixer.c:322
malloc() of "16" with the following non-sleepable locks held:
exclusive sleep mutex pcm0:mixer (pcm mixer) r = 0 (0xc2d34540) locked @ 
/usr/src/sys/dev/sound/pcm/mixer.c:322
malloc() of "16" with the following non-sleepable locks held:
exclusive sleep mutex pcm0:mixer (pcm mixer) r = 0 (0xc2d34540) locked @ 
/usr/src/sys/dev/sound/pcm/mixer.c:322
malloc() of "16" with the following non-sleepable locks held:
exclusive sleep mutex pcm0:mixer (pcm mixer) r = 0 (0xc2d34540) locked @ 
/usr/src/sys/dev/sound/pcm/mixer.c:322
[snip]
and later today i got even this:

acquiring duplicate lock of same type: "pcm channel"
 1st pcm0:record:0 @ /usr/src/sys/dev/sound/pcm/sound.c:195
 2nd pcm0:play:0 @ /usr/src/sys/dev/sound/pcm/sound.c:195
Stack backtrace:

with no backtrace at all.

[EMAIL PROTECTED] flag]$ uname -a
FreeBSD southcross.skynet.org 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sun Oct 19 12:07:09 
CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SOUTHCROSS  i386
[EMAIL PROTECTED] flag]$ 

-- 
Paolo

Italian FreeBSD User Group: http://www.gufi.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: sata + vinum + Asus p4p800 = :(

2003-10-20 Thread Balazs Nagy
On Monday, Oct 20, 2003, at 19:02 Europe/Budapest, Alexander Leidinger 
wrote:

Greg 'groggy' Lehey schrieb:

Provide a dump?  Analyse the problem yourself?  This *is* -CURRENT,
after all.
I can reproduce this here (same MB). I don't think it's a vinum 
problem,
but vinum seems to be a good way to reproduce the bug. I set up a 
stripe
over 2 SATA disks, newfs it, run "iozone -a" and BOOM.
Well, my /etc dir is gone, and I have no other bootable device. 
Tomorrow my hardware guy will bring me a new be7s motherboard...  Sorry 
guys, the rest is in your hands.
--
jul

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: bug in NSS ?

2003-10-20 Thread Alex Deiter
>> I have a problem with nss_ldap on FreeBSD.
>> After tranfer users from /etc/passwd to ldap directories my users cannot
>> send a mail via /usr/bin/mail | /usr/sbin/sendmail  program:

>What are the contents of the /usr/local/lib/sasl*/Sendmail.conf file?
>Is pwcheck_method set to saslauthd, or sasldb?
>If it is set to saslauthd, what flags do you use for it (-a pam or -a
ldap)?

my /usr/local/lib/sasl2/Sendmail.conf:
pwcheck_method: auxprop
auxprop_plugin: sasldb

Thanks!

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: pcm & exclusive sleep mutex with Oct19 CURRENT

2003-10-20 Thread Kris Kennaway
On Mon, Oct 20, 2003 at 07:15:19PM +0200, Paolo Pisati wrote:
> 
> from my dmesg:
> [snip]
> pcm0:  port 0xb800-0xb8ff irq 5 at device 1.0 on pci2
> pcm0: failed to enable memory mapping!
> pcm0: 
> malloc() of "64" with the following non-sleepable locks held:
> exclusive sleep mutex pcm0:mixer (pcm mixer) r = 0 (0xc2d34540) locked @ 
> /usr/src/sys/dev/sound/pcm/mixer.c:322

Unfortunately none of the sound developers have been interested in
looking at the locking problems in the code.

> acquiring duplicate lock of same type: "pcm channel"
>  1st pcm0:record:0 @ /usr/src/sys/dev/sound/pcm/sound.c:195
>  2nd pcm0:play:0 @ /usr/src/sys/dev/sound/pcm/sound.c:195
> Stack backtrace:
> 
> with no backtrace at all.

FWIW, the backtrace would have been reported on the system console.

Kris


pgp0.pgp
Description: PGP signature


Re: ethercons: ethernet console driver for 5-current

2003-10-20 Thread Kris Kennaway
On Mon, Oct 20, 2003 at 10:03:52AM -0700, Steve Kargl wrote:
> On Mon, Oct 20, 2003 at 12:13:27PM -0400, Robert Watson wrote:
> > 
> > I had a fair amount of time over the last week running in disconnected
> > operation, and realized I had too many cables under my desk, so I spent a
> > bit of time exploring the FreeBSD console code.  After reading a FREENIX
> > paper this summer on a Linux ethernet console driver, I took a pass at
> > implementing ethernet console support for FreeBSD.
> 
> Robert,
> 
> This looks very interesting!  Can we run ddb over the
> ethercon to debug a wedged machine?

No..that was addressd in Robert's mail.

Kris

pgp0.pgp
Description: PGP signature


Re: ethercons: ethernet console driver for 5-current

2003-10-20 Thread Robert Watson

On Mon, 20 Oct 2003, Steve Kargl wrote:

> On Mon, Oct 20, 2003 at 12:13:27PM -0400, Robert Watson wrote:
> > 
> > I had a fair amount of time over the last week running in disconnected
> > operation, and realized I had too many cables under my desk, so I spent a
> > bit of time exploring the FreeBSD console code.  After reading a FREENIX
> > paper this summer on a Linux ethernet console driver, I took a pass at
> > implementing ethernet console support for FreeBSD.
> 
> This looks very interesting!  Can we run ddb over the ethercon to debug
> a wedged machine? 

Not currently.  In the current implementation, the ethernet console picks
up its input, and generates output, using the ethernet layer of the
network stack.  Since the debugger suspends scheduling, this means
interrupt threads, netisrs, etc, aren't running, so for now, ethercons is
disabled when "in the debugger" (db_active != 0).  This permits other
console devices, such as serial console, to be used for the debugger,
however, at the same time. 

To support ethernet debugging, the debugger would need to be able to drive
polling of the network interface in an interrupt-thread-free environment,
and reproduce more of the lower level network code (i.e., not use mbufs,
etc).  This is feasible to do, but would probably require adding new
interfaces to the ethernet driver, and supporting only ethernet cards that
had these additional debugging interfaces.  Compared to serial console,
you'd also have a lot more situations where the driver/hardware state
would be sufficiently inconsistent as to make debugging network-related
crashes difficult.  On the other hand, Darwin runs quite well with a
network debugger; I believe they have a fairly complex UDP/IP
implementation in the network debugger, although I haven't inspected it. 
Apple has the advantage, though, of providing very few ethernet drivers.

So I'm happy to look at it, but the level of time investment to get to
network debugging from the current (and pretty simple) ethercons device
will be fairly high.  I know Jonathan Lemon was looking at network console
and debugging code previously, but I don't have copies of his patches.  If
I had to guess, I'd assume he had modified the if_fxp driver, and perhaps
others, to provide an appropriate polled interface for use with a
debugger, but I don't know for sure.  If someone has copies of these
patches, I'd be happy to take a look at them. 

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: this /rescue thing

2003-10-20 Thread Christoph P. Kukulies
On Mon, Oct 20, 2003 at 08:06:10AM -0700, David O'Brien wrote:
> On Mon, Oct 20, 2003 at 11:55:57AM +0200, C. Kukulies wrote:
> > ===> rescue/rescue
> > install -s -o root -g wheel -m 555   rescue /rescue
> > install -o root  -g wheel -m 555  nextboot_FIXED  /rescue/nextboot.sh
> > install: /rescue/nextboot.sh: Not a directory
> > *** Error code 71
> > 
> > Stop in /u/src/rescue/rescue.
> > *** Error code 1
> > 
> > Looking into / I see that /rescue is a file.
> 
> There was some pilot error in the order in which you updated your system
> after we added 'rescue'.  You need to 'rm -rf /rescue ; mkdir /rescue'
> and then rebuild and install it.
> 
> > What is the safe method to put /rescue elsewhere (in an area with enough
> > space). It also seems that it is being deleted by make world, at least I
> > seem to remember that putting a soft link into /rescue into / didn't
> > help either.
> 
> You're missing the point of /rescue.  It MUST be in / to be of any use.

Yeah, but what do if the partition overflows? 

Actually I never had the need for it in the past. What would be the correct
use of /rescue?  The most cumbersome issue in the past was the ever growing
root FS in FreeBSD. I wish back the days of a 40 MB root FS.

Is it possible to switch it off? Or to circumvent it somehow?

--
Chris Christoph P. U. Kukulies kuku_at_physik.rwth-aachen.de
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Asus A7V8X-X USB problems

2003-10-20 Thread Doug White
On Sat, 18 Oct 2003, Greg J. wrote:

> On Sat, 18 Oct 2003 15:55:52 -0700 (PDT)
> Doug White <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 15 Oct 2003, Doug White wrote:
> >
> > > > >
> > > > > > Anyone else having these errors? Is there a way to fix it?
> > > > >
> > > > > What's attached to the ports?
> > > > Nothing.. if I plug anything in (like a mouse) it freezes my
> > > > system.
> > >
> > > Interesting .. which VIA chipset is it? I have a KT400 at home that
> > > hasn't built current in a while but worked as of a few weeks ago.
> > > I'll have to try a fresh build.
> >
> > Incidentally I built -current and no issues. Unforutnately I snipped
> > the dmesg so I couldn't see if the chips match up.
> >
> > This is what my soyo is detecting as:
> >
> > usb0:  on uhci0
> > ehci0:  mem 0xe410-0xe41000ff
> > irq 10 at device 16.3 on pci0
> >
>
> Same.. except my ehci has: mem 0xe480-0xe48000ff irq 6
>
> I updated again yesterday (10/17/2003) & the problem disappeared.. maybe
> it didn't update one of the usb source files last time? Thanks for your
> help.
>

Cool .. no worries.

-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: this /rescue thing

2003-10-20 Thread Tim Kientzle
C. Kukulies wrote:
/rescue is always causing trouble with me here. make world falls over 
with:

===> rescue/rescue
install -s -o root -g wheel -m 555   rescue /rescue
install -o root  -g wheel -m 555  nextboot_FIXED  /rescue/nextboot.sh
install: /rescue/nextboot.sh: Not a directory
*** Error code 71
Stop in /u/src/rescue/rescue.
*** Error code 1
Looking into / I see that /rescue is a file.

Why is this /rescue being created in /? It used to blow up and 
overflow the / filesystem (there were times when a 40 MB root FS was
sufficient).

What is the safe method to put /rescue elsewhere (in an area with enough
space). It also seems that it is being deleted by make world, at least I
seem to remember that putting a soft link into /rescue into / didn't
help either.
Symlinking /rescue -> / will cause exactly the problem you're
seeing.  (Because there is a file called /rescue/rescue, which
will then get installed on top of the symlink.  Boom!)  Don't do that.
You could probably symlink /rescue -> /usr/rescue, but that
sort of defeats the purpose.
/rescue is part of a plan to reduce the size of the / partition,
though it's a somewhat involved process.  There are two key pieces:
1) Building /bin and /sbin dynamically.  This is a big space
   savings, but comes at a cost.  Namely, it's a lot easier
   to trash a dynamic /bin than the old static one.
2) /rescue contains a compact set of statically-linked executables
   (about 3MB total) that are provided to help in system recovery
   if /bin or /sbin gets damaged.
The catch, of course, is that step #2 needs to be finished first,
temporarily increasing the / partition size until #1 is done.
You have several options:

 * Disable /rescue.   Define NO_RESCUE to suppress it from
   being built and installed, e.g.,
 make -DNO_RESCUE buildworld
 make -DNO_RESCUE installworld
   Or add it to /etc/make.conf
 * Take the plunge and compile /bin dynamically.
   Define WITH_DYNAMICROOT in /etc/make.conf.
 * Get a bigger hard disk.  ;-)

Hope this helps,

Tim Kientzle

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: pcm & exclusive sleep mutex with Oct19 CURRENT

2003-10-20 Thread Paolo Pisati
On Mon, Oct 20, 2003 at 10:37:00AM -0700, Kris Kennaway wrote:
> Unfortunately none of the sound developers have been interested in
> looking at the locking problems in the code.

=(
 
> > acquiring duplicate lock of same type: "pcm channel"
> >  1st pcm0:record:0 @ /usr/src/sys/dev/sound/pcm/sound.c:195
> >  2nd pcm0:play:0 @ /usr/src/sys/dev/sound/pcm/sound.c:195
> > Stack backtrace:
> > 
> > with no backtrace at all.
> 
> FWIW, the backtrace would have been reported on the system console.

righty right kris, here we go:

backtrace(c0836d0c,c2d41754,c0a257d1,c3,246) at backtrace+0x17
witness_lock(c2d347c0,8,c0a257d1,c3,c2d34500) at witness_lock+0x672
_mtx_lock_flags(c2d347c0,0,c0a257d1,c3,3) at _mtx_lock_flags+0xba
pcm_chnalloc(c2d1f400,1,9e7c,,8) at pcm_chnalloc+0x56
dsp_open(c08f10f0,803,2000,c340d130,c06947a2) at dsp_open+0x19f
spec_open(cf175a68,cf175b24,c069c6b2,cf175a68,0) at spec_open+0x30b
spec_vnoperate(cf175a68,0,c08fe0e0,c340d130,c392b248) at spec_vnoperate+0x18
vn_open_cred(cf175bd8,cf175cd8,0,c3ef6880,20) at vn_open_cred+0x432
vn_open(cf175bd8,cf175cd8,0,20,c08f7b30) at vn_open+0x30
kern_open(c340d130,8ae2050,0,803,0) at kern_open+0x140
open(c340d130,cf175d10,c084f404,3ed,3) at open+0x30
syscall(1002f,893002f,bfbf002f,29a975b5,8ae2058) at syscall+0x2c0
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (5), eip = 0x2853ed3f, esp = 0xbfbfb4fc, ebp = 0xbfbfb518 ---

and 

backtrace(c0836dc3,c102f110,c08497be,c08497be,c0849659) at backtrace+0x17
witness_lock(c102f110,8,c0849659,148,0) at witness_lock+0x672
_mtx_lock_flags(c102f110,0,c0849659,148,3) at _mtx_lock_flags+0xba
_vm_map_lock(c102f0b0,c0849659,148,c08f5de0,2b4) at _vm_map_lock+0x36
kmem_malloc(c102f0b0,1000,101,ce70a810,c07996f7) at kmem_malloc+0x3a
page_alloc(c103a3c0,1000,ce70a803,101,c083326a) at page_alloc+0x27
slab_zalloc(c103a3c0,1,8,c084afa2,68c) at slab_zalloc+0xb7
uma_zone_slab(c103a3c0,1,c084afa2,68c,0) at uma_zone_slab+0xe6
uma_zalloc_internal(c103a3c0,0,1,0,c101f470) at uma_zalloc_internal+0x3e
bucket_alloc(44,1,c084afa2,70b,0) at bucket_alloc+0x5e
uma_zfree_arg(c101f3c0,ce77ae04,0,778,0) at uma_zfree_arg+0x2c6
swp_pager_meta_free_all(c30e5cb8,c0848f76,c0848edb,21a) at swp_pager_meta_free_a
ll+0xf2
swap_pager_dealloc(c30e5cb8,1,c084af06,104,0) at swap_pager_dealloc+0x11a
vm_pager_deallocate(c30e5cb8,0,c084a0eb,260,c084afa2) at vm_pager_deallocate+0x3
d
vm_object_terminate(c30e5cb8,0,c084a0eb,207,c062d650) at vm_object_terminate+0x2
03
vm_object_deallocate(c30e5cb8,c2ee8d98,c30e5cb8,c2ee8d98,ce70a9c8) at vm_object_
deallocate+0x371
vm_map_entry_delete(c16d59d8,c2ee8d98,c0849834,8b6,0) at vm_map_entry_delete+0x3
b
vm_map_delete(c16d59d8,0,bfc0,c16d59d8,c16d59d8) at vm_map_delete+0x383
vm_map_remove(c16d59d8,0,bfc0,356,804f2c4) at vm_map_remove+0x55
exec_new_vmspace(ce70ab88,c08c7ac0,c0830c69,296,0) at exec_new_vmspace+0x235
exec_elf32_imgact(ce70ab88,0,c08318b5,ff,c08f77e8) at exec_elf32_imgact+0x1b0
kern_execve(c2d38980,8051080,bfbffd1c,804f2c0,0) at kern_execve+0x38c
execve(c2d38980,ce70ad10,c084f404,3ed,3) at execve+0x30
syscall(2f,2f,2f,1,bfbffd1c) at syscall+0x2c0
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (59), eip = 0x280d683f, esp = 0xbfbffd0c, ebp = 0xbfbffd38 ---

hope this helps.

-- 
Paolo

Italian FreeBSD User Group: http://www.gufi.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


PCVT in 5.1-CURRENT

2003-10-20 Thread William Pechter
Does FreeBSD 5.1-Current actually work with the PCVT driver.

I've been unable to get any output to the console after the loader
starts the kernel load with PCVT.

If anyone's got a working configuration with PCVT I'd love to get
a copy of their kernel configuration... I've moved up to 5.1-Current
from 4.8-STABLE and I'm quite pleased with the performance and
reliability on my rather low-end hardware, but I can't seem to get PCVT
working.

Bill

[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Random signals in {build,install}world recently?

2003-10-20 Thread Marius Strobl
On Mon, Oct 20, 2003 at 05:08:26PM +0200, Christian Brueffer wrote:
> On Mon, Oct 20, 2003 at 10:50:02AM -0400, Barney Wolff wrote:
> > On Mon, Oct 20, 2003 at 03:20:56PM +0200, Mark Santcroos wrote:
> > > On Mon, Oct 20, 2003 at 10:27:38AM +0200, Harti Brandt wrote:
> > > > On Mon, 20 Oct 2003, Vallo Kallaste wrote:
> > > > 
> > > > VK>Hi
> > > > VK>
> > > > VK>It seems to be a recent problem. The hardware is OK, both Windows XP
> > > > VK>(which I use very seldom) and Gentoo Linux do not exhibit any
> > > > VK>problems.
> > > > VK>Basically one will get random signals as I have got in build- and
> > > > VK>installworld. It's impossible to complete make -j2 buildworld on my
> > > > VK>machine, but sometimes non-parallel buildworld will do, only to die
> > > > VK>later in installworld.
> > > > VK>This is on two-processor AMD 2400+ MP system, ASUS A7M-266D mobo and
> > > > VK>1GB ECC memory, ATA disks and CD/RW-DVD only. 4BSD scheduler if it
> > > > VK>matters.
> > > > 
> > > > I have the same MB just with 1800+ processors. I had to reduce the CPU
> > > > frequency by about 10% in the BIOS setup to get the machine stable. I
> > > > assume the problem is actually the memory.
> > > 
> > > Couldn't the following be of help here?
> > > 
> > > options DISABLE_PSE
> > > options DISABLE_PG_G
> > 
> > I don't think so.  I tried that on my A7M266D with no effect.  I believe
> > something in recent pmap code doesn't like this mobo, or maybe dual
> > athlons in general.  I can run RELENG_5_1 rock solid, and -current from
> > 9/24/03 rock solid, but -current from 10/3 or later gets random sigs
> > and eventually panics.  I have scsi disks so it's not ata.
> > 
> 
> I have the same experiences.  Also AMD A7M-266D with two 1800+ Athlons here.
> Used to work fine, but got random signals with my latest builds.
> 

Here, too. However, on a Tyan Thunder K7 with MP 1200 and a Tyan Tiger MPX
with MP 1600+. Additionally to random signals I also get ICEs from GCC at
random places and freezes with `make -jX buildworld` but no panics.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: PCVT in 5.1-CURRENT

2003-10-20 Thread Hellmuth Michaelis
William Pechter wrote:

> Does FreeBSD 5.1-Current actually work with the PCVT driver.
> 
> I've been unable to get any output to the console after the loader
> starts the kernel load with PCVT.
> 
> If anyone's got a working configuration with PCVT I'd love to get
> a copy of their kernel configuration... I've moved up to 5.1-Current
> from 4.8-STABLE and I'm quite pleased with the performance and
> reliability on my rather low-end hardware, but I can't seem to get PCVT
> working.

I have it working at 

FreeBSD bert.int.kts.org 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Mon Oct  6 15:38:22 CEST 
2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BERT  i386

as usual with no special tweaks (kernel config in private mail).

hellmuth
-- 
Hellmuth Michaelis  Hamburg, Europe  hm\at\kts\dot\org  www.kts.org
a duck is like a bicycle because they both have two wheels except the duck (tl)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


GEOM gbde broken?

2003-10-20 Thread Thorsten Schroeder
Hi,

i updated my -current box yesterday from cvs to FreeBSD 5.1-CURRENT #6: Sun
Oct 19 17:40:10 CEST 2003.

Now i'm not able to attach gbde encrypted filesystems - regardless if it's a
disk image created with mdconfig, or a partition on harddisk.

gdbe attach works without any error message, but when i try fsck the partition
/ disk it fails. I'm also not able to mount this thing.

I moved the image files to another -current box (Sep 25 14:51:13 CEST 2003)
and i was able to attach, fsck and mount the gdbe-disks.

After gdbe attach it's possible to grep for cleartext data in /dev/$disk.bde
but you're not able to fsck it:

# /sbin/fsck -t ffs -p /dev/md0c.bde
Cannot find file system superblock
/dev/md0c.bde: CAN'T CHECK FILE SYSTEM.
/dev/md0c.bde: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
/dev/md0c.bde: CANNOT SEEK BLK: -1
/dev/md0c.bde: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.

# /sbin/fsck -t ffs /dev/md0c.bde
** /dev/md0c.bde
Cannot find file system superblock
ioctl (GCINFO): Inappropriate ioctl for device
fsck_ffs: /dev/md0c.bde: can't read disk label

And its also not possible to create a new gbde-device. After gdbe init and
gbde attach of a newly created memory disk (-t vnode) i tried to newfs it and:

# newfs -U -O2 /dev/md0c.bde
/dev/md0c.bde: 4.8MB (9728 sectors) block size 16384, fragment size 2048
using 4 cylinder groups of 1.20MB, 77 blks, 192 inodes.
with soft updates
super-block backups (for fsck -b #) at:
160, 2624, 5088, 7552
cg 0: bad magic number

What's wrong?

Greetings,

  Thorsten

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: GEOM gbde broken?

2003-10-20 Thread Florian C. Smeets
Thorsten Schroeder wrote:
Hi,

i updated my -current box yesterday from cvs to FreeBSD 5.1-CURRENT #6: Sun
Oct 19 17:40:10 CEST 2003.
Now i'm not able to attach gbde encrypted filesystems - regardless if it's a
disk image created with mdconfig, or a partition on harddisk.
[...]

update your sources again and everything should be fine. I think this 
was fixed yesterday.

regards,
flo
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: GEOM gbde broken?

2003-10-20 Thread Poul-Henning Kamp
In message <[EMAIL PROTECTED]>, Thorsten Schroeder writes:
>Hi,
>
>i updated my -current box yesterday from cvs to FreeBSD 5.1-CURRENT #6: Sun
>Oct 19 17:40:10 CEST 2003.
>
>Now i'm not able to attach gbde encrypted filesystems - regardless if it's a
>disk image created with mdconfig, or a partition on harddisk.

There was a problem with an updated version of the kernels AES/Rijndael
routines, this was fixed some hours later than you CVSup'ed yesterday.

Pull in -current now, then it will work.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


[current tinderbox] failure on i386/i386

2003-10-20 Thread Tinderbox
TB --- 2003-10-20 18:12:23 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org
TB --- 2003-10-20 18:12:23 - starting CURRENT tinderbox run for i386/i386
TB --- 2003-10-20 18:12:23 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/i386/i386
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-10-20 18:14:50 - building world
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src
TB --- /usr/bin/make -B buildworld
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: populating 
>>> /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything..
TB --- 2003-10-20 19:11:06 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
>>> Kernel build for GENERIC started on Mon Oct 20 19:11:06 GMT 2003
>>> Kernel build for GENERIC completed on Mon Oct 20 19:25:21 GMT 2003
TB --- 2003-10-20 19:25:21 - generating LINT kernel config
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf
TB --- /usr/bin/make -B LINT
TB --- 2003-10-20 19:25:21 - building LINT kernel
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src
TB --- /usr/bin/make buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Mon Oct 20 19:25:21 GMT 2003
[...]
cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99  -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 
-DGUPROF -finline-limit=15000 -fno-strict-aliasing -fno-builtin 
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror 
-finstrument-functions -Wno-inline 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/vm/vnode_pager.c
uudecode < 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/fla/i386/msysosak.o.uu
uudecode < 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/oltr/i386-elf.trlld.o.uu
uudecode < 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd/i386-elf.hal.o.uu
cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99  -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 
-DGUPROF -finline-limit=15000 -fno-strict-aliasing -fno-builtin 
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror 
-finstrument-functions -Wno-inline 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/compat/linux/linux_file.c
cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99  -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 
-DGUPROF -finline-limit=15000 -fno-strict-aliasing -fno-builtin 
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror 
-finstrument-functions -Wno-inline 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/compat/linux/linux_getcwd.c
cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99  -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/

Re: acpi on fujitsu-siemens

2003-10-20 Thread Nate Lawson
>   ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPCB.LNKU._CRS] (Node 
> 0xc40e49c0), AE_AML_UNINITIALIZED_LOCAL
>   ACPI-0175: *** Error: Method execution failed [\\_SB_.PCI0.LPCB.LNKU._CRS] (Node 
> 0xc40e49c0), AE_AML_UNINITIALIZED_LOCAL

This means your AML is lousy.  Try some of the hints on this page:
http://www.cpqlinux.com/acpi-howto.html

Please also post a link to your ASL, produced by:
acpidump -t -d > fujitsu.asl

-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


kuku@kukulies.org

2003-10-20 Thread masta




Christoph P. Kukulies wrote:

[ stuff removed ]

>>You're missing the point of /rescue.  It MUST be in / to be of any use.
>
>
> Yeah, but what do if the partition overflows?

Plan ahead next time. Maybe take a backup, and remove redundancies or
unnecessary files. You could simply resize your slices in a more
appropriate way.

>
> Actually I never had the need for it in the past. What would be the
correct use of /rescue?

Yes that is likely. You don't normally use a fire hose until you have a
fire to put out. Removing the /rescue is considered foot-shooting.


> The most cumbersome issue in the past was the ever growing root FS in
FreeBSD. I wish back the days of a 40 MB root FS.

Those conditions still exist. You could enable the WITH_DYNAMICROOT
make.conf option to reduce the size of your root filesystem by approx
30Mb. Alternatively you could alter the fstab to mount your root area as
read-only to prevent whatever it is you have done to exceed its capacity.
One idea is to simply not login as root to do your stuff, which might
involve activity that saves large files in your /root homedir area. Here
is my root details with the dynamic binaries:

buda# cd /
buda# du -xhc -d1
512B./dev
4.0K./tmp
2.0K./usr
2.0K./var
2.4M./stand
1.5M./etc
2.0K./cdrom
940K./bin
 17M./boot
2.0K./mnt
2.0K./proc
 11M./root
4.1M./sbin
3.7M./rescue
3.1M./lib
262K./libexec
 43M.
 43Mtotal

As you can see the /boot and /root areas are bulky. Regarding the /boot
area, you could reduce the kernel modules to items you actually use with
make.conf options, or simply make a suitable static monolith kernel and
forget the idea of loadable kernel modules. Regarding the /root area, this
just shows I've been a bad boy and shouldn't login as root so much.

>
> Is it possible to switch it off? Or to circumvent it somehow?

You could alter the makefiles to provide a "NO_RESCUE" if that doesn't
already exist. But I think the init program and/or the kernel would need
to change so that /rescue/init isn't spawned in the situation of your
corrupt /bin & /sbin.


 __  __   _
|  \/  | __ _ ___| |_ __ _
| |\/| |/ _` / __| __/ _` |
| |  | | (_| \__ \ || (_| |
|_|  |_|\__,_|___/\__\__,_|

unzip ; strip ; touch ; finger ; mount ; fsck ; more ; yes ; umount ; sleep


[EMAIL PROTECTED]
http://wifibsd.org



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


panic: Memory modified after free

2003-10-20 Thread othermark
I have a strange panic during the isa pnp code that does not occur with a
5.0-release kernel.  I have tried enabling and disabling acpi.  it does
not effect this panic one way or another.  This is a kernel from -current
10/20 (today).  I'm not sure how to get this to boot with no way to disable
pnp probing (pnpbios(4)).

OK boot -v
SMAP type=01 base= len=0009fc00
SMAP type=02 base=0009fc00 len=0400
SMAP type=02 base=000e len=0002
SMAP type=01 base=0010 len=1ff0
SMAP type=02 base=fec0 len=1000
SMAP type=02 base=fec01000 len=1000
SMAP type=02 base=fee0 len=1000
SMAP type=02 base=fff8 len=0008
Copyright (c) 1992-2003 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.1-CURRENT #1: Mon Oct 20 10:40:30 PDT 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/FLUKE
Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a14000.
Calibrating clock(s) ... i8254 clock: 1193058 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter "i8254" frequency 1193182 Hz quality 0
Calibrating TSC clock ... TSC clock: 996598941 Hz
CPU: Intel Pentium III (996.60-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x68a  Stepping = 10
  Features=0x387fbff
real memory  = 536870912 (512 MB)
Physical memory chunk(s):
0x1000 - 0x0009efff, 647168 bytes (158 pages)
0x0010 - 0x003f, 3145728 bytes (768 pages)
0x00c26000 - 0x1f6d9fff, 514539520 bytes (125620 pages)
avail memory = 511942656 (488 MB)
bios32: Found BIOS32 Service Directory header at 0xc00fdb90
bios32: Entry = 0xfdba0 (c00fdba0)  Rev = 0  Len = 1
pcibios: PCI BIOS entry at 0xf+0xdbc1
pnpbios: Found PnP BIOS data at 0xc00f4b00
pnpbios: Entry = f:3b84  Rev = 1.0
Other BIOS signatures found:
wlan: <802.11 Link Layer>
null: 
random: 
mem: 
Pentium Pro MTRR support enabled
npx0: [FAST]
npx0:  on motherboard
npx0: INT 16 interface
pci_open(1):mode 1 addr port (0x0cf8) is 0x8070
pci_open(1a):   mode1res=0x8000 (0x8000)
pci_cfgcheck:   device 0 [class=06] [hdr=80] is there (id=00081166)
pcibios: BIOS version 2.10
Using $PIR table, 13 entries at 0xc00f5070
PCI-Only Interrupts: none
Location  Bus Device Pin  Link  IRQs
embedded00A   0x11  3 4 5 7 9 10 11 12 14 15
embedded00B   0x13  3 4 5 7 9 10 11 12 14 15
embedded0   15A   0x01  10
slot 1  01A   0x1d  3 4 5 7 9 10 11 12 14 15
slot 1  01B   0x1c  3 4 5 7 9 10 11 12 14 15
slot 1  01C   0xff  3 4 5 7 9 10 11 12 14 15
slot 1  01D   0xff  3 4 5 7 9 10 11 12 14 15
slot 2  04A   0x10  5
slot 2  04B   0x11  9
slot 2  04C   0x12  10
slot 2  04D   0x13  11
embedded03A   0x13  11
embedded03B   0xff  3 4 5 7 9 10 11 12 14 15
embedded03C   0xff  3 4 5 7 9 10 11 12 14 15
embedded03D   0xff  3 4 5 7 9 10 11 12 14 15
embedded07A   0x14  11
embedded07B   0xff  3 4 5 7 9 10 11 12 14 15
embedded07C   0xff  3 4 5 7 9 10 11 12 14 15
embedded07D   0xff  3 4 5 7 9 10 11 12 14 15
embedded0   11A   0x13  11
embedded0   11B   0xff  3 4 5 7 9 10 11 12 14 15
embedded0   11C   0xff  3 4 5 7 9 10 11 12 14 15
embedded0   11D   0xff  3 4 5 7 9 10 11 12 14 15
embedded10A   0x10  5
embedded10B   0xff  3 4 5 7 9 10 11 12 14 15
embedded10C   0xff  3 4 5 7 9 10 11 12 14 15
embedded10D   0xff  3 4 5 7 9 10 11 12 14 15
embedded12A   0x12  10
embedded12B   0xff  3 4 5 7 9 10 11 12 14 15
embedded12C   0xff  3 4 5 7 9 10 11 12 14 15
embedded12D   0xff  3 4 5 7 9 10 11 12 14 15
slot 3  15A   0x11  9
slot 3  15B   0x12  10
slot 3  15C   0x13  11
slot 3  15D   0x10  5
embedded21A   0x11  9
embedded21B   0xff  3 4 5 7 9 10 11 12 14 15
embedded21C   0xff  3 4 5 7 9 10 11 12 14 15
embedded21D   0xff  3 4 5 7 9 10 11 12 14 15
embedded22A   0x12  10
embedded22B   0xff  3 4 5 7 9 10 11 12 14 15
embedded22C   0xff  3 4 5 7 9 10 11 12 14 15
embedded22D   0xff  3 4 5 7 9 10 11 12 14 15
slot 4  26A   0x12  10
slot 4  26B   0x13  11
slot 4  26C   0x10  5
slot 4  26D   0x11  9
pcib1:  at pcibus 1 on motherboard
pci1:  on pcib1
pci1: physical bus=1
map[10]: type 1, range 32, base feae, size 17, enabled
pci_cfgintr_valid: BIOS irq 5 is valid
pci_cfgintr: 1:0 INTA BIOS irq 5
found-> vendor=0x8086, dev=0x1001, revid=0x02
bus=1, slot=0, 

PC Card Ethernet attach fails in -CURRENT (FA410TX on ThinkPad 240X)

2003-10-20 Thread Mark Valentine
I happily installed 5.1 on this laptop over the network using my NETGEAR
FA410TX PCMCIA card, but on updating to -CURRENT the attach fails.

Verbose boots from both 5.1-RELEASE and -CURRENT are appended, but the
vital difference is this:

 ed1:  at port 0x100-0x11f irq 11 function 0 config 32 on pccard0
-ed1: bpf attached
-ed1: address 00:48:54:c0:99:7b, type Linksys (16 bit) 
-miibus0:  on ed1
-ukphy0:  on miibus0
-ukphy0: OUI 0x080017, model 0x0002, rev. 0
-ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
+device_probe_and_attach: ed1 attach returned 6

The card had also been working happily with various 4.x releases.

Any ideas?

Cheers,

Mark.

Copyright (c) 1992-2003 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.1-RELEASE #0: Thu Jun  5 02:55:42 GMT 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
Preloaded elf kernel "/boot/kernel/kernel" at 0xc06d4000.
Preloaded elf module "/boot/kernel/acpi.ko" at 0xc06d41f4.
Calibrating clock(s) ... i8254 clock: 1193161 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter "i8254"  frequency 1193182 Hz
Calibrating TSC clock ... TSC clock: 497838412 Hz
Timecounter "TSC"  frequency 497838412 Hz
CPU: Intel Pentium III (497.84-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x683  Stepping = 3
  
Features=0x383f9ff
real memory  = 201261056 (191 MB)
Physical memory chunk(s):
0x1000 - 0x0009efff, 647168 bytes (158 pages)
0x006fb000 - 0x0bc69fff, 190246912 bytes (46447 pages)
avail memory = 188096512 (179 MB)
bios32: Found BIOS32 Service Directory header at 0xc00f6cf0
bios32: Entry = 0xfd8b0 (c00fd8b0)  Rev = 0  Len = 1
pcibios: PCI BIOS entry at 0xfd8b0+0x12f
pnpbios: Found PnP BIOS data at 0xc00f6d20
pnpbios: Entry = f:ac81  Rev = 1.0
Other BIOS signatures found:
wlan: <802.11 Link Layer>
null: 
random: 
mem: 
Pentium Pro MTRR support enabled
npx0:  on motherboard
npx0: INT 16 interface
acpi0:  on motherboard
pci_open(1):mode 1 addr port (0x0cf8) is 0x8058
pci_open(1a):   mode1res=0x8000 (0x8000)
pci_cfgcheck:   device 0 [class=06] [hdr=00] is there (id=71948086)
pcibios: BIOS version 2.10
Using $PIR table, 6 entries at 0xc00fdf60
PCI-Only Interrupts: none
Location  Bus Device Pin  Link  IRQs
embedded07A   0x60  3 4 5 6 7 9 10 11 12 14 15
embedded07B   0x61  3 4 5 6 7 9 10 11 12 14 15
embedded07C   0x62  3 4 5 6 7 9 10 11 12 14 15
embedded07D   0x63  3 4 5 6 7 9 10 11 12 14 15
embedded0   10A   0x61  3 4 5 7 9 10 11 15
embedded0   11A   0x62  3 4 5 6 7 9 10 11 12 14 15
embedded0   12A   0x63  3 4 5 7 9 10 11 15
embedded00A   0x60  3 4 5 6 7 9 10 11 12 14 15
embedded00B   0x61  3 4 5 6 7 9 10 11 12 14 15
embedded00C   0x62  3 4 5 6 7 9 10 11 12 14 15
embedded00D   0x63  3 4 5 6 7 9 10 11 12 14 15
AcpiOsDerivePciId: bus 0 dev 7 func 0
AcpiOsDerivePciId: bus 0 dev 10 func 0
acpi0: power button is handled as a fixed feature programming model.
ACPI timer looks GOOD min = 2, max = 3, width = 1
ACPI timer looks GOOD min = 2, max = 3, width = 1
ACPI timer looks GOOD min = 2, max = 4, width = 2
ACPI timer looks GOOD min = 2, max = 3, width = 1
ACPI timer looks GOOD min = 2, max = 3, width = 1
ACPI timer looks GOOD min = 2, max = 3, width = 1
ACPI timer looks GOOD min = 2, max = 3, width = 1
ACPI timer looks GOOD min = 2, max = 3, width = 1
ACPI timer looks GOOD min = 2, max = 3, width = 1
ACPI timer looks GOOD min = 2, max = 3, width = 1
Timecounter "ACPI-fast"  frequency 3579545 Hz
AcpiOsDerivePciId: bus 0 dev 0 func 0
can't fetch resources for \\_SB_.PCI0.ISA_.FIR_ - AE_AML_INVALID_RESOURCE_TYPE
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0
acpi_cpu0:  on acpi0
acpi_tz0:  on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
 initial configuration 
\\_SB_.PCI0.ISA_.LNKD irq  11: [  3  4  5  6  7  9 10 11 14 15] low,level,sharable 
0.7.3
\\_SB_.PCI0.ISA_.LNKB irq  11: [  3  4  5  6  7 10 11 14 15] low,level,sharable 0.10.0
\\_SB_.PCI0.ISA_.LNKC irq   5: [  3  4  5  6  7 10 11 14 15] low,level,sharable 0.11.0
\\_SB_.PCI0.ISA_.LNKD irq  11: [  3  4  5  6  7  9 10 11 14 15] low,level,sharable 
0.12.0
 before setting priority for links 
 before fixup boot-disabled links -
 after fixup boot-disabled links --
 arbitrated configuration -
\\_SB_.PCI0.ISA_.LNKD irq  11: [  3  4  5  6  7  9 10 11 14 15] low,level,sharable 
0.7.3
\\_SB_.PCI0.ISA_.LNKB irq  11: [  3  4  5  6  7 10 11 14 15] low,level,sharable 0.10.0
\\_SB_.PCI0.ISA_.LNKC irq   5: [  3  4  5  6  7 10 11 14 15] low,level,sharable 0.11.0
\\_SB_.PCI0.ISA_.LNKD irq  11: [  3  4  5  6  7  9 10 11 14 15] low,level,sharable 
0.12.0

Buildworld fails in 5.1-CURRENT in wall

2003-10-20 Thread Scott Wegener
Fails on usr.bin/wall as follows, cvsup'ed as of ~8pm EST:

--
stage 2.1: cleaning up the object tree
--
cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj  MACHINE_ARCH=i386  MACHINE=i386
CPUTYPE=
..
..
..
===> usr.bin/vi
rm -f nex nvi cl_bsd.o cl_funcs.o cl_main.o cl_read.o cl_screen.o
cl_term.o cut.o delete.o exf.o key.o line.o log.o main.o mark.o msg.o
options.o options_f.o put.o screen.o search.o seq.o recover.o util.o
ex.o ex_abbrev.o ex_append.o ex_args.o ex_argv.o ex_at.o ex_bang.o
ex_cd.o ex_cmd.o ex_cscope.o ex_delete.o ex_display.o ex_edit.o
ex_equal.o ex_file.o ex_filter.o ex_global.o ex_init.o ex_join.o
ex_map.o ex_mark.o ex_mkexrc.o ex_move.o ex_open.o ex_preserve.o
ex_print.o ex_put.o ex_quit.o ex_read.o ex_screen.o ex_script.o ex_set.o
ex_shell.o ex_shift.o ex_source.o ex_stop.o ex_subst.o ex_tag.o ex_txt.o
ex_undo.o ex_usage.o ex_util.o ex_version.o ex_visual.o ex_write.o
ex_yank.o ex_z.o ex_tcl.o ex_perl.o getc.o v_at.o v_ch.o v_cmd.o
v_delete.o v_ex.o v_increment.o v_init.o v_itxt.o v_left.o v_mark.o
v_match.o v_paragraph.o v_put.o v_redraw.o v_replace.o v_right.o
v_screen.o v_scroll.o v_search.o v_section.o v_sentence.o v_status.o
v_txt.o v_ulcase.o v_undo.o v_util.o v_word.o v_xchar.o v_yank.o v_z.o
v_zexit.o vi.o vs_line.o vs_msg.o vs_refresh.o vs_relative.o vs_smap.o
vs_split.o vi.1.gz vi.1.cat.gz
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> usr.bin/vis
rm -f vis vis.o foldit.o vis.1.gz vis.1.cat.gz
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> usr.bin/vmstat
rm -f vmstat vmstat.o vmstat.8.gz vmstat.8.cat.gz
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> usr.bin/w
rm -f w fmt.o pr_time.o proc_compare.o w.o w.1.gz uptime.1.gz w.1.cat.gz
uptime.1.cat.gz
rm -f .depend GPATH GRTAGS GSYMS GTAGS
===> usr.bin/wall
".depend", line 2: Need an operator
".depend", line 4: Need an operator
".depend", line 5: Need an operator
".depend", line 6: Need an operator
".depend", line 7: Need an operator
".depend", line 8: Need an operator
".depend", line 9: Need an operator
".depend", line 10: Need an operator
".depend", line 11: Need an operator
".depend", line 12: Need an operator
".depend", line 13: Need an operator
".depend", line 14: Need an operator
".depend", line 16: Need an operator
".depend", line 17: Need an operator
".depend", line 18: Need an operator
".depend", line 19: Need an operator
".depend", line 20: Need an operator
".depend", line 22: Need an operator
".depend", line 24: Need an operator
".depend", line 27: Need an operator
".depend", line 30: Need an operator
".depend", line 32: Need an operator
".depend", line 34: Need an operator
".depend", line 36: Need an operator
".depend", line 37: Need an operator
".depend", line 38: Need an operator
".depend", line 39: Need an operator
".depend", line 40: Need an operator
".depend", line 41: Need an operator
".depend", line 42: Need an operator
".depend", line 44: Need an operator
".depend", line 45: Need an operator
".depend", line 47: Need an operator
".depend", line 49: Need an operator
".depend", line 51: Need an operator
".depend", line 53: Need an operator
".depend", line 54: Need an operator
".depend", line 55: Need an operator
".depend", line 56: Need an operator
".depend", line 57: Need an operator
".depend", line 58: Need an operator
".depend", line 59: Need an operator
".depend", line 60: Need an operator
".depend", line 61: Need an operator
".depend", line 63: Need an operator
".depend", line 65: Need an operator
".depend", line 67: Need an operator
".depend", line 70: Need an operator
make: fatal errors encountered -- cannot continue
*** Error code 1
Stop in /usr/src/usr.bin.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.

Script done on Mon Oct 20 17:54:49 2003

Scott



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: bug in NSS ?

2003-10-20 Thread Scot W. Hetzel
From: "Alex Deiter" <[EMAIL PROTECTED]>
> >> I have a problem with nss_ldap on FreeBSD.
> >> After tranfer users from /etc/passwd to ldap directories my users
cannot
> >> send a mail via /usr/bin/mail | /usr/sbin/sendmail  program:
>
> >What are the contents of the /usr/local/lib/sasl*/Sendmail.conf file?
> >Is pwcheck_method set to saslauthd, or sasldb?
> >If it is set to saslauthd, what flags do you use for it (-a pam or -a
> ldap)?
>
> my /usr/local/lib/sasl2/Sendmail.conf:
> pwcheck_method: auxprop
> auxprop_plugin: sasldb
>
Is the Sendmail.conf file the same as the FreeBSD file on the Solaris 8
system?

How is saslauthd started on both systems (-a pam, -a sasldb, -a ldap)?

Scot

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


DVD+R burning flakey after ATAng.

2003-10-20 Thread David Gilbert
First of all, as someone noted with disk-at-once, DVD+R (which is
always disk-at-once) doesn't entirely burn properly.  I havn't been
able to nail it down, but certain ISO images work and certain ones
don't.

This all started screwing up with ATAng.  At first, ATAng didn't
support atapicam, but that was rectified.  Now the dvd+rw port
(growisofs) doesn't work at all ... it finishes with an error that I'm
loathe to coaster another (expensive) DVD to find out.  burncd will
successfully burn some images and not others.  I havn't found the
pattern yet.

Has anyone with knowledge in these areas looked at DVD burning?

Dave.

-- 

|David Gilbert, Independent Contractor.   | Two things can only be |
|Mail:   [EMAIL PROTECTED]|  equal if and only if they |
|http://daveg.ca  |   are precisely opposite.  |
=GLO
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: bug in NSS ?

2003-10-20 Thread Scot W. Hetzel
From: "Scot W. Hetzel" <[EMAIL PROTECTED]>
> From: "Alex Deiter" <[EMAIL PROTECTED]>
> > >> I have a problem with nss_ldap on FreeBSD.
> > >> After tranfer users from /etc/passwd to ldap directories my users
> cannot
> > >> send a mail via /usr/bin/mail | /usr/sbin/sendmail  program:
> >
> > >What are the contents of the /usr/local/lib/sasl*/Sendmail.conf file?
> > >Is pwcheck_method set to saslauthd, or sasldb?
> > >If it is set to saslauthd, what flags do you use for it (-a pam or -a
> > ldap)?
> >
> > my /usr/local/lib/sasl2/Sendmail.conf:
> > pwcheck_method: auxprop
> > auxprop_plugin: sasldb
> >
> Is the Sendmail.conf file the same as the FreeBSD file on the Solaris 8
> system?
>
Does  sasldblistusers2 on the Solaris 8 system list the test user in the
sasldb file?  If it does, is their a test user in the FreeBSD sasldb file?

> How is saslauthd started on both systems (-a pam, -a sasldb, -a ldap)?
>

Scot

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


RE: panic with unloading nvidia.ko

2003-10-20 Thread Jason Dictos
 Happens to me too :(. I've been trying to get that darn nvidia module to
load in the latest current branch without hosing my system.

I'm not sure what the magic formula is, but it was working before I
recompiled the kernel for ipfilter support.

Currently the nvidia module loads ok, but when I try to start X the system
usually just hard locks up with a blank screen. On reboot, if I unload the
nvidia module, another crash occurs.

Where's that radeon card when you need it.

-Jason

-Original Message-
From: C. Kukulies
To: [EMAIL PROTECTED]
Sent: 10/20/2003 4:12 AM
Subject: panic with unloading nvidia.ko


I just got a kernel panic after making /usr/ports/x11/nvidia-driver.
I did a make, make reinstall. Then I did a kldunload nvidia.ko
and got:

nvidia0: detached
panic: malloc(9)/free(9) confusion.
Probably freeing with wrong type, but maybe not here.
Debugger("panic")
Stopped at Debugger+0x54:  xchgl   %ebx, in_Debugger.0

trace shows:

Debugger
panic
free
os_free
__nvsym00022
__nvsym00638
__nvsym00678
__nvsym00723
rm_shutdown_rm
nvidia_modevent
driver_module_handler
module_unload
linker_file_unload
kld_unload
syscall
Xint0x80


--
Chris Christoph P. U. Kukulies kuku_at_physik.rwth-aachen.de

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
"[EMAIL PROTECTED]"


This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com



This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


atapicam doesn't work anymore: WAS: DVD+R burning flakey after ATAng.

2003-10-20 Thread slave-mike
atapicam seems to have ceased being functional as well.

Performing OPC...
/usr/local/bin/cdrecord: Input/output error. send opc: scsi sendcmd: 
retryable error
CDB:  54 01 00 00 00 00 00 00 00 00
status: 0x2 (CHECK CONDITION)

David Gilbert wrote:
First of all, as someone noted with disk-at-once, DVD+R (which is
always disk-at-once) doesn't entirely burn properly.  I havn't been
able to nail it down, but certain ISO images work and certain ones
don't.
This all started screwing up with ATAng.  At first, ATAng didn't
support atapicam, but that was rectified.  Now the dvd+rw port
(growisofs) doesn't work at all ... it finishes with an error that I'm
loathe to coaster another (expensive) DVD to find out.  burncd will
successfully burn some images and not others.  I havn't found the
pattern yet.
Has anyone with knowledge in these areas looked at DVD burning?

Dave.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: USB Keyboard questions

2003-10-20 Thread Andre Guibert de Bruet

On Mon, 20 Oct 2003, Peter wrote:

> I have been reading that page and I have the keyboard working, but I
> fail to see how this will help a user that only has a USB Keyboard
> that wants to use FreeBSD5.1 and is unable to install it due to the
> lack of USB support from the start.

Some BIOSes offer a "USB legacy support" option which allows the use of a
usb keyboard as if it were a PS2 keyboard during system startup.

> And I still would like to know if its my keyboard that is out of sync
> with the USB spec since it will add letters when I write like .
> "This should read like this" but can end up like "Thisi should reaed
> likek this"

Does this keyboard exhibit the same behavior when it's plugged into a
Windows machine? It's a little early to speculate what the issue could be,
as there are a number of links in this chain but it's very possible that
you simply have a wonky keyboard on your hands.

Regards,

> Andre Guibert de Bruet | Enterprise Software Consultant >
> Silicon Landmark, LLC. | http://siliconlandmark.com/>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: PCcards not working (5.1)

2003-10-20 Thread M. Warner Losh
In message: <[EMAIL PROTECTED]>
[EMAIL PROTECTED] writes:
: On Thu, Oct 16, 2003 at 09:32:55AM -0600, M. Warner Losh wrote:
: > ...
: > : You should use devd instead of pccardd in -current.
: > : See devd(8) and devd.conf(8).
: > 
: > That's one problem, but not the problem.  The problem that he's
: > hitting is that he can't get memory to read the card's CIS.  That's
: > usually solved with setting hw.cbb.start_memory to a good value.
: 
: Hi Warner et al,
: 
: What would be a "good value"?

Some value > than the amount of RAM you have.  Make sure that no other
devices on the bus conflict with it.  I'm working on some changes to
help prevent accidental multiple assignments that can happen with the
current code, but haven't pulled it all together yet.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: PC Card Ethernet attach fails in -CURRENT (FA410TX on ThinkPad 240X)

2003-10-20 Thread M. Warner Losh
In message: <[EMAIL PROTECTED]>
Mark Valentine <[EMAIL PROTECTED]> writes:
:  ed1:  at port 0x100-0x11f irq 11 function 0 config 32 on pccard0
: -ed1: bpf attached
: -ed1: address 00:48:54:c0:99:7b, type Linksys (16 bit) 
: -miibus0:  on ed1
: -ukphy0:  on miibus0
: -ukphy0: OUI 0x080017, model 0x0002, rev. 0
: -ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
: +device_probe_and_attach: ed1 attach returned 6
: 
: The card had also been working happily with various 4.x releases.
: 
: Any ideas?

it worked for me sometime before 5.1, but I had two people at bsdcon
trip me about this.  something weird has happened to the if_ed driver
to screw this up.  I'm not sure what it is :-(

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Buildworld fails in 5.1-CURRENT in wall

2003-10-20 Thread M. Warner Losh
I'd remove all the .depend files and try again.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Buildworld fails in 5.1-CURRENT in wall

2003-10-20 Thread Scott W
M. Warner Losh wrote:

I'd remove all the .depend files and try again.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
 

I've tried that one- I'm not familiar with freeBSD's build environment, 
but 'find /usr/src -name ".depend" shows the only .depend files are in 
the kernel tree /usr/src/sus/i386/compile/ , so I'm assuming it's 
generating them as part of the build process itself, or dumping them 
outside of the /usr/src heirarchy.  Tried again from cvsup ~11pm with 
same results...any other ideas?

Scott

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Buildworld fails in 5.1-CURRENT in wall

2003-10-20 Thread M. Warner Losh
In message: <[EMAIL PROTECTED]>
Scott W <[EMAIL PROTECTED]> writes:
: M. Warner Losh wrote:
: 
: >I'd remove all the .depend files and try again.
: >
: >Warner
: >___
: >[EMAIL PROTECTED] mailing list
: >http://lists.freebsd.org/mailman/listinfo/freebsd-current
: >To unsubscribe, send any mail to "[EMAIL PROTECTED]"
: >
: >  
: >
: I've tried that one- I'm not familiar with freeBSD's build environment, 
: but 'find /usr/src -name ".depend" shows the only .depend files are in 
: the kernel tree /usr/src/sus/i386/compile/ , so I'm assuming it's 
: generating them as part of the build process itself, or dumping them 
: outside of the /usr/src heirarchy.  Tried again from cvsup ~11pm with 
: same results...any other ideas?

find /usr/obj -name .depend

or better yet

rm -rf /usr/obj/*

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Buildworld fails in 5.1-CURRENT in wall

2003-10-20 Thread Scott Wegener, Roadster Performance
M. Warner Losh wrote:

In message: <[EMAIL PROTECTED]>
   Scott W <[EMAIL PROTECTED]> writes:
: M. Warner Losh wrote:
: 
: >I'd remove all the .depend files and try again.
: >
: >Warner
: >___
: >[EMAIL PROTECTED] mailing list
: >http://lists.freebsd.org/mailman/listinfo/freebsd-current
: >To unsubscribe, send any mail to "[EMAIL PROTECTED]"
: >
: >  
: >
: I've tried that one- I'm not familiar with freeBSD's build environment, 
: but 'find /usr/src -name ".depend" shows the only .depend files are in 
: the kernel tree /usr/src/sus/i386/compile/ , so I'm assuming it's 
: generating them as part of the build process itself, or dumping them 
: outside of the /usr/src heirarchy.  Tried again from cvsup ~11pm with 
: same results...any other ideas?

find /usr/obj -name .depend

or better yet

rm -rf /usr/obj/*

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
 

D'oh!  Got it, trying now.. thanks! :-)

Scott

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: bug in NSS ?

2003-10-20 Thread Дейтер Александр Валерьевич
> > > my /usr/local/lib/sasl2/Sendmail.conf:
> > > pwcheck_method: auxprop
> > > auxprop_plugin: sasldb
> > Is the Sendmail.conf file the same as the FreeBSD file on the Solaris 8
> > system?

yes of course. On Solaris8 box and FreeBSD box i have a identical
configuration.

> Does  sasldblistusers2 on the Solaris 8 system list the test user in the
> sasldb file?  If it does, is their a test user in the FreeBSD sasldb file?

yes.

# sasldblistusers2
[EMAIL PROTECTED]: userPassword
[EMAIL PROTECTED]: userPassword

on FreeBSD and Solaris  i can successfully authenticate any user from sasldb
via SMTP with sendmail:

# perl -e 'use MIME::Base64; print encode_base64("test\0test\0test");'
dGVzdAB0ZXN0AHRlc3Q=

$ telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 server.komi.mts.ru ESMTP Sendmail 8.12.10/8.12.10; Tue, 21 Oct 2003
13:29:41 +0400 (MSD)
ehlo test
250-server.komi.mts.ru Hello localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH CRAM-MD5 DIGEST-MD5 NTLM LOGIN PLAIN
250-DELIVERBY
250 HELP
AUTH PLAIN dGVzdAB0ZXN0AHRlc3Q=
235 2.0.0 OK Authenticated
quit
221 2.0.0 server.komi.mts.ru closing connection
Connection closed by foreign host.

But, user test (from ldap) on FreeBSD cannot send mail from command line via
/usr/bin/mail or /usr/sbin/sendmail (if MSP use AUTH):

%id
uid=1000(test) gid=1000(test) groups=1000(test)

%date | /usr/sbin/sendmail -v root
root... Connecting to [127.0.0.1] via relay...
220 server.komi.mts.ru ESMTP Sendmail 8.12.10/8.12.10; Tue, 21 Oct 2003
13:44:57 +0400 (MSD)
>>> EHLO server.komi.mts.ru
250-server.komi.mts.ru Hello localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH CRAM-MD5 DIGEST-MD5 NTLM LOGIN PLAIN
250-DELIVERBY
250 HELP
>>> QUIT
221 2.0.0 server.komi.mts.ru closing connection
root... Deferred: Temporary AUTH failure
Closing connection to [127.0.0.1]

On Solaris this work fine.

And any user from /etc/passwd can successfully send mail from command line
via /usr/bin/mail or /usr/sbin/sendmail (if MSP use AUTH) on Solaris and
FreeBSD:

$ id
uid=70(pgsql) gid=70(pgsql) groups=70(pgsql)

$ date|/usr/sbin/sendmail -v root
root... Connecting to [127.0.0.1] via relay...
220 server.komi.mts.ru ESMTP Sendmail 8.12.10/8.12.10; Tue, 21 Oct 2003
13:51:05 +0400 (MSD)
>>> EHLO server.komi.mts.ru
250-server.komi.mts.ru Hello localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH CRAM-MD5 DIGEST-MD5 NTLM LOGIN PLAIN
250-DELIVERBY
250 HELP
>>> AUTH PLAIN c21tc3AAc21tc3AAc21tc3A=
235 2.0.0 OK Authenticated
>>> MAIL From:<[EMAIL PROTECTED]> SIZE=29
[EMAIL PROTECTED]
250 2.1.0 <[EMAIL PROTECTED]>... Sender ok
>>> RCPT To:<[EMAIL PROTECTED]>
>>> DATA
250 2.1.5 <[EMAIL PROTECTED]>... Recipient ok
354 Enter mail, end with "." on a line by itself
>>> .
250 2.0.0 h9L9p5XM000790 Message accepted for delivery
root... Sent (h9L9p5XM000790 Message accepted for delivery)
Closing connection to [127.0.0.1]
>>> QUIT
221 2.0.0 server.komi.mts.ru closing connection

AUTH PLAIN c21tc3AAc21tc3AAc21tc3A= - is authinfo for user smmsp
(smmsp\0smmsp\0smmsp):

# perl -e 'use MIME::Base64;print decode_base64("c21tc3AAc21tc3AAc21tc3A=")
, "\n";'
smmspsmmspsmmsp

Why auth work for local users and don't work for nss_ldap users ?

Thanks!

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


usbd doesn't get DEVICE_DETACH? (plus patch for typo in usbd.c)

2003-10-20 Thread Johny Mattsson
Hi all,

BACKGROUND:
After a recent purchase of a Palm Tungsten W, I've been spending a few 
hours getting the synchronization working in FreeBSD (which hasn't been 
an easy task). I've almost got it all up and running, by using a PPP 
over Serial over USB setup, but I have a small problem remaining.

THE PROBLEM:
Basically, what's happening is this: When I initiate the sync on the 
Palm, it lights up the USB port and a /dev/ucom0 is created for me. My 
usbd then launches a ppp instance for that port, as well as the service 
daemon for the Palm device. This is all well and wonderful. However, 
when the sync is complete, the Palm closes down the USB port (to be 
expected), and /dev/ucom0 is removed. The problem is that the usbd only 
sees a DRIVER_DETACH, not a DEVICE_DETACH message, and because of that, 
it doesn't execute the "detach" statement for ucom0 (in my case, to shut 
down ppp and the service daemon). The net effect is that I get a ppp 
hanging around and getting in the way for the next sync.

SPECIFIC QUESTION:
What I'd like to know is whether usbd should pick up on the implicit 
device detach in the DRIVER_DETACH event (probably won't work if there's 
more than one device hanging off the driver detaching), or if there 
should indeed be a DEVICE_DETACH arriving before the DRIVER_DETACH?

If I read usb.c correctly, it appears that when a detach event is 
posted, any events in the queue with the same cookie will be discarded. 
Is this intended behaviour, or should DEVICE_DETACH messages be left in 
the queue for normal processing? For me it would make more sense if they 
were kept, but I don't have any previous exposure to this code, so I'm 
not an authoritative voice exactly.

As can be see in the trace below, the DRIVER_DETACH event does contain 
the device name, so it would be easy to modify usbd to handle this 
scenario as well. It doesn't feel like a very elegant way to do things, 
though, and as I mentioned above, it probably can't deal with the case 
where there's more than one device handing off the detaching driver.

If someone points out what would be the preferred way of resolving this, 
I'm happy to get a patch happening.

Trace showing that there's no device-detach picked up by usbd:

usbd: processing event queue on /dev/usb
usbd: driver-attach event cookie=3217029324 devname=ucom0
USB_EVENT_DRIVER_ATTACH
usbd: processing event queue on /dev/usb
usbd: device-attach event at 1066715435.318666000, Palm Handheld, Palm, 
Inc.:
  vndr=0x0830 prdct=0x0031 rlse=0x0100 clss=0x subclss=0x 
prtcl=0x
  device names: ucom0
usbd: ucom0 matches ucom0
usbd: Found action 'Palm Tungsten W' for Palm Handheld, Palm, Inc. at ucom0
usbd: action 0: Palm Tungsten W
  vndr=0x0830 prdct=0x0031
  devname: ucom0
  attach='/usr/sbin/ppp -auto palm; /usr/local/bin/pi-csd -H sarah -a 
192.168.2.3 -n 255.255.255.0'
  detach='killall ppp; killall pi-csd'
usbd: Setting DEVNAME='ucom0'
usbd: Executing '/usr/sbin/ppp -auto palm; /usr/local/bin/pi-csd -H 
sarah -a 192.168.2.3 -n 255.255.255.0'
Working in auto mode
Using interface: tun0
/usr/local/bin/pi-csd(50923): Connection Service Daemon for Palm 
Computing(tm) device active.
/usr/local/bin/pi-csd(50923): Accepting connection requests for 'sarah' 
at 192.168.2.3 with mask 255.255.255.0.
/usr/local/bin/pi-csd(50923): Connection from [192.168.2.253], req 
'sarah', 192.168.2.3, 255.255.255.0 = accept.
/usr/local/bin/pi-csd(50923): Connection from [192.168.2.253], req 
'sarah', 192.168.2.3, 255.255.255.0 = accept.
/usr/local/bin/pi-csd(50923): Connection from [192.168.2.253], req 
'sarah', 192.168.2.3, 255.255.255.0 = accept.
Terminated
usbd: '/usr/sbin/ppp -auto palm; /usr/local/bin/pi-csd -H sarah -a 
192.168.2.3 -n 255.255.255.0' returned 143
usbd: driver-detach event cookie=3217029324 devname=ucom0
USB_EVENT_DRIVER_DETACH
usbd: doing timeout discovery on /dev/usb0
usbd: doing timeout discovery on /dev/usb1


Oh, and there's a typo in usbd.c too, it's printing DETACH when the 
event is ATTACH. One-line patch to fix this is ATTACHed (pun intended).

Cheers,
/Johny
--
Johny Mattsson - System Designer ,-.   ,-.   ,-.  There is no truth.
http://www.earthmagic.org _.'  `-'   `-'  There is only perception.
--- usbd.c.org  Tue Oct 21 15:49:52 2003
+++ usbd.c  Tue Oct 21 15:50:10 2003
@@ -908,7 +908,7 @@
break;
case USB_EVENT_DRIVER_ATTACH:
if (verbose)
-   printf("USB_EVENT_DRIVER_DETACH\n");
+   printf("USB_EVENT_DRIVER_ATTACH\n");
break;
case USB_EVENT_DRIVER_DETACH:
if (verbose)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Random signals in {build,install}world recently?

2003-10-20 Thread Terry Lambert
Harti Brandt wrote:
> On Mon, 20 Oct 2003, Mark Santcroos wrote:
> MS>On Mon, Oct 20, 2003 at 10:27:38AM +0200, Harti Brandt wrote:
> MS>> On Mon, 20 Oct 2003, Vallo Kallaste wrote:
> MS>> VK>Basically one will get random signals as I have got in build- and
> MS>> VK>installworld. It's impossible to complete make -j2 buildworld on my
> MS>> VK>machine, but sometimes non-parallel buildworld will do, only to die
> MS>> VK>later in installworld.
> MS>> VK>This is on two-processor AMD 2400+ MP system, ASUS A7M-266D mobo and
> MS>> VK>1GB ECC memory, ATA disks and CD/RW-DVD only. 4BSD scheduler if it
> MS>> VK>matters.
> MS>>
> MS>> I have the same MB just with 1800+ processors. I had to reduce the CPU
> MS>> frequency by about 10% in the BIOS setup to get the machine stable. I
> MS>> assume the problem is actually the memory.
> MS>
> MS>Couldn't the following be of help here?
> MS>
> MS>options DISABLE_PSE
> MS>options DISABLE_PG_G
> 
> Is the processor bug that these options seem to circumvent dependend on
> the actual operating frequency of the processor?

No.  It is dependent on the amount of memory in the system, and the
specific processor features.  For example, if you have a newer chip
pair, you are more likely to see the problem than on an older system,
though all Pentium class processors supporting 4M pages have the
problems.

If the issues you are seeing are not signal 10's in processes or a
trap 12 (page not present) panic of the kernel, then most likely the
issue with the 1800+ machine is thermal, if it is not in fact a bad
memory issue (have your memory tested on a professional test machine).

I've noticed a lot of bad problems with Hynix memory lately; your
mileage may vary.  At Whistle we had a problem with memory with Gold
contacts, and didn't have any problems with the ones with Tin.

If you could enable HLT in the idle loop (there is a sysctl, and,
I don't know if it's been integrated yet, Julian Elischer published
a patch that did this and aded an IPI to work around the scheduling
latency, which is what not having the HLT supposedly fixed), then
you will likely see the intermittent problem clear itself up, if it
is in fact thermal.

If you are overclocking your machine, or you have bought parts that
have been falsely labeled as higher frequency than they are actually
rated to run at ("counterfeit" chips), then either of these issues
could also be your problem.  So could a borderline power supply.

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


make release...

2003-10-20 Thread Anthony Fajri

fajri  >> more stable-supfile|grep release
*default release=cvs tag=RELENG_4

==

# make release CHROOTDIR=/home/fajri/data/root BUILDNAME=FAJRI
CVSROOT=/home/fajri/data/usr RELEASETAG=RELENG_4

if [ -f /etc/resolv.conf ]; then  cp -p /etc/resolv.conf
/home/fajri/data/root/etc;  fi
cd /home/fajri/data/root/usr && rm -rf src &&  cvs -R -d /home/fajri/data/usr co
-P -r RELENG_4 src
cvs [checkout aborted]: no such tag RELENG_4
*** Error code 1

Stop in /home/fajri/data/usr/src/release.

===

FreeBSD xxx.xxx.xxx 4.8-STABLE FreeBSD 4.8-STABLE #0: Sat Oct 11
09:05:56 GMT 2003 [EMAIL PROTECTED]:/usr/src/sys/compile/xxx
i386

#  make release CHROOTDIR=/home/fajri/data/root BUILDNAME=FAJRI \
CVSROOT=/home/fajri/data/usr RELEASETAG=RELENG_4_8 \
BUILDNAME=RELENG_4_8_STABLE_FAJRI

cd /home/fajri/data/root/usr && rm -rf src &&  cvs -R -d /home/fajri/data/usr co
-P -r RELENG_4_8 src
cvs [checkout aborted]: no such tag RELENG_4_8
*** Error code 1

===

# make release CHROOTDIR=/home/fajri/data/root BUILDNAME=FAJRI \
CVSROOT=/home/fajri/data/usr

cd /home/fajri/data/root/usr && rm -rf ports && cvs -R -d /home/fajri/data/usr
co  -P ports
cvs checkout: cannot find module `ports' - ignored
*** Error code 1

Stop in /home/fajri/data/usr/src/release.



# make release CHROOTDIR=/home/fajri/data/root BUILDNAME=FAJRI
CVSROOT=/home/fajri/data/usr RELEASETAG=RELENG_4_8_RELEASE

cd /home/fajri/data/root/usr && rm -rf src &&  cvs -R -d /home/fajri/data/usr co
-P -r RELENG_4_8_RELEASE src
cvs [checkout aborted]: no such tag RELENG_4_8_RELEASE
*** Error code 1


..::f::..



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Random signals in {build,install}world recently?

2003-10-20 Thread Terry Lambert
Barney Wolff wrote:
> I don't think so.  I tried that on my A7M266D with no effect.  I believe
> something in recent pmap code doesn't like this mobo, or maybe dual
> athlons in general.  I can run RELENG_5_1 rock solid, and -current from
> 9/24/03 rock solid, but -current from 10/3 or later gets random sigs
> and eventually panics.  I have scsi disks so it's not ata.

I think you need to define "random"; do you mean "rare in frequency
over time at unpredicatable intervals" or "you never know what
program is going to get shot in the head, every 5 seconds, like
clockwork"?

My impression so far in this therad is that it's the former.  If
it's the latter, then I need to think about the problem differently.


Note that you can identify the patch that caused the problem, if
there's an 8 day difference, in no more than 4 kernel recompiles
(log2(8)+1), if you have a local CVS mirror.

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"