cvsup from 4.11-RELEASE to 4.11-RELEASE-p1 28,000 errors

[Leland]

I have got to be doing someting wrong, it is right in front of me and I just
don't seel it.
Hope someone can help, thanks.

>From a clean install of 4.11-RELEASE with All Distributions,
cvsup-without-gui was then installed from ports.

cvsup -g -L 2 cvs-supfile  will produce src-all/checkouts.cvs:RELENG_4_11
with 8310752 bytes
and more than 28,000 lines starting with "C src/"

Here is my cvs-supfile:
*default host=cvsup9.us.FreeBSD.org
*default tag=RELENG_4_11
*default date=2005.03.28.15.57.00
*default base=/usr/local/etc/cvsup
*default prefix=/usr/local/etc/cvsup
*default release=cvs
*default delete use-rel-suffix
*default compress
src-all
ports-all
doc-all
cvsroot-all

Here is the first 19 lines of checkouts.cvs:RELENG_4_11 "C " errors

C src/COPYRIGHT,v RELENG_4_11 2005.06.08.21.29.53
2#871#110#11153550885#173563#444 1.4.2.1.2.1 2005.01.01.23.24.04
2#871#110#11046218444#61173#644
C src/Makefile,v RELENG_4_11 2005.06.08.21.29.53
2#871#110#11189457726#2859233#444 1.234.2.19 2003.04.16.09.59.40
2#871#110#10504871804#84803#644
C src/Makefile.inc1,v RELENG_4_11 2005.06.08.21.29.53
2#871#110#11189457726#4008533#444 1.141.2.70.2.1 2004.12.17.13.41.58
2#871#110#11032909185#243063#644
C src/Makefile.upgrade,v RELENG_4_11 2005.06.08.21.29.53
2#871#110#11063134785#295583#444 1.17 99.08.28.01.35.58
2#871#19#9358041584#97613#644
C src/README,v RELENG_4_11 2005.06.08.21.29.53
2#871#110#11153550885#267873#444 1.15.2.4 2002.04.26.16.01.35
2#871#110#10198368954#26993#644
C src/UPDATING,v RELENG_4_11 2005.06.08.21.29.53
2#871#110#11184490206#4967663#444 1.73.2.91.2.10 2005.05.13.00.02.11
2#871#110#11159425315#451853#644
C src/bin/Makefile,v RELENG_4_11 2005.06.08.21.29.53
2#871#110#11153550885#129343#444 1.15.2.2 2000.10.31.09.43.57
2#871#19#9729854373#4723#644
C src/bin/Makefile.inc,v RELENG_4_11 2005.06.08.21.29.53
2#871#110#11153550885#103563#444 1.11.2.1 2001.12.13.09.58.12
2#871#110#10082374923#1693#644
C src/bin/cat/Makefile,v RELENG_4_11 2005.06.08.21.29.53
2#871#110#11153550884#41063#444 1.5 99.08.27.23.13.32
2#871#19#9357956123#1443#644
C src/bin/cat/cat.1,v RELENG_4_11 2005.06.08.21.29.53
2#871#110#11153550885#228223#444 1.10.2.9 2001.12.14.14.22.08
2#871#110#10083397284#52633#644
C src/bin/cat/cat.c,v RELENG_4_11 2005.06.08.21.29.53
2#871#110#11153550885#277923#444 1.14.2.8 2002.06.29.05.09.26
2#871#110#10253273664#72173#644
C src/bin/chio/Makefile,v RELENG_4_11 2005.06.08.21.29.53
2#871#110#11153550884#66293#444 1.6.2.1 2001.07.28.19.22.01
2#871#19#9963481213#2043#644
C src/bin/chio/chio.1,v RELENG_4_11 2005.06.08.21.29.53
2#871#110#11153550885#300653#444 1.10.2.8 2003.05.16.22.43.15
2#871#110#10531249954#84603#644
C src/bin/chio/chio.c,v RELENG_4_11 2005.06.08.21.29.53
2#871#110#11153550885#680433#444 1.15.2.3 2001.07.28.19.22.01
2#871#19#9963481215#273603#644
C src/bin/chio/defs.h,v RELENG_4_11 2005.06.08.21.29.53
2#871#110#11153550884#69333#444 1.2.2.1 2001.07.28.19.22.01
2#871#19#9963481214#24423#644
C src/bin/chio/pathnames.h,v RELENG_4_11 2005.06.08.21.29.53
2#871#110#11153550884#45253#444 1.2 99.08.27.23.13.35
2#871#19#9357956154#18383#644
C src/bin/chmod/Makefile,v RELENG_4_11 2005.06.08.21.29.53
2#871#110#11153550884#56673#444 1.5.2.1 2001.08.01.00.34.15
2#871#19#9966260553#1643#644
C src/bin/chmod/chmod.1,v RELENG_4_11 2005.06.08.21.29.53
2#871#110#11153550885#384663#444 1.17.2.16 2003.02.24.03.01.00
2#871#110#10460556604#91573#644
C src/bin/chmod/chmod.c,v RELENG_4_11 2005.06.08.21.29.53
2#871#110#11153550885#247663#444 1.16.2.7 2003.11.14.15.27.08
2#871#110#10688236284#57433#644



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

Re: 5.4 Installer + Promise FT100TX2 = Loader crash

[Mark Kirkwood]

I have experienced this (since about 5.3) on a dual PIII Tyan S1834. In 
my case perseverance seems to pay off - one in (approx) 10 boots will 
work...


Mark


Daniel O'Connor wrote:

Hi,
I am updating an old 4.x system to 5.4 here and it has a Promise FT100TX2 RAID 
controller (in mirror).


The problem is that when I boot the CD the loader crashes (does a reg dump) 
but only if the card is present and an array is defined. I can't record what 
the dump is because it continually sprays the dump down the screen which 
makes it unreadable :(


I have seen this on an AMD64 system (I used the same RAID card in it) and got 
the same problem. To work around it on that system I installed via the 
motherboard IDE controller and then moved the disk over to the RAID 
controller.


It only seems to affect booting the installer - once the system is installed 
it boots from the RAID card just fine (!)


I just tried booting from floppy and that works (?!) although that method 
doesn't probe my PS/2 keyboard for some reason :-/


Does anyone have any suggestions for fixing the RAID + CD boot problem?



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

5.4 fails to find boot drive, then panics.

[Mike Meyer]

I'm trying to install 5.4-RELEASE off of CDROM on an ASUS P5S800 motherboard
with a SATA drive in it. The SATA drive shows up as ad4 during the install
process, and the install goes just fine.

But the resulting system fails to boot. It goes through the boot sequence,
draws the cute 5.x booto menu, then issues the messages:

Can't work out which disk we are booting from.
Guessed BIOS device 0x not found by probes, defaulting to disk0:

panic: free: guard1 fail @0x5195c from 
/usr/src/sys/boot/i386/loader/../../common/module.c:957
--> Press a key on the console to reboot <--

Booting with debug messages doesn't change this at all.

There don't appear to be any bug reports related to this problem. Checking
google turns up a lot of peole who had this problem, but the only solution
was a guy who had a bad disk. I checked the md5 sum on the downloaded image,
and the software that I used to burn the image (Disk Utility on Mac OS X)
claimed to verify the burned disk - which I believe means it did a checksum
on the image and the disk.

There is an AGA DVD drive in the system on the secondary master. I thought
that it was getting confused by the drive numbers, and checked the bios to see
if I could turn off the ATA controllers. There's apparently no way to do that.

I suspect the panic is due to a bug in code that is only exercised if the boot
"can't work out which disk we are booting from." So if I can solve that, the
system should boot ok, and I can file a bug report for the panic. I'm hoping
that I can tweak a boot config file to solve the boot problem, and that someone
here knows what needs to be tweaked.

Maybe a diffferent boot loader would solve the problem?

Thanks,
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

5.4 Installer + Promise FT100TX2 = Loader crash

[Daniel O'Connor]

Hi,
I am updating an old 4.x system to 5.4 here and it has a Promise FT100TX2 RAID 
controller (in mirror).

The problem is that when I boot the CD the loader crashes (does a reg dump) 
but only if the card is present and an array is defined. I can't record what 
the dump is because it continually sprays the dump down the screen which 
makes it unreadable :(

I have seen this on an AMD64 system (I used the same RAID card in it) and got 
the same problem. To work around it on that system I installed via the 
motherboard IDE controller and then moved the disk over to the RAID 
controller.

It only seems to affect booting the installer - once the system is installed 
it boots from the RAID card just fine (!)

I just tried booting from floppy and that works (?!) although that method 
doesn't probe my PS/2 keyboard for some reason :-/

Does anyone have any suggestions for fixing the RAID + CD boot problem?

Thanks.

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C


pgp4ZGOAr5xv5.pgp
Description: PGP signature

Re: 5.4-p1 crash

[Doug White]

On Mon, 20 Jun 2005, Philippe PEGON wrote:

> Philippe PEGON wrote:
> > Mitch Parks wrote:
> >
> >> On Sun, 19 Jun 2005, Doug White wrote:
> >>
> >>> On Fri, 17 Jun 2005, Mitch Parks wrote:
> >>>
>  Below are details regarding another crash on a Dell 2600 SMP (HTT
>  and USB
>  disabled). It has been 9 days since the last crash. I didn't have
>  the serial
>  console in place for this last crash, but it is now.
> >>>
> >>>
> >>>
> >>> As noted, the ttwakeup() panic is a known bug. The best thing we have
> >>> for
> >>> a fix is this patch:
> >>>
> >>> http://people.freebsd.org/~mlaier/tty.t_pgrp.diff
> >>>
> >>> Please give it a try and report back if you have any more panics (or
> >>> don't :-) ).
> >>
> >>
> >>
> >> Thanks! This patch appears to be for 5.3, but I manually applied the
> >> chunk of the patch that didn't apply cleanly and the countdown is on.
> >>
> >> I'll report back in 10 days unless something bad happens before then.
> >>
> >> Below is the patch chunk #10 that I actually applied rather than the
> >> one given. If I've done something bad here by removing the PGRP_LOCK
> >> please let me know.
> >
> >
> > I'm not a kernel developper, but if you remove
> >
> > PGRP_LOCK(tp->t_pgrp);
> >
> > and the PGRP_UNLOCK(tp->t_pgrp) in the if condition (removed by the
> > orginal patch)
> >
> > there is maybe another "PGRP_UNLOCK(tp->t_pgrp);" to remove if the if
> > condition doesn't match, line 2528 in the original 5.4-p1 tty.c ?
>
> after having applied the patch (with your modification), there is no
> "sx_sunlock(&proctree_lock)" in the ttyinfo function if the three
> conditions failed. Maybe we have just to replace
> "PGRP_UNLOCK(tp->t_pgrp);" line 2528 by "sx_sunlock(&proctree_lock)" ?
> I think that we need the helps of a kernel developper.

No, that would be a leaked lock, which would cause hangs.  More likely its
some other case that got missed that needs locks extended to it, or the
aliased pgrp isn't the underlying problem.

I've run out of time to debug this, unfortunately...

>
> >
> >>
> >> 
> >> Hunk #6 succeeded at 1154 (offset -51 lines).
> >> Hunk #7 succeeded at 1215 (offset -6 lines).
> >> Hunk #8 succeeded at 1203 (offset -51 lines).
> >> Hunk #9 succeeded at 1946 (offset -5 lines).
> >> Hunk #10 failed at 2562.
> >> Hunk #11 succeeded at 2847 (offset -212 lines).
> >> 1 out of 11 hunks failed--saving rejects to tty.c.rej
> >>
> >>
> >> @@ -2495,19 +2511,21 @@
> >>  * On return following a ttyprintf(), we set tp->t_rocount to
> >> 0 so
> >>  * that pending input will be retyped on BS.
> >>  */
> >> +   sx_slock(&proctree_lock);
> >> if (tp->t_session == NULL) {
> >> +   sx_sunlock(&proctree_lock);
> >> ttyprintf(tp, "not a controlling terminal\n");
> >> tp->t_rocount = 0;
> >> return;
> >> }
> >> if (tp->t_pgrp == NULL) {
> >> +   sx_sunlock(&proctree_lock);
> >> ttyprintf(tp, "no foreground process group\n");
> >> tp->t_rocount = 0;
> >> return;
> >> }
> >> -   PGRP_LOCK(tp->t_pgrp);
> >> -   if ((p = LIST_FIRST(&tp->t_pgrp->pg_members)) == 0) {
> >> -   PGRP_UNLOCK(tp->t_pgrp);
> >> +   if ((p = LIST_FIRST(&tp->t_pgrp->pg_members)) == NULL) {
> >> +   sx_sunlock(&proctree_lock);
> >> ttyprintf(tp, "empty foreground process group\n");
> >> tp->t_rocount = 0;
> >> return;
> >>
> >> Or the complete patch:
> >> http://kuoi.asui.uidaho.edu/~mitch/crash/tty_5.4.patch
> >>
> >> Mitch Parks
> >> [EMAIL PROTECTED]
> >> ___
> >> freebsd-stable@freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> >> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> >
> >
>
>
>

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

Re[2]: ATA DMA timeouts [NOT FIXED] (forget my last mail)

[Tony Byrne]

Hello Martin,

M> believe it or not. After sending the last mail and closing
M> firefox, the system has been hanging for a few seconds and
M> spit this out:

M> ad0: TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=226025086

Yeah, I updated and rebuilt on seeing your email, but found it did
little.  I has TIMEOUTs again within 10 minutes of rebooting.

M> Sorry for causing noise. :(
M> I'm going to test a kernel every week and report, when the
M> problems are gone.

I'd certainly be interested in hearing about your results, but from
the general lack of discussion of the problem on this list, I'm
guessing we may be on our own. I'm not sure anyone is actually working
on a "fix", because I'm not sure the problem is recognized.

I have two separate Intel IHC5 based boxes affected by DMA TIMEOUTS,
both with SATA drives and I'd like to get to the bottom of this.

Regards,

Tony.

-- 
Tony Byrne


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

Re: Data corruption in cd9660 on FreeBSD 4.11?

[Peter Jeremy]

On Fri, 2005-Jun-24 22:31:06 +1000, Stephen McKay wrote:
>I'm experiencing data corruption when reading CDs and DVDs on FreeBSD 4.11.
...
>So, can anyone suggest any more tests I could try?  Or is there a kind of
>hardware fault that could cause this substitution of whole blocks read from
>CDs without causing any other problems?

You might like to post the relevant sections of a verbose boot - the
ATA and CD probes.

Are you running the CD/DVD drives in PIO or UDMA modes?  In the former,
the CPU is reading the data from the CD and writing it to memory.  In
the latter, the CPU tells the disk controller where to write.  It could
be instructive to change modes and see what happens.

Have you tried anything other than ISO9660 filesystems on a physical CD?
What happens if you just dd the CD-ROM?  What happens if you use a vnode
mount (see vnconfig(8)) of an ISO filesystem sitting in a UFS filesystem?

Anything unusual in your kernel config file?

Have you tried building a kernel with WITNESS and/or DIAGNOSTIC?

Any chance of you repeating the tests with a 5.x system?  Maybe
on a spare small partition or using a 5.4-RELEASE disk1 as a live
filesystem.

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

Re: panic in RELENG_5 UMA

[Gary Mu1der]

Sorry, I forgot to add that this is a Tyan Thunder K8SPRO w/dual AMD 
Opteron Processors, model no. 246, 4GB of RAM and an Adaptec 2200S RAID 
controller.


The NIC being used is the onboard Broadcom Gigabit Ethernet (bge).

Thanks,
Gary


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

Re: panic in RELENG_5 UMA

[Gary Mu1der]

All,

Can someone confirm that the following stack trace is showing the same 
problem, or not?


I can reproduce the problem with the custom kernel config included below 
(which is basically GENERIC stripped of devices I don't have or need and 
IPFILTER added), but not with a stock GENERIC kernel.


To cause the crash I'm running 20-30 instances of the following script:

d5# cat arping.sh
#!/bin/sh

while :
do
arp -d 192.168.4.$1 >/dev/null 2>&1;
ping -c 1 -t 1 192.168.4.$1 >/dev/null 2>&1;
done

d5# uname -a
FreeBSD d5.bidx.com 5.4-RELEASE FreeBSD 5.4-RELEASE #6: Thu Jun 23
13:45:20 EDT 2005
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/DB-DUAL-AMD64-RAID5  amd64

d5# kgdb /usr/obj/usr/src/sys/DB-DUAL-AMD64-RAID5/kernel.debug ./vmcore.5
[GDB will not be able to debug user-mode threads:
/usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd".
#0  doadump () at pcpu.h:167
167 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0  doadump () at pcpu.h:167
#1  0x in ?? ()
#2  0x802557b7 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:410
#3  0x80255fef in panic (fmt=0xff00b5907500 " ë6µ")
at /usr/src/sys/kern/kern_shutdown.c:566
#4  0x8029ad2a in sbdrop_locked (sb=0xb6274860, len=1146)
at /usr/src/sys/kern/uipc_socket2.c:1149
#5  0x8029afe2 in sbflush_locked (sb=0xb6274860)
at /usr/src/sys/kern/uipc_socket2.c:1116
#6  0x8029b049 in sbrelease_locked (sb=0xb6274860,
so=0xff00a0a2a8a0)
at /usr/src/sys/kern/uipc_socket2.c:564
#7  0x8029b0d5 in sbrelease (sb=0xb6274860,
so=0xff00a0a2a8a0)
at /usr/src/sys/kern/uipc_socket2.c:577
#8  0x80297b03 in sorflush (so=0xff00a0a2a8a0)
at /usr/src/sys/kern/uipc_socket.c:1483
#9  0x80297e42 in sofree (so=0xff00a0a2a8a0) at
/usr/src/sys/kern/uipc_socket.c:407
#10 0x80298467 in soclose (so=0xff00a0a2a8a0) at
/usr/src/sys/kern/uipc_socket.c:485
#11 0x802847b5 in soo_close (fp=0xff009ca95b60, td=0x0)
at /usr/src/sys/kern/sys_socket.c:299
#12 0x8022c2c0 in fdrop_locked (fp=0xff009ca95b60,
td=0xff00b5907500)
at file.h:288
#13 0x8022c40a in closef (fp=0xff009ca95b60,
td=0xff00b5907500)
at /usr/src/sys/kern/kern_descrip.c:1920
#14 0x8022e5be in fdfree (td=0xff00b5907500)
at /usr/src/sys/kern/kern_descrip.c:1624
#15 0x80238bd0 in exit1 (td=0xff00b5907500, rv=0)
at /usr/src/sys/kern/kern_exit.c:236
#16 0x8023a04e in sys_exit (td=0x0, uap=0x0) at
/usr/src/sys/kern/kern_exit.c:93
#17 0x8035cd8c in syscall (frame=
  {tf_rdi = 0, tf_rsi = 5263360, tf_rdx = 0, tf_rcx = 34366596768,
tf_r8 = 0, tf_r9 = 140737488350136, tf_rax = 1, tf_rbx = 0, tf_rbp = 3,
tf_r10 = -1099499764224, tf_r11 = 515, tf_r12 = 140---Type  to
continue, or q  to quit---
737488350376, tf_r13 = 0, tf_r14 = 0, tf_r15 = 0, tf_trapno = 12,
tf_addr = 34368259080, tf_flags = 0, tf_err = 2, tf_rip = 34366590280,
tf_cs = 43, tf_rflags = 514, tf_rsp = 140737488350296, tf_ss = 35}) at
/usr/src/sys/amd64/amd64/trap.c:771
#18 0x80349f88 in Xfast_syscall () at
/usr/src/sys/amd64/amd64/exception.S:248
#19 0x in ?? ()
#20 0x00505000 in ?? ()
#21 0x in ?? ()
#22 0x00080068a6a0 in ?? ()
#23 0x in ?? ()
#24 0x7fffebb8 in ?? ()
#25 0x0001 in ?? ()
#26 0x in ?? ()
#27 0x0003 in ?? ()
#28 0xffb50600 in ?? ()
#29 0x0203 in ?? ()
#30 0x7fffeca8 in ?? ()
#31 0x in ?? ()
#32 0x in ?? ()
#33 0x in ?? ()
#34 0x000c in ?? ()
#35 0x000800820408 in ?? ()
#36 0x in ?? ()
#37 0x0002 in ?? ()
#38 0x000800688d48 in ?? ()
#39 0x002b in ?? ()
#40 0x0202 in ?? ()
#41 0x7fffec58 in ?? ()
#42 0x0023 in ?? ()
#43 0x7fffe968 in ?? ()
#44 0x0023 in ?? ()
#45 0x in ?? ()
---Type  to continue, or q  to quit---
#46 0x in ?? ()
#47 0x in ?? ()
#48 0x in ?? ()
#49 0x in ?? ()
#50 0x in ?? ()
#51 0x in ?? ()
#52 0x in ?? ()
#53 0xa14b4000 in ?? ()
#54 0xb6274c40 in ?? ()
#55 0x0101 in ?? ()
#56 0x in ?? ()
#57 0xff00b536eba0 in ?? ()
#58 0xff00ec19a780 in ?? ()
#59 0xb6274b58 in ?? ()
#6

Re: pxeboot, NFS and root-path: bug or documentation error?

[Brian Candler]

On Fri, Jun 24, 2005 at 01:50:37PM -0400, John Baldwin wrote:
> It uses TFTP to fetch the pxeboot binary itself.  After that, it uses either 
> NFS or TFTP.  By default it uses NFS to access /boot/loader and friends.  If 
> you want it to just use TFTP and not use NFS at all, you need to recompile 
> pxeboot with LOADER_TFTP_SUPPORT=yes defined in make.  That is:
> 
> % cd /sys/boot
> % make clean
> % make LOADER_TFTP_SUPPORT=yes
> % cp /usr/obj/usr/src/sys/boot/i386/pxeldr/pxeboot /usr/tftpboot

Thank you, that's very clear. Re-reading the manpage I do now see the phrase
"selectable through compile-time options"; perhaps it would be worth also
showing those options.

Is there any fundamental reason why both couldn't be compiled in at once,
e.g. limitations on the pxeboot binary size? Or is it just awkward to
implement?

I would have no objection to

options root-path = "tftp://192.168.0.1/usr/tftpboot";

I would also have no objection to "pxeboot.nfs" and "pxeboot.tftp" being
built :-)

I'll try building the tftp version when back in the office next week.

Thanks again,

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

Re: ATA_DMA errors

[twesky]

I don't think it is a hardware problem.  Unless you replace it with
the exact same hardware, it'll be difficult to determine if it was the
hardware.

I haven't had any issues with 5.3R or any stable version before April
15.  I am going to do some checking this weekend and see if it is
hardware or software what is causing my timeouts.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ATA_DMA errors

[Johny Mattsson]

twesky wrote:

I am having ATA_DMA errors on 5.4R and 5 STABLE up to June 16 (haven't
done a cvsup again).  It doesn't happen on 5.3R or lower.


I've just upgraded my fileserver from 5.1-R to 5.4-R, and I'm seeing 
this problem too now on 3 out of 4 drives.




The exact error message is below:

It happens within a few hours of use.  The laptop will then reboot,
and fsck must be ran.  After fsck the timeouts happen within a few
seconds of booting.


My system uses a "SiI 0680 UDMA133 controller" in addition to the old 
built-in "Intel PIIX4 UDMA33 controller". My system drive hangs off the 
PIIX4 controller and I see no issues with it, only drives off the SiI;


ad0: 8207MB  [16676/16/63] at ata0-master UDMA33
ad4: 57241MB  [116301/16/63] at ata2-master UDMA100
ad6: 76319MB  [155061/16/63] at ata3-master UDMA100
ad7: 152627MB  [310101/16/63] at 
ata3-slave UDMA100



Right after the upgrade things worked well for a couple of hours, and 
then I got a reboot all of a sudden. Upon inspection I found tons of 
both "READ_DMA timed out" as well as "WRITE_DMA UDMA ICRC error" 
messages in log prior to the reboot. After the reboot it went to do the 
fsck and made it perhaps halfway through it before it started churning 
out READ_DMA timed out messages again, followed by the "ad7: warning - 
removed from configuration" message.


Things did not get better from there, but with each sucessive reboot 
more and more started going wrong. In order to be able to get the system 
to even boot in the end I had to physically disconnect the ad7 drive, 
but even so I'm getting READ_DMA timed out messages for ad4 and ad6.


Since I'm getting WRITE_DMA errors on both ad6 and ad7 now (I haven't 
written anything to ad4 yet, so I don't know if I'll get errors on that 
one too), and I wasn't a few hours ago when I was running 5.1-R, I 
refuse to believe that two disks have gone bad in that timespan!


I'm not sure what I should do at this point - theoretically I could 
proceed to roll back to 5.1 to prevent further data loss, but I'm 
guessing it'd be good if I kept it for a little while so that I could 
run tests for patches :-/



Seeing the comments about possible failing controller hardware, I might 
see if I can find a replacement controller tomorrow... any ideas in the 
meantime will be appreciated though!


Still feels very iffy that this started happening right after the 
upgrade... I was expecting to get rid of some of the quirks from the 
early preview, not get far worse ones! :-(



Oh, btw, using smartmontools' smartctl, I've gotten the information that 
ad4 has had 32 write errors in total, ad6 have had 0 (despite seeing the 
WRITE_DMA errors in the system log), and ad7 refuses to even talk SMART.



###

Here's the contents of the dmesg from before I pulled ad7 out:

Jun 24 18:22:19 kernel: FreeBSD 5.4-RELEASE #0: Sun May 8 10:21:06 UTC 2005
Jun 24 18:22:19 kernel:
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
Jun 24 18:22:19 kernel: Timecounter "i8254" frequency 1193182 Hz quality 0
Jun 24 18:22:19 kernel: CPU: Pentium II/Pentium II Xeon/Celeron
(467.73-MHz 686-class CPU)
Jun 24 18:22:19 kernel: Origin = "GenuineIntel" Id = 0x665 Stepping = 5
Jun 24 18:22:19 kernel:
Features=0x183f9ff
Jun 24 18:22:19 kernel: real memory = 805240832 (767 MB)
Jun 24 18:22:19 kernel: avail memory = 778231808 (742 MB)
Jun 24 18:22:19 kernel: npx0:  on motherboard
Jun 24 18:22:19 kernel: npx0: INT 16 interface
Jun 24 18:22:19 kernel: acpi0:  on motherboard
Jun 24 18:22:19 kernel: acpi0: Power Button (fixed)
Jun 24 18:22:19 kernel: Timecounter "ACPI-safe" frequency 3579545 Hz
quality 1000
Jun 24 18:22:19 kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port
0x4008-0x400b on acpi0
Jun 24 18:22:19 kernel: cpu0:  on acpi0
Jun 24 18:22:19 kernel: acpi_throttle0:  on cpu0
Jun 24 18:22:19 kernel: acpi_button0:  on acpi0
Jun 24 18:22:19 kernel: pcib0:  port
0x5000-0x500f,0x4000-0x4041,0xcf8-0xcff on acpi0
Jun 24 18:22:19 kernel: pci0:  on pcib0
Jun 24 18:22:19 kernel: agp0:  mem 0xe000-0xe3ff at device 0.0 on pci0
Jun 24 18:22:19 kernel: pcib1:  at device 1.0 on pci0
Jun 24 18:22:19 kernel: pci1:  on pcib1
Jun 24 18:22:19 kernel: isab0:  at device 7.0 on pci0
Jun 24 18:22:19 kernel: isa0:  on isab0
Jun 24 18:22:19 kernel: atapci0:  port
0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0
Jun 24 18:22:19 kernel: ata0: channel #0 on atapci0
Jun 24 18:22:19 kernel: ata1: channel #1 on atapci0
Jun 24 18:22:19 kernel: uhci0: 
port 0x9000-0x901f irq 11 at device 7.2 on pci0
Jun 24 18:22:19 kernel: usb0: 
on uhci0
Jun 24 18:22:19 kernel: usb0: USB revision 1.0
Jun 24 18:22:19 kernel: uhub0: Intel UHCI root hub, class 9/0, rev
1.00/1.00, addr 1
Jun 24 18:22:19 kernel: uhub0: 2 ports with 2 removable, self powered
Jun 24 18:22:19 kernel: pci0:  at device 7.3 (no driver attached)
Jun 24 18:22:19 kernel: atapci1:  port
0xa400-0xa40f,0xa000-0xa003,0x9c00-0x9c07,0x9800-0x9803,0x9400-0x9407 
mem 0xe9001000-0xe900

10ff irq 9 at 

Network/fxp related panic in 5.4?

[Eirik Øverby]

Hi all,

I recently re-enabled SMP on one of my 5.4 servers (dual intel p3),  
and after a relatively short while (couple of days) it starts acting  
up. Today it was frozen and had jumped into kernel debugger on serial  
console. Problem is that my serial console was controlled by a  
terminal at work, and when I got home it seemed that the work  
terminal had disconnected. All I could do was a 'trace' - I don't  
have the panic screen (if any) nor do I have any other output because  
the watchdog triggered the powerswitch cycle just after I got the trace:


Tracing pid 29 tid 10 td 0xc22a
fxp_intr_body(c2404000,c2404000,40,,8) at fxp_intr_body+0xd0
fxp_intr(c2404000,0,0,0,0) at fxp_intr+0x14e
ithread_loop(c22f6500,e3384d38,0,0,0) at ithread_loop+0x1b8
fork_exit(c06a9150,c22f6500,e3384d38) at fork_exit+0x80
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xe3384d6c, ebp = 0 ---
db>

What makes me wonder is ... When I connected the serial console, the  
db> prompt was already there. Does that mean that the work terminal  
disconnect somehow sent a telnet break, and triggered the kernel  
debugger? I.e. - this was no panic, but a stupid serial console hiccup?


Is there any way to prevent this in the future - like changing the  
control character that would trigger the kernel debugger? (I have  
BREAK_TO_DEBUGGER in my kernel config..)


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

Re: pxeboot, NFS and root-path: bug or documentation error?

[John Baldwin]

On Friday 24 June 2005 01:03 pm, Brian Candler wrote:
> I have been setting up a pxeboot "jumpstart" environment for FreeBSD 4.11,
> following the instructions at
> http://www.freebsd.org/doc/en_US.ISO8859-1/articles/pxe/
>
> Rather than build pxeboot like this:
> # rm -rf /usr/obj/*
> # cd /usr/src/sys/boot
> # make
> # cp /usr/src/sys/boot/i386/pxeldr/pxeboot /usr/tftpboot
> I just copied /boot/pxeboot from the FreeBSD-4.11 CD-ROM. Otherwise I
> followed the instructions very closely.
>
> The pxeboot client machine is a Compaq ProLiant DL380.
>
> On first attempt, it got as far as pxeboot starting, and then:
>
>   pxe_open: server addr: 192.168.0.1
>   pxe_open: server path: /pxeroot
>   pxe_open: gateway ip: 0.0.0.0
>   Booting [kernel]...
>   can't load 'kernel'
>   can't load 'kernel.old'
>
> And my NFS server logs a failed attempt to mount /pxeroot:
>
>   Jun 24 16:32:40 sr-mon-00 mountd[642]: mount request from 192.168.0.240
> for non existent path /pxeroot
>   Jun 24 16:32:49 sr-mon-00 last message repeated 59 times
>
> This is strange; I thought that at this stage pxeboot would be pulling
> across the kernel and ramdisk via TFTP from /usr/tftpboot, although the
> documentation is far from clear. pxeboot(8) says:
>
>  pxeboot recognizes next-server and option root-path directives as the
>  server and path to NFS mount for file requests, respectively, or the
>  server to make TFTP requests to.
>
> (Erm, so exactly how do I choose whether to use NFS or to use TFTP for the
> next stage?)
>
> Anyway, assuming that I'm forced to use NFS at this point, I added another
> DHCP option:
>
>   option root-path "192.168.0.1:/usr/tftpboot";
>
> This option is not shown in the example dhcpd.conf in pxeboot(8), nor in
> the article referred to above. However, if I also put an entry in the NFS
> server's /etc/hosts file for the client DHCP address, it then works
> properly.
>
> So the question is: when pxeboot runs on the client, is it able to fetch
> loader.rc, the kernel and ramdisk via TFTP, or only via NFS?
>
> If it's only NFS, then I think the pxeboot(8) manpage, and the pxeboot
> article, ought to be updated. If it *can* use TFTP, does anyone have any
> suggestions for what I was doing wrong?

It uses TFTP to fetch the pxeboot binary itself.  After that, it uses either 
NFS or TFTP.  By default it uses NFS to access /boot/loader and friends.  If 
you want it to just use TFTP and not use NFS at all, you need to recompile 
pxeboot with LOADER_TFTP_SUPPORT=yes defined in make.  That is:

% cd /sys/boot
% make clean
% make LOADER_TFTP_SUPPORT=yes
% cp /usr/obj/usr/src/sys/boot/i386/pxeldr/pxeboot /usr/tftpboot

-- 
John Baldwin <[EMAIL PROTECTED]>  <><  http://www.baldwin.cx/~john/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org

-- 
John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: dmesg queries

[Vivek Khera]

On Jun 24, 2005, at 12:09 PM, Chris Phillips wrote:


Here's what has me writing... looking in /var/run/dmesg I see: -

kernel: ioapic0: Changing APIC ID to 2
kernel: ioapic1: Changing APIC ID to 3
kernel: ioapic1: WARNING: intbase 32 != expected base 24
kernel: ioapic0  irqs 0-23 on motherboard
kernel: ioapic1  irqs 32-55 on motherboard

Should I be worried by that WARNING?


I see this as well on my PE800.



Also in /var/run/dmesg I see: -

kernel: Interrupt storm detected on "irq19: uhci0 uhci2";  
throttling interrupt source
kernel: Interrupt storm detected on "irq18: bge0 uhci1+";  
throttling interrupt source




I get this as well.  I don't use USB so I turned that off at the BIOS  
and removed it from my kernel, but I still get "interrupt storm" on  
my bge0 device.  No idea why.


Performance is not all that great on this box disk-wise, but CPU wise  
it is acceptably fast.  I run FreeBSD/amd64 on it rather than FreeBSD/ 
i386.



Vivek Khera, Ph.D.
+1-301-869-4449 x806

pxeboot, NFS and root-path: bug or documentation error?

[Brian Candler]

I have been setting up a pxeboot "jumpstart" environment for FreeBSD 4.11, 
following the instructions at 
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/pxe/

Rather than build pxeboot like this:
# rm -rf /usr/obj/*
# cd /usr/src/sys/boot
# make
# cp /usr/src/sys/boot/i386/pxeldr/pxeboot /usr/tftpboot
I just copied /boot/pxeboot from the FreeBSD-4.11 CD-ROM. Otherwise I followed 
the instructions very closely.

The pxeboot client machine is a Compaq ProLiant DL380.

On first attempt, it got as far as pxeboot starting, and then:

  pxe_open: server addr: 192.168.0.1
  pxe_open: server path: /pxeroot
  pxe_open: gateway ip: 0.0.0.0
  Booting [kernel]...
  can't load 'kernel'
  can't load 'kernel.old'

And my NFS server logs a failed attempt to mount /pxeroot:

  Jun 24 16:32:40 sr-mon-00 mountd[642]: mount request from 192.168.0.240 for 
non existent path /pxeroot
  Jun 24 16:32:49 sr-mon-00 last message repeated 59 times

This is strange; I thought that at this stage pxeboot would be pulling across 
the kernel and ramdisk via TFTP from /usr/tftpboot, although the 
documentation is far from clear. pxeboot(8) says:

 pxeboot recognizes next-server and option root-path directives as the
 server and path to NFS mount for file requests, respectively, or the
 server to make TFTP requests to.

(Erm, so exactly how do I choose whether to use NFS or to use TFTP for the 
next stage?)

Anyway, assuming that I'm forced to use NFS at this point, I added another 
DHCP option:

  option root-path "192.168.0.1:/usr/tftpboot";

This option is not shown in the example dhcpd.conf in pxeboot(8), nor in the 
article referred to above. However, if I also put an entry in the NFS 
server's /etc/hosts file for the client DHCP address, it then works properly.

So the question is: when pxeboot runs on the client, is it able to fetch 
loader.rc, the kernel and ramdisk via TFTP, or only via NFS?

If it's only NFS, then I think the pxeboot(8) manpage, and the pxeboot 
article, ought to be updated. If it *can* use TFTP, does anyone have any 
suggestions for what I was doing wrong?

Regards,

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

dmesg queries

[Chris Phillips]

Hi All,

I'm trying to figure out a couple of things & would like some advice please.

My server was on FreeBSD 5.3 STABLE #1 this morning (I only took it to 
STABLE, because at the time, my GigNIC was not supported fully 
@RELEASE).  I upgraded today & it's now looking like this: -


% uname -a
FreeBSD venus.rainbow-it.net 5.4-RELEASE-p2 FreeBSD 5.4-RELEASE-p2 #2: 
Fri Jun 24 13:43:08 BST 2005 
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/VENUS  i386


It's a lowly Dell PowerEdge 800 


Here's what has me writing... looking in /var/run/dmesg I see: -

kernel: ioapic0: Changing APIC ID to 2
kernel: ioapic1: Changing APIC ID to 3
kernel: ioapic1: WARNING: intbase 32 != expected base 24
kernel: ioapic0  irqs 0-23 on motherboard
kernel: ioapic1  irqs 32-55 on motherboard

Should I be worried by that WARNING?


Also in /var/run/dmesg I see: -

kernel: Interrupt storm detected on "irq19: uhci0 uhci2"; throttling 
interrupt source
kernel: Interrupt storm detected on "irq18: bge0 uhci1+"; throttling 
interrupt source


I think the top device is a Logitech QuickCam Express & the bottom one 
(using irq18), is my onboard Gigabit NIC.  Would these lines in dmesg 
suggest that there is a problem and if so, is there anything that I can 
do to combat it?  Is it likely that this 'throttling', is slowing my NIC 
at all?



I have seen this kind of notification (throttling), when printing.  This 
is the dmesg output for that device: -


kernel: ppc0:  port 0x778-0x77f,0x378-0x37f 
irq 7 drq 1 on acpi0

kernel: ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode
kernel: ppc0: FIFO with 16/16/8 bytes threshold
kernel: ppbus0:  on ppc0
kernel: ppbus0: IEEE1284 device found /NIBBLE/ECP
kernel: Probing for PnP devices on ppbus0:
kernel: ppbus0:  PRINTER MLC,PCL,PML
kernel: lpt0:  on ppbus0
kernel: lpt0: Interrupt-driven port
kernel: ppi0:  on ppbus0


Now, the upgrade may well have stopped the behavior mentioned below, but 
if not, does anyone know what I might have done wrong, to be getting (a 
lot of) messages like: -


sio0: 1848 more interrupt-level buffer overflows (total 11269) ?

This is the device: -

kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 
0x10 on acpi0

kernel: sio0: type 16550A


Finally, is it considered "bad form", to ask multiple questions like I 
have, or should I have separated them & sent them in multiple emails?


Kind Regards,


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

Re: ATA DMA timeouts [NOT FIXED] (forget my last mail)

[Martin]

Hi (again),

believe it or not. After sending the last mail and closing
firefox, the system has been hanging for a few seconds and
spit this out:

ad0: TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=226025086

I'm back on kernel of May 26th again. This time I did not have
a corrupted file system or at least not as badly corrupted that
it panics the kernel, like the first time.

Usually my system has DMA timeouts very early while booting up
and creates mess on the file systems.

Sorry for causing noise. :(
I'm going to test a kernel every week and report, when the
problems are gone.

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

Re: EHCI: mtools stuck in state 'physrd' or panic

[Stefan Walter]

Mike Tancsa in gmane.os.freebsd.stable:

> If you reformat the USB stick with UFS2, does IO still hang the box ?

I haven't tried that, but instead tried to just dump the whole USB stick
to a file with "dd if=/dev/da2 of=stickimage bs=1024". The dd process also
hung in state "physrd" eventually, and about a minute after pulling out
the USB stick the system panic'd.

Furthermore, I tried the same (both mcopy and dd) on my notebook (Centrino
-> Intel ICH4 chipset), which didn't have ehci in its kernel until then,
either. It worked flawlessly, multiple times.

Stefan
-- 
No reading beyond this point


pgpdMFKJF869g.pgp
Description: PGP signature

Re: Portupgrade in Xfree86 pkg failed

[Daniel O'Connor]

On Fri, 24 Jun 2005 20:47, Warren wrote:
> Just before doing PortUpgrade before sending the 1st email
>
> > Did you read /usr/ports/UPDATING?
>
> cant say as i did.

Well that was silly..
Not that I think there is a specific entry in this case but it is a good habit 
to get in to..

Do you have the kernel source installed? I think you may need that to build 
the xfree86-dri port (I don't know why it doesn't check)

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C


pgpLwwFvumZLC.pgp
Description: PGP signature

Re: EHCI: mtools stuck in state 'physrd' or panic

[Mike Tancsa]

At 08:50 AM 24/06/2005, Stefan Walter wrote:

I can also list the content of the FAT filesystem with mtools' mdir
command. When trying to copy a file from the stick to a local filesystem,
however, mcopy is almost immediately stuck in state "physrd" (according to
top(1)) after copying a varying number of bytes (between 100 and 2200 KB
is what I've seen so far). I cannot kill the mtools process, but pulling
out the USB stick helps - it panics after a few times of doing that,
though.


If you reformat the USB stick with UFS2, does IO still hang the box ?

---Mike 


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

Re: Simultaneously two versions of one port?

[Stefan Walter]

Thomas Beer in gmane.os.freebsd.stable:

> I'm trying to install gdesklets which depends on
> py24-orbit. However, py23-orbit is already
> installed. I googled and tryed various ways
> with portupgrade et al. What to do?

Do you still need the Python 2.3 stuff? If not, you could just upgrade all
packages installed for 2.3 with 'portupgrade "py23*"', for instance.

Stefan
-- 
No reading beyond this point


pgpX5W7W4GdGd.pgp
Description: PGP signature

EHCI: mtools stuck in state 'physrd' or panic

[Stefan Walter]

Hi,

I just updated to this morning's RELENG_5 and thought I'd give USB 2.0 a
try to speed up data exchange with my USB sticks. The controller is
correctly identified, it seems:

ehci0:  mem 0xdbfdf700-0xdbfdf7ff irq 3 at 
device 16.3 on pci0

When plugging in a USB stick, it is correctly identified, too:

umass0: USB Flash Disk, rev 2.00/2.00, addr 2
da2 at umass-sim0 bus 0 target 0 lun 0
da2: < USB BAR 2.00> Removable Direct Access SCSI-2 device 
da2: 40.000MB/s transfers
da2: 124MB (255744 512 byte sectors: 64H 32S/T 124C)

I can also list the content of the FAT filesystem with mtools' mdir
command. When trying to copy a file from the stick to a local filesystem,
however, mcopy is almost immediately stuck in state "physrd" (according to
top(1)) after copying a varying number of bytes (between 100 and 2200 KB
is what I've seen so far). I cannot kill the mtools process, but pulling
out the USB stick helps - it panics after a few times of doing that,
though.

I thought it might have to do with IRQ sharing first, but according to
"vmstat -i" and dmesg, ehci0 doesn't share its IRQ with anything else.

I know that the ehci(4) man page says the driver is not finished and quite
buggy, but that doesn't mean I shouldn't report a problem, right? ;)

Any ideas?

Stefan


pgpuFhzD1g7Qh.pgp
Description: PGP signature

Re: Simultaneously two versions of one port?

[Thomas Beer]

> either, 'cd'  to the port that is causing the problem, devel/py-orbit2, in
> this case and type 'make deinstall', than go back to your original port and
> issue a make again

What's with existing dependencies?

> 
> or, 'cd' to the port that is causing the problem, devel/py-orbit2, in this
> case and type 'make -DFORCE_PKG_REGISTER install clean'. This forces an
> upgrade of the troublesome port, but may result in a double registered port.
> This can be checked by issuing 'pkgdb -F'
> 
> Good luck,
> 
> Pascal
> 
> On Fri, 24 Jun 2005 14:17:29 +0200, Thomas Beer wrote
> > Dear All,
> >
> > I'm trying to install gdesklets which depends on
> > py24-orbit. However, py23-orbit is already
> > installed. I googled and tryed various ways
> > with portupgrade et al. What to do?
> >
> > Thanks Tom
> >
> > [EMAIL PROTECTED] gdesklets]# make install
> > ===>   gdesklets-0.34.3 depends on file: /usr/local/bin/python - found
> >
> > <---snip--->
> >
> > ===>  Installing for py24-orbit-2.0.1_1
> > ===>   py24-orbit-2.0.1_1 depends on file: /usr/local/bin/python2.4 - found
> > ===>   py24-orbit-2.0.1_1 depends on executable: pkg-config - found
> > ===>   py24-orbit-2.0.1_1 depends on shared library: glib-2.0.600 - found
> > ===>   py24-orbit-2.0.1_1 depends on shared library: IDL-2.0 - found
> > ===>   py24-orbit-2.0.1_1 depends on shared library: ORBit-2.0 - found
> > ===>   Generating temporary packing list
> > ===>  Checking if devel/py-orbit2 already installed
> > ===>   An older version of devel/py-orbit2 is already installed
> > (py23-orbit-2.0.1_1)
> >  You may wish to ``make deinstall'' and install this port again
> >  by ``make reinstall'' to upgrade it properly.
> >  If you really wish to overwrite the old port of devel/py-orbit2
> >  without deleting it first, set the variable "FORCE_PKG_REGISTER"
> >  in your environment or the "make install" command line.
> > *** Error code 1
> >
> > Stop in /usr/ports/devel/py-orbit2.
> > *** Error code 1
> >
> > Stop in /usr/ports/x11-toolkits/py-gnome2.
> > *** Error code 1
> >
> > Stop in /usr/ports/deskutils/gdesklets.
> >
> > --
> > --  Which is worse:  ignorance or apathy?
> > --  Don't know.  Don't care.
> > ___
> > freebsd-stable@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> 
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> 


-- 
--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Data corruption in cd9660 on FreeBSD 4.11?

[Stephen McKay]

Hi!

I'm experiencing data corruption when reading CDs and DVDs on FreeBSD 4.11.
My best theory so far is that cd9660 or perhaps the VFS layer is mishandling
2048 byte buffers (since they are smaller than one virtual memory page),
occasionally writing them to the wrong location in RAM.  Read on for why
I think so.

First up, I don't think this is the usual hardware problem since the machine
has done huge numbers of buildworlds (in 4.x and -current) without any of
the telltale signs (eg bus errors and segmentation violations).  There are
no error messages in /var/log/messages.  Also, it moonlights as a games
machine and plays Doom 3, Battlefield 1942, Neverwinter Nights and so forth
like a champ.  Memory, cpu, video, disk, networking are all just fine 100%
of the time.

The hardware is an ASUS P4P800 mobo (including onboard Marvell Yukon gigabit
ethernet) with a P4 2.8GHz cpu, 1GB RAM, Maxtor 120GB disk, Pioneer 103S
DVD-ROM, LiteOn SOHW-1673S DVD burner in an Antec Sonata case.

Now that I have a DVD burner, I make backups of my main machines (over NFS)
but have found that they often don't verify as 100% correct.  The symptom
is that, for some files, an entire 2048 DVD sector is replaced with
different (non-zero) data.  This occurs both when reading with the Pioneer
DVD-ROM and when reading with the LiteOn burner (though I don't test with
the Pioneer much as it is slower).

I emphasise that all burns have been 100% correct (ie the burning process
worked and this can be verified by reading on, say, my iBook), so all of
the hardware seems to be operating correctly (and swiftly, I might add).
The problem is that reading the iso9660 file system is not safe.

After some experimenting, I've found that the problem also occurs when
reading CDs, and I built a test CD (of photos of a recent wedding) and in
testing I read this CD over and over.  I compare the CD with the original
files (via NFS) using diff.  When diff finds a difference, I save copies
of the differing files before they can be flushed from the cache.

I have calculated checksums for all 2048 blocks on the CD, so I can know
if any given block of 2048 bytes came from the CD and if so which file it
came from.  In all cases so far, the 2048 byte error has been a block from
another file, not a random corruption.

I am starting to believe that, under high load, the cd9660 file system
code tells the ata driver to put a 2K block in the wrong spot in memory,
leaving some old junk in the gap in the file being read, and blasting some
other 2K block of memory.  It may not be cd9660 code per se that is wrong,
but a bug in the complex buffer handling code (getblk, getnewbuf, allocbuf,
etc).

Why do I believe it is writing to the wrong memory, rather than any number
of other flaws?  In two runs (out of many), unusual things occurred that
are consistent with memory being overwritten, rather than, say, a 2K block
just not being read at all: In one, an innocent sshd core-dumped (which
is something that has never happened except when running my cd9660 tests),
and in another, a previously OK cached NFS file became corrupted.

Explaining that last case further: I had been running a test script that
would mount the CD, compare files, unmount the CD, and repeat.  This meant
that the NFS copy of the files was read over and over and hence became
memory resident (there being enough space in 1GB of RAM for one copy of
the files, plus my normal programs).  Several tests passed without fault
(hence all the NFS files were cached and correct), when suddenly there
were multiple corruptions; call them file A and file B.  File A was the
usual corruption where a 2K block of another file was unexpectedly present
in the copy read from the CD, but in file B it was the NFS file that was
wrong.  In fact it contained the missing block from file A!  In short, the
fully memory resident NFS file B had been corrupted by reading file A from
the CD.

It's been pretty interesting hunting this problem, but now I'm sort of
stuck.  I believe that some 2K reads from DVDs and CDs end up in the wrong
place in RAM, but I can't find where this happens in the code (it's pretty
hard to work out just by reading it), and I can't rule out the possibility
that there's a hardware error here that I've just never run across before.

So, can anyone suggest any more tests I could try?  Or is there a kind of
hardware fault that could cause this substitution of whole blocks read from
CDs without causing any other problems?

And does anyone know of any commits made anywhere in the 5 years since
4.x split off from 5.x that may be relevant?  Yep.  5 years.  I have
started looking, but there's a fair bit of stuff in there...

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

Re: Simultaneously two versions of one port?

[Pascal Groenen]

Dear Thom,

What I do when something like this happens is:

either, 'cd'  to the port that is causing the problem, devel/py-orbit2, in 
this case and type 'make deinstall', than go back to your original port and 
issue a make again

or, 'cd' to the port that is causing the problem, devel/py-orbit2, in this 
case and type 'make -DFORCE_PKG_REGISTER install clean'. This forces an 
upgrade of the troublesome port, but may result in a double registered port. 
This can be checked by issuing 'pkgdb -F'

Good luck,

Pascal

On Fri, 24 Jun 2005 14:17:29 +0200, Thomas Beer wrote
> Dear All,
> 
> I'm trying to install gdesklets which depends on
> py24-orbit. However, py23-orbit is already
> installed. I googled and tryed various ways
> with portupgrade et al. What to do?
> 
> Thanks Tom
> 
> [EMAIL PROTECTED] gdesklets]# make install
> ===>   gdesklets-0.34.3 depends on file: /usr/local/bin/python - found
> 
> <---snip--->
> 
> ===>  Installing for py24-orbit-2.0.1_1
> ===>   py24-orbit-2.0.1_1 depends on file: /usr/local/bin/python2.4 - found
> ===>   py24-orbit-2.0.1_1 depends on executable: pkg-config - found
> ===>   py24-orbit-2.0.1_1 depends on shared library: glib-2.0.600 - found
> ===>   py24-orbit-2.0.1_1 depends on shared library: IDL-2.0 - found
> ===>   py24-orbit-2.0.1_1 depends on shared library: ORBit-2.0 - found
> ===>   Generating temporary packing list
> ===>  Checking if devel/py-orbit2 already installed
> ===>   An older version of devel/py-orbit2 is already installed
> (py23-orbit-2.0.1_1)
>  You may wish to ``make deinstall'' and install this port again
>  by ``make reinstall'' to upgrade it properly.
>  If you really wish to overwrite the old port of devel/py-orbit2
>  without deleting it first, set the variable "FORCE_PKG_REGISTER"
>  in your environment or the "make install" command line.
> *** Error code 1
> 
> Stop in /usr/ports/devel/py-orbit2.
> *** Error code 1
> 
> Stop in /usr/ports/x11-toolkits/py-gnome2.
> *** Error code 1
> 
> Stop in /usr/ports/deskutils/gdesklets.
> 
> -- 
> --  Which is worse:  ignorance or apathy?
> --  Don't know.  Don't care.
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"

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

Simultaneously two versions of one port?

[Thomas Beer]

Dear All,

I'm trying to install gdesklets which depends on
py24-orbit. However, py23-orbit is already
installed. I googled and tryed various ways
with portupgrade et al. What to do?

Thanks Tom

[EMAIL PROTECTED] gdesklets]# make install
===>   gdesklets-0.34.3 depends on file: /usr/local/bin/python - found

<---snip--->

===>  Installing for py24-orbit-2.0.1_1
===>   py24-orbit-2.0.1_1 depends on file: /usr/local/bin/python2.4 - found
===>   py24-orbit-2.0.1_1 depends on executable: pkg-config - found
===>   py24-orbit-2.0.1_1 depends on shared library: glib-2.0.600 - found
===>   py24-orbit-2.0.1_1 depends on shared library: IDL-2.0 - found
===>   py24-orbit-2.0.1_1 depends on shared library: ORBit-2.0 - found
===>   Generating temporary packing list
===>  Checking if devel/py-orbit2 already installed
===>   An older version of devel/py-orbit2 is already installed
(py23-orbit-2.0.1_1)
 You may wish to ``make deinstall'' and install this port again
 by ``make reinstall'' to upgrade it properly.
 If you really wish to overwrite the old port of devel/py-orbit2
 without deleting it first, set the variable "FORCE_PKG_REGISTER"
 in your environment or the "make install" command line.
*** Error code 1

Stop in /usr/ports/devel/py-orbit2.
*** Error code 1

Stop in /usr/ports/x11-toolkits/py-gnome2.
*** Error code 1

Stop in /usr/ports/deskutils/gdesklets.

-- 
--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Portupgrade in Xfree86 pkg failed

[Warren]

On Fri, 24 Jun 2005 9:11 pm, Daniel O'Connor wrote:
> On Fri, 24 Jun 2005 20:35, Warren wrote:
> > ln
> > -s
> > /usr/ports/graphics/xfree86-dri/work/xc/programs/Xserver/hw/xfree86/os-su
> >pp ort/linux/drm/xf86drmRandom.c xf86drmRandom.c
> > rm -f xf86drmSL.c
> > ln
> > -s
> > /usr/ports/graphics/xfree86-dri/work/xc/programs/Xserver/hw/xfree86/os-su
> >pp ort/linux/drm/xf86drmSL.c xf86drmSL.c
> > make: don't know how to make /drm.h. Stop
> > *** Error code 2
> >
> > Stop in /usr/ports/graphics/xfree86-dri/work/xc/lib/GL.
> > *** Error code 1
> >
> > Stop in /usr/ports/graphics/xfree86-dri.
>
> What commanad did you run?

portupgrade -aDk -m BATCH=yes
> What version of FreeBSD are you running?
5.4-STABLE
> When did you last cvsup your ports tree?
Just before doing PortUpgrade before sending the 1st email
> Did you read /usr/ports/UPDATING?
cant say as i did.

-- 
Yours Sincerely
Shinjii
http://www.shinji.nq.nu
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Portupgrade in Xfree86 pkg failed

[Daniel O'Connor]

On Fri, 24 Jun 2005 20:35, Warren wrote:
> ln
> -s
> /usr/ports/graphics/xfree86-dri/work/xc/programs/Xserver/hw/xfree86/os-supp
>ort/linux/drm/xf86drmRandom.c xf86drmRandom.c
> rm -f xf86drmSL.c
> ln
> -s
> /usr/ports/graphics/xfree86-dri/work/xc/programs/Xserver/hw/xfree86/os-supp
>ort/linux/drm/xf86drmSL.c xf86drmSL.c
> make: don't know how to make /drm.h. Stop
> *** Error code 2
>
> Stop in /usr/ports/graphics/xfree86-dri/work/xc/lib/GL.
> *** Error code 1
>
> Stop in /usr/ports/graphics/xfree86-dri.

What commanad did you run?
What version of FreeBSD are you running?
When did you last cvsup your ports tree?
Did you read /usr/ports/UPDATING?

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C


pgpJv9uMlTlvs.pgp
Description: PGP signature

Lock Order Reversal #66

[Marc Olzheim]

This time I didn't get a LOR, but:

kdb_backtrace(0,1,c07328e8,c0732780,c0700d3c) at 0xc053f7e1 = kdb_backtrace+0x29
witness_checkorder(c6c33900,9,c06ce108,3d3) at 0xc0549180 = 
witness_checkorder+0x544
_mtx_lock_flags(c6c33900,0,c06ce108,3d3,0) at 0xc052184b = _mtx_lock_flags+0x5b
in_pcblookup_local(c0757820,0,7eca,1) at 0xc059c17b = in_pcblookup_local+0xbf
in_pcbbind_setup(cc78b708,0,cc78b740,cc78b722,c634e800) at 0xc059b5ea = 
in_pcbbind_setup+0x52a
in_pcbbind(cc78b708,0,c634e800,c8345534,1) at 0xc059b07a = in_pcbbind+0xce
tcp_usr_listen(c68f4dec,c5c96c00) at 0xc05b4f59 = tcp_usr_listen+0xad
solisten(c68f4dec,1,c5c96c00,cadb6dd0,0) at 0xc055efd8 = solisten+0x18
listen(c5c96c00,ebae4d04,2,4,213) at 0xc05641d0 = listen+0x5c
syscall(2f,2f,2f,3,0) at 0xc0682d0b = syscall+0x227
Xint0x80_syscall() at 0xc067260f = Xint0x80_syscall+0x1f
--- syscall (106, FreeBSD ELF32, listen), eip = 0x280e8f7b, esp = 0xbfbfeb0c, 
ebp = 0xbfbfeb68 ---


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0xee440140
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc055a986
stack pointer   = 0x10:0xec45f9e8
frame pointer   = 0x10:0xec45f9f0
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 = 29055 (screen)
[thread pid 29055 tid 100828 ]
Stopped at  0xc055a986 = ptcopen+0x56:  movl0xc07067c0 = 
linesw(,%eax,4),%eax
db> 

:-(

kern.ostype: FreeBSD
kern.osrelease: 5.4-STABLE
kern.osrevision: 199506
kern.version: FreeBSD 5.4-STABLE #12: Mon May 30 11:39:53 CEST 2005
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/SE3DEBUG

hw.machine: i386
hw.model: Intel(R) Xeon(TM) CPU 3.06GHz
hw.ncpu: 4
hw.byteorder: 1234
hw.physmem: 4151205888
hw.usermem: 4003508224
hw.pagesize: 4096
hw.floatingpoint: 1
hw.machine_arch: i386
hw.realmem: 4160225280
hw.aac.iosize_max: 65536
hw.ata.ata_dma: 1
hw.ata.wc: 1
hw.ata.atapi_dma: 0
hw.pci.enable_io_modes: 1
hw.pci.do_powerstate: 0
hw.pci.host_mem_start: 2147483648
hw.pci.irq_override_mask: 57080
hw.intr_storm_threshold: 500
hw.availpages: 1013478
hw.bus.devctl_disable: 0
hw.kbd.keymap_restrict_change: 0
hw.syscons.saver.keybonly: 1
hw.syscons.bell: 1
hw.syscons.sc_no_suspend_vtswitch: 0
hw.busdma.total_bpages: 33
hw.busdma.zone0.total_bpages: 1
hw.busdma.zone0.free_bpages: 1
hw.busdma.zone0.reserved_bpages: 0
hw.busdma.zone0.active_bpages: 0
hw.busdma.zone0.total_bounced: 0
hw.busdma.zone0.total_deferred: 0
hw.busdma.zone0.lowaddr: 0x
hw.busdma.zone0.alignment: 4096
hw.busdma.zone0.boundary: 0
hw.busdma.zone1.total_bpages: 32
hw.busdma.zone1.free_bpages: 32
hw.busdma.zone1.reserved_bpages: 0
hw.busdma.zone1.active_bpages: 0
hw.busdma.zone1.total_bounced: 0
hw.busdma.zone1.total_deferred: 0
hw.busdma.zone1.lowaddr: 0x
hw.busdma.zone1.alignment: 2
hw.busdma.zone1.boundary: 65536
hw.clockrate: 3065
hw.instruction_sse: 1
hw.acpi.supported_sleep_state: S1 S4 S5
hw.acpi.power_button_state: S5
hw.acpi.sleep_button_state: S1
hw.acpi.lid_switch_state: NONE
hw.acpi.standby_state: S1
hw.acpi.suspend_state: S3
hw.acpi.sleep_delay: 1
hw.acpi.s4bios: 0
hw.acpi.verbose: 0
hw.acpi.reset_video: 1
hw.acpi.cpu.cx_supported: C1/0
hw.acpi.cpu.cx_lowest: C1
hw.acpi.cpu.cx_usage: 100.00%
hw.em0.debug_info: -1
hw.em0.stats: -1
hw.em0.rx_int_delay: 0
hw.em0.tx_int_delay: 66
hw.em0.rx_abs_int_delay: 66
hw.em0.tx_abs_int_delay: 66
hw.em1.debug_info: -1
hw.em1.stats: -1
hw.em1.rx_int_delay: 0
hw.em1.tx_int_delay: 66
hw.em1.rx_abs_int_delay: 66
hw.em1.tx_abs_int_delay: 66

Marc


pgpUyaY3Y4y3a.pgp
Description: PGP signature

Portupgrade in Xfree86 pkg failed

[Warren]

ln 
-s 
/usr/ports/graphics/xfree86-dri/work/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/xf86drmRandom.c
 
xf86drmRandom.c
rm -f xf86drmSL.c
ln 
-s 
/usr/ports/graphics/xfree86-dri/work/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/xf86drmSL.c
 
xf86drmSL.c
make: don't know how to make /drm.h. Stop
*** Error code 2

Stop in /usr/ports/graphics/xfree86-dri/work/xc/lib/GL.
*** Error code 1

Stop in /usr/ports/graphics/xfree86-dri.

-- 
Yours Sincerely
Shinjii
http://www.shinji.nq.nu
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Winbind NT domain authentication

[Thomas Fazekas]

Hi list,

Sorry for the cros-post, I'm not sure which list is better for
me as I got a question related to samba, configuration, FreeBSD.

I'm trying to configure NT authentication on FreeBSD 5.4 with 
Samba 3.0.12 (installed form the ports collection).
I've folowed the Samba 3 howto I've managed the following :

wbinfo -g returns correctly the domain groups

wbinfo -u returns all the users (including those ones from the domain)

ntlm auth does authenticate the user correctly
ntlm_auth --username=usr1
password:
NT_STATUS_OK: Success (0x0)
and in the winbind log I get :
rpc: trusted_domains
[ 3141]: request interface version
[ 3141]: request location of privileged pipe
[ 3141]: request domain name
[ 3141]: request misc info
[ 3141]: pam auth MYDOMAIN\usr1
rpc_dc_name: Returning DC PASSV_SERV (_the_ip_) for domain MYDOMAIN
IPC$ connections done anonymously
Connecting to host=PASSV_SERV
Connecting to _the_ip_ at port 445

I suspect this means that my samba/winbind configuration is correct.
The trouble is that I still can't login (login or ssh) with usernames
from the domain.
If I try with MYDOMAIN\usr1 I just get an Access Denied.
The worse is that I'm not sure that I'm looking for the logs in the 
right place, the auth.log of messages doesn't show any trace of
winbind beeing called.

My smb.conf :

workgroup = MYDOMAIN
netbios name = MY_BSD
password server = passwd_serv_ip
security = domain
encrypt passwords = yes
#passdb backend = tdbsam guest
server string = MY_BSD Samba Server

# separate domain and username with '\', like DOMAIN\username
winbind separator = \\
# use uids from 1 to 2 for domain users
idmap uid = 1-2
# use gids from 1 to 2 for domain groups
idmap gid = 1-2
# allow enumeration of winbind users and groups
winbind enum users = yes
winbind enum groups = yes
# give winbind users a real shell (only needed if they have telnet access)
template homedir = /home/winnt/%D%U
template shell = /usr/local/bin/bash

My nsswitch.conf

group: compat winbind
group_compat: nis
hosts: files dns winbind
networks: files
passwd: compat winbind
passwd_compat: nis
shells: files

and finally my /etc/pam.d/sshd

# auth
authrequiredpam_nologin.so  no_warn
#auth   sufficient  pam_opie.so no_warn no_fake_prompts
#auth   requisite   pam_opieaccess.so   no_warn allow_local
#auth   sufficient  pam_krb5.so no_warn try_first_pass
#auth   sufficient  pam_ssh.so  no_warn try_first_pass
#auth   requiredpam_unix.so no_warn try_first_pass
#tfa
authsufficient  pam_winbind.so  debug try_first_pass
authsufficient  pam_unix.so no_warn try_first_pass

# account
#accountrequiredpam_krb5.so
account requiredpam_login_access.so
account sufficient  pam_winbind.so  debug
account sufficient  pam_unix.so

# session
#sessionoptionalpam_ssh.so
session requiredpam_permit.so

# password
#password   sufficient  pam_krb5.so no_warn try_first_pass
passwordsufficient  pam_winbind.so  debug try_first_pass
passwordsufficient  pam_unix.so no_warn try_first_pass

I hope this question is not silly but only for NT authentication smbd/nmbd
is not necessary to run, isn't it ? Winbind should do de job.

This is the 2'nd week I keep trying setting this thing up, and one of the most
frustrating experience ever...
Can anybody give me some hints (other then going to a psychiatrist)

Thomas

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

marking ports as 'cleaned' in portaudit.conf ?

[Dick Davies]

I just manually patched up my ruby18 install and tried to tell portaudit that 
the local port is now clean, but it
doesn't want to know:

[EMAIL PROTECTED] rasputnik # portaudit  
Affected package: ruby-1.8.2_3
Type of problem: ruby -- arbitrary command execution on XMLRPC server.
Reference: 


^C
[EMAIL PROTECTED] rasputnik # cat /usr/local/etc/portaudit.conf
portaudit_fixed="594eb447-e398-11d9-a8bd-000cf18bbe54"
[EMAIL PROTECTED] rasputnik # 

what did I miss?

-- 
'Save the cost of installing cable TV by taping current editions of Top Of The 
Pops
and then watching them in fifteen years' time.' -- Top Tips
Rasputin :: Jack of All Trades - Master of Nuns
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"