Re: Freebsd 6.2 and booting from iSCSI

2007-10-05 Thread Kirill Ponomarew
On Fri, Oct 05, 2007 at 12:56:08PM -0600, The Presence wrote:
> I recently deployed a NetAPP S300 device, and I want to be able to load 
> system OS from it.
> 
> I have several HP DL380 G3 systems that I want to be able to boot from iSCSI, 
> but I am not sure how to proceed.  NetAPP states that the adapters I would 
> want to do this are the QLA405x and QLA406x lines.  Since the HP DL380 G3s 
> use PCI-X I need the QLA-4050 or the QLA-4052 adapters.  Unfortunately, 
> QLogic states that they only support Windows, RHEL, and SuSE.
> 
> Firstly, has anyone had any luck booting from any system with FreeBSD.  My 
> main drivers here are:
> 
> 1) I can do a bare-metal restore very simply.
> 2) I can easily change base system by just changing the TOE parameters in 
> BIOS.
> 3) I can have multiple systems have access to the same data without having to 
> have multiple copies of the data, but do this in block mode instead of file 
> mode.
> 
> Secondly, has anyone actually had this work with the HP DL380 G3?  If so what 
> HBA did you use to do it?  Since the QLogic network cards start at around 
> $800 or so, I don't want to make this a trial and error effort, if its 
> avoidable.

I think we don't support QLogic HBAs 4xxx.

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


Re: large RAID volume partition strategy

2007-08-29 Thread Kirill Ponomarew
On Wed, Aug 29, 2007 at 10:07:19AM -0400, Vivek Khera wrote:
> 
> On Aug 17, 2007, at 10:44 PM, Ivan Voras wrote:
> 
>> 
>> fdisk and bsdlabels both have a limit: because of the way they store the
>> data about the disk space they span, they can't store values that
>> reference space > 2 TB. In particular, every partition must start at an
>> offset <= 2 TB, and cannot be larger than 2 TB.
> 
> Thanks.  This is good advice (along with your other note about doing it in 
> the RAID volume manager).  Nearly everyone else decided to jump on the raid 
> level instead and spew forth the "RAID10 is better for database" party 
> line.  Well to you folks: once you have 1Gb cache and a lot of disks, there 
> is not much difference between RAID10 and RAID5 or RAID6 in my testing.
 
What type I/O did you test, random read/writes, sequential writes ?
The performance of RAID group always depends on what software you
run on your RAID group.  If it's database, be prepared for many
random read/writes, hence dd(1) tests would be useless.

> I ended up making 6 RAID volumes across all the disks to maximize spindle 
> counts and strip the data at 16kB.  This seems to work well, and I can 
> assign the other partition as I need later on.
> 
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"

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


Re: problem with pkg_version

2006-02-12 Thread Kirill Ponomarew
On Sun, Feb 12, 2006 at 03:51:50PM +0100, Sebastian Stach wrote:
> When using pkg_version with the -o argument to print the origin
> instead of the package name it doesn't work correct.
> 
> # pkg_version -o
> (output stripped)
> x11/xorg=
> x11/xorg=
> x11/xorg=
> (output stripped)
> 
> The output should be:
> 
> # pkg_version -o
> (output stripped)
> x11/xorg=
> x11/xorg-clients=
> x11/xorg-documents  =
> (output stripped)
> 
> Looking at the code in "/usr/src/usr.sbin/pkg_install/version/perform.c"
> in function "show_version" pkg_version removes everything after the last
> "-" from the origin.

[snip]

Yeah, it seems I broke it in rev. 1.13, sorry for that, the fix will
be committed.

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


Re: xorg-clients conflicts with xterm (patch)

2005-11-22 Thread Kirill Ponomarew
On Wed, Nov 23, 2005 at 12:47:13PM +1100, Mark Andrews wrote:
> 
> > 
> > > $ sh
> > > $ PACKAGES=/home/packages
> > > $ export PACKAGES
> > > $ /usr/local/sbin/pkg_info -I xorg-clients-6.8.2
> > > pkg_info: can't find package 'xorg-clients-6.8.2' installed or in a file!
> > > $ PKG_PATH=/home/packages/All
> > > $ export PKG_PATH
> > > $ /usr/local/sbin/pkg_info -I xorg-clients-6.8.2
> > > xorg-clients-6.8.2  X client programs and related files from X.Org
> > > $ 
> > 
> > We need to clean PKG_PATH from the envirionment when looking
> > for conflicts.
> > 
> > e.g.
> > 
> > found=`${SETENV} PKG_PATH= ${PKG_INFO} -I ${CONFLICTS:C/.+/'&'/} 2>/dev/
> > null | ${AWK} '{print $$1}'`;
> > 
> > Mark
> 
> While we are fixing things the man page for pkg_info needs to be updated.
> PKG_PATH is not mentioned.  It's hard to debug problems without the required
> information.

That's true.  I'll update pkg_info(1) soon.

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


Re: portsdb warning

2005-05-24 Thread Kirill Ponomarew
On Tue, May 24, 2005 at 09:30:54PM +0100, Jayton Garnett wrote:
> Hello list,
> 
> Is this a warning to be concerned about? or to not worry about?
> ---
> jayton# portsdb -Uu
> Updating the ports index ... Generating INDEX.tmp - please 
> wait.."/usr/ports/Mk/bsd.port.mk", line 4847: warning: duplicate script 
> for target "add-plist-post" ignored
> ---

Just ignore it, it's harmless.

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


Re: new base system snmpd

2005-05-24 Thread Kirill Ponomarew
On Tue, May 24, 2005 at 11:45:01AM +0400, Boris Samorodov wrote:
> Hi!
> 
> On Tue, 24 May 2005 11:14:36 +0400 Gleb Smirnoff wrote:
> 
> > On Tue, May 24, 2005 at 09:06:27AM +0200, Patrick M. Hausen wrote:
> > P> > P.S. Default configuration file and startup script have already been
> > P> > committed to RELENG_5.
> > P> 
> > P> Since this is a rather minor but very convenient change - any
> > P> chance it will be committed to RELENG_5_4?
> 
> > No. RELENG_5_4 is a _security_ branch. Only security related fixes are
> > committed into it.
> 
> No. http://www.freebsd.org/releases/5.4R/announce.html: 

RELENG_5_4 was mentioned, not RELENG_5_4_0_RELEASE 

> -
> FreeBSD 5.4 will become an "Errata Branch". In addition to Security
> fixes other well-tested fixes to basic functionality will be committed
> to the RELENG_5_4 branch after the release.
> -
> 
> However, it is neither a "New Features Branch" nor a "New Documents
> Branch".

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


problems with Maestro sound card

2005-05-07 Thread Kirill Ponomarew
Trying to kldload Maestro sound card module (snd_maestro.ko) on
FreeBSD 5.4-RC4 on Toshiba Satellite 4060XCDT fails with:

pcm0:  port 0xfc00-0xfcff irq 11 at device 12.0 on 
pci0
pcm0: agg_rdcodec() RW_DONE timed out.
pcm0: will perform cold reset.
pcm0: agg_rdcodec() RW_DONE timed out.
pcm0: agg_rdcodec() PROGLESS timed out.
pcm0: agg_rdcodec() RW_DONE timed out.
pcm0: agg_wrcodec() PROGLESS timed out.
pcm0: agg_rdcodec() PROGLESS timed out.
pcm0: agg_rdcodec() RW_DONE timed out.
pcm0: agg_wrcodec() PROGLESS timed out.
pcm0: agg_rdcodec() PROGLESS timed out.
pcm0: agg_rdcodec() RW_DONE timed out.
pcm0: agg_wrcodec() PROGLESS timed out.
pcm0: agg_rdcodec() PROGLESS timed out.
pcm0: agg_rdcodec() RW_DONE timed out.
pcm0: agg_wrcodec() PROGLESS timed out.
pcm0: agg_rdcodec() PROGLESS timed out.
pcm0: 
pcm0: agg_rdcodec() PROGLESS timed out.
pcm0: agg_rdcodec() RW_DONE timed out.
pcm0: ac97 codec reports dac not ready
pcm0: agg_wrcodec() PROGLESS timed out.
pcm0: agg_wrcodec() PROGLESS timed out.

The same troubles I got on FreeBSD 5.3-RELEASE.  Any tips and
advices ?  Thanks.

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


Re: 4.11R panics

2005-04-10 Thread Kirill Ponomarew
On Fri, Apr 08, 2005 at 10:14:17AM -0700, Doug White wrote:
> > Fatal trap 12: page fault while in kernel mode
> > fault virtual address   = 0x20202020
> 
> Hm, something ran into a bunch of ASCII spaces..
> 
> Can you jump to frame #6 and print *kbp?  It appears the kernel malloc
> bucket list is corrupted, so I'm curious just how badly that struct is
> spammed.

#0  dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
487 if (dumping++) {
(kgdb) up 6
#6  0xc0193533 in malloc (size=324, type=0xc030d780, flags=9)
at /usr/src/sys/kern/kern_malloc.c:243
243 va = kbp->kb_next;
(kgdb) print *kbp
$1 = {kb_next = 0x20202020 , 
  kb_last = 0xcc8fa000 "", kb_calls = 5704, kb_total = 448, kb_elmpercl = 8, 
  kb_totalfree = 13, kb_highwat = 40, kb_couldfree = 0}

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


4.11R panics

2005-04-06 Thread Kirill Ponomarew
Got today on one of our servers running 4.11-RELEASE:


GNU gdb 4.18 (FreeBSD)
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
IdlePTD at physical address 0x003b9000
initial pcb at physical address 0x0031b5c0
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x20202020
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc0193533
stack pointer   = 0x10:0xef9fbc88
frame pointer   = 0x10:0xef9fbca4
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 = 6866 (man)
interrupt mask  = net tty bio cam 
trap number = 12
panic: page fault

syncing disks... 22 1 1 1 1 1 1 1 7 
done
Uptime: 6h47m18s
twe0: Cannot delete unit. error = 16

dumping to dev #twed/0x20001, offset 8913024
dump 3839 3838 3837 3836 3835 3834 3833 3832 3831 3830 3829 3828 3827 3826 3825 
3824 3823 3822 3821 3820 3819 3818 3817 3816 3815 3814 3813 3812 3811 3810 3809 
3808 3807 3806 3805 3804 3803 3802 3801 3800 3799 3798 3797 3796 3795 3794 3793 
3792 3791 3790 3789 3788 3787 3786 3785 3784 3783 3782 3781 3780 3779 3778 3777 
3776 3775 3774 3773 3772 3771 3770 3769 3768 3767 3766 3765 3764 3763 3762 3761 
3760 3759 3758 3757 3756 3755 3754 3753 3752 3751 3750 3749 3748 3747 3746 3745 
3744 3743 3742 3741 3740 3739 3738 3737 3736 3735 3734 3733 3732 3731 3730 3729 
3728 3727 3726 3725 3724 3723 3722 3721 3720 3719 3718 3717 3716 3715 3714 3713 
3712 3711 3710 3709 3708 3707 3706 3705 3704 3703 3702 3701 3700 3699 3698 3697 
3696 3695 3694 3693 3692 3691 3690 3689 3688 3687 3686 3685 3684 3683 3682 3681 
3680 3679 3678 3677 3676 3675 3674 3673 3672 3671 3670 3669 3668 3667 3666 3665 
3664 3663 3662 3661 3660 3659 3658 3657 3656 3655 3654 3653 3652 3651 3650 3649 
3648 3647 3646 3645 3644 3643 3642 3641 3640 3639 3638 3637 3636 3635 3634 3633 
3632 3631 3630 3629 3628 3627 3626 3625 3624 3623 3622 3621 3620 3619 3618 3617 
3616 3615 3614 3613 3612 3611 3610 3609 3608 3607 3606 3605 3604 3603 3602 3601 
3600 3599 3598 3597 3596 3595 3594 3593 3592 3591 3590 3589 3588 3587 3586 3585 
3584 3583 3582 3581 3580 3579 3578 3577 3576 3575 3574 3573 3572 3571 3570 3569 
3568 3567 3566 3565 3564 3563 3562 3561 3560 3559 3558 3557 3556 3555 3554 3553 
3552 3551 3550 3549 3548 3547 3546 3545 3544 3543 3542 3541 3540 3539 3538 3537 
3536 3535 3534 3533 3532 3531 3530 3529 3528 3527 3526 3525 3524 3523 3522 3521 
3520 3519 3518 3517 3516 3515 3514 3513 3512 3511 3510 3509 3508 3507 3506 3505 
3504 3503 3502 3501 3500 3499 3498 3497 3496 3495 3494 3493 3492 3491 3490 3489 
3488 3487 3486 3485 3484 3483 3482 3481 3480 3479 3478 3477 3476 3475 3474 3473 
3472 3471 3470 3469 3468 3467 3466 3465 3464 3463 3462 3461 3460 3459 3458 3457 
3456 3455 3454 3453 3452 3451 3450 3449 3448 3447 3446 3445 3444 3443 3442 3441 
3440 3439 3438 3437 3436 3435 3434 3433 3432 3431 3430 3429 3428 3427 3426 3425 
3424 3423 3422 3421 3420 3419 3418 3417 3416 3415 3414 3413 3412 3411 3410 3409 
3408 3407 3406 3405 3404 3403 3402 3401 3400 3399 3398 3397 3396 3395 3394 3393 
3392 3391 3390 3389 3388 3387 3386 3385 3384 3383 3382 3381 3380 3379 3378 3377 
3376 3375 3374 3373 3372 3371 3370 3369 3368 3367 3366 3365 3364 3363 3362 3361 
3360 3359 3358 3357 3356 3355 3354 3353 3352 3351 3350 3349 3348 3347 3346 3345 
3344 3343 3342 3341 3340 
---
#0  dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
487 if (dumping++) {
(kgdb) bt full
#0  dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
error = 0
#1  0xc0197d4b in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:316
howto = 256
#2  0xc0198189 in panic (fmt=0xc02ec46c "%s") at 
/usr/src/sys/kern/kern_shutdown.c:595
fmt = 0xc02ec46c "%s"
bootopt = 256
buf = "page fault", '\000' 
#3  0xc02a1203 in trap_fatal (frame=0xef9fbc48, eva=538976288) at 
/usr/src/sys/i386/i386/trap.c:974
frame = (struct trapframe *) 0xef9fbc48
code = 16
type = 12
ss = 16
esp = 0
softseg = {ssd_base = 0, ssd_limit = 1048575, ssd_type = 27, ssd_dpl = 
0, ssd_p = 1, ssd_xx = 14, ssd_xx1 = 0, 
  ssd_def32 = 1, ssd_gran = 1}
#4  0xc02a0eb1 in trap_pfault (frame=0xef9fbc48, usermode=0, eva=538976288) at 
/usr/src/sys/i386/i386/trap.c:867
va = 538976256
vm = (struct vmspace *) 0x0
map = 0xebdf3480
rv = 0
ftype = 1 '\001'
p = (struct proc *) 0xef940f20
#5  0xc02a0a2b in trap (frame={tf_fs = -274792432, tf_es = -94738840

Re: 4.11-RELEASE panics

2005-03-03 Thread Kirill Ponomarew
On Thu, Mar 03, 2005 at 12:19:44PM +0100, Kirill Ponomarew wrote:
> 4.11-R paniced today, trace, dmesg and kernel config are attached.

The same machine paniced again:

GNU gdb 4.18 (FreeBSD)
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
IdlePTD at physical address 0x00335000
initial pcb at physical address 0x002a8740
panicstr: from debugger
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x2aa2
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc0204ce8
stack pointer   = 0x10:0xdfd90b64
frame pointer   = 0x10:0xdfd90b70
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 = 170 (perl)
interrupt mask  = net bio cam 


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x2aa2
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc0204ce8
stack pointer   = 0x10:0xdfd90b64
frame pointer   = 0x10:0xdfd90b70
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= trace trap, interrupt enabled, resume, IOPL = 0
current process = 170 (perl)
interrupt mask  = net bio cam 
panic: from debugger


Fatal trap 3: breakpoint instruction fault while in kernel mode
instruction pointer = 0x8:0xc0222b18
stack pointer   = 0x10:0xdfd90978
frame pointer   = 0x10:0xdfd90980
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, IOPL = 0
current process = 170 (perl)
interrupt mask  = net bio cam 


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x2aa2
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc0204ce8
stack pointer   = 0x10:0xdfd90b64
frame pointer   = 0x10:0xdfd90b70
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= trace trap, interrupt enabled, resume, IOPL = 0
current process = 170 (perl)
interrupt mask  = net bio cam 


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x2aa2
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc0204ce8
stack pointer   = 0x10:0xdfd90b64
frame pointer   = 0x10:0xdfd90b70
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= trace trap, interrupt enabled, resume, IOPL = 0
current process = 170 (perl)
interrupt mask  = net bio cam 


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x2aa2
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc0204ce8
stack pointer   = 0x10:0xdfd90b64
frame pointer   = 0x10:0xdfd90b70
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= trace trap, interrupt enabled, resume, IOPL = 0
current process = 170 (perl)
interrupt mask  = net bio cam 


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x2aa2
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc0204ce8
stack pointer   = 0x10:0xdfd90b64
frame pointer   = 0x10:0xdfd90b70
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= trace trap, interrupt enabled, resume, IOPL = 0
current process = 170 (perl)
interrupt mask  = net bio cam 


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x2aa2
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc0204ce8
stack pointer   = 0x10:0xdfd90b64
frame pointer   = 0x10:0xdfd90b70
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= trace trap, interrupt enabled, resume, IOPL = 0
current process = 170 (perl)
interrupt mask  = net bio cam 


Fatal trap 12: page fault while in kernel mode
fault virt

Re: [HEADS UP] perl symlinks in /usr/bin will be gone

2005-01-30 Thread Kirill Ponomarew
On Sun, Jan 30, 2005 at 12:23:43PM +0100, Mathieu Arnold wrote:
> +-le 30/01/2005 12:19 +0100, Kirill Ponomarew ?crivait :
> | On Sun, Jan 30, 2005 at 09:08:34PM +1000, Mark Sergeant wrote:
> |> > If it's linux tradition to put perl in this path, perl programmers
> |> > should assume another path on FreeBSD, so it isn't an argument for
> |> > the proposed change.
> |> > 
> |> As per the current perl-5.8.6 INSTALL file ...
> |> 
> |> It may seem obvious, but Perl is useful only when users can easily
> |> find it.  It's often a good idea to have both /usr/bin/perl and
> |> /usr/local/bin/perl be symlinks to the actual binary.
> | 
> | /usr/bin and /usr/local/bin are *BOTH* in default $PATH.
> 
> Last time I looked, cron did not have usr/local in it's path.

I meant user enviroments, not cron.

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


Re: [HEADS UP] perl symlinks in /usr/bin will be gone

2005-01-30 Thread Kirill Ponomarew
On Sun, Jan 30, 2005 at 09:11:34PM +1000, Mark Sergeant wrote:
> >find /some/directory -type f -print0 | \
> > xargs -0 perl -pi -e 's,^#! ?/usr(/local)?/bin/perl,#!/usr/bin/env 
> >perl'
> >
> 
> One problem I always had with "env" or equivalents... what happens if 
> someone manages to polute $PATH with a perl that is not infact perl but 
> something else, I remember being taught "Always specify full paths to 
> binaries, especially in cron".

/usr/local/bin is default path in $PATH on FreeBSD, so problems like
"what if it isn't perl, but something else" should be resolved by
users/admins.

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


Re: [HEADS UP] perl symlinks in /usr/bin will be gone

2005-01-30 Thread Kirill Ponomarew
On Sun, Jan 30, 2005 at 11:47:32AM +0100, Holger Kipp wrote:
> > I'm fine with this plan for 6-CURRENT.  For 5-STABLE, it's a major
> > user-visible change, and that is something that we promised to avoid
> > with stable branches.
> 
> It violates POLA on 5-STABLE, and it will violate POLA on 6-CURRENT,
> especially as most perl programmers assume /usr/bin/perl to be the
> correct path. 

If it's linux tradition to put perl in this path, perl programmers
should assume another path on FreeBSD, so it isn't an argument for
the proposed change.

> We had enough good arguments against this change already, so imho
> the correct thing to do is do just what Kris asked for: remove the
> _dangling_ symlinks.

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


Re: [HEADS UP] perl symlinks in /usr/bin will be gone

2005-01-29 Thread Kirill Ponomarew
On Sat, Jan 29, 2005 at 09:24:25PM +0100, Anton Berezin wrote:
> Unless I hear too many cries "don't do that" (with justification), I
> plan to not create any perl symlinks in /usr/bin in the forthcoming
> upgrade of both lang/perl5.8 (to 5.8.6) and lang/perl5 (to 5.6.2).  This
> will ONLY be true for FreeBSD 5.X and FreeBSD CURRENT;  the existing
> pollution of /usr/bin will still be performed for older versions of
> FreeBSD, if requested via use.perl script.
> 
> In practical terms this will mean a one-time sweep of your scripts in
> order to convert them, in a typical case, from #! /usr/bin/perl to
> #! /usr/local/bin/perl.
> 
> CORRECT perl-dependant ports should not be affected.
> 
> In order to keep pkg-install simple, no old symlink chasing and removal
> will be done, although the detailed instructions will be posted in
> ports/UPDATING and in pkg-message for the ports.

Anyway do not forget about mail to portmgr with the patch
's|#!/usr/bin/perl|#!/usr/bin/env perl' for Tools/* stuff before
committing these changes.

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


Re: ruby and portupgrade

2005-01-18 Thread Kirill Ponomarew
On Tue, Jan 18, 2005 at 03:01:46AM -0800, whitevamp wrote:
> i am trying to do a portupgrade and after it running for 7 hrs and not doing
> anything it quits with this error message.
> 
> black-buity# portupgrade -aRrcCv
>
> --->  Reading default options: -v -D -l /var/tmp/portupgrade.results -L
> /var/tmp/portupgrade-%s::%s.log
> --->  Session started at: Sat, 15 Jan 2005 12:07:25 -0800
> [Updating the pkgdb  in /var/db/pkg ... - 110 packages
> found (-0 +23) ... done]
> --->  Session ended at: Sat, 15 Jan 2005 19:13:25 -0800 (consumed 07:05:59)
> /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:323:in `deorigin': cannot convert
> nil into String (PkgDB::DBError)
>from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:916:in `tsort_build'
>from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:915:in `each'
>from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:915:in `tsort_build'
>from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:907:in `each'
>from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:907:in `tsort_build'
>from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:929:in `sort_build'
>from /usr/local/lib/ruby/site_ruby/1.8/pkgdb.rb:933:in `sort_build!'
>from /usr/local/sbin/portupgrade:674:in `main'
>from /usr/local/sbin/portupgrade:207:in `initialize'
>from /usr/local/sbin/portupgrade:207:in `new'
>from /usr/local/sbin/portupgrade:207:in `main'
>from /usr/local/sbin/portupgrade:1845
> black-buity#
> 
> black-buity# ruby --version
> ruby 1.8.2 (2004-07-29) [i386-freebsd5]
> black-buity# uname -a
> FreeBSD black-buity.vampextream.com 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Fri
> Dec 10 14:50:33 PST 2004
> [EMAIL PROTECTED]:/usr/src/sys/i386/compile/VAMPEXTREAM  i386
> black-buity#
> 
> i have read UPDATEING and didnt find any thing on 1.8 just updateing ruby
> from 1.6 to 1.8 ..
> so my quistions are
> 
> 1. what would be causeing this??
> 2. how do i fix this?
> 
> and thanks inadvance for any help on this issue/ error message 

Database seems to be corrupted, rebuild it with 'pkgdb -fu'

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


Re: Qt33 Build Problem

2005-01-17 Thread Kirill Ponomarew
On Mon, Jan 17, 2005 at 03:23:36PM -0500, Tom Huppi wrote:
> There is a reference to it in the 5.3 Errata (at least):
> 
>  http://www.freebsd.org/releases/5.3R/errata.html
> 
> ...but I would have had a bit more trouble finding it had I not
> known to look for the string 'libc_r'.
> 
> I worked at re-building Qt33 for quite some time, but
> 'libqt-mt.so' still retains a reference to 'libc_r'.  If there are
> any common reasons why this may be, I'de be interested to know of
> them.  I got rid of all other references (except one other library
> associated also with Qt33), but couldn't nuke that one so I
> resorted to the 'libmap.conf' hack which I would have preferred
> not to do.

In most cases there are dependencies which are still linked to
libc_r, so check them first.

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


Re: Qt33 Build Problem

2005-01-17 Thread Kirill Ponomarew
On Mon, Jan 17, 2005 at 08:59:58AM -0600, Hamilton, Kent wrote:
> I have two systems that I'm having problems building qt33 on.  Both are
> RELENG_5_3 with perl-threaded-5.8.5 on dual processor Dell PowerEdge
> systems.
>  
> I'm getting the same error building on both systems. I'm trying to build
> with all the config options turned on (CUPS, NAS, OpenGL, XFt). The uic
> that gets built dies with a thread error so I can't finish the build. 
>  
> The error is:
> Fatal error 'Spinlock called when not threaded.' at line 83 in file
> /usr/src/lib/libpthread/thread/thr_spinlock.c (errno = 0)
> Abort (code dumped)
> kernel: pid 14119 (uic), uid 0: existed on signal 6 (core dumped)
>  
> I'd really appreciate any suggestions. 
> 
> I don't subscribe to freebsd-ports so if you are answering on that list
> please add me to the message.

You can rebuild all your ports, or use libmap.conf(5), or even
better, search the archives to understand this problem.

We should really put it into FAQ, if it's not there.

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


panic on FreeBSD-4.9 RELEASE

2003-12-04 Thread Kirill Ponomarew
Hi,

Could somebody investigate it ?

-Kirill
IdlePTD at phsyical address 0x0037e000
initial pcb at physical address 0x002c1200
panicstr: softdep_setup_inomapdep: found inode
panic messages:
---
panic: softdep_setup_inomapdep: found inode

syncing disks... 35 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 
giving up on 30 buffers
Uptime: 9d3h36m21s

(kgdb)  where full
#0  dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
error = 0
#1  0xc015c827 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:316
howto = 256
#2  0xc015cc65 in panic (
fmt=0xc0266f20 "softdep_setup_inomapdep: found inode")
at /usr/src/sys/kern/kern_shutdown.c:595
fmt = 0xc0266f20 "softdep_setup_inomapdep: found inode"
bootopt = 256
buf = "softdep_setup_inomapdep: found inode", '\000' 
#3  0xc01beca6 in softdep_setup_inomapdep (bp=0xcf964514, ip=0xc4fbb400, 
newinum=7321924) at /usr/src/sys/ufs/ffs/ffs_softdep.c:1194
bp = (struct buf *) 0xcf964514
ip = (struct inode *) 0xc4fbb400
newinum = 7321924
inodedep = (struct inodedep *) 0xc3fd7e80
bmsafemap = (struct bmsafemap *) 0x0
#4  0xc01bb55c in ffs_nodealloccg (ip=0xc4fbb400, cg=325, ipref=7324371, 
mode=33152) at /usr/src/sys/ufs/ffs/ffs_alloc.c:1373
ipref = 324
fs = (struct fs *) 0xc329b800
cgp = (struct cg *) 0xd229c000
bp = (struct buf *) 0xcf964514
inosused = (
u_int8_t *) 0xd229c2be 'Ъ' , "[EMAIL 
PROTECTED]/2\177╬©чЩ_ЪmЪШЧЩЪШъЪъМЪщВВшЪЪ©╜ЪВЪЪЪС", 'Ъ' , 
"ЧЪ\177ЪЪЪ\177╤ЪЪУЪО", 'Ъ' , 
"ЗЪЪЪ╠Эy©\1779ЧЪЪЪВ\213}Н\237Б©ЪЪЧ©Ъ©©ЪЪЩЪВ\177ЪЪwЪЪ|ОВШЪЪЩЪВЪ"...
error = 0
start = 40
len = 324
loc = 0
map = 0
i = 0
#5  0xc01ba66f in ffs_hashalloc (ip=0xc4fbb400, cg=325, pref=7324371, 
size=33152, allocator=0xc01bb360 )
at /usr/src/sys/ufs/ffs/ffs_alloc.c:863
cg = 325
fs = (struct fs *) 0xc329b800
result = 0
i = -1020676096
icg = 325
#6  0xc01ba104 in ffs_valloc (pvp=0xe489a680, mode=33152, cred=0xc3fe3180, 
vpp=0xe4382ca0) at /usr/src/sys/ufs/ffs/ffs_alloc.c:607
cred = (struct ucred *) 0x0
pip = (struct inode *) 0xc4fbb400
fs = (struct fs *) 0xc329b800
ip = (struct inode *) 0xc4fbb400
ino = 325
ipref = 0
cg = 325
error = -990137344
#7  0xc01cd16f in ufs_makeinode (mode=33152, dvp=0xe489a680, vpp=0xe4382edc, 
cnp=0xe4382ef0) at /usr/src/sys/ufs/ufs/ufs_vnops.c:2069
mode = 33152
ip = (struct inode *) 0xe4382e10
pdir = (struct inode *) 0xc4fbb400
newdir = {d_ino = 32, d_reclen = 0, d_type = 0 '\000', 
  d_namlen = 0 '\000', 
  d_name = "L\000\000\000\002\000\000\000\000\002\000\000\177╥\000\000 
\223\216о╛\000\000\000L\000\000\000 
_(ю\200╕\211Д\200\000\000\000\2001ЧцЮЕ5ДХ,8Дeт\034ю\030-8Д,-8Д2p\030ю\030-8Д\200╕\211Д5╛оЦП.8ДюWгДЮЕ5ДLю\000\000э.8Д\b\000\000\000,-8Д═](ю\200╕\211Дэ.8ДП.8ДЮЕ5Д8-8Дeт\034юp-8Д\200-8Д\235\237\030юp-8Д\000н\224БП.8Д\000╛оЦЮЕ5Д\000\000\000\000ЧЪЪЪ\000\000\000\000\000\000\000\000\b\000\000\000
 \000\000\000ю#\003Д`](ю"...}
tvp = (struct vnode *) 0x0
error = -466080260
#8  0xc01cabb8 in ufs_create (ap=0xe4382dfc)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:195
ap = (struct vop_create_args *) 0xe4382dfc
error = 0
#9  0xc01cd465 in ufs_vnoperate (ap=0xe4382dfc)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2376
ap = (struct vop_generic_args *) 0x0
#10 0xc019243c in vn_open (ndp=0xe4382ec8, fmode=1539, cmode=384)
at vnode_if.h:106
a = {a_desc = 0xc0285de0, a_dvp = 0xe489a680, a_vpp = 0xe4382edc, 
  a_cnp = 0xe4382ef0, a_vap = 0xe4382e10}
dvp = (struct vnode *) 0x0
vap = (struct vattr *) 0xe4382e10
cmode = 0
vp = (struct vnode *) 0xe435e5e0
p = (struct proc *) 0xe435e5e0
cred = (struct ucred *) 0xc3fe3180
vat = {va_type = VREG, va_mode = 384, va_nlink = -1, 
  va_uid = 4294967295, va_gid = 4294967295, va_fsid = 4294967295, 
  va_fileid = -1, va_size = 18446744073709551615, va_blocksize = -1, 
  va_atime = {tv_sec = -1, tv_nsec = -1}, va_mtime = {tv_sec = -1, 
tv_nsec = -1}, va_ctime = {tv_sec = -1, tv_nsec = -1}, 
  va_gen = 4294967295, va_flags = 4294967295, va_rdev = 4294967295, 
  va_bytes = 18446744073709551615, va_filerev = 0, va_vaflags = 0, 
  va_spare = 0}
vap = (struct vattr *) 0xe4382e10
mode = -466080144
error = -466080260
#11 0xc018e638 in open (p=0xe435e5e0, uap=0xe4382f80)
at /usr/src/sys/kern/vfs_syscalls.c:1029
uap = (struct open_args *) 0xe4382f80
fdp = (struct filedesc *) 0xc4bc4200
fp = (struct file *) 0xc4732940
vp = (struct vnode *) 0xe4382f80
cmode = 0
flags = 1539
oflags = 0
nfp = (struct file *) 0xc4732940
type = 0
indx = 12
error = 0
lf = {l_start = 0, l_l

gdb coredumps

2003-08-01 Thread Kirill Ponomarew
Hi,

After kernel panic I couldn't get gdb work properly.

msi$ uname -sr
FreeBSD 4.7-RELEASE

msi$ gdb -k /usr/src/sys/compile/MSINW/kernel.debug vmcore.0 
GNU gdb 4.18 (FreeBSD)
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...Deprecated
bfd_read called at /usr/src/gnu/usr.bin/binutil
s/gdb/../../../../contrib/gdb/gdb/dbxread.c line 2627 in elfstab_build_psymtabs
Deprecated bfd_read called at 
/usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c
line 933
 in fill_symbuf

IdlePTD at phsyical address 0x65746e49
initial pcb at physical address 0x002cff20
panic messages:
---
dmesg: cannot read PTD
---
#0  0x0 in ?? ()
(kgdb) where
#0  0x0 in ?? ()
Segmentation fault (core dumped)

-Kirill
Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 4.7-RELEASE #0: Thu Mar  6 12:27:11 CET 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/MSINW
Timecounter "i8254"  frequency 1193182 Hz
CPU: AMD Athlon(TM) XP 2400+ (2000.08-MHz 686-class CPU)
  Origin = "AuthenticAMD"  Id = 0x681  Stepping = 1
  
Features=0x383fbff
  AMD Features=0xc040
real memory  = 1073725440 (1048560K bytes)
avail memory = 1041793024 (1017376K bytes)
Preloaded elf kernel "kernel" at 0xc034a000.
Pentium Pro MTRR support enabled
Using $PIR table, 10 entries at 0xc00f1bf0
npx0:  on motherboard
npx0: INT 16 interface
pcib0:  on motherboard
pci0:  on pcib0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
pci1:  at 0.0 irq 11
pci0:  (vendor=0x14e4, dev=0x4401) at 9.0 irq 12
twe0: <3ware Storage Controller> port 0xb800-0xb80f mem 
0xf180-0xf1ff,0xf200-0xf20f irq 15 at device 11.0 on pci0
twe0: 8 ports, Firmware FE7X 1.05.00.036, BIOS BE7X 1.08.00.044
fxp0:  port 0xb400-0xb43f mem 
0xf080-0xf08f,0xf100-0xf1000fff irq 11 at device 13.0 on pci0
fxp0: Ethernet address 00:02:b3:4c:0b:66
inphy0:  on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
fxp1:  port 0xb000-0xb03f mem 
0xef80-0xef81,0xf000-0xffff irq 10 at device 14.0 on pci0
fxp1: Ethernet address 00:02:b3:4c:32:12
inphy1:  on miibus1
inphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ahc0:  port 0xa800-0xa8ff mem 
0xef00-0xef000fff irq 12 at device 15.0 on pci0
aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
uhci0:  port 0xa400-0xa41f irq 14 at device 16.0 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 0xa000-0xa01f irq 14 at device 16.1 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
uhci2:  port 0x9800-0x981f irq 14 at device 16.2 on pci0
usb2:  on uhci2
usb2: USB revision 1.0
uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
pci0:  at 16.3 irq 14
isab0:  at device 17.0 on pci0
isa0:  on isab0
atapci0:  at device 17.1 on pci0
atapci0: ATA channel disabled by BIOS
orm0:  at iomem 0xc-0xc,0xd-0xd17ff,0xd4000-0xd4fff on isa0
fdc0:  at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0
ata1 at port 0x170-0x177,0x376 irq 15 on isa0
atkbdc0:  at port 0x60,0x64 on isa0
atkbd0:  flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
sc0:  at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
ppc0:  at port 0x378-0x37f irq 7 on isa0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
ppbus0: IEEE1284 device found /NIBBLE/ECP
Probing for PnP devices on ppbus0:
ppbus0:  PJL,MLC,PCL
lpt0:  on ppbus0
lpt0: Interrupt-driven port
ppi0:  on ppbus0
plip0:  on ppbus0
ncp_load: [210-213]
Waiting 3 seconds for SCSI devices to settle
twed0:  on twe0
twed0: 117799MB (241252672 sectors)
twed1:  on twe0
twed1: 235598MB (482505216 sectors)
twe0: command interrupt
sa0 at ahc0 bus 0 target 4 lun 0
sa0:  Removable Sequential Access SCSI-2 device 
sa0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit)
Mounting root from ufs:/dev/twed0s1a
WARNING: / was not properly dismounted
#
# GENERIC -- Generic kernel configuration file for FreeBSD/i386
#
# For more information on this file, please read the handbook section on
# Kernel Configuration Files:
#
#http://www.FreeBSD.org/handbo

Re: "unknown option "TCP_RESTRICT_RST" ?"

2001-06-10 Thread Kirill Ponomarew

On Sun, Jun 10, 2001 at 09:05:26PM +0100, Nuno Teixeira wrote:
> Hello to all,
> 
> I allways used TCP_RESTRICT_RST on my firewall/kernel configuration. I'm
> tracking STABLE and the last build was on 2001-06-06. Today, 2001-06-10,
> when I'm make buildkernel I got the error: ""unknown option
> "TCP_RESTRICT_RST" ".
> 
> Does this option has been deprecated?

[from cvs-all]

Date: Sat, 9 Jun 2001 09:18:15 -0700 (PDT)
From: Dag-Erling Smorgrav <[EMAIL PROTECTED]>
Log: MFC: Nuke the TCP_RESTRICT_RST option.

[/from cvs-all]

-- 
Kirill Ponomarew

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message



Re: gnome 1.2 install

2000-10-19 Thread Kirill Ponomarew

Hi Ade,

Chris BeHanna has advised me to add "#include " before "#include
" and it did work.

Thanks

On Thu, 19 Oct 2000, Ade Lovett wrote:

>On Thu, Oct 19, 2000 at 09:44:51AM -0500, Ade Lovett wrote:
>> Find the port that installed /usr/local/include/malloc.h and delete it
>> with extreme prejudice.
>
>It's devel/libmalloc, which I've just marked as BROKEN so this issue
>won't come up again until either the port is fixed or just plain
>deleted.
>
>   pkg_delete libmalloc-1.18
>
>and start over, and you'll be fine.
>
>Thanks to Sean O'Connell <[EMAIL PROTECTED]> for kicking me hard
>enough to realise I could do this myself :)
>
>-aDe
>
>

-- 
Kirill Ponomarew





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message